ehr sd rm milestones 2008 2009 2010 2011 healthcare soa reference architecture (h-soa-ra) ehr sd rm...
DESCRIPTION
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 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. The Practical Guide is available at http://hssp.wikispaces.com/PracticalGuide EHR SD RM info is available at: ttp://hssp.wikispaces.com/Reference+ArchitectureTRANSCRIPT
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 Details available at Nancy Orvis, GovProjects;
Stephen.Hufnagel, SOA Alean Kirnak, PHER; John Ritter, EHR EHR SD
RM Milestones 2008 2009 2010 2011 Healthcare SOA Reference
Architecture (H-SOA-RA) EHR SD RM Immunization & Response
Management (IRM) Prototype 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) Project Description The Practical Guide for
SOA in Healthcare Volume II presents a case study,which adds an
Immunization Management Capability (IMC) to Volume IsSampleHealths
Service Oriented Architecture (SOA). We used theTOGAF Architecture
Development Method (ADM) and HL7 ServiceAware Interoperability
Framework (SAIF) Enterprise Conformance andCompliance Framework
(ECCF). Volume II demonstrates the use ofHL7s EHR System Design
Reference Model (EHR-SD RM) linkedartifacts (e.g., EHR System
Functional Model, FHIM, HITSP, HITEC,HSSP, IHE, NIEM, etc) to
provide an initial architectural baseline suitablefor an EHR
related SOA acquisition, development or certification project. The
Practical Guide is available at EHR SD RM info is available at:
ttp://hssp.wikispaces.com/Reference+Architecture Project Approach
Two use cases from the Health and Human Services (HHS) American
HealthInformation Community (AHIC) were used. The Immunization
ResponseManagement (IRM) use case and its Vaccine and Drug
Administration andReporting scenario and the Public Health Case
Reporting (PHER) use case wereused to develop the business
architecture, Information Exchange Requirements(IERs), data
requirements, interoperability specifications and
conformancestatements for the IMCs Services. EHR System Functional
Model defined requirements HITSP Defined Interoperability
Specifications IHE Defined Implementation Profiles SAIF
Alpha-Project Conclusions
The TOGAF ADM is a rigorous process, which efficiently led us
toproduce a set of clear, complete, concise, correct and
consistentinteroperability specifications and conformance
statements. The SAIF-ECCF is an architectural Exchange
Architecture; we used itas an architectural executive summary to
effectively present the IMCinteroperability specifications and
conformance statements. Other architecture development methods or
other architecturalframeworks, such as the Rational Unified
Process, the Zachman or theDOD Architectural Framework can
complement and benefit-from HL7sEHR-SD-RM and SAIF-ECCF to build
and present an exchangearchitecture, interoperability
specifications and conformance statements. Project Conclusions
Effective SOA programs involve cooperation and coordination among a
wide variety of business, technical andfunctional participants from
across an organization, including senior management sponsorship,
businesscommunity ownership, program management, governance,
architecture, project level execution, test andcertification and
sustainment teams. The HL7 EHR-SD-RM helps bring these communities
together throughout aBusiness 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
forinteroperability and meaningful use objectives and criteria.
Immunization Management Project Conclusions
The HITSP selected Immunization message is HL7 v2.5. Most
existingimmunization repositories are using HL7 v2.31. It is
difficult to justify theexpense to bring legacy system to current
standards. This document shows an Immunization Management
Capability technicalsolution; it does not address the more
challenging Service Contract neededamong stakeholders (e.g.,
agencies, states, hospitals). Project Value Use Case One of the
most difficult challenges facing healthcare organizations making
ITinvestments today comes from deciding whether to go all-in with a
particularvendor, or whether to self-integrate components from
multiple vendors. Theappeal of the single-vendor solution is strong
no finger-pointing, out-of-the-boxintegration, [US-based] EHR
certification via the Certification Commission forHealthcare IT
(CCHIT), and so on. This is contrasted with seemingly increasedrisk
and work involved in a multi-vendor solution involving integration.
A multi- vendor SOA solution can offer compelling best-of-breed
options; where, a SOApromotes an easier integration and alignment
across suppliers into a cohesive,testable and certifiable
architecture. We demonstrated an approach that can buildand present
consistent Interoperability Specifications (IS) and
conformancecriteria for both best-of-suite and best-of-breed
components and their exchangearchitecture. Having these ISs,
exchange architectures, certification criteria andassociated
business cases is the appropriate due diligence needed to help
justifya best-of-suite vs. best-of-breed decision. Suggested SAIF
ECCF Specification Stack Template Immunization Management ECCF
Specification Stack
Subject Specification 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
Inventor 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 SAIF Lessons Learned (slide 1 of 3)
An ECCF SS can be presented as an Architectural Executive Summaryor
Information Exchange Architecture to add value to a project. A
mature ECCF SS must be clear, complete, concise, correct,
consistentand traceable, as a whole. ECCF documentation is
misleading by sayingthat viewpoints must be horizontally consistent
and vertically traceable. Architectural artifact granularity may
not match ECCF categories (e, g,.component data and functions) SAIF
Lessons Learned (slide 2 of 3)
The ECCF placement of architectural artifacts is not always
intuitivelyobvious (e.g., structural specifications of modules and
their information). Arguable, many of the Table 5 artifacts might
be in both the Enterpriseand 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. SAIF Lessons Learned (slide 3
of 3)
A value set of architectural artifacts, clear definitions and an
ontology isneeded. Because of ambiguity, some architectural
artifacts are listed inmultiple cells having different purpose and
contents in the respective cells(e.g., business vs. requirements
level and design level capability andcontracts). Within the ECCF,
Function and Service mean the same thing,considering that the
difference between a well specified function and aservice is that a
service is public, reusable and has an associated ServiceAgreement
or contract also known as a Distributed User ResourceSharing
Agreement (DURSA). Questions? [email protected]
[email protected]
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 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 Infoways 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 HL7s 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 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
UMLLegend Abbreviations PART II: HL7 SAIF, Requirements Management,
Architecture and Governance Processes PART III: Prototype
(Immunization and Adverse Event Reporting) Constructing a Future
State EHR Reference Architecture
OBJECTIVE:A system agnostic Future State EHR Business Architecture
(BA)specified with alexicon, based upon HITSPs data architecture,
HL7s SystemFunctional Model (EHR-S FM) and HL7sReference
Information Model (RIM). A Health IT EHR BA can be modeled as
clinical stakeholder requirements andtheirworkflow-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
fromthe HITSP data models managed by the EHR Functions used within
the EHR BA,categorized using the HL7 RIM Entity, Role and
Actionfoundation classes. These concepts are the topic of this
presentation 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 ElectronicResource Planning (ERP)
/ Logisticsand Financial components, which are needed for
completeness of a Health IT Enterprise. 18 Healthcare SOA Framework
Based on HL7 EHR System Functional Model & Thomas Erls 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 sT e c h n I c a lCommon 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
CommunicationsProfiles/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 willexpress 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", "alab
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 expressoperations to modify the state of that
"object". Rather, a patientID service would generallyencompass
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, anencounter, 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 basedon exposing sets of
information. The functional profiles of the service are generally
not focusedon the state of the underlying information or in the
trigger events that modify the state of thatinformation. They tend
to be focused along different lines - typically along the lines of
aninformation 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. 19 19 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 ANATOMY OF AN ANCILLARY SYSTEM
LABORATORY RADIOLOGY PHARMACY CARDIOLOGY OT/PT/SPEECH IDENTITY
TERMINOLOGY AUTHORIZATION SCHEDULING COREBUSINESSSERVICES SUPPLY
CHAIN (ORDER/CHARGE) DOCUMENT RECORDS MANAGEMENT s DECISION SUPPORT
PERFORMANCE DATA MANAGEMENT 21 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 22 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 Actrelationship 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) HITSP Constructs A HITSP
Interoperability Specification (IS) defines a business context,
supports a businessworkflow, constrains and orchestrates underlying
constructs. A HITSP Capability (CAP) is a specification that
assembles HITSP constructs to fulfill a businessneed for
information exchanges. To use a Capability, an Interoperability
Specification or animplementation conformance statement must assign
Systems to one or more Capability SystemRoles 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 Rolemust be supported,
includingall interfaces specified by the underlying HITSP
constructsaccording to the conditions specified for the assigned
System Role. If a Capability option is selected, the implementation
must conform to the Capabilitysspecifications for that option. A
HITSP Service Collaboration (SC) binds communications
infrastructure, security and privacyconstructs together. A HITSP
Transaction Package (TP), Transaction (T), Component (C) is where
standards-basedInterface Design Specifications are specified and
conformance requirements are defined. HITSP Harmonization
Framework
IS 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 HITSP Data Architecture
within HITSP Harmonization Framework
HITSP Documents are available at Detailed HITSP Data Architecture
is available online at GREEN indicates reusable elements 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. 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 patients 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 patients genetic relatives in terms of possible or
relevant health risk factors that have a potential impact on the
patients health Social History Data defining the patients
occupational, personal (e.g. lifestyle), social, and environmental
history that have a potential impact on the patients health Medical
Equipment Medical Equipment includes implanted and external medical
devices and equipment that a patients health status depends on, as
well as any pertinent equipment or device history Functional Status
Data defining the patients 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
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 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 Basic UML Legend 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 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 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
programperformance. 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 increasedemphasis placed on linkage of
investment to agency program performance and the PRM will help
agencies produce enhanced performanceinformation. 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
opportunitiesthat span traditional organizational boundaries.
Business Reference Model - The Business Reference Model (BRM) is a
functional-driven framework for describing and organizing the
day-to-daybusiness operations of the Federal Government into Lines
of Business (LOBs), independent of the agencies that perform the
business operation. TheBRM 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 identifygovernment-wide opportunities to
leverage IT investments and assets from a service perspective. This
model helps understand the services deliveredby 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 ofBusiness (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 abilityto 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 ServiceOriented Architecture
(SOA). Furthermore, it also serves as the foundation to advance the
re-use of technology and best practices from each of theService
Components on a government-wide basis. Linking Business and
Technical Architectures EHR System Design Reference Model (EHR SD
RM)
Supporting Requirements/ Architecture Development Cycle
PROCESSINPUTS -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 offormal 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 PROCESSOUTPUTS -System Architecture,
-Test Specifications -Configuration ManagementBaselines 36 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 verifiablethat the solution meets requirements and validated
that it meets the users 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 EHR SD RM
Supporting Requirements, Governance & Architectural Processes
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 agroup
exercises its authority and demonstrates accountability for
accepted responsibilitieswithin a particular jurisdiction. SAIF
Principles: Applicable within each of HL7s 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. HL7 SAIF Responsibilities Conformance and Compliance
Framework (ECCF)
Policy Why Content What Behavior How Implementation Where
Comutation Traceable Consistency 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 HL7
SAIF ECCF 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
HITSP, HL7, HITEC, FHIMS, NIEM and NHINWithin 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 EHRS 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
NIEMInformation 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 PART III Prototype EXAMPLE
Vaccination and Adverse Event Reporting Prototype AHIC Use Cases
EHR-S FM HITSP Capabilities Information Model 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 Reportingand Scenario 2: Vaccine and Drug
Inventory Reporting EXAMPLE ARTIFACT: Vaccine and Drug
Administration and Reporting Information Exchanges EXAMPLE
ARTIFACTVaccine and Drug Administration and Reporting Use Case Full
use case available at: 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 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
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 EHR System
Functional Model Interoperability Specifications
EXAMPLE ARTIFACTHL7 Requirements and Certification Criteria and
HITSP Design HL7 EHR System Functional Model HITSP Interoperability
Specifications EXAMPLE ARTIFACT EHR-S Requirements EXAMPLE ARTIFACT
EHR-S FM Dependencies EXAMPLE ARTIFACT HITSP Interoperability
Design Specifications IS10 IRM HITSP Constructs Mapped to Standards
Contact Information Nancy Orvis Chief Integration Architect Office
of the Chief Information Officer DoD Military Health System Steve
Hufnagel Enterprise Architect, TIAG contract support