0. HL7 “EHR SD RM” Project “EHR System Design Reference Model”
HL7 SAIF Alpha Project Report
Documented in Appendix of
The Practical Guide to SOA in Healthcare Volume II:
Immunization Management Case Study
For presentation at HL7 Rio Workgroup Meeting, 18 May 2010
Practical Guide:
EHR SD RM info:
Nancy Orvis, GovProjects; Stephen.Hufnagel, SOA
Alean Kirnak, PHER; John Ritter, EHR

1. EHR SD RM Milestones
2008
2009
2010
2011
Healthcare SOA Reference Architecture
(H-SOA-RA)
EHR SD RM Immunization & Response Management (IRM) Prototype
Oct
HSSP Practical Guide for SOA in Healthcare Volume II: Immunization Case Study
Informative Reference __________
EHR SD RM Informative Reference
Jan
EHR SD RM DSTU
Oct
Normative Standard
DSTU is Draft Standard for Trial Use (ANSI standards development)

2. SAIF Alpha Project Documentation Plan The Practical Guide For SOA in Healthcare Volume II
Version A, dated 26 Mar 2010 Table of Contents
Version B, dated 02 Apr 2010 Background Section (1st Draft)
Version C, dated 09 Apr 2010 Executive Summary, TOGAF ADM and SAIF Sections (1st Draft)
Version D, dated 16 Apr 2010, Executive Summary and TOGAF ADM (2nd Draft)
Version E, dated 30 Apr SAIF-ECCF Appendix (2nd Draft)
Version F, dated 30 Apr IHE, TOGAF ADM and SAIF Sections (3th Draft)
Version G, dated 07 May 2010, Full document edit, cleanup, review and gap identification
Version H, dated 14 May 2010, Document & Slides for HL7 WG meeting in Rio de Janeiro.
TODO …
Version ?, dated summer 2010, ECCF architectural artifact ontology & glossary
Version ?, dated summer 2010, Add FHIM to IMC specification
Version ?, dated summer 2010, Add NIEM IEPDs to IMC specification
Version ?, dated summer 2010, Add CCHIT certification criteria to IMC
Version ?, dated summer 2010, Integrate NHIN Connect & Direct Services into ECCF PIM
Version ?, dated summer 2010, Add UITS IMC Platform Specific specifications
Version ?, dated summer 2010, Enhance the TOGAF & ECCF discussions linking views together
Version ?, dated summer 2010, Refine ECCF Conformance Statements
Version 1.0, dated 01-Oct-2010, for HL7 24th Annual Plenary & Working Group Meeting

3. 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, HITEC, HSSP, IHE, NIEM
To provide an Exchange Architecture baseline suitable for an EHR related
SOA acquisition, development or certification project.

4. SAIF Alpha-Project Approach
Two use cases from the Health and Human Services (HHS) American Health Information Community (AHIC) were used. The Immunization Response Management (IRM) use case and its Vaccine and Drug Administration and Reporting scenario and the Public Health Case Reporting (PHER) use case were used to develop the business architecture, Information Exchange Requirements (IERs), data requirements, interoperability specifications and conformance statements for the IMC’s Services.
EHR System Functional Model defined requirements
HITSP Defined Interoperability Specifications
IHE Defined Implementation Profiles

5. Immunization Management Conclusions
Updating Legacy System Standards - The HITSP selected Immunization message is HL7 v2.5. Most existing immunization repositories are using HL7 v2.31. It is difficult to justify the expense to bring legacy system to current standards.
Social Issues Trump Technical Issues - The Case Study shows an Immunization Management Capability technical solution; it does not address the more socially challenging Service Contract needed among stakeholders (e.g., agencies, states, hospitals).
There is an implicit common information model across immunization standards, which require a explicit common information model. .
SOA changes the cost equation from N squared to a linear cost per interface
Reuse has been shown to increase quality and reduce cost.

6. SAIF Alpha-Project Conclusions
The TOGAF ADM is a rigorous process, which efficiently led us to produce a set of clear, complete, concise, correct and consistent interoperability specifications and conformance statements.
The SAIF-ECCF is an architectural “Exchange Architecture;” we used it as an architectural executive summary to effectively present the IMC interoperability specifications and conformance statements.
Other architecture development methods or other architectural frameworks, such as the Rational Unified Process, the Zachman or the DOD Architectural Framework can complement and benefit-from HL7’s EHR-SD-RM and SAIF-ECCF to build and present an exchange architecture, interoperability specifications and conformance statements.

7. 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.

8. Project Value Use Case
One of the most difficult challenges facing healthcare organizations making IT investments today comes from deciding whether to go all-in with a particular vendor, or whether to self-integrate components from multiple vendors. The appeal of the single-vendor solution is strong – no finger-pointing, out-of-the-box integration, [US-based] EHR certification via the Certification Commission for Healthcare IT (CCHIT), and so on. This is contrasted with seemingly increased risk and work involved in a multi-vendor solution involving integration. A multi-vendor SOA solution can offer compelling best-of-breed options; where, a SOA promotes an easier integration and alignment across suppliers into a cohesive, testable and certifiable architecture. We demonstrated an approach that can build and present consistent Interoperability Specifications (IS) and conformance criteria for both best-of-suite and best-of-breed components and their exchange architecture. Having these ISs, exchange architectures, certification criteria and associated business cases is the appropriate due diligence needed to help justify a best-of-suite vs. best-of-breed decision.

9. Suggested SAIF ECCF Specification Stack Template

10. Meet in the Middle
Copyright 2009 Software Partners LLC

11. Standards Overlap For Services#
Service
Identification
Retrieve, Locate and Update
Decision Support 1
Standards Org
HL7 2
Capability
Identification Service Functional Mode
Retrieve, Locate, Update SFM
Decision Support SFM 3
OMG 4
Service Definition
Identification Service Specification
Retrieve, Locate, Update Spec
Decision Support Service Spec 5
Profile Org
IHE 6
Interoperability Layer
PIX/PDQ
Immunization Content (IC)
Immunization Content
Request for Clinical Guidance 7
AIRA/CDC 8
Draft: 2.5 Implemen- tation Guide 9
2.3.1 Implemen- tation Guide 10 11
Base Standard
Version 2
Version 3 Patient Admin messaging
Version 3 Immunization (POIZ) messaging
Version 3 Care Record CDA
Version 3 Care Record messaging

12. Overlap Removed – Transform into Taxonomy
Task Service
GetPatientIZStatus
Mediating Service
Identification
Retrieve, Locate, Update
Decision Support
Utility Service
PIX/PDQ transactions
HL7 Version 2.5 Imple-mentation Guide VXU, RIH
Version 3 Immuni- zation (POIZ) messaging
XDS.b, Immuni- zation Content (IC)
Request for Clinical Guidance, Immunization Content

13. Deployment Example
Copyright 2009 Software Partners LLC

14. Immunization Management ECCF Specification Stack
Subject
Specification
Enterprise
Viewpoint
“Why”
Policy
Information
“What”
Content
Computational
“How”
Behavior
Engineering
“Where”
Implementation
CIM
(Conceptual)
Inventory of
Use Cases
Capabilities-Services
Requirements
Contracts
Stakeholders
Business Scope
Business Vision
Business Objectives
Policy & Regulations
Domain Entities
Roles,
Activities,
Associations.
Information Models
Conceptual
Domain
Inventories of
Capabilities-Components,
Functions-Services.
Accountability, Roles
Behaviors, Interactions
Functional Profiles,
Interfaces, Contracts
Conceptual Functional Service Specifications
Inventory of Platforms/ Environments.
PIM
(Logical)
Applicable Rules
Use Case Specs
Governance.
Technology Neutral Standards
Wireframes of
architectural layers
Components and
Associations
Localized
Constrained
Project
Message Content Specifications
Component. specs
Interface Specs
Interaction Specs
Collaboration Participations
Collaboration Types
Function Types
Interface Types
Collaboration Scripts
Service Contracts
Existing Platform models, Capabilities, Libraries and Versions.
PSM
(Implementable)
Business Nodes
Business Rules
Business Procedures
Business Workflow
Technology Specific Standards
Database Schemas
Message Schemas
Transformation Schemas (e.g., XSD)
Automation Unit
Technical Interfaces
Technical Operations
Orchestration Scripts
Application Specs.
GUI Specifications
Component Designs
Deployment Topology
Platform Bindings 14

15. Standards Sources of ECCF Content

16. SAIF Lessons Learned (slide 1 of 3)
An ECCF SS can be presented as an “Architectural Executive Summary” or “Information Exchange Architecture” to add value to a project.
A mature ECCF SS must be clear, complete, concise, correct, consistent and traceable, as a whole. ECCF documentation is misleading by saying that viewpoints must be horizontally consistent and vertically traceable.
Architectural artifact granularity may not match ECCF categories (e, g,. component data and functions)

17. SAIF Lessons Learned (slide 2 of 3)
The ECCF placement of architectural artifacts is not always intuitively obvious (e.g., structural specifications of modules and their information). Arguable, many of the Table 5 artifacts might be in both the Enterprise and Computational Viewpoints, such as:
Functional and non-functional Requirements
Stakeholders and their roles and capabilities
Use Case inventory and Use Case Specifications
Capabilities and their Services
Component inventory
Function-Service inventory
Contracts and business rules
Strict viewpoint traceability would require all of the above artifacts being in the Computational Viewpoint.

18. SAIF Lessons Learned (slide 3 of 3)
A value set of baseline architectural artifacts, clear definitions and an ontology is needed. Because of ambiguity, some architectural artifacts are listed in multiple cells having different purpose and contents in the respective cells (e.g., business vs. requirements level and design level capability and contracts).
Within the ECCF, “Function” and “Service” mean the same thing, considering that the difference between a well specified function and a service is that a service is public, reusable and has an associated Service Agreement or contract also known as a Distributed User Resource Sharing Agreement (DURSA).

19. Questions? Nancy.Orvis@tma.osd.mil Stephen.Hufnagel.ctr@tma.osd.mil
HOW TO PARTICIPATE:
Coordinate with or cell.
We have a weekly telecom each Friday Eastern
PHONE: , CODE: # WEB LINK:
PROJECT WIKI:

20. BACKUP 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
Presented at HL7 Atlanta Meeting, January 2010
Details available at
Dir Health Stds Participation
Architect & System Engineer
Last Updated 14 May 2010

21. 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: For Project Information, see
EHR SD RM Framework
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
Socialize EHR SD RM (HL7 Meeting, Jan 2010)
Collaborate with others within HL7 (ongoing)
Publish HL7 HSSP Practical Guide for SOA in Healthcare Part 2: Case Study (May 2010)
Solicit public comment; collaborate with IHE; HL7/OMG SOA Conference (May to Sept)
HL7 Informative ballot (Oct 2010)
HL7 Normative ballot (Oct 2011)
1 - Populate a framework of candidate healthcare services, with IERs, based on SAIF service categories
Define priority Information Exchange Requirements (IERs) Define priority Data Requirements (DRs) along with IERs
Map IERs and DRs to the framework of candidate healthcare services
Build Catalog of candidate Services from 2008 H-SOA-RA work
Show AHIC-HITSP traceability (e.g., AHIC IERs to HITSP ISs to standards)
Show NHIN traceability (align with NHIN services)
Show CCHIT traceability (align with CCHIT test criteria)
Compare and contrast framework of candidate healthcare services with Canada Infoway’s SOA and/or other SOA
2 - Define EHR-SD RM
Map Priority IERs and DRs to EHR-S FM
Map candidate services to EHR-S FM
Define EHR-SD RM based Business Transformation Architecture methodology for
Identify gaps and overlaps in HL7’s portfolio
Identify artifacts that do not now exist but are indicated in the EHR-S FM
Identify the extent of duplication that may exist across HL7 artifacts
3 - Create prototype EHR-SD RM validation case study prototype, using
AHIC-HITSP Public Health and Emergency Response use cases and Interoperability Specifications
Services Aware Enterprise Architecture Framework (SAIF)
HITSP Multi-Enterprise Architecture of Networked Services Standards (MEANS) and
HL7 HSSP Practical Guide for SOA in Healthcare “sample health” example specifications
Include mapping to MHS and DOD specific IERs and DRs
Publish HL7 HSSP Practical Guide for SOA in Healthcare Part 2: Case Study
To show HITSP, NHIN and CCHIT conformance criteria, use OMG Object Constraint Language and/or OWL Semantic Ontology specification language

22. Contents
Constructing a Future State EHR Reference Architecture
HL7 EHR System Functional Model (EHR-S FM)
Healthcare SOA Reference Framework
HL7 RIM (Reference Information Model)
HITSP Harmonization Framework
HITSP Constructs
HITSP Data Architecture
HITSP Clinical Document Components
HITSP/C83 Data Module Categories
EHR Way Forward Business Architecture Specification Framework
Future State EHR Reference Architecture Adding ARRA and FHIM
Basic UML Legend
Abbreviations
PART II: HL7 SAIF, Requirements Management, Architecture and Governance Processes
PART III: Prototype (Immunization and Adverse Event Reporting)

23. 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

24. HL7 EHR System Functional Model (EHR-S) > 160 System Functions in 4 level categorization (separate spreadsheet available for full enumeration)
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).
System Functions
Other
O Electronic Resource Planning (ERP)
O Finances
O Other
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. 24

25. 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
Functional
Areas + Focal Classes
Entity
Information
Management
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
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
Re: Focal Classes:
 The issue is less the idea of a focal class than a business focal class.
The difference is that when you model the service, you are generally modeling a service that will express the state changes of a business.
For example, via analysis, you would find the states of a business focal class (canceled, new, active, signed, finalized in lab orders for
example) and the trigger events that would correspond to state changes ("a lab is ordered", "a lab is canceled", "a lab specimen is corrupted", and so on).
 You could say that a "patient" is a focal class, but a patient ID service generally doesn't express operations to modify the state of that "object". Rather, a patientID service would generally encompass operations that would express information about the class (reconcileID or lookUpID, eg) rather than tying the service functional components to changes in the state of that class.
 It is not a subtle distinction - most clinical domains are focused on a focal class (an order, an encounter, an appointment, a schedule, a lab).
A business service is focused with exposing that class to the enterprise.
 Infrastructure services (or the subset information services) are generally function calls or based on exposing sets of information. The functional profiles of the service are generally not focused on the state of the underlying information or in the trigger events that modify the state of that information. They tend to be focused along different lines - typically along the lines of an information profile (a RIM-based patient class, eg, or a CDA-based CCD).
The focal class is explicit in a business service, generally implicit in other services. 25 25

26. HL7 EHR_S-Based Functional Architecture/Services Analysis
ETC
Infrastructure
Functions
Manage Business Rules
Interoperability
Infrastructure
Services
Security
Policy
Records Management
Audit
Terminology
Registry
Workflow
Business Rules
etc
Terminology
Unique ID, Registry, and Director
Primary Care
Critical/Emergency Care
Dental
Non-Surgical Specialty Care
Laboratory
Nursing
Pharmacy
Population Health
Behavioral Health
ETC.
Information and Records Management
Security
Lines of Business
Record Management
Manage Patient History
Preferences, Directives, Consents, and Authorizations
Core Clinical
Services
Entity Identification
Resource Location and
Updating Services
Decision Support
Orders Management
Scheduling
Image Management
Etc.
Summary Lists
Management of Assessment
Cross-Cutting Direct Care/
Support Functions
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

27. ANATOMY OF AN ANCILLARY SYSTEM
LABORATORY
RADIOLOGY
PHARMACY
CARDIOLOGY
OT/PT/SPEECH
IDENTITY
TERMINOLOGY
AUTHORIZATION
SCHEDULING
CORE BUSINESS SERVICES
SUPPLY CHAIN (ORDER/CHARGE)
DOCUMENT
RECORDS MANAGEMENT s
DECISION SUPPORT
PERFORMANCE
DATA MANAGEMENT 27

28. INTEGRATED REQUIREMENTS DESIGNS: Putting the H-SOA-RA Pieces Together
Ancillary
Systems
INTEGRATED
REQUIREMENTS
DESIGNS:
Putting the
H-SOA-RA
Pieces Together
LABORATORY
PT/OT/SPEECH
RADIOLOGY
PHARMACY
SPECIALTY CARE
RESPIRATORY
CARDIOLOGY
DIETARY
IDENTITY
TERMINOLOGY
Inter-Service
TEST ONLY
AUTHORIZATION
INPATIENT
SCHEDULING
Inter-Agency
Federated
Business
Services
SUPPLY CHAIN:
(ORDERS/CHARGES)
Core Business
Services ER
DOCUMENT
RECORDS MANAGEMENT
ASU
Federated Services, may be categorized by:
-- Encounter Types
-- CMS billing category
-- Record type
-- Care setting type
-- etc.
DECISION SUPPORT
Across
Providers
PERFORMANCE
CLINIC
DATA MANAGEMENT
OUTPATIENT OTHER
ANALYTIC
Agnostic
Services
SUPPORT
Data sets are defined for each system functional-capability-service module
IT PLATFORM 28

29. 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
Role – a responsibility of, or part played by, an Entity
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.
Language /
communication
The HL7 RIM supports EHR interoperability; an EHR may needs additional foundation classes (e.g., Responsibility)

30. Federal Health Information Model (FHIM) Person Model (Harmonized with RIM, HIPAA & HITSP)

31. Federal Health Information Model (FHIM) Process
Define
Strategy
Define
Modeling
Process
Define
Style
Guide/
Tools
Gather
Participants
Establish
Workgroups
Present
UML Models,
XML
schema
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
Lab
Workgroup
tbd

32. 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.

33. HITSP Harmonization FrameworkIS
Capability
Service Collaboration
Transaction, Transaction Package
Components
IS = Interoperability Specification
Addressing
Business
Needs
Available
for Independent
Implementation
Providing
Infrastructure,
Security,
Privacy
Defining
Information
Content
Data Architecture
Base and Composite Standards

34. HITSP Data Architecture within HITSP Harmonization Framework
HITSP Documents are available at
Detailed HITSP Data Architecture is available online at
GREEN indicates reusable elements 34

35. HITSP Clinical Document Components
HITSP Reuse Paradigm:
With HITSP/Capability 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.

36. 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
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

37. Requirements Analysis Interface Design Analysis
EHR System Design Reference Model (EHR SD RM) Constructing a Future State EHR Reference Architecture
Functional Analysis
Object Analysis
Requirements Analysis
Interface Design Analysis
Service Analysis

38. 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

39. Basic UML Legend

40. 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

41. PART II: Requirements Management, Governance, Architectural Processes and HL7 SAIF
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

42. 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.

43. Linking Business and Technical Architectures

44. EHR System Design Reference Model (EHR SD RM)
Supporting Requirements/ Architecture Development Cycle
PROCESS INPUTS
-Required Capabilities
-Environments
-Constraints
EHR
System Design
Reference Model
Capabilities, Functions,
Information and
Information Exchanges
Stakeholder
Requirements
Definition
Functions –
Dependencies
Conformance
Criteria
Conformance is a recognition of formal testing, that prove that a system provides 100% support for a given standard.
Requirements
Loop
Interface
Specifications
Requirements
Analysis
Specifications
Loop
Test
Specifications
Architectural
Specifications
Verification & Validation
Loop
Test
Loop
PROCESS OUTPUTS
-System Architecture,
-Test Specifications
-Configuration Management Baselines 44

45. 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
Test Specifications
How Requirements-Specifications are validated
Requirements Loop
Ensure all requirements are covered by at least one function
Ensure all functions are justified by a valid requirement (no unnecessary duplication)
Design Loop
Ensure all functions are covered by at least one hardware or software element
Ensure all elements of physical architecture are justified by a valid functional requirement (no unnecessary duplication)
Verification & Validation (V&V) Loop
Each requirement must be verifiable that the solution meets requirements and validated that it meets the user’s needs and expectations.
V&V can be accomplished by: Inspection, Analysis, Demonstration, Test
Test Loop
Ensure all information is covered by test specifications
Ensure all interfaces are covered by test specifications

46. EHR SD RM Supporting Requirements, Governance & Architectural Processes

47. 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.

48. HL7 SAIF Responsibilities Conformance and Compliance Framework (ECCF)
Policy
“Why”
Content
“What”
Behavior
“How”
Implementation
“Where”
Comutation
Traceable
Consistency

49. HL7 SAIF Specification Stack Views Conformance and Compliance Framework (ECCF)
Topic
Specification
Enterprise / Business View
“WHY”
Information
View
“WHAT”
Computational
“HOW”
Engineering
“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.
Specific
Rules, Procedures
Localized Information Model, Transforms, Schema
Collaboration scripts, Orchestrations, Realized Interfaces
Execution Context, Platform Bindings, Deployment Model
Policy
Content
Behavior
Implementation
Policy
Content
Behavior
Implementation
Traceable
Consistency

50. HL7 SAIF ECCF

51. HITSP Within HL7 SAIF ECCF Specification Stack
Topic
Specification
Enterprise / Business View
“WHY”
Information
View
“WHAT”
Computational
“HOW”
Engineering
“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.
Specific
Rules, Procedures
Localized Information Model, Transforms, Schema
Collaboration scripts, Orchestrations, Realized Interfaces
Execution Context, Platform Bindings, Deployment Model
Policy
Content
Behavior
Implementation
HITSP Security Framework
HITSP Data Architecture
HITSP Capability
Harmonization Requests/ Use Case
HITSP Capability
HITSP Interoperability Specification
HITSP
Component
HITSP Transaction, Transaction Package and Service Collaboration
Traceable
Consistency

52. HITSP, HL7, HITEC, FHIMS, NIEM and NHIN Within HL7 SAIF ECCF Specification Stack
Topic
Specification
Enterprise / Business View
“WHY”
Information
View
“WHAT”
Computational View
“HOW”
Engineering
“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.
Specific
Rules, Procedures
Localized Information Model, Transforms, Schema
Collaboration scripts, Orchestrations, Realized Interfaces
Execution Context, Platform Bindings, Deployment Model
Policy
Content
Behavior
Implementation
HITEC MU
HL7 EHR–S FM
HITSP Security Framework
HL RIM
FHA FHIMS
HITSP DA
HITSP Capability
HL7 EHR-S FM
Harmonization-Requests/ Use Case
HITSP Capability
Tomcat, JBoss, J2SE, Eclipse, GlassFish ESB, OpenSSO
HITSP Interoperability Specification (IS)
HITSP
Component
NIEM Information Exchange Package
NIEM,
HITSP Transaction, Transaction Package and Service Collaboration
HSSP and
NHIN-Connect
Services
Traceable
EHR-S FM is EHR System Functional Model
EHR SD RM is EHR System Design Reference Model
HITEC MU is 2009 HITEC Act Meaningful Use Objectives/ Criteria
NIEM is National Information Exchange Model
RIM is Reference Information Model
FHIMS is Federal Health Information Model & Standards
DA is Data Architecture
Consistency

53. PART III Prototype EXAMPLE
Vaccination and Adverse Event Reporting Prototype
AHIC Use Cases
EHR-S FM
HITSP Capabilities
Information Model

54. 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

55. EXAMPLE ARTIFACT: Vaccine and Drug Administration and Reporting Information Exchanges55

56. EXAMPLE ARTIFACT Vaccine and Drug Administration and Reporting Use Case Full use case available at:

57. 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

58. 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

59. 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

60. EHR System Functional Model Interoperability Specifications
EXAMPLE ARTIFACT HL7 Requirements and Certification Criteria and HITSP Design
HL7
EHR System Functional Model
HITSP
Interoperability Specifications

61. EXAMPLE ARTIFACT EHR-S Requirements

62. EXAMPLE ARTIFACT EHR-S FM Dependencies

63. EXAMPLE ARTIFACT HITSP Interoperability Design Specifications

64. IS10 IRM HITSP Constructs Mapped to Standards

65. HITSP and Immunization Use Case#
Capability
Patient Identification
Data Retrieval and Update
Decision Support 1
Standards Org
HL7 2
Service Specification
Identification Service Functional Model
Retrieve, Locate, Update SFM
Decision Support SFM 3
OMG 4
Identification Service Specification
Retrieve, Locate, Update Spec
Decision Support Service Spec 5
Profile Org
IHE 6
SOA Profile
SOA White Paper 7 8
Immunization Profile
PIX/PDQ SC110
Query for Existing Data (QED) CAP123 SC113
Immunization Content (IC) CAP119 CAP133 SC112
Request for Clinical Guidance CAP133
(IC payload) 9
American Immunization Registry Association/CDC 10
Draft: 2.5 Impl Guide 11
2.3.1 Impl Guide CAP131 CAP132 SC115
2.3.1 Impl Guide CAP131 CAP132 SCII5 12 13
Original Standard V2
V3 Patient Admin messaging
V3 Care Record messaging
V3 (POIZ) Immunization messaging
V3 Care Record CDA
V3 POIZ messaging

66. Immunization Use Case - Simplified#
Capability
Patient Identification
Data Retrieval and Update
Decision Support 1
Standards Org
HL7 2
Service Specification
Identification Service Functional Model
Retrieve, Locate, Update SFM
Decision Support SFM 3
OMG 4
Identification Service Specification
Retrieve, Locate, Update Spec
Decision Support Service Spec 5
Profile Org
IHE 6
SOA Profile
SOA White Paper 7
IHE/American Immunization Registry Association/CDC 8
Immunization Profile
PIX/PDQ SC110
Future Draft: 2.5 Impl Guide
Query for Existing Data (QED) CAP123 SC113
Immunization Content (IC) CAP119 CAP133 SC112
Request for Clinical Guidance
CAP133
(IC payload) 12 13
Original Standard V2
V3 Patient Admin messaging
V3 Care Record messaging
V3 Care Record CDA

67. Immunization Use Case Within HL7 SAEAF ECCF Specification Stack#
Patient Identification
Data Retrieval and Update
Decision Support 1
Enterprise View (Service Functional Models) 2
Identification Service Functional Model
Retrieve, Locate, Update SFM
Decision Support SFM 3
Computational View (Service Definitions) 4
Identification Service Specification
Retrieve, Locate, Update Spec
Decision Support Service Spec 5
Information View (Payloads) 6
PIX/PDQ SC110
Future Draft: 2.5 Impl Guide
Query for Existing Data (QED) CAP123 SC113
Immunization Content (IC) CAP119 CAP133 SC112
Request for Clinical Guidance
CAP133
(IC payload) 7
Implementation View (Vendor Implementations) 8
Base Standard 9 V2
V3 Patient Admin msg
V3 Care Record msg
V3 Care Record CDA
V3 Care Record mesg

68. Service Definition Ref: A Service-Oriented Architecture (SOA) View of IHE Profiles IHE 2009

69. Meaningful Use Rules and Regs#
Capability
Patient Identification
Data Retrieval and Update
Decision Support 1
Standards Org
HL7 2
Service Specification
Identification Service Functional Model
Retrieve, Locate, Update SFM
Decision Support SFM 3
OMG 4
Identification Service Specification
Retrieve, Locate, Update Spec
Decision Support Service Spec 5
Profile Org
IHE 6
SOA Profile
SOA White Paper 7 8
Immunization Profile
PIX/PDQ SC110
Query for Existing Data (QED) CAP123 SC113
Immunization Content (IC) CAP119 CAP133 SC112
Request for Clinical Guidance CAP133 (IC payload) 9
American Immunization Registry Association/CDC 10
Draft: 2.5 Impl Guide 11
2.3.1 Impl Guide CAP131 CAP132 SC115
2.3.1 Impl Guide CAP131 CAP132 SCII5 12 13
Original Standard V2
V3 Patient Admin msg
V3 Care Record msg
V3 (POIZ) Immunization msg
V3 Care Record CDA
V3 Care Record messaging
V3 POIZ messaging

70. Contact Information
Nancy Orvis
Chief Integration Architect
Office of the Chief Information Officer
DoD Military Health System
Steve Hufnagel
Enterprise Architect, TIAG contract support