EHR SD RM
SAIF Alpha Project
“EHR System-Design Reference-Model”
Constructing a Future State
EHR Reference Architecture
EHR Way Ahead Business Architecture
From HL7, HITSP and ARRA Artifacts
For presentation at HL7 Cambridge, MA Meeting, 5 October 2010
Slides and White Paper Available at:
EHR SD RM info: http://hssp.wikispaces.com/Reference+Architecture
Also See Practical Guide for SOA in Healthcare Vol II: Immunization
Management Case Study at http://hssp.wikispaces.com/PracticalGuide
Nancy.Orvis@tma.osd.mil, GovProjects;
Stephen.Hufnagel.ctr@tma.osd.mil, SOA
Suggestions for Improvement Requested
EHR SD RM - EHR Way Forward … Future State Reference Architecture
Slide 0
EHR SD RM Milestones
2008
2009
Healthcare
SOA Reference
Architecture
(H-SOA-RA)
EHR SD RM
Immunization &
Response
Management
(IRM) Prototype
2010
2011
HSSP Practical
Guide for SOA in
Healthcare Volume
II: Immunization
Case Study
Oct
EHR SD RM
Informative White
Paper
TBD
May
EHR SD RM
Informative
Reference
Sep
EHR SD RM
DSTU
TBD
EHR SD RM
Normative
Standard
EHR-S CI-IM
& HF&EA
DSTU 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
EHR SD RM - EHR Way Forward … Future State Reference Architecture
Slide 1
2008 initiated H-SOA-RA
Healthcare SOA Reference Architecture
This Reference Architecture is built on the HL7 EHR System
Functional Model (EHR-S FM), HITSP Interoperability
specifications/Capabilities and OMG SOA layers. The
objective of the H-SOA-RA is to assure semantic
interoperability at the Service Level and consistency within
and among systems’ architectural specifications, resulting
in aligned, interoperable and agile enterprise architectures
and their system components.
EHR SD RM info: http://hssp.wikispaces.com/Reference+Architecture
EHR SD RM - EHR Way Forward … Future State Reference Architecture
Slide 2
HL7 EHR System Functional Model (EHR-S)
> 160 System Functions in 4 level categorization
(separate spreadsheet available for full enumeration)
System Functions
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).
Other
O-1
Electronic Resource Planning (ERP)
O-2
Finances
O-3
Other
EHR SD RM - EHR Way Forward … Future State Reference Architecture
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.
Slide 3
Healthcare SOA Framework
Based on HL7 EHR System Functional Model & Thomas Erl’s SOA Layers
HL7 System Functions 
Direct Care
Supportive
Information
Infrastructure
Other
Business
Process
Value Chains
Composite
Services
Federated Composition (e.g., Choreograph or Orchestration) Within and Across Business Areas
Core Business
Services
Functional
Areas + Focal Classes
Functional
Areas + Focal Classes
Functional
Areas + Focal Classes
Functional
Areas + Focal Classes
Entity
Services
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…)
Application
Services
Ambulatory Care Systems,
In Patient Care Systems
Logistics Systems
Financial Systems
Decision Support Systems
Data Marts
Repositories
Business Objects
Implementation
Profiles
Integrated Healthcare
Enterprise (IHE) Profiles
Analysis Profiles
Communications
Profiles/Stacks
Implementation Profiles
EHR SD RM - EHR Way Forward … Future State Reference Architecture
Slide 4
4
ANATOMY OF AN ANCILLARY SYSTEM
LABORATORY
RADIOLOGY
PHARMACY
CARDIOLOGY
OT/PT/SPEECH
s
CORE BUSINESS SERVICES
IDENTITY
TERMINOLOGY
AUTHORIZATION
SCHEDULING
SUPPLY CHAIN
(ORDER/CHARGE)
DOCUMENT
RECORDS MANAGEMENT
DECISION SUPPORT
PERFORMANCE
DATA MANAGEMENT
EHR SD RM - EHR Way Forward … Future State Reference Architecture
Slide 5
5
HL7 EHR_S-Based Functional Architecture/Services Analysis
ETC
Manage Business Rules
Interoperability
Terminology
Unique ID, Registry, and Director
Information and Records Management
Security
Cross-Cutting Direct Care/
Support Functions
Record Management
Manage Patient History
Preferences, Directives, Consents, and Authorizations
Summary Lists
Management of Assessment
Care Plans, Treatment Plans, Guidelines, and Protocols
Orders and Referral Management
Documentation of Care, Measurement, and Results
Record Patient Specific Instructions
Clinical Decision Support
Clinical Workflow Tasking
Support Clinical Communication
Support Knowledge Access
ETC
•Security
•Policy
•Records Management
•Audit
•Terminology
•Registry
•Workflow
•Business Rules
•etc
ETC.
Behavioral Health
Population Health
Pharmacy
Nursing
Laboratory
Non-Surgical Specialty Care
Dental
Critical/Emergency Care
Primary Care
Lines of Business
Infrastructure
Services
Core Clinical
Services
•Entity Identification
•Resource Location and
Updating Services
•Decision Support
•Orders Management
•Scheduling
•Image Management
•Etc.
6
2009 initiated EHR-SD RM
EHR System Design Reference Model
This project matures and integrates the April 2008 Healthcare Services
Oriented Reference Architecture (H-SOA-RA) into an EHR System
Design Reference Model (EHR-SD RM), using the HL7 SOA-Aware
Enterprise Architecture Framework (SAIF), HITSP interoperability
specifications, EHR System Functional Model (EHR-S FM) and ARRA
artifacts. Emphasis is placed on maintaining HITSP, ARRA, NHIN and
CCHIT conformance by maintaining EHR-S FM traceability. Mapping
and analysis of the HL7 product portfolio against the EHR-S FM is 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.
EHR SD RM info: http://hssp.wikispaces.com/Reference+Architecture
EHR SD RM - EHR Way Forward … Future State Reference Architecture
Slide 7
EHR-SD RM Project Description and Plan
PROJECT 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:
1.
For Project Information, see http://hssp.wikispaces.com/Reference+Architecture
EHR SD RM Framework
–
2.
Populate the framework with HL7 EHR-S Functional Model content, candidate healthcare Information
Exchanges, HITSP capabilities/ services and data architecture
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)
EHR SD RM - EHR Way Forward … Future State Reference Architecture
Slide 8
HITSP Harmonization Framework
Addressing
Business
Needs
Defining
Information
Content
IS
IS = Interoperability
Specification
Capability
Available
for Independent
Implementation
Service
Collaboration
Transaction,
Transaction Package
Providing
Infrastructure,
Security,
Privacy
Components
Data Architecture
Base and Composite Standards
EHR SD RM - EHR Way Forward … Future State Reference Architecture
Slide 9
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.
EHR SD RM - EHR Way Forward … Future State Reference Architecture
Slide 10
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.
 NIEM Information Exchange Package Documents
 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
EHR SD RM - EHR Way Forward … Future State Reference Architecture
Slide 11
PROCESS INPUTS
-Required Capabilities
-Environments
-Constraints
EHR System Design Reference Model (EHR SD RM)
Supporting Requirements/ Architecture Development Cycle
Stakeholder
Requirements
Definition
Capabilities, Functions,
Information and
Information Exchanges
EHR
System Design
Reference Model
Functions –
Dependencies
Requirements
Loop
Requirements
Analysis
Conformance Conformance is a
recognition of formal
Criteria
Interface
testing, that prove that
Specifications
a system provides
100% support for a
given standard.
Specifications
Loop
Verification & Validation
Loop
Architectural
Specifications
Test
Specifications
Test
Loop
PROCESS OUTPUTS
-System Architecture,
-Test Specifications
-Configuration Management Baselines
12
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?
Requirements Loop

Ensure all requirements are covered by at least one
function

Ensure all functions are justified by a valid requirement
(no unnecessary duplication)
– 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
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
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
Test Loop

Ensure all information is covered by test specifications

Ensure all interfaces are covered by test specifications
13
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
EHR SD RM - EHR Way Forward … Future State Reference Architecture
Slide 14
Basic UML Legend
class Basic UML Legend
Concept Outline
Legend
Author
dependency
realize
Publisher
Book
compose
1..*
aggregate
associate
Chapter
Preface
generalize
Biography
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).
EHR SD RM - EHR Way Forward … Future State Reference Architecture
Slide 15
Functional Analysis
Object Analysis
EHR System Design Reference Model (EHR SD RM)
Constructing a Future State EHR Reference Architecture
Requirements
Analysis
EHR SD RM - EHR Way Forward … Future State Reference Architecture
Interface Design Analysis
Service Analysis
Slide 16
16
2010 SAIF Alpha Project
The 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
EHR SD RM - EHR Way Forward … Future State Reference Architecture
Slide 17
Immunization Management ECCF Specification Stack
Subject
Specification
CIM
(Conceptual)
PIM
(Logical)
Enterprise
Viewpoint
Information
Viewpoint
Computational
Viewpoint
Engineering
Viewpoint
“Why”
Policy
“What”
Content
“How”
Behavior
“Where”
Implementation
 Inventory of
o Use Cases
o Capabilities-Services
o Requirements
o Contracts
o Stakeholders
 Business Scope
 Business Vision
 Business Objectives
 Policy & Regulations
 Applicable Rules
 Use Case Specs
 Governance.
 Technology Neutral
Standards
 Wireframes of
o architectural layers
o Components and
o Associations
 Inventory of
o Domain Entities
o Roles,
o Activities,
o Associations.
 Information Models
o Conceptual
o Domain
 Inventories of
o Capabilities-Components,
o Functions-Services.
 Requirements
o Accountability, Roles
o Behaviors, Interactions
o Functional Profiles,
o Interfaces, Contracts
 Conceptual Functional
Service Specifications
 Information Models
 Use Case Specs
o Localized
 Component. specs
o Constrained
 Interface Specs
o Project
 Interaction Specs
 Message Content
 Collaboration Participations
Specifications
 Collaboration Types
 Function Types
 Interface Types
 Collaboration Scripts
 Service Contracts
 Database Schemas  Automation Unit
 Message Schemas
 Technical Interfaces
 Transformation
 Technical Operations
Schemas (e.g., XSD)  Orchestration Scripts
Business Nodes
Business Rules
Business Procedures
Business Workflow
Technology Specific
EHR SD RM - EHR Way Forward … Future State Reference Architecture
Standards

PSM

(Implementable) 


 Inventory of Platforms/
Environments.
 Existing Platform
models, Capabilities,
Libraries and Versions.





Slide 18
Application Specs.
GUI Specifications
Component Designs
Deployment Topology
Platform Bindings
18
EHR SD RM - EHR Way Forward … Future State Reference Architecture
Slide 19
SAIF ECCF Services Aware
Interoperability
Architecture Enterprise Compliance
and Conformance
Framework
Implement
& Test
V&V
Checkpoint
EHR-S FM &
EHR-S CI-IM
EHR System
Function Model &
EHR System
ComputationallyIndependent
InformationModel
Initiation
V&V
Checkpoint
Peer
Review
“Ballot”
HL7 Development
Framework (HDF)
V&V
Checkpoin
t
Analysis
DSTU - Draft Standard for
Trial Use “Prototype”
Draft Working Document; Not
for Public Distribution
Specifications for
• Business Objects
• Components
• Capabilities
• Applications
• Systems
Interoperability Specifications for
• Messages and/or
• Documents and/or
• Services
V&V is Verification and Validation
DAM Domain Analysis Models
CDA Clinical Document Architecture
CMET Common Model Element Types
D-MIM Domain Message Information Model
Design
V&V
Checkpoint
20
PSM
SAIF ECCF
Viewpoints
CIM
CIM is Computationally Independent Model
PIM is Platform Independent Model
PSM is Platform Specific Model
PIM
Draft Working
Document; Not for
Public Distribution
EHR SD RM - EHR Way Forward … Future State Reference Architecture
Slide 21
21

SAIF Alpha-Project Conclusions
Effective SOA programs involve cooperation and coordination among a wide variety of business, technical and
functional participants from across an organization, including senior management sponsorship, business
community ownership, program management, governance, architecture, project level execution, test and
certification and sustainment teams. The HL7 EHR-SD-RM helps bring these communities together throughout a
Business Capability Lifecycle. It maps capabilities and business Information Exchange Requirements (IERs) to the
– HL7 EHR System Functional Model (EHR-S FM), to
– Healthcare Information Technology Standards Panel (HITSP)
Data Architecture,
Security and Privacy Architecture,
Harmonization Framework,
Interoperability Specifications, Constructs and their referenced standards;
– Federal Health Information Model (FHIM);
– National Information Exchange Model (NIEM)
Information Exchange Package Documents (IEPDs);
– Integrating the Healthcare Enterprise (IHE) profiles;
– Certification Commission for Health Information Technology (CCHIT) criteria and
– 2009 Health Information Technology for Economic and Clinical Health (HITECH) Act selected standards for
interoperability and meaningful use objectives and criteria.
EHR SD RM - EHR Way Forward … Future State Reference Architecture
Slide 22
EHR-S CI-IM
EHR System Computationally-Independent
Information-Model (Started Jun2010)
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.
EHR SD RM - EHR Way Forward … Future State Reference Architecture
Slide 23
HL7 RIM (Reference Information Model)
Six Core Classes Defining a Semantic Framework which
Maintains Clinical Data Context
ENTITY
ROLE
ACT (aka ACTION)
Participation
Role link
Act relationship
ACT – something that has happened or may happen
Entity – a person,
animal, organization,
or thing
Language
/
Role – a responsibility of, or part played by, an Entity
communication
Participation
– the involvement of a Role in an Act
Act Relationship – a relationship between two Acts
Role Link – a relationship between two Roles.
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.
The HL7 RIM supports EHR interoperability; an EHR may
needs additional foundation classes (e.g., Responsibility)
EHR SD RM - EHR Way Forward … Future State Reference Architecture
Slide 24
Federal Health Information Model (FHIM) Person
Model (Harmonized with RIM, HIPAA & HITSP)
EHR SD RM - EHR Way Forward … Future State Reference Architecture
Slide 25
HL7 EHR System
Computationally-Independent
Information-Model
(EHR-S CI-IM) Project
Draft Working Document; Not for
Public Distribution
EHR-S
CI-IM
RIM
Classes
Entity a.b.c
EHR-S Data Modules
EHR-S
FM
…
1:1
DC x.y.z EHR-S
Function Profile
Relationshi
p between
…
Function
Profiles
and
SC x.y.z EHR-S
Function Profile
…
IN x.y.z EHR-S
Function Profile
…
DC is Direct Care
SC is Supportive Care
IN is Infrastructure
Data
Profiles
For each
EHR-S
Function,
its Data
Profile =
Set of RIM
Classes
and their
EHR-S Data
Modules
Entity d.e.f
1:N
…
EHR-S Data Modules
Relationship
among
…
Role d.e.f
Data Profiles
Role a.b.c
Act a.b.c
EHR-S Data Modules
…
and
RIM
Classes
…
Act d.e.f
…
Act Relationship a.b.c
Act Relationship d.e.f
EHR-S Data Modules
…
…
Role Link a.b.c
EHR-S Data Modules
…
Participation a.b.c
EHR-S Data Modules
…
Role Link d.e.f
…
Participation d.e.f
…
Slide 26
Harmonization Framework and Exchange
Architecture (HF&EA) Started Jun 2010
The first objective of this HL7 Harmonization Framework and Exchange Architecture (HF&EA)
project is to define a notional set of architectural artifacts for HL7 projects and EHR System
(EHR-S) development or acquisition projects. The second objective is to define the
relationships among HL7 architectural artifacts and how they relate to other healthcare
related standards and architectural artifacts, which can support a Model Driven Architecture
(MDA) waterfall, spiral, agile or other development methodology. The third objective is to be
an implementation guide for the use of the HL7 Development Framework (HDF) process
and HL7 Service Aware Interoperability Framework Enterprise Compliance and
Conformance Framework (SAIF ECCF) structure by which architectural work products are
reused or developed, are organized into an Interoperability Specification and used
throughout an architecture development project, the governance that should be enacted on
these work products, and the scope of the standardization effort itself. The fourth objective
is to define a Healthcare Information Exchange Model (H-IEM) for model-driven Healthcare
Information Exchange Package Documentation (H-IEPD) and exchange architecture. The
fifth objective is to demonstrate how the HDF and ECCF can complement other frameworks
such as TOGAF, Agile Scrum, DODAF and Zachman.
EHR SD RM - EHR Way Forward … Future State Reference Architecture
Slide 27
Example of SAIF Traceability
Using HL7 EHR-S FM
Business Viewpoints
Information Viewpoints
Conceptual Independent Model
Platform Independent Model
Platform Specific Model
Conceptual Independent Model
Platform Independent Model
Platform Specific Model
Engineering/Technical
Viewpoints
Conceptual Independent Model
Platform Independent Model
Platform Specific Model
NCIDs
NCIDs
NCIDs
Behavioral
Viewpoints
HL7 SDO
EHR-S FM
NCIDs
Conceptual Independent Model
Platform Independent Model
Platform Specific Model
Key to Traceability
Traceability is achieved by using Numeric Concept Identifiers (NCIDs) from the HL7 EHR System Functional Model (EHR-S FM)
as attributes to all SAIF artifacts. This is analogous to a library system, which uses Dewey decimal numbers as book identifiers.
28
Slide 28
Notional EHR SD RM Logical View
class IRD&M
CONOPS
Healthare
Deliv ery
Stakeholder
Needs
IT Syatem
A
Healthcare
Systems
Force
Health
Protection
PMO
X
B
DHIMS
Y
C
DHIS
Z
EHR-S FM NCID
IM Capability
DC1
LI-1
S2
TIMPO
Alpha
Beta
LI-2
IN3
Funding Source
LI-3
Gamma
Each association has one-or-more SDO DAM NCIDs
D
EHR-S FM NCIDS are hierarchical, such as:
DC.1.0.0.0 is Care Management
DC.1.7.0.0 is Orders and Referrals Management.
DC.1.7.2.0 is Non-Medication Orders and Referrals Management.
DC.1.7.2.2 Manage Orders for Diagnostic Tests.
"We must collect the data in the way we want to use the date." Data use will determine the associations we
must maintain! Associations above are each labeled with one or more NCID numbers; The associations will
change depending on the audit questions we may want to ask. As an example:
 What system support a particular user need?
 What funding sources were used to pay for a particular user need?
 What systems suport a particular IM capability?

...
29
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 Architecture
SAIF Implementation Guide
EHR SD RM - EHR Way Forward … Future State Reference Architecture
Slide 30
EHR SD RM Issue
 2011 Representation?
– Linked XML (most flexible for documentation, current preference)
–
–
–
–
–
–
–
–
–
–
EHR–S FM (R2) and it’s profiles (2011)
HL7 Domain Analysis Models (DAMS) and Detailed Clinical Models (DCMs)
HITSP (2010) Interoperability Specifications and constructs
ARRA MU Meaningful Use Objectives & Criteria (2010)
EHR CI-IM, FHIM and NIEM (TBD)
Local Profile
Investment Portfolio (Capabilities vs. funding line items and year)
Systems (Configuration Managed Capabilities)
Responsible Organizations (Program/Project Management Offices)
Innovation Projects
– Modeling Tool (graphically based … best for presentations)
– Enterprise Architect
– Eclipse IBM/ Rational
– Eclipse Papyrus
– Other Representation (HL7 MIF)
SAIF ECCF integration/ Pre-population Use
Project Specific Web-based Ad-Hoc Report Generator
EHR SD RM - EHR Way Forward … Future State Reference Architecture
Slide 31
The National Way Forward (Oct 2010)
ONC Standards and Interoperability Framework
Standards
Development
(TBD)
Use Case Development
and Functional
Requirements
(Accenture)
Harmonization of
Core Concepts
(Deloitte)
Pilot Demonstration
Projects
(Lockheed Martin)
Implementation
Specifications
(Deloitte)
Reference
Implementation
(Lockheed Martin)
Certification
and Testing
(Stanley/Deloitte)
Tools and Services
(Use Case Development, Harmonization Tools, Vocabulary Browser, Value Set Repository, Testing Scripts, etc)
(Stanley)
EHR SD RM - EHR Way Forward … Future State Reference Architecture
Slide 32
Contact Information
Nancy Orvis
Steve Hufnagel
Chief Integration Architect
Enterprise Architect, TIAG contract support
Office of the Chief Information OfficerOffice of the Chief Information Officer
DoD Military Health System
DoD Military Health System
Email: nancy.orvis@tma.osd.mil
Email: steven.hufnagel.ctr@tma.osd.mil
HOW TO PARTICIPATE:
Coordinate with SHufnagel@tiag.net, 703-575-7912-cell.
We have a weekly telecom each Friday 1230-1330 Eastern
PHONE:
+1 770-657-9270, CODE: 071582#
WEB LINK:
http://my.dimdim.com/hssp
PROJECT WIKI: http://hssp.wikispaces.com/Reference+Architecture
Backup Slides Follow
33
RECORDS MANAGEMENT
DECISION SUPPORT
PERFORMANCE
Agnostic
Services
DATA MANAGEMENT
ANALYTIC
EHR SD RM - EHR IT
Way
Forward … Future State Reference Architecture
PLATFORM
INTEGRATED
REQUIREMENTS
DESIGNS:
Putting the
H-SOA-RA
Pieces Together
Federated
Business
Services
Inter-Service
Inter-Agency
SUPPORT
Across
Providers
DOCUMENT
OUTPATIENT OTHER
SUPPLY CHAIN:
(ORDERS/CHARGES)
ER
SCHEDULING
ASU
AUTHORIZATION
CLINIC
Core Business
Services
TERMINOLOGY
INPATIENT
IDENTITY
TEST ONLY
Ancillary
Systems
Federated Services,
may be categorized by:
-- Encounter Types
-- CMS billing category
-- Record type
-- Care setting type
-- etc.
Data sets are defined for
each system functionalSlide
34
capability-service
module 34
EHR SD RM Supporting Requirements, Governance & Architectural Processes
35
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.
EHR SD RM - EHR Way Forward … Future State Reference Architecture
Slide 36
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
EHR SD RM - EHR Way Forward … Future State Reference Architecture
Slide 37
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.
EHR SD RM - EHR Way Forward … Future State Reference Architecture
Slide 38
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.
EHR SD RM - EHR Way Forward … Future State Reference Architecture
Slide 39
HITSP/C83 Data Module Categories
Module 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
EHR SD RM - EHR Way Forward … Future State Reference Architecture
Slide 40
Federal Health Information Model (FHIM)
Process
Define
Strategy
Define
Modeling
Process
Define
Style
Guide/
Tools
Present
UML Models,
XML
schema
Gather
Establish
Participants Workgroups
Draft
Models /
Document
Concepts
& codes
Vet
Model &
Data
Dictionary
Harmonize
Feedback
Domain Workgroup Plan
Person
Workgroup
Enrollment
Eligibility
Coordination
of Benefits
Workgroup
Security
&
Privacy
Workgroup
Behavioral
Health
Pharmacy
Workgroup
EHR SD RM - EHR Way Forward … Future State Reference Architecture
Lab
Workgroup
Slide 41
tbd
PART III Prototype EXAMPLE
 Vaccination and Adverse Event Reporting Prototype
– AHIC Use Cases
– EHR-S FM
– HITSP Capabilities
– Information Model
EHR SD RM - EHR Way Forward … Future State Reference Architecture
Slide 42
SAIF Alpha-Project Description
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 HL7’s EHR System Design Reference Model (EHR-SD RM)
– Linking EHR System Functional Model, FHIM, HITSP, HITECH, HSSP, IHE, NIEM
 To provide an Exchange Architecture baseline suitable for an EHR related
– SOA acquisition, development or certification project.
EHR SD RM - EHR Way Forward … Future State Reference Architecture
Slide 43
EHR-SD RM Prototype [2008 AHIC Use Cases]
Immunization and Response Management (IRM)
 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 - EHR Way Forward … Future State Reference Architecture
Slide 44
EXAMPLE ARTIFACT: Vaccine and Drug Administration and Reporting Information Exchanges
45
45
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
46
EHR-SD RM Prototype
Information 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
47
EHR-SD RM Prototype
Data Requirements (DRs)
Vaccine and Drug Administration and Reporting Use Case

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
For details, see HITSP IS 10
Immunization and Response
Management, available at
www.HITSP.org
48
EHR-SD RM Prototype
HITSP 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
49
EXAMPLE ARTIFACT
HL7 Requirements and Certification Criteria and HITSP Design
class EHR-S FM: CAP131 Update Immunization Registry
CAP131 Update Immunization Registry
DC.1.8.2 (Manage Immunization Administration)
CAP132 Retrieve Immunization Registry Information
CAP133 Communicate Immunization Summary
HL7
EHR System
Functional Model
HITSP
Interoperability
Specifications
50
EXAMPLE ARTIFACT
EHR-S Requirements
51
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)
IN.2.5.2 (Manage Structured Health Record Information)
IN.3 Registry and Directory Services
S.1.1 (Registry Notification)
IN.4.1 (Standard Terminologies and Terminology Models)
S.2.2.2 (Standard Report Generation)
IN.4.2 (Maintenance and Versioning of Standard Terminologies)
S.3.7.1 (Clinical Decision Support System Guidelines Updates)
IN.1.6 (Secure Data Exchange)
IN.4.3 (Terminology Mapping)
IN.5.1 (Interchange Standards)
IN.1.7 (Secure Data Routing)
IN.5.2 (Interchange Standards Versioning and Maintenance )
IN.2.4 (Extraction of Health Record Information)
IN.6 Business Rules Management
IN.2.5.1 (Manage Unstructured Health Record Information)
52
EXAMPLE ARTIFACT
HITSP Interoperability Design Specifications
uc CAP131 Update Immunization Registry
Content Consumer
Content Creator
CAP131 Update Immunization Registry
HITSP/C72 Immunization Message Component
Message Receiver
Message Sender
Request Patient Identification
HITSP/SC110 - Request Patient Identifier
HITSP/SC115 – HL7 Messaging
Request HL7 Message
Respond to HL7 Message
HITSP/T24 Pseudonymize
53
IS10 IRM
HITSP
Constructs
Mapped to
Standards
54
HITSP and Immunization Use Case
# Capability
1 Standards Org
2 Service Specification
3 Standards Org
4
5
6
7
Service Specification
Profile Org
SOA Profile
Profile Org
Patient Identification
Identification Service
Functional Model
Identification Service
Specification
Data Retrieval and Update
HL7
Decision Support
Retrieve, Locate, Update SFM
OMG
Decision Support SFM
Retrieve, Locate, Update Spec
IHE
SOA White Paper
IHE
Decision Support Service Spec
Immunization
Content (IC)
Query for
Existing
Data (QED)
8 Immunization Profile
9 Profile Org
10 Immunization Profile
11 Immunization Profile
12 Standards Org
13 Original Standard
PIX/PDQ
PIX/PDQ
SC110
SC110
CAP119
CAP133
SC112
CAP123
SC113
Draft: 2.5
Impl Guide
2.3.1 Impl
Guide
American Immunization Registry Association/CDC
Draft: 2.5
Impl Guide
2.3.1 Impl
Guide
CAP131
CAP132
SC115
CAP131
CAP132
SCII5
Request for
Clinical
Guidance
CAP133
(IC payload)
HL7
V2
V3 Patient
Admin
messaging
V2
V3 Care
V3 (POIZ)
Record Immunization
V3 Care
messaging messaging Record CDA
EHR SD RM - EHR Way Forward … Future State Reference Architecture
V3 Care
Record
messaging
Slide 55
V3 POIZ
messaging
Immunization Use Case - Simplified
# Capability
Patient Identification
Data Retrieval and Update
1 Standards Org
2 Service Specification
HL7
Identification Service
Functional Model
Retrieve, Locate, Update SFM
3 Standards Org
4
5
6
7
Service Specification
Profile Org
SOA Profile
Profile Org
8 Immunization Profile
12 Standards Org
13 Original Standard
Decision Support
Decision Support
SFM
OMG
Identification Service
Specification
Decision Support
Service Spec
PIX/PDQ
Retrieve, Locate, Update Spec
IHE
SOA White Paper
IHE/American Immunization Registry Association/CDC
Query for Immunization
Existing Content (IC) Request for Clinical
Data (QED) CAP119
Guidance
Future
PIX/PDQ Draft: 2.5 CAP123 CAP133
CAP133
SC110
SC110
Impl Guide
SC113
SC112
(IC payload)
HL7
V2
V3 Patient
Admin
messaging
V2
V3 Care
Record
V3 Care
messaging Record CDA
EHR SD RM - EHR Way Forward … Future State Reference Architecture
Slide 56
V3 Care Record
messaging
Immunization Use Case Within
HL7 SAEAF ECCF Specification Stack
#
Patient Identification
Identification Service
Functional Model
Identification Service
Specification
PIX/PDQ
SC110
7
8
9
Decision Support SFM
Retrieve, Locate, Update Spec
Decision Support
Service Spec
Information View (Payloads)
5
6
Retrieve, Locate, Update SFM
Computational View (Service Definitions)
3
4
Decision Support
Enterprise View (Service Functional Models)
1
2
Data Retrieval and Update
V2
Future Draft:
PIX/PDQ
2.5 Impl
SC110
Guide
Query for Immunization
Content (IC)
Existing
Data (QED) CAP119
Request for Clinical
Guidance
CAP123 CAP133
CAP133
SC113
SC112
(IC payload)
Implementation View (Vendor Implementations)
V3 Patient
Admin msg
V2
Base Standard
V3 Care
V3 Care
Record msg Record CDA
EHR SD RM - EHR Way Forward … Future State Reference Architecture
V3 Care Record mesg
Slide 57
Service Definition
Ref: A Service-Oriented Architecture (SOA) View of IHE Profiles IHE 2009
EHR SD RM - EHR Way Forward … Future State Reference Architecture
Slide 58
Meaningful Use Rules and Regs
# Capability
1 Standards Org
2
3
4
5
6
7
Patient Identification
Identification Service
Service Specification
Functional Model
Standards Org
Identification Service
Service Specification
Specification
Profile Org
SOA Profile
Profile Org
Data Retrieval and Update
HL7
Decision Support
Retrieve, Locate, Update SFM
OMG
Decision Support SFM
Decision Support Service
Spec
Retrieve, Locate, Update Spec
IHE
SOA White Paper
IHE
Query for
Immunization
Existing
Content (IC) Request for
Data
Clinical
CAP119
(QED)
Guidance
CAP123
CAP133 CAP133 (IC
PIX/PDQ PIX/PDQ
SC113
SC112
8 Immunization Profile SC110 SC110
payload)
9 Profile Org
American Immunization Registry Association/CDC
Draft: 2.5
Draft: 2.5
10 Immunization Profile Impl Guide
Impl Guide
2.3.1 Impl
2.3.1 Impl
Guide
Guide
11 Immunization Profile
12 Standards Org
13 Original Standard
CAP131
CAP132
SC115
CAP131
CAP132
SCII5
HL7
V2
V3 Patient
Admin msg
V2
V3 (POIZ)
V3 Care Immunization
V3 Care
Record msg
msg
Record CDA
EHR SD RM - EHR Way Forward … Future State Reference Architecture
V3 Care
Record
messaging
Slide 59
V3 POIZ
messaging
Immunization Management Case Study
Questions?
Nancy.Orvis@tma.osd.mil
Stephen.Hufnagel.ctr@tma.osd.mil
Akirnak@swpartners.com
JohnRitter1@verizon.net
HOW TO PARTICIPATE:
Coordinate with SHufnagel@tiag.net, 703-681-3929 or 703-575-7912-cell.
We have a weekly telecom each Friday 1230-1330 Eastern
PHONE:
+1 770-657-9270, CODE: 071582#
WEB LINK:
http://my.dimdim.com/hssp
PROJECT WIKI: http://hssp.wikispaces.com/Reference+Architecture
EHR SD RM - EHR Way Forward … Future State Reference Architecture
Slide 60