hl7 “ehr sd rm” project “ehr system design reference model”
DESCRIPTION
HL7 “EHR SD RM” Project “EHR System Design Reference Model” Constructing a Future State EHR Reference Architecture EHR Way Ahead Business Architecture Healthcare SOA Reference Architecture Enterprise Information Model From HL7 and HITSP Artifacts - PowerPoint PPT PresentationTRANSCRIPT
Slide 1EHR SD RM - EHR Way Forward … Future State Reference Architecture
HL7 “EHR SD RM” Project “EHR System Design Reference Model”
Constructing a Future State EHR Reference Architecture • EHR Way Ahead Business Architecture • Healthcare SOA Reference Architecture• Enterprise Information Model
From HL7 and HITSP ArtifactsFor presentation at HL7 Rio Workgroup Meeting, 18 May 2010
Details available at www.HSSP.wikispaces.com/Reference+Architecture
[email protected], Dir Health Stds [email protected], Architect & System Engineer
Last Updated 26 March 2010
Slide 2EHR SD RM - EHR Way Forward … Future State Reference Architecture
Federal Enterprise Architecture (FEA)www.whitehouse.gov/omb/egov
Performance Reference Model - The FEA PRM is a framework to measure the performance of major IT initiatives and their contribution to program performance. The PRM leverages performance measurement best practices from the public and private sectors, including the Balanced Scorecard, Baldrige Criteria, Value Measurement Methodology, program logic models, the value chain, and the theory of constraints. There is an increased emphasis placed on linkage of investment to agency program performance and the PRM will help agencies produce enhanced performance information. Furthermore, the PRM will assist in: improving the alignment of program goals and objectives with Mission Area goals and objectives; improving communication of program contributions such as technology (input) to outputs and outcomes; and in identifying improvement opportunities that span traditional organizational boundaries.
Business Reference Model - The Business Reference Model (BRM) is a functional-driven framework for describing and organizing the day-to-day business operations of the Federal Government into Lines of Business (LOBs), independent of the agencies that perform the business operation. The BRM is the first layer of the Federal Enterprise Architecture and it is the organizing construct for the analysis of the other four reference models: performance, service components, data, and technology.
Service Component Reference Model - The Service Component Reference Model (SRM) is a functional framework to evaluate to identify government-wide opportunities to leverage IT investments and assets from a service perspective. This model helps understand the services delivered by the government and assess if there is an opportunity to group like services and create leverage opportunities, such as reuse or shared services.
Data Reference Model - The Data Reference Model (DRM) describes at an aggregate level, the data and information required to support the Lines of Business (LOBs). The three elements of data exchange that have been standardized include data description, data context, and data sharing. Establishing a common data model streamlines the information exchange process within and across the Federal Government and facilitates the ability to identify duplicative data resources.
Technical Reference Model - The Technical Reference Model (TRM) establishes a common technical framework for categorizing standards, specifications, and technologies that support and enable the delivery of services. This framework can be leveraged to support the development, delivery, and exchange of business and application components (Service Components) that may be leveraged in a Component-based or Service Oriented Architecture (SOA). Furthermore, it also serves as the foundation to advance the re-use of technology and best practices from each of the Service Components on a government-wide basis.
Slide 3EHR SD RM - EHR Way Forward … Future State Reference Architecture
EHR-SD RM Project Description and PlanPROJECT DESCRIPTION: HL7 EHR System Design Reference Model (EHR SD RM) This project will mature the April 2008 Healthcare Services
Oriented Reference Architecture (H-SOA-RA) version 1.0 into H-SOA-RA Version 2.0, for HL7 Architecture Review Board (ArB) consideration, and then integrate it into an EHR System Design Reference Model (EHR-SD RM), using the HL7 SOA-Aware Enterprise Architecture Framework (SAIF), HITSP Multi-Enterprise Architecture of Networked Services Standards (MEANS), EHR System Functional Model (EHR-S FM). Emphasis will be placed on maintaining AHIC, HITSP, NHIN and CCHIT conformance by maintaining Information Exchange Requirements (IERs) and Data Requirements (DRs) traceability. Mapping and analysis of the HL7 product portfolio against the EHR-S FM will be used to integrate the reference architecture with HL7 product lines and initially mature the resulting model as a technical white papers, then an informative reference model and finally a standard reference model. An HSSP based prototype case study architectural specification will be built to validate the effort.
Phases: For Project Information, see http://hssp.wikispaces.com/Reference+Architecture
1. EHR SD RM Framework– Populate the framework with HL7 EHR-S Functional Model content, candidate healthcare Information
Exchanges, HITSP capabilities/ services and data architecture 2. Information Model
– Loosely-coupled top-down Framework– Rigorously specified bottom up structure/ content based on HITSP Data Architecture
3. Socialize EHR SD RM (HL7 Meeting, Jan 2010)4. Collaborate with others within HL7 (ongoing)5. Publish HL7 HSSP Practical Guide for SOA in Healthcare Part 2: Case Study (May 2010)6. Solicit public comment; collaborate with IHE; HL7/OMG SOA Conference (May to Sept)7. HL7 Informative ballot (Oct 2010)8. HL7 Normative ballot (Oct 2011)
Slide 4EHR 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
HSSP Practical Guide for SOA in
Healthcare Volume II: IRM Case
Study __________
EHR SD RM Informative
DSTU
DSTU is Draft Standard for Trial Use (ANSI standards development)
2011
EHR SD RM Normative Standard
Slide 5EHR SD RM - EHR Way Forward … Future State Reference Architecture
class Capability
seq Capability
Business Goal
Business Process Model
Core Business Area
Business
Mission Segment
Cost Benefits Analysis
- cost- benefits- AOA
Solution
+ Actor+ Application Specification+ Logical Data Model+ Scenario+ Software (notional)+ Use Case+ Use Case Association+ Use Case Step+ Versioned Specification
Alternatives
Bold indicates addition/change to CBDI
Legend
Software/Service (Notional)
+ Inter Software Relationship+ Nonsoftware Services+ Proposed Operation+ Software Classification+ Software Classification Group+ Software Function+ Software Service+ Software/Service (notional)
User Outcome
Policy
Organization
Enterprise Information Model
+ Business Rules+ Code Set+ Data Module+ Data Structure+ Grammar+ Morphology+ Ontology+ Syntax+ Vocabulary-Terminology
Operational Activity
+ Level 1: Business+ Level 2: Component+ Level 3: Detail
Specification
Security and Privacy
Reference Architecture
Exchange Architecture
Deployment
Strategic Objectives
supportsderived from
«import»
«import»
«import»
describes
«import»
«import»
supports
derived from
supports
«import»
1..*
derived from
constrained by
«import»
«import»
«import»
Linking Business and Technical Architectures
Slide 6EHR SD RM - EHR Way Forward … Future State Reference Architecture
CONTENTS2. Constructing a Future State EHR Reference Architecture
3. HL7 EHR System Functional Model (EHR-S FM)
4. Healthcare SOA Reference Framework
5. HL7 RIM (Reference Information Model)
6. HITSP Harmonization Framework
7. HITSP Constructs
8. HITSP Data Architecture
9. HITSP Clinical Document Components
10. HITSP/C83 Data Module Categories
11. EHR Way Forward Business Architecture Specification Framework
12. Future State EHR Reference Architecture Adding ARRA and FHIM
13. Basic UML Legend
14. Abbreviations
15. PART II: HL7 SAIF, Requirements Management, Architecture and Governance Processes
16. PART III: Prototype (Immunization and Adverse Event Reporting)
Slide 7EHR SD RM - EHR Way Forward … Future State Reference Architecture
Constructing a Future State EHR Reference Architecture
OBJECTIVE: A system agnostic Future State EHR Business Architecture (BA) specified with a lexicon, based upon HITSP’s data architecture, HL7’s System Functional Model (EHR-S FM) and HL7’s Reference Information Model (RIM).
A Health IT EHR BA can be modeled as clinical stakeholder requirements and their workflow-orchestration of
HL7 RIM compliant HITSP data modules manipulated by
HL7 EHR-S FM functions.
An EHR Information Model, for a project or enterprise, can be constructed from the HITSP data models managed by the EHR Functions used within the EHR BA, categorized using the HL7 RIM Entity, Role and Action foundation classes.
These concepts are the topic of this presentation
Slide 8EHR 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 9EHR SD RM - EHR Way Forward … Future State Reference Architecture
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
9
Slide 10EHR SD RM - EHR Way Forward … Future State Reference Architecture
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.
Slide 11EHR 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
11
Slide 12EHR SD RM - EHR Way Forward … Future State Reference ArchitectureIT PLATFORM
SUPPORT
ANALYTIC
DATA MANAGEMENT
PERFORMANCE
DECISION SUPPORT
RECORDS MANAGEMENT
DOCUMENT
SUPPLY CHAIN: (ORDERS/CHARGES)
SCHEDULING
AUTHORIZATION
TERMINOLOGY
IDENTITY
RADIOLO
GY
LABORATORY
PHARMACY
CLI
NIC
AS
U
T
ES
T O
NLY
O
UT
PA
TIE
NT
OT
HE
R
INP
AT
IEN
T E
R
CARDIOLO
GY
PT/O
T/SPEECH
DIETARY
SPECIALTY CARE
Ancillary Systems
Co
re B
usi
nes
s S
ervi
ces
INTEGRATEDREQUIREMENTS
DESIGNS: Putting the H-SOA-RA
Pieces Together
RESPIRATORY
Fed
erat
ed B
usi
nes
sS
ervi
ces
Ag
no
stic
S
ervi
ces
Federated Services, may be categorized by: -- Encounter Types -- CMS billing category -- Record type -- Care setting type -- etc.
Data sets are defined for each system functional-
capability-service module 12In
ter-
Age
ncy
Inte
r-S
ervi
ceA
cros
sP
rovi
ders
Slide 13EHR 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 14EHR SD RM - EHR Way Forward … Future State Reference Architecture
HITSP Constructs A HITSP Interoperability Specification (IS) defines a business context, supports a business
workflow, constrains and orchestrates underlying constructs.
A HITSP Capability (CAP) is a specification that assembles HITSP constructs to fulfill a business need for information exchanges. To use a Capability, an Interoperability Specification or an implementation conformance statement must assign Systems to one or more Capability System Roles and identify how the Capability Options are to be addressed. The use of a Capability shall:
– for each assigned Capability System Role, the responsibilities of the assigned System Role must be supported, including all interfaces specified by the underlying HITSP constructs according to the conditions specified for the assigned System Role.
– If a Capability option is selected, the implementation must conform to the Capability’s specifications for that option.
A HITSP Service Collaboration (SC) binds communications infrastructure, security and privacy constructs together.
A HITSP Transaction Package (TP), Transaction (T), Component (C) is where standards-based Interface Design Specifications are specified and conformance requirements are defined.
Slide 15EHR SD RM - EHR Way Forward … Future State Reference Architecture
HITSP Harmonization Framework
AddressingBusiness
Needs
ProvidingInfrastructure,
Security,Privacy
Data Architecture
Available for Independent Implementation
DefiningInformation
Content
IS = Interoperability Specification
Base and Composite Standards
Slide 16EHR SD RM - EHR Way Forward … Future State Reference Architecture
class Data Architecture
EHR System Interoperability Specifications
Capability
Data Architecture
Data Module
Data Element
Value Set
HITSP Constructs
Component (C)
Transaction Package (TP)
Transaction (T)
Service Collaboration (SC)
Selected Standard
HITSP/C83 - CDA Content Modules Component
HITSP/C154 - HITSP Data Dictionary
HITSP/ C80 - Clinical Document and Message Terminology Component
HITSP/TN903 - Data Architecture Technical Note
HITSP/TN904 - Harmonization Framework and Exchange Architecture Technical Note
HITSP/TN901 - Technical Note for Clinical Documents
Data Requirement (DR)
+ Data Module
Capability Requirements
+ Information Exchange+ option+ Scenario+ system role
ARRA Requirement for Certified EHR Systems
Information Exchange Requirement (IER)
+ Systems+ Exchange Content+ Exchange Action+ Exchange Attribute
ARRA Meaningful Use Measures
+ Stakeholder
Regulatory Guidance
Scenario
+ conditions
Certification Criteria
+ Capability
Capability Design
+ conditions+ optionality+ system role
requirementsdesign
Legend
HITSP Data Architecture within
HITSP Harmonization Framework
GREEN indicates reusable elements
HITSP Documents are available at www.HITSP.orgDetailed HITSP Data Architecture is available online at www.USHIK.org
Slide 17EHR SD RM - EHR Way Forward … Future State Reference Architecture
HITSP Clinical Document Components
HITSP Reuse Paradigm: With HITSP/Capability 119 - Communication of Structured
Documents, a HL7 Clinical Data Architecture (CDA) document can be
composed, from any group of C83 data modules, and then it can be
communicated. Benefit: agile system interoperability.
Slide 18EHR SD RM - EHR Way Forward … Future State Reference Architecture
HITSP/C83 Data Module CategoriesModule Category Description
Personal Information The personal information includes name, address, contact information, personal identification information, ethnic and racial affiliation and marital status of a person
Support Support includes the patient's sources of support, such as immediate family, relatives and/or guardians. This includes next of kin, caregivers, support organizations, and key contacts relative to healthcare decisions. Support providers may include providers of healthcare related services, such as a personally controlled health record, or registry of emergency contacts
Healthcare Providers This includes a list of the healthcare providers and organizations that provide or have provided care to the patient
Insurance Providers and Payers
Insurance providers include data about the organizations or individuals who may pay for a patient's healthcare, and the relationships, demographics and identifiers of those individuals with respect to the payer. Such organizations or individuals may be health insurance plans, other payers, guarantors, parties with financial responsibility, some combination of payers or the patient directly
Allergies and Drug Sensitivities
This includes the allergy or intolerance conditions, severity and associated adverse reactions suffered by the patient
Conditions This includes relevant clinical problems and conditions for which the patient is receiving care, including information about onset, severity, and providers treating the condition. Conditions are broader than, but include diagnoses
Medications This includes the patient's prescription or non-prescription medications and medication history, and may include prescriptions, fulfillments and medication administration activities
Immunizations This includes data describing the patient's immunization history
Vital Signs This includes data about the patient’s vital signs
Test Results This includes data about current and historical test results from laboratory or other diagnostic testing performed on the patient
Encounter This includes data describing the interactions between the patient and clinicians. Interaction includes both in-person and non-in-person encounters such as telephone and email
Procedures This includes data describing procedures performed on a patient
Family History Data defining the patient’s genetic relatives in terms of possible or relevant health risk factors that have a potential impact on the patient’s health
Social History Data defining the patient’s occupational, personal (e.g. lifestyle), social, and environmental history that have a potential impact on the patient’s health
Medical Equipment Medical Equipment includes implanted and external medical devices and equipment that a patient’s health status depends on, as well as any pertinent equipment or device history
Functional Status Data defining the patient’s functional status with respect to, ambulatory ability, mental status or competency, activities of daily living, including bathing, dressing, feeding, grooming, home/living situation having an effect on the health status of the patient, and ability to care for self
Plan of Care The plan of care contains data defining prospective or intended orders, interventions, encounters, services, and procedures for the patient
Slide 19EHR SD RM - EHR Way Forward … Future State Reference Architecture
Functional Analysis Object Analysis
Requirements Analysis
Interface Design Analysis Service Analysis
EHR System Design Reference Model (EHR SD RM) Constructing a Future State EHR Reference Architecture
Slide 20EHR SD RM - EHR Way Forward … Future State Reference Architecture
Value Proposition of Standards Based Approach
Analysis Pre-Done: Analysts from throughout industry have vetted and contributed to the development of thorough specifications
Less Customization: COTS vendors are already building applications to meet these specifications.
Comprehensive View: Standards provide a way to ensure that requirements and design address all of the necessary issues
Lack of unexpected dependencies late in project: All functions and specifications have been pre-analyzed and defined
Better Interoperability: Standards based approaches will ensure development between all stakeholders are able to communicate at the project and technical level
Across Project Visibility: Normalized requirements and design would allow for “apples to apples” comparison across the portfolio
Slide 21EHR SD RM - EHR Way Forward … Future State Reference Architecture
Basic UML Legend class Basic UML Legend
Book
Preface
Chapter
Publisher
Biography
Author Legend
A book realizes an author's concept outline. A Concept Outline and a Book depends on an Author to be written. A Book "has-an" index and is composed of one or more chapters. A Biography "is-a" type of book. A Book is associated with a publisher. Association is a relationship between two classes, that may describes the reasons for the relationship and the rules that govern the relationship. Aggregation ("has-a") is a special form of an association that specifies a whole-part relationship between the aggregate (whole) and a component part. The parts can
exist on their own and are therefore shareable among multiple owner classes. Composition (a strong type of "uses a" relationship) is a form of aggregation which requires that a part instance be included in at most one composite at a time, and
that the composite object is responsible for the creation and destruction of the parts. A dependency is a type of relationship that signifies that one element, or group of elements, acting as the client depends on another element or group of elements that
act as a supplier. It is a weak relationship that denotes that if the supplier is changed the client may be affected. It is a unidirectional relationship. Realize is a relationship where a source object implements or Realizes its destination object. Realize connectors are used to express traceability and completeness in
the model. Generalization ("is-a") is a relationship in which one model element (the child) is based on another model element (the parent).
Concept Outline
dependency
aggregate1..*
compose
associate
generalize
realize
Slide 22EHR SD RM - EHR Way Forward … Future State Reference Architecture
Abbreviations
B-Case is Business Case
BPM is Business Process Model
CCD is Continuity of Care Document
CCHIT is Certification Commission for Health Information Technology
CDRL is Contract Deliverable
DBT is Defense Business Transformation
IHE is Integrating the Healthcare Enterprise
NHIN is National Health Information Exchange
PCC is Patient Care Coordination
RM-ODP is Reference Model of Open Distributed Processing
SOA is Service Oriented Architecture
Slide 23EHR SD RM - EHR Way Forward … Future State Reference Architecture
PART II: HL7 SAIF, Requirements Management and Architectural Processes
• EHR SD RM within the Requirements and Architecture Development Cycle
• The HL7 Services-Aware Interoperability Framework (SAIF)
• HL7 SAIF ECCF Specification Stack
• HITSP Within HL7 SAIF ECCF Specification Stack
• HL7, HITSP, FHIMS and NHIN Within HL7 SAIF ECCF Specification Stack
Slide 24EHR SD RM - EHR Way Forward … Future State Reference Architecture
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
Architecture Design
Architecture Design
Stakeholder Requirements
Definition
Stakeholder Requirements
DefinitionRequirements Loop
Verification & ValidationLoop
DesignLoop
PROCESS INPUTS-Required Capabilities-Environments-Constraints
PROCESS OUTPUTS-System Architecture, -System & Test Specifications-Configuration Management Baselines
Test Specifications
Test Specifications
Capabilities - Functions,Information Model
Information Exchanges
Functions – Dependencies
Function orService
Interface Design
Specifications
Compliance means a system provides support for a given standard.Conformance is a recognition of formal testing, that prove that a system provides 100% support for a given standard.
Conformance Criteria
Slide 25EHR SD RM - EHR Way Forward … Future State Reference Architecture
EHR SD RM Supporting Requirements/ Architecture Development Cycle
Stakeholder Requirements
– What is the system supposed to do?
– Where will the products of the system be used?
– Under what conditions will the products 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
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
Slide 26EHR SD RM - EHR Way Forward … Future State Reference Architecture
EHR SD RM Supporting Requirements & Architectural Processes
2010 slide
Slide 27EHR SD RM - EHR Way Forward … Future State Reference Architecture
The HL7 Services-Aware Interoperability Framework (SAIF)
SAIF Contains: Enterprise Conformance and Compliance Framework (ECCF) is based on RM-ODP Behavioral Framework (BF)
– Interoperability Scenarios supporting the RM-ODP Computational Viewpoint Governance Framework (GF)
– Governance is the overarching policy structure and set of related processes by which a group exercises its authority and demonstrates accountability for accepted responsibilities within a particular jurisdiction.
SAIF Principles: Applicable within each of HL7’s three Interoperability Paradigms (IPs),
– (i.e., messages, documents, and services). Provide support for measurable conformance and compliance. Define appropriate governance structures and processes. Provide support for directly implementable solutions. Address the growing disparity between the various solution sets emerging from HL7. Utilize existing V3/RIM artifacts and expertise to the maximum degree possible.
Slide 28EHR SD RM - EHR Way Forward … Future State Reference Architecture
HL7 SAIF ResponsibilitiesConformance and Compliance Framework (ECCF)
Consistency
Tra
ceab
le
Implementation“Where”
Behavior“How”
Content“What”
Policy“Why”
Slide 29EHR SD RM - EHR Way Forward … Future State Reference Architecture
HL7 SAIF Specification Stack ViewsConformance and Compliance Framework (ECCF)
Consistency
Tra
ceab
le
ImplementationBehaviorContentPolicyTopic
Specification
Enterprise / Business View
“WHY”
Information View
“WHAT”
Computational View
“HOW”
Engineering View
“WHERE”
Conceptual
Business Context, Reference Context
Domain Analysis (Information) Model
Collaboration Analysis, Functional Profile(s), Service Roles and
Relationships
Existing Platform capabilities
Platform-
Independent
Business Governance Project-oriented Domain Information Model,
Constrained Information Model, Localized Information Model, Hierarchical Message
Definition
Collaboration Types, Interface Specification and Functional
Groups, Interaction Types and Collaboration Participations,
Contracts Parts
Existing Platform models, libraries, etc.
Platform-
Specific
Rules, Procedures Localized Information Model, Transforms, Schema
Collaboration scripts, Orchestrations, Realized
Interfaces
Execution Context, Platform Bindings, Deployment Model
Slide 30EHR SD RM - EHR Way Forward … Future State Reference Architecture
HITSP WithinHL7 SAIF ECCF Specification Stack
Topic
Specification
Enterprise / Business View
“WHY”
Information View
“WHAT”
Computational View
“HOW”
Engineering View
“WHERE”
Conceptual
Business Context, Reference Context
Domain Analysis (Information) Model
Collaboration Analysis, Functional Profile(s), Service Roles and
Relationships
Existing Platform capabilities
Platform-
Independent
Business Governance Project-oriented Domain Information Model,
Constrained Information Model, Localized Information Model, Hierarchical Message
Definition
Collaboration Types, Interface Specification and Functional
Groups, Interaction Types and Collaboration Participations,
Contracts Parts
Existing Platform models, libraries, etc.
Platform-
Specific
Rules, Procedures Localized Information Model, Transforms, Schema
Collaboration scripts, Orchestrations, Realized
Interfaces
Execution Context, Platform Bindings, Deployment Model
Consistency
Tra
ceab
le
HITSP DAHITSP CAP
Harmonization Requests/ Use Case
HITSP CAP
HITSP Transaction,
Transaction Package and Service
Collaboration
HITSP Component
HITSP IS
ImplementationBehavior
HITSP Harmonization
Framework
EHR-S FM is EHR System Functional ModelEHR SD RM is EHR System Design Reference ModelRIM is Reference Information ModelFHIMS is Federal Health Information Model & StandardsDA is Data Architecture
ContentPolicy
Slide 31EHR SD RM - EHR Way Forward … Future State Reference Architecture
HL7, HITSP, FHIMS, NIEM and NHIN WithinHL7 SAIF ECCF Specification Stack
Topic
Specification
Enterprise / Business View
“WHY”
Information View
“WHAT”
Computational View
“HOW”
Engineering View
“WHERE”
Conceptual
Business Context, Reference Context
Domain Analysis (Information) Model
Collaboration Analysis, Functional Profile(s), Service Roles and
Relationships
Existing Platform capabilities
Platform-
Independent
Business Governance Project-oriented Domain Information Model,
Constrained Information Model, Localized Information Model, Hierarchical Message
Definition
Collaboration Types, Interface Specification and Functional
Groups, Interaction Types and Collaboration Participations,
Contracts Parts
Existing Platform models, libraries, etc.
Platform-
Specific
Rules, Procedures Localized Information Model, Transforms, Schema
Collaboration scripts, Orchestrations, Realized
Interfaces
Execution Context, Platform Bindings, Deployment Model
Consistency
Tra
ceab
le
HL7 RIMFHA FHIMSHITSP DAHITSP CAP
Harmonization Requests/ Use Case
HITSP Capability
NIEM, HITSP Transaction,
Transaction Package and Service
Collaboration
HITSP Component
NIEM Information Exchange Package
HL7 EHR-S FMHITSP
Harmonization Framework
HL7 EHR SD RM
HITSP IS
EHR-S FM is EHR System Functional ModelEHR SD RM is EHR System Design Reference ModelNIEM is National Information Exchange ModelRIM is Reference Information ModelFHIMS is Federal Health Information Model & StandardsDA is Data Architecture
NHIN ConnectServices
Tomcat, JBoss, J2SE, Eclipse,
GlassFish ESB, OpenSSO
31
ImplementationBehaviorContentPolicy
Slide 32EHR SD RM - EHR Way Forward … Future State Reference Architecture
PART III Prototype EXAMPLE
Vaccination and Adverse Event Reporting Prototype– AHIC Use Cases– EHR-S FM– HITSP Capabilities– Information Model
Slide 33EHR SD RM - EHR Way Forward … Future State Reference Architecture
The IRM AHIC Use Case and HITSP Interoperability Specification are intended to support current interoperability approaches between EHRs and Immunization Information Systems while allowing for a migration toward emerging interoperability implementations and document sharing environments where PHRs are able to be included in the information flow
The Interoperability Specification also allows for basic electronic information exchanges to enable requirement communications and alerting mechanisms and to lay the foundation for future clinical support capabilities – Scenario 1: Vaccine and Drug Administration and Reporting and– Scenario 2: Vaccine and Drug Inventory Reporting
EHR-SD RM Prototype [2008 AHIC Use Cases] Immunization and Response Management (IRM)
Slide 34EHR SD RM - EHR Way Forward … Future State Reference Architecture 34
EXAMPLE ARTIFACT: Vaccine and Drug Administration and Reporting Information Exchanges
Slide 35EHR SD RM - EHR Way Forward … Future State Reference Architecture
EXAMPLE ARTIFACT Vaccine and Drug Administration and Reporting Use Case
Full use case available at: http://healthit.hhs.gov/portal/server.pt?open=512&objID=1255&parentname=CommunityPage&parentid=1&mode=2&in_hi_userid=10741&cached=true
Slide 36EHR SD RM - EHR Way Forward … Future State Reference Architecture
EHR-SD RM PrototypeInformation Exchange Requirements (IERs)
Vaccine and Drug Administration and Reporting Use Case
IER10 Identify patient IER13 Send/receive notification of document availability IER18 Send/receive clinical document IER26 Identify communication recipients IER27 Send non-patient notification message or alert IER40 Query for existing data IER42 Request/receive medical concept knowledge IER54 Query/response for clinical message data IER67 Send/receive clinical message IER78 Send/receive Vaccine Inventory Requirements IER79 Query/response for inventory usage data IER80 Send/receive Vaccine Inventory Data
For details, see HITSP IS 10 Immunization and Response
Management, available at www.HITSP.org
Slide 37EHR SD RM - EHR Way Forward … Future State Reference Architecture
DR08 Unstructured Data DR11 Immunization response data DR12 Adverse Event Report DR13 Drug/Vaccine Inventory Data DR14 Drug/Vaccine Inventory Usage Data DR15 Drug/Vaccine Inventory Availability Data DR16 Supply Chain Management Vaccine Recall DR17 Decision Support Data DR18 Vaccination Data DR19 Medication Administration data DR20 Aggregate Inventory of Available Vaccine DR21 Terminology Data DR22 Generic Alert Data DR23 Consumer Vaccination View
EHR-SD RM PrototypeData Requirements (DRs)
Vaccine and Drug Administration and Reporting Use Case
For details, see HITSP IS 10 Immunization and Response
Management, available at www.HITSP.org
Slide 38EHR SD RM - EHR Way Forward … Future State Reference Architecture
EHR-SD RM PrototypeHITSP Security and Privacy
Vaccine and Drug Administration and Reporting Use Case
IER01 Provide authorization and consent
IER02 Send data over secured communication channel
IER03 Create audit log entry
IER04 Synchronize system time
IER05 Verify entity identity
IER06 Provide proof of document integrity and origin
IER55 Anonymize patient identifiable data
IER56 Pseudonymize patient identifying information For details, see HITSP IS 10 Immunization and Response
Management, available at www.HITSP.org
Slide 39EHR SD RM - EHR Way Forward … Future State Reference Architecture
EXAMPLE ARTIFACT HL7 Requirements and Certification Criteria and HITSP Design
class EHR-S FM: CAP131 Update Immunization Registry
DC.1.8.2 (Manage Immunization Administration) CAP132 Retrieve Immunization Registry Information
CAP131 Update Immunization Registry
CAP133 Communicate Immunization Summary
HL7EHR System
Functional Model
HITSPInteroperability Specifications
Slide 40EHR SD RM - EHR Way Forward … Future State Reference Architecture
EXAMPLE ARTIFACT EHR-S Requirements
class DC.1.8.2 (Manage Immunization Administration)
+ 1.The system SHALL provide the ability to recommend required immunizations, and when they are due, during an encounter based on widely accepted immunization schedules.+ 1.The system SHALL provide the ability to recommend required immunizations, and when they are due, during an encounter based on widely accepted immunization schedules.+ 2.The system SHOULD provide the ability to recommend required immunizations based on patient risk factors.+ 2.The system SHOULD provide the ability to recommend required immunizations based on patient risk factors.+ 3.The system SHALL perform checking for potential adverse or allergic reactions for all immunizations when they are about to be given.+ 3.The system SHALL perform checking for potential adverse or allergic reactions for all immunizations when they are about to be given.+ 4.The system SHALL provide the ability to capture immunization administration details, including date, type, lot number and manufacturer.+ 4.The system SHALL provide the ability to capture immunization administration details, including date, type, lot number and manufacturer.+ 5.The system SHOULD provide the ability to capture other clinical data pertinent to the immunization administration (e.g. vital signs).+ 5.The system SHOULD provide the ability to capture other clinical data pertinent to the immunization administration (e.g. vital signs).+ 6.The system SHALL record as discrete data elements data associated with any immunization.+ 6.The system SHALL record as discrete data elements data associated with any immunization.+ 7.The system SHOULD provide the ability to associate standard codes with discrete data elements associated with an immunization.+ 7.The system SHOULD provide the ability to associate standard codes with discrete data elements associated with an immunization.+ 8.The system SHALL provide the ability to update the immunization schedule.+ 8.The system SHALL provide the ability to update the immunization schedule.+ 9.The system SHOULD provide the ability to prepare a report of a patient‘s immunization history upon request for appropriate authorities such as schools or day-care centers.+ 9.The system SHOULD provide the ability to prepare a report of a patient‘s immunization history upon request for appropriate authorities such as schools or day-care centers.+ 10.The system SHALL conform to function DC.1.4.1 (Manage Allergy, Intolerance and Adverse Reaction Lists).+ 10.The system SHALL conform to function DC.1.4.1 (Manage Allergy, Intolerance and Adverse Reaction Lists).+ 11.The system SHOULD transmit required immunization information to a public health immunization registry.+ 11.The system SHOULD transmit required immunization information to a public health immunization registry.+ 12.The system SHOULD receive immunization histories from a public health immunization registry.+ 12.The system SHOULD receive immunization histories from a public health immunization registry.
DC.1.8.2 Conformance Criteria
+ 1.The system SHALL provide the ability to recommend required immunizations, and when they are due, during an encounter based on widely accepted immunization schedules.+ 2.The system SHOULD provide the ability to recommend required immunizations based on patient risk factors.+ 3.The system SHALL perform checking for potential adverse or allergic reactions for all immunizations when they are about to be given.+ 4.The system SHALL provide the ability to capture immunization administration details, including date, type, lot number and manufacturer.+ 5.The system SHOULD provide the ability to capture other clinical data pertinent to the immunization administration (e.g. vital signs).+ 6.The system SHALL record as discrete data elements data associated with any immunization.+ 7.The system SHOULD provide the ability to associate standard codes with discrete data elements associated with an immunization.+ 8.The system SHALL provide the ability to update the immunization schedule.+ 9.The system SHOULD provide the ability to prepare a report of a patient‘s immunization history upon request for appropriate authorities such as schools or day-care centers.+ 10.The system SHALL conform to function DC.1.4.1 (Manage Allergy, Intolerance and Adverse Reaction Lists).+ 11.The system SHOULD transmit required immunization information to a public health immunization registry.+ 12.The system SHOULD receive immunization histories from a public health immunization registry.
Slide 41EHR SD RM - EHR Way Forward … Future State Reference Architecture
EXAMPLE ARTIFACT EHR-S FM Dependencies
class DC.1.8.2 (Manage Immunization Administration)
See Also
DC.1.3.2 (Manage Patient Advance Directives)
DC.1.4.4 (Manage Immunization List)
S.1.1 (Registry Notification)
S.2.2.2 (Standard Report Generation)
S.3.7.1 (Clinical Decision Support System Guidelines Updates)
IN.1.6 (Secure Data Exchange)
IN.1.7 (Secure Data Routing)
IN.2.4 (Extraction of Health Record Information)
IN.2.5.1 (Manage Unstructured Health Record Information)
IN.2.5.2 (Manage Structured Health Record Information)
IN.4.1 (Standard Terminologies and Terminology Models)
IN.3 Registry and Directory Services
IN.4.2 (Maintenance and Versioning of Standard Terminologies)
IN.4.3 (Terminology Mapping)
IN.5.1 (Interchange Standards)
IN.5.2 (Interchange Standards Versioning and Maintenance )
IN.6 Business Rules Management
Slide 42EHR SD RM - EHR Way Forward … Future State Reference Architecture
EXAMPLE ARTIFACTHITSP Interoperability Design Specifications
uc CAP131 Update Immunization Registry
CAP131 Update Immunization RegistryContent Consumer
Content Creator
Message Receiver
Message Sender
Request Patient Identification
Request HL7 Message
Respond to HL7 Message
HITSP/C72 Immunization Message Component
HITSP/T24 Pseudonymize
HITSP/SC110 - Request Patient Identifier
HITSP/SC115 – HL7 Messaging
Slide 43EHR SD RM - EHR Way Forward … Future State Reference Architecture
IS10 IRM HITSP
Constructs Mapped to Standards
Slide 44EHR SD RM - EHR Way Forward … Future State Reference Architecture
Contact Information
Nancy Orvis
Chief Integration Architect
Office of the Chief Information Officer
DoD Military Health System
Email: [email protected]
Steve Hufnagel
Enterprise Architect, TIAG contract support
Office of the Chief Information Officer
DoD Military Health System
Email: [email protected]