Please Send Suggestions for Improvement to [email protected], GovProjects;
description
Transcript of Please Send Suggestions for Improvement to [email protected], GovProjects;
Slide 1EHR SD RM - EHR Way Forward … Future State Reference Architecture
Please Send Suggestions for Improvement [email protected], GovProjects;
[email protected], EHR, SOA, ArB
EHR SD RM SAIF Alpha Project
“EHR System-Design Reference-Model”
Constructing a Future StateEHR Reference Architecture
EHR Way Ahead Business Architecture
From HL7, HITSP and ARRA Artifacts
For presentation at HL7 Sydney Workgroup Meeting, 11 Jan 2011
Practical Guide: http://hssp.wikispaces.com/PracticalGuide EHR SD RM info: http://hssp.wikispaces.com/Reference+Architecture
Slide 2EHR SD RM - EHR Way Forward … Future State Reference Architecture
Objective of this Presentation is toDiscuss the Following Next Step Questions …
How should the EHR-SD RM be represented?– Hypothesis: XML DB, DITTA documentation
Use cases for EHR-SD RM use?– Ad Hoc Reporting needs– Web based tools needs– Profile needs (e.g., domain adaption vs. local use adaption)
How to ballot the EHR-SD RM?– Part of EHR-S FM R2.1– Independent of EHR-S FM
Who will Participate?– Information Model sub-project– XML/XSL Technical expert– Subject Matter Experts (e.g., diabetes, Immunization, etc.)
Slide 3EHR SD RM - EHR Way Forward … Future State Reference Architecture
EHR SD RM Milestones
2008 2009 2010
Healthcare SOA Reference
Architecture
(H-SOA-RA)
EHR SD RM Immunization &
Response Management
(IRM) Prototype
May
HSSP Practical Guide for SOA in
Healthcare Volume II: Immunization
Case StudyDSTU is Draft Standard for Trial Use (ANSI standards development)
EHR-S CI-IM is EHR System Computationally Independent Information Model
HF&EA is Harmonization Framework and Exchange Architecture
2011
May
EHR-S FM R2.0
With
EHR SD RM Informative Reference
Sep
EHR SD RM Integrated into
EHR-S FM
R2.1
Slide 4EHR SD RM - EHR Way Forward … Future State Reference Architecture
2008 Healthcare SOA FrameworkBased on HL7 EHR System Functional Model & Thomas Erl’s SOA Layers HL7 System Functions Direct Care Supportive Information
InfrastructureOther
Business Process
Value Chains
CompositeServices Federated Composition (e.g., Choreograph or Orchestration) Within and Across Business Areas
Core BusinessServices
Functional Areas + Focal Classes
Functional Areas + Focal Classes
Functional Areas + Focal Classes
Functional Areas + Focal Classes
EntityServices
Information Management
Information Management
Information Management
Information Reporting and Management
Agnostic Services C r o s s T e c h n I c a l “Common S e r v I c e s”(e.g., Security, Privacy, Auditing, Logging…)
ApplicationServices
Ambulatory Care Systems,In Patient Care Systems
Logistics SystemsFinancial Systems
Decision Support Systems
Data MartsRepositories
Business Objects
ImplementationProfiles
Integrated Healthcare Enterprise (IHE) Profiles
Analysis Profiles Communications Profiles/Stacks
Implementation Profiles
4
Slide 5EHR SD RM - EHR Way Forward … Future State Reference Architecture
HL7 EHR System Functional Model (EHR-S)> 160 System Functions in 4 level categorization
(separate spreadsheet available for full enumeration)
NOTE: “Other” Category - The EHR-S model does NOT include Electronic Resource Planning (ERP) / Logistics and Financial components, which are needed for completeness of a Health IT Enterprise.
Other O-1 Electronic Resource Planning (ERP)
O-2 Finances
O-3 Other
Sys
tem
Fu
nct
ion
s
EHR-S FM functions can be grouped into Service Components … aka Capabilities
(e.g., Lab Order Capability, which
does eligibility and authorization
function as well as lab order function).
Slide 6EHR SD RM - EHR Way Forward … Future State Reference Architecture
SUPPLY CHAIN (ORDER/CHARGE)
ANATOMY OF AN ANCILLARY SYSTEM
AUTHORIZATION
DOCUMENT
RECORDS MANAGEMENT
DECISION SUPPORT
PERFORMANCE
DATA MANAGEMENT
SCHEDULING
IDENTITY
TERMINOLOGY
LABORATORY RADIOLOGY PHARMACY CARDIOLOGY OT/PT/SPEECH
s
CO
RE
B
US
INE
SS
S
ER
VIC
ES
6
Capabilities, which orchestrate Core Business Services
HL7 EHR_S-Based Functional Architecture/Services Analysis
Security
Unique ID, Registry, and DirectorTerminology
Information and Records Management
Interoperability
ETCSupport Knowledge Access
Support Clinical Communication Clinical Workflow TaskingClinical Decision Support
Record Patient Specific Instructions Documentation of Care, Measurement, and Results
Orders and Referral Management Care Plans, Treatment Plans, Guidelines, and Protocols
Management of AssessmentSummary Lists
Preferences, Directives, Consents, and Authorizations Manage Patient History
Record Management
Manage Business RulesETC
Pri
mar
y C
are
Cri
tica
l/Em
erg
ency
Car
e
Den
tal
No
n-S
urg
ical
Sp
ecia
lty
Car
e
Lab
ora
tory
Nu
rsin
g
Ph
arm
acy
Po
pu
lati
on
Hea
lth
Beh
avio
ral H
ealt
h
ET
C.
Cro
ss-C
utt
ing
Dir
ect
Car
e/S
up
po
rt F
un
ctio
ns
Infra
stru
ctur
e
Func
tions
Lines of Business
InfrastructureServices•Security•Policy•Records Management•Audit•Terminology•Registry•Workflow•Business Rules•etc
Core ClinicalServices•Entity Identification•Resource Location and Updating Services•Decision Support•Orders Management•Scheduling•Image Management•Etc.
7
EHR System Design Reference Model (EHR SD RM) Supporting Requirements/ Architecture Development Cycle
EHR System Design Reference Model
EHR System Design Reference Model
RequirementsAnalysis
RequirementsAnalysis
Stakeholder Requirements
Definition
Stakeholder Requirements
DefinitionRequirements Loop
Verification & ValidationLoop
SpecificationsLoop
PROCESS INPUTS-Required Capabilities-Environments-Constraints
PROCESS OUTPUTS-System Architecture, -Test Specifications-Configuration Management Baselines
Capabilities, Functions,Information and
Information Exchanges
Conformance CriteriaInterface
Specifications
TestLoop
Functions – Dependencies
Test Specifications
Test Specifications
Conformance is a recognition of formal
testing, that prove that a system provides 100% support for a
given standard.
Architectural Specifications
Architectural Specifications
8
EHR SD RM Supporting Requirements/ Architecture Development Cycle
Stakeholder Requirements
– What is the system supposed to do?
Under what conditions will the products be used?
– Where will the products of the system be used?
– How often? How long?
– Who will use the products of the system?
Requirements Analysis (“HOW?” using “Action Verbs”)
– Analyze functions and Services
Decompose higher level functions to lower level functions
Allocate performance requirements to the functions
Architecture Design (Which hardware/ software elements)
– Define the physical architecture Each part must perform at least one function
Some parts may perform more than one function
Test Specifications
– How Requirements-Specifications are validated
Requirements Loop Ensure all requirements are covered by at least one
function Ensure all functions are justified by a valid requirement
(no unnecessary duplication)
Design Loop Ensure all functions are covered by at least one
hardware or software element Ensure all elements of physical architecture are
justified by a valid functional requirement (no unnecessary duplication)
Verification & Validation (V&V) Loop
Each requirement must be verifiable that the solution meets requirements and validated that it meets the user’s needs and expectations.
V&V can be accomplished by: Inspection, Analysis, Demonstration, Test
Test Loop Ensure all information is covered by test specifications Ensure all interfaces are covered by test specifications
9
Slide 10EHR SD RM - EHR Way Forward … Future State Reference Architecture
2010 SAIF Alpha ProjectThe Practical Guide For SOA in Healthcare Volume II
Immunization Management Case Study
The Practical Guide for SOA in Healthcare Volume II presents a case study, which adds an Immunization Management Capability (IMC) to Volume I’s SampleHealth’s Service Oriented Architecture (SOA). We used the TOGAF Architecture Development Method (ADM) and HL7 Service Aware Interoperability Framework (SAIF) Enterprise Conformance and Compliance Framework (ECCF). Volume II demonstrates the use of HL7’s EHR System Design Reference Model (EHR-SD RM) linked artifacts (e.g., EHR System Functional Model, FHIM, HITSP, HITEC, HSSP, IHE, NIEM, etc) to provide an initial architectural baseline suitable for an EHR related SOA acquisition, development or certification project. We conclude with lessons learned.
Healthcare Services Specification Project (HSSP) Practical Guide: http://hssp.wikispaces.com/PracticalGuide
11
SAIF ECCF examples
Slide 12
EHR-S FM
BehavioralViewpoints
Conceptual Independent ModelPlatform Independent Model
Platform Specific Model
Information ViewpointsConceptual Independent Model
Platform Independent ModelPlatform Specific Model
Engineering/Technical Viewpoints
Conceptual Independent ModelPlatform Independent Model
Platform Specific Model
Example of SAIF Traceability Using HL7 EHR-S FM
FMIDs
FMIDsFMIDs
FMIDs
Business ViewpointsConceptual Independent Model
Platform Independent ModelPlatform Specific Model
Key to Traceability Traceability is achieved by using Functional Model Identifiers (FMIDs) as attributes to all SAIF artifacts.
This is analogous to a library system, which uses Dewey decimal numbers as book identifiers.
Investment Portfolio Line Items
Planning budget for new, improved or sunset capabilities
FMIDs
FMIDs Product Line Inventory
Inventory of systems and their capabilities and Functions
Slide 13EHR SD RM - EHR Way Forward … Future State Reference Architecture
Immunization Management ECCF Specification Stack
SubjectSpecification
EnterpriseViewpoint
“Why”Policy
InformationViewpoint
“What”Content
ComputationalViewpoint
“How”Behavior
EngineeringViewpoint
“Where”Implementation
CIM(Conceptual)
Inventory ofo Use Caseso Capabilities-Services o Requirementso Contracts o Stakeholders
Business Scope Business Vision Business Objectives Policy & Regulations
Inventory of o Domain Entitieso Roles, o Activities, o Associations.
Information Modelso Conceptualo Domain
Inventories ofo Capabilities-Components,o Functions-Services.
Requirementso Accountability, Roleso Behaviors, Interactionso Functional Profiles, o Interfaces, Contracts
Conceptual Functional Service Specifications
Inventory of Platforms/ Environments.
PIM(Logical)
Applicable Rules Use Case Specs Governance. Technology Neutral
Standards Wireframes of
o architectural layers o Components ando Associations
Information Modelso Localizedo Constrainedo Project
Message Content Specifications
Use Case Specs Component. specs Interface Specs Interaction Specs Collaboration Participations Collaboration Types Function Types Interface Types Collaboration Scripts Service Contracts
Existing Platform models, Capabilities, Libraries and Versions.
PSM(Implementable)
Business Nodes Business Rules Business Procedures Business Workflow Technology Specific
Standards
Database Schemas Message Schemas Transformation
Schemas (e.g., XSD)
Automation Unit Technical Interfaces Technical Operations Orchestration Scripts
Application Specs. GUI Specifications Component Designs Deployment Topology Platform Bindings
13
Slide 14EHR SD RM - EHR Way Forward … Future State Reference Architecture
Initiation
AnalysisPeer
Review“Ballot”
Design
EHR-S FM & EHR-S CI-IMEHR System
Function Model & EHR System
Computationally-Independent Information-
Model
DAM Domain Analysis Models CDA Clinical Document Architecture
CMET Common Model Element TypesD-MIM Domain Message Information ModelInteroperability Specifications for
• Messages and/or• Documents and/or• Services
HL7 Development Framework (HDF)
Implement& Test
Specifications for• Business Objects• Components• Capabilities• Applications• Systems
V&VCheckpoin
t
V&VCheckpoint
V&V CheckpointV&V is Verification and Validation
SAIF ECCF -Services Aware Interoperability Architecture - Enterprise Compliance and Conformance Framework
V&VCheckpoint
DSTU - Draft Standard for Trial Use “Prototype”
Draft Working Document; Not for Public Distribution
15
Slide 16EHR SD RM - EHR Way Forward … Future State Reference Architecture
SAIF ECCFViewpoints CIMPSM
PIM
ECCF
CIM is Computationally Independent ModelPIM is Platform Independent Model
PSM is Platform Specific Model
Draft Working Document; Not for Public Distribution
16
InteroperabilitySpecification
Slide 17EHR SD RM - EHR Way Forward … Future State Reference Architecture
EHR-S CI-IM (Started Jun 2010)
EHR System Computationally-Independent Information-Model
This project will produce a set of Constrained Information Models called EHR-S “data profiles”. Each EHR-S data profile corresponds directly with an EHR-S function profile and each EHR-S data profile will include one-or-more Reference Information Model classes. Pairs of EHR-S function profiles and data profiles can be used to define business objects, which can be composed into software components, capabilities, applications, systems and their message exchanges and/or document exchanges and/or services. The superset of EHR-S data profiles is called the EHR-S Computationally-Independent Information-Model, which supports the HL7 Development Process and Service Aware Interoperability Framework. The project will include the development and execution of a communication strategy to ensure that all affected stakeholders are engaged.
Slide 18EHR SD RM - EHR Way Forward … Future State Reference Architecture
HL7 RIM (Reference Information Model)Six Core Classes Defining a Semantic Framework which
Maintains Clinical Data Context
The HL7 RIM expresses the data content needed in a specific clinical or administrative context and provides an explicit
representation of the semantic and lexical connections that exist between the information carried in the fields of HL7 messages.
Role link
Act relationship
Participation
The HL7 RIM supports EHR interoperability; an EHR may needs additional foundation classes (e.g., Responsibility)
Language /
communication
ACT (aka ACTION)ROLEENTITY
ACT – something that has happened or may happenEntity – a person, animal, organization, or thingRole – a responsibility of, or part played by, an EntityParticipation – the involvement of a Role in an ActAct Relationship – a relationship between two ActsRole Link – a relationship between two Roles.
Slide 19EHR SD RM - EHR Way Forward … Future State Reference Architecture
Federal Health Information Model (FHIM) Person Model (Harmonized with RIM, HIPAA & HITSP)
Slide 20
EHR-S FM
DC x.y.z EHR-S Function Profile
…
SC x.y.z EHR-S Function Profile
…
IN x.y.z EHR-S Function Profile
…
Entity a.b.c
EHR-S Data Modules
…
1:1
Relationship between
Function Profiles
and
Data Profiles
For each EHR-S
Function, its Data
Profile = Set of RIM
Classes and their EHR-S
Data Modules
EHR-S CI-IM
Role a.b.c
EHR-S Data Modules
…
Act a.b.c
EHR-S Data Modules
…
Act Relationship a.b.c
EHR-S Data Modules
…
Role Link a.b.c
EHR-S Data Modules
…
Participation a.b.c
EHR-S Data Modules
…
Entity d.e.f
…
RIM Classes
Role d.e.f
…
Act d.e.f
…
Act Relationship d.e.f
…
Role Link d.e.f
…
Participation d.e.f
…
1:N
Relationship among
Data Profiles
and
RIM Classes
DC is Direct CareSC is Supportive CareIN is Infrastructure
HL7 EHR System Computationally-
Independent Information-Model
(EHR-S CI-IM) Project
Draft Working Document; Not for Public Distribution
Slide 21EHR SD RM - EHR Way Forward … Future State Reference Architecture
EHR SD RM Status (Oct 2010)
Supporting EHR System Functional Model R2
– EHR SD RM foundation (linked XML version) Spring 2011 ballot
– HITSP (2010 completion)
– ARRA Meaningful Use Objectives/ Criteria (Jun 2010 Final Rule)
Sub Projects
– EHR Computationally Independent Information Model
– Harmonization Framework and Exchange ArchitectureSAIF Executive Summary and
Implementation Guide
http://hssp.wikispaces.com/PracticalGuide
Slide 22EHR SD RM - EHR Way Forward … Future State Reference Architecture
Prototype Demonstration of Browser-Version XML with XSL & XSLT HTML Style Sheet
EHR-S FM R1.1 linked to
– US Meaningful Use Objectives and Criteria
– US Mandated Standards
– Information Model (TBD)
Slide 23EHR SD RM - EHR Way Forward … Future State Reference Architecture
EHR SD RM Issue/Questions 2011 Planned Representation (Better Options?)
– Linked XML (most flexible for documentation, current preference)– EHR–S FM (R2) and it’s profiles (2011)
• ISSUE: Managing Profiles• ISSUE: Tracking Changes / Comments• ISSUE: Managing HL7 Domain Analysis Models (DAMS)? and • ISSUE: Managing Detailed Clinical Models (DCMs)?• ISSUE: DITTA Publishing? (Resources needed)• ISSUE: Data Base / Web version? (Resources Needed)
– EHR CI-IM - Computationally Independent Information Model • ISSUE: RIM/RIMBA expertise needed
– US HITSP (2010) Health & Human Services Selected Standards– US ARRA MU Meaningful Use Objectives & Criteria (2010)
Slide 24EHR SD RM - EHR Way Forward … Future State Reference Architecture
Call for Participation
XSL style sheet expert for
– EHR-S FM R2
– EHR-S FM R2 with EHR SD RM additions
– Profiles
– Comment/Change tracking
EHR Computationally Independent Information Model
– Decomposed by EHR-S FM
– Traceable to RIM
Contact Information
Nancy Orvis
Chief Integration Architect
Information Management
DoD Military Health System
Email: [email protected]
HOW TO PARTICIPATE:Coordinate with [email protected], 703-575-7912-cell.
We have a weekly telecom each Friday 1230-1330 EasternPHONE: +1 770-657-9270, CODE: 071582#WEB LINK: http://my.dimdim.com/hsspPROJECT WIKI: http://hssp.wikispaces.com/Reference+Architecture
Steve Hufnagel
Enterprise Architect, TIAG contract support
Information Management
DoD Military Health System
Email: [email protected]
25Backup Slides Available at Web Site
Slide 26EHR SD RM - EHR Way Forward … Future State Reference Architecture
Immunization Management Case StudyQuestions?
HOW TO PARTICIPATE:Coordinate with [email protected], 703-681-3929 or 703-575-7912-cell.
We have a weekly telecom each Friday 1230-1330 EasternPHONE: +1 770-657-9270, CODE: 071582#WEB LINK: http://my.dimdim.com/hsspPROJECT WIKI: http://hssp.wikispaces.com/Reference+Architecture