Slide 1EHR SD RM - EHR Way Forward … Future State Reference Architecture
HL7 “EHR SD RM” Project “EHR System Design Reference Model”
Constructing a Future State EHR Reference Architecture • EHR Way Ahead Business Architecture • Healthcare SOA Reference Architecture• Enterprise Information Model
From HL7 and HITSP ArtifactsFor presentation at HL7 Phoenix Workgroup Meeting, January 2010
Details available at www.HSSP.wikispaces.com/Reference+Architecture
[email protected], Chief of Integration & [email protected], Architect & System Engineer
Alean Kirnak, President, Software Partners
Slide 2EHR SD RM - EHR Way Forward … Future State Reference Architecture
Federal Enterprise Architecture (FEA)www.whitehouse.gov/omb/egov
Performance Reference Model - The FEA PRM is a framework to measure the performance of major IT initiatives and their contribution to program performance. The PRM leverages performance measurement best practices from the public and private sectors, including the Balanced Scorecard, Baldrige Criteria, Value Measurement Methodology, program logic models, the value chain, and the theory of constraints. There is an increased emphasis placed on linkage of investment to agency program performance and the PRM will help agencies produce enhanced performance information. Furthermore, the PRM will assist in: improving the alignment of program goals and objectives with Mission Area goals and objectives; improving communication of program contributions such as technology (input) to outputs and outcomes; and in identifying improvement opportunities that span traditional organizational boundaries.
Business Reference Model - The Business Reference Model (BRM) is a functional-driven framework for describing and organizing the day-to-day business operations of the Federal Government into Lines of Business (LOBs), independent of the agencies that perform the business operation. The BRM is the first layer of the Federal Enterprise Architecture and it is the organizing construct for the analysis of the other four reference models: performance, service components, data, and technology.
Service Component Reference Model - The Service Component Reference Model (SRM) is a functional framework to evaluate to identify government-wide opportunities to leverage IT investments and assets from a service perspective. This model helps understand the services delivered by the government and assess if there is an opportunity to group like services and create leverage opportunities, such as reuse or shared services.
Data Reference Model - The Data Reference Model (DRM) describes at an aggregate level, the data and information required to support the Lines of Business (LOBs). The three elements of data exchange that have been standardized include data description, data context, and data sharing. Establishing a common data model streamlines the information exchange process within and across the Federal Government and facilitates the ability to identify duplicative data resources.
Technical Reference Model - The Technical Reference Model (TRM) establishes a common technical framework for categorizing standards, specifications, and technologies that support and enable the delivery of services. This framework can be leveraged to support the development, delivery, and exchange of business and application components (Service Components) that may be leveraged in a Component-based or Service Oriented Architecture (SOA). Furthermore, it also serves as the foundation to advance the re-use of technology and best practices from each of the Service Components on a government-wide basis.
Slide 3EHR SD RM - EHR Way Forward … Future State Reference Architecture
EHR-SD RM Project Description and PlanPROJECT DESCRIPTION: HL7 EHR System Design Reference Model (EHR SD RM) This project will mature the April 2008 Healthcare Services
Oriented Reference Architecture (H-SOA-RA) version 1.0 into H-SOA-RA Version 2.0, for HL7 Architecture Review Board (ArB) consideration, and then integrate it into an EHR System Design Reference Model (EHR-SD RM), using the HL7 SOA-Aware Enterprise Architecture Framework (SAEAF), 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.
NEXT STEPS: For Project Information, see http://hssp.wikispaces.com/Reference+Architecture
1. EHR SD RM Framework– Populate the framework with HL7 EHR-S Functional Model content, candidate healthcare Information
Exchanges, HITSP capabilities/ services and data architecture 2. Information Model
– Loosely-coupled top-down Framework– Rigorously specified bottom up structure/ content based on HITSP Data Architecture
3. Socialize EHR SD RM (HL7 Meeting, Jan 2010)4. Collaborate with others within HL7 (ongoing)5. Publish HL7 HSSP Practical Guide for SOA in Healthcare Part 2: Case Study (May 2010)6. Solicit public comment; collaborate with IHE; HL7/OMG SOA Conference (May to Sept)7. HL7 Informative ballot (Oct 2010)8. HL7 Normative ballot (Oct 2011)
Slide 4EHR SD RM - EHR Way Forward … Future State Reference Architecture
class Capability
seq Capability
Business Goal
Business Process Model
Core Business Area
Business
Mission Segment
Cost Benefits Analysis
- cost- benefits- AOA
Solution
+ Actor+ Application Specification+ Logical Data Model+ Scenario+ Software (notional)+ Use Case+ Use Case Association+ Use Case Step+ Versioned Specification
Alternatives
Bold indicates addition/change to CBDI
Legend
Software/Service (Notional)
+ Inter Software Relationship+ Nonsoftware Services+ Proposed Operation+ Software Classification+ Software Classification Group+ Software Function+ Software Service+ Software/Service (notional)
User Outcome
Policy
Organization
Enterprise Information Model
+ Business Rules+ Code Set+ Data Module+ Data Structure+ Grammar+ Morphology+ Ontology+ Syntax+ Vocabulary-Terminology
Operational Activity
+ Level 1: Business+ Level 2: Component+ Level 3: Detail
Specification
Security and Privacy
Reference Architecture
Exchange Architecture
Deployment
Strategic Objectives
supportsderived from
«import»
«import»
«import»
describes
«import»
«import»
supports
derived from
supports
«import»
1..*
derived from
constrained by
«import»
«import»
«import»
Linking Business and Technical Architectures
Slide 5EHR SD RM - EHR Way Forward … Future State Reference Architecture
CONTENTS2. Constructing a Future State EHR Reference Architecture
3. HL7 EHR System Functional Model (EHR-S FM)
4. Healthcare SOA Reference Framework
5. HL7 RIM (Reference Information Model)
6. HITSP Harmonization Framework
7. HITSP Constructs
8. HITSP Data Architecture
9. HITSP Clinical Document Components
10. HITSP/C83 Data Module Categories
11. EHR Way Forward Business Architecture Specification Framework
12. Future State EHR Reference Architecture Adding ARRA and FHIM
13. Basic UML Legend
14. Abbreviations
15. PART II: HL7 SAEAF, Requirements Management Process and Governance
16. PROTOTYPE: Immunization and Adverse Event Reporting
Slide 6EHR SD RM - EHR Way Forward … Future State Reference Architecture
Constructing a Future State EHR Reference ArchitectureOBJECTIVE: A system agnostic Future State EHR Business Architecture (BA)
specified with a lexicon, based upon HITSP’s data architecture, HL7’s System Functional Model (EHR-S FM) and HL7’s Reference Information Model (RIM).
A Health IT EHR BA can be modeled as clinical stakeholder requirements and their workflow-orchestration of
HL7 RIM compliant HITSP data modules manipulated by
HL7 EHR-S FM functions.
An EHR Information Model, for a project or enterprise, can be constructed from the HITSP data models managed by the EHR Functions used within the EHR BA, categorized using the HL7 RIM Entity, Role and Action foundation classes.
These concepts are the topic of this presentation
Slide 7EHR SD RM - EHR Way Forward … Future State Reference Architecture
HL7 EHR System Functional Model (EHR-S)> 160 System Functions in 4 level categorization
(separate spreadsheet available for full enumeration)
NOTE: “Other” Category - The EHR-S model does NOT include Electronic Resource Planning (ERP) / Logistics and Financial components, which are needed for completeness of a Health IT Enterprise.
Other O-1 Electronic Resource Planning (ERP)
O-2 Finances
O-3 Other
Syst
em F
unct
ions
EHR-S FM functions can be grouped into Service Components … aka Capabilities
(e.g., Lab Order Capability, which
does eligibility and authorization
function as well as lab order function).
Slide 8EHR SD RM - EHR Way Forward … Future State Reference Architecture
Healthcare SOA FrameworkBased on HL7 EHR System Functional Model & Thomas Erl’s SOA Layers HL7 System Functions Direct Care Supportive Information
InfrastructureOther
Business Process
Value Chains
CompositeServices Federated Composition (e.g., Choreograph or Orchestration) Within and Across Business Areas
Core BusinessServices
Functional Areas + Focal Classes
Functional Areas + Focal Classes
Functional Areas + Focal Classes
Functional Areas + Focal Classes
EntityServices
Information Management
Information Management
Information Management
Information Reporting and Management
Agnostic Services C r o s s T e c h n I c a l “Common S e r v I c e s”(e.g., Security, Privacy, Auditing, Logging…)
ApplicationServices
Ambulatory Care Systems,In Patient Care Systems
Logistics SystemsFinancial Systems
Decision Support Systems
Data MartsRepositories
Business Objects
ImplementationProfiles
Integrated Healthcare Enterprise (IHE) Profiles
Analysis Profiles Communications Profiles/Stacks
Implementation Profiles
8
Slide 9EHR SD RM - EHR Way Forward … Future State Reference Architecture
HL7 RIM (Reference Information Model)Six Core Classes Defining a Semantic Framework which
Maintains Clinical Data Context
The HL7 RIM expresses the data content needed in a specific clinical or administrative context and provides an explicit
representation of the semantic and lexical connections that exist between the information carried in the fields of HL7 messages .
Role link
Act relationship
Participation
The HL7 RIM supports EHR interoperability; an EHR may needs additional foundation classes (e.g., Responsibility)
Language /
communication
ACT (aka ACTION)ROLEENTITY
ACT – something that has happened or may happenEntity – a person, animal, organization, or thingRole – a responsibility of, or part played by, an EntityParticipation – the involvement of a Role in an ActAct Relationship – a relationship between two ActsRole Link – a relationship between two Roles.
Slide 10EHR SD RM - EHR Way Forward … Future State Reference Architecture
HITSP Constructs A HITSP Interoperability Specification (IS) defines a business context, supports a business workflow,
constrains and orchestrates underlying constructs.
A HITSP capability (CAP) is a specification that assembles HITSP constructs to fulfill a business need for information exchanges. To use a Capability, an Interoperability Specification or an implementation conformance statement must assign Systems to one or more Capability System Roles and identify how the Capability Options are to be addressed. The use of a Capability shall:
– for each assigned Capability System Role, the responsibilities of the assigned System Role must be supported, including all interfaces specified by the underlying HITSP constructs according to the conditions specified for the assigned System Role.
– If a Capability option is selected, the implementation must conform to the Capability’s specifications for that option.
A HITSP Service Collaboration (SC) binds communications infrastructure, security and privacy constructs together.
HITSP Transaction Packages/ Transactions/ Components (TP/T/Cs) are where standards-based Interface Design Specifications are specified are given and conformance requirements are defined.
Slide 11EHR SD RM - EHR Way Forward … Future State Reference Architecture
HITSP Harmonization Framework
AddressingBusiness
Needs
ProvidingInfrastructure,
Security,Privacy
Data Architecture
Available for Independent Implementation
DefiningInformation
Content
IS = Interoperability Specification
Slide 12EHR SD RM - EHR Way Forward … Future State Reference Architecture
class Data Architecture
EHR System Interoperability Specifications
Capability
Data Architecture
Data Module
Data Element
Value Set
HITSP Constructs
Component (C)
Transaction Package (TP)
Transaction (T)
Service Collaboration (SC)
Selected Standard
HITSP/C83 - CDA Content Modules Component
HITSP/C154 - HITSP Data Dictionary
HITSP/ C80 - Clinical Document and Message Terminology Component
HITSP/TN903 - Data Architecture Technical Note
HITSP/TN904 - Harmonization Framework and Exchange Architecture Technical Note
HITSP/TN901 - Technical Note for Clinical Documents
Data Requirement (DR)
+ Data Module
Capability Requirements
+ Information Exchange+ option+ Scenario+ system role
ARRA Requirement for Certified EHR Systems
Information Exchange Requirement (IER)
+ Systems+ Exchange Content+ Exchange Action+ Exchange Attribute
ARRA Meaningful Use Measures
+ Stakeholder
Regulatory Guidance
Scenario
+ conditions
Certification Criteria
+ Capability
Capability Design
+ conditions+ optionality+ system role
requirementsdesign
Legend
HITSP Data Architecture within
HITSP Harmonization Framework
GREEN indicates reusable elements
HITSP Documents are available at www.HITSP.orgDetailed HITSP Data Architecture is available online at www.USHIK.org
Slide 13EHR SD RM - EHR Way Forward … Future State Reference Architecture
HITSP Clinical Document Components
HITSP Reuse Paradigm: With HITSP/Capability 119 - Communication of Structured
Documents, a HL7 Clinical Data Architecture (CDA) document can be
composed, from any group of C83 data modules, and then it can be
communicated. Benefit: agile system interoperability.
Slide 14EHR SD RM - EHR Way Forward … Future State Reference Architecture
HITSP/C83 Data Module CategoriesModule Category Description
Personal Information The personal information includes name, address, contact information, personal identification information, ethnic and racial affiliation and marital status of a person
Support Support includes the patient's sources of support, such as immediate family, relatives and/or guardians. This includes next of kin, caregivers, support organizations, and key contacts relative to healthcare decisions. Support providers may include providers of healthcare related services, such as a personally controlled health record, or registry of emergency contacts
Healthcare Providers This includes a list of the healthcare providers and organizations that provide or have provided care to the patient
Insurance Providers and Payers
Insurance providers include data about the organizations or individuals who may pay for a patient's healthcare, and the relationships, demographics and identifiers of those individuals with respect to the payer. Such organizations or individuals may be health insurance plans, other payers, guarantors, parties with financial responsibility, some combination of payers or the patient directly
Allergies and Drug Sensitivities
This includes the allergy or intolerance conditions, severity and associated adverse reactions suffered by the patient
Conditions This includes relevant clinical problems and conditions for which the patient is receiving care, including information about onset, severity, and providers treating the condition. Conditions are broader than, but include diagnoses
Medications This includes the patient's prescription or non-prescription medications and medication history, and may include prescriptions, fulfillments and medication administration activities
Immunizations This includes data describing the patient's immunization history
Vital Signs This includes data about the patient’s vital signs
Test Results This includes data about current and historical test results from laboratory or other diagnostic testing performed on the patient
Encounter This includes data describing the interactions between the patient and clinicians. Interaction includes both in-person and non-in-person encounters such as telephone and email
Procedures This includes data describing procedures performed on a patient
Family History Data defining the patient’s genetic relatives in terms of possible or relevant health risk factors that have a potential impact on the patient’s health
Social History Data defining the patient’s occupational, personal (e.g. lifestyle), social, and environmental history that have a potential impact on the patient’s health
Medical Equipment Medical Equipment includes implanted and external medical devices and equipment that a patient’s health status depends on, as well as any pertinent equipment or device history
Functional Status Data defining the patient’s functional status with respect to, ambulatory ability, mental status or competency, activities of daily living, including bathing, dressing, feeding, grooming, home/living situation having an effect on the health status of the patient, and ability to care for self
Plan of Care The plan of care contains data defining prospective or intended orders, interventions, encounters, services, and procedures for the patient
Slide 15EHR SD RM - EHR Way Forward … Future State Reference Architecture
class EHR Business Architecture Specification
HITSP Constructs
+ Component (C)+ Transaction (T)+ Transaction Package (TP)+ Service Collaboration (SC)
HITSP Capability Requirements
+ Information Exchange+ option+ Scenario+ system role
Information Exchange Requirement (IER)
+ Systems+ Exchange Content+ Exchange Action+ Exchange Attribute
Service
HITSP Capability Design
+ conditions+ optionality+ system role
Interface
SOA Layers
+ Business Processes+ Composite Services+ Core Business Services+ Component Services+ Operational Services+ Implementation Profiles
requirementsdesign
Legend
EHR Business Architecture
Selected Standard
HL7 Reference Information Model (RIM)
+ Role+ Entity+ Act+ Participation+ Act relationship+ Role relationship
HL7 EHR SD RM
+ EHR-S FM+ FHIMS+ HITSP Capability Design+ SOA Layer
NHIN Connect Service
Behavioral Model
Functional Requirements
EHR-S FM
+ Direct Care+ Supportive Care+ Information Infrastructure
Use Case
realize
EHR Future State Reference
Architecture …
EHR Way ForwardBusiness
ArchitectureSpecificationFramework
Slide 15
Functional Analysis Object Analysis
Requirements Analysis
Interface Design Analysis
Service Analysis
Slide 16EHR SD RM - EHR Way Forward … Future State Reference Architecture
class EHR Business Architecture Specification with ARRA & FHIMS
HITSP Constructs
+ Component (C)+ Transaction (T)+ Transaction Package (TP)+ Service Collaboration (SC)
HITSP Capability Requirements
+ Information Exchange+ option+ Scenario+ system role
Information Exchange Requirement (IER)
+ Exchange Action+ Exchange Attribute+ Exchange Content+ Systems
Service
HITSP Capability Design
+ conditions+ optionality+ system role
Interface
SOA Layers
+ Business Processes+ Composite Services+ Core Business Services+ Component Services+ Operational Services+ Implementation Profiles
requirementsdesign
Legend
EHR Business Architecture
Selected Standard
Certification Criteria
+ Capability
Federal Health Informations Model & Standards (FHIMS)
Federal Health Data Model
HL7 Reference Information Model (RIM)
+ Act+ Act relationship+ Entity+ Participation+ Role+ Role relationship
Clinical Document Architecture (CDA)
ARRA Meaningful Use Measures
+ Stakeholder
Agency Information Model
Agency Data Model
HL7 EHR SD RM
+ EHR-S FM+ FHIMS+ HITSP Capability Design+ SOA Layer
NHIN Connect Service
ARRA is American Recovery and Reinvestment Act of 2009FHIMS is Federal Health Information Model and StandardsEHR-S FM is EHR System Functional-ModelEHR SD RM is EHR System Design Reference-Model
Realize relationship: a source object implements or Realizes its destination object. Realize connectors are used toexpress traceability and completeness in the model.
A HITSP Capability (CAP) specifies interfaces for a set of information exchanges, grouped by system role (e.g., lab order prescriber, lab order filler).A HITSP conformant system implements the specified interfaces for the information exchanges which are required to support the selected system roles of each HITSP capability implemented within the system.
Functions vs. Services differ in that a services enforces encapsulation (e.g., information hiding), have associated governance and Distributed User Resource Sharing Agreements (DURSAs), which defines the business rules for a services' information exchanges.
A Health IT Business Architecture (BA) can be modeled as clinical stakeholders and their workflow-orchestration of system-functions, defined by the HL7 System Functional Model. HITSP Capabilities group and specify system roles, information exchanges and system interfaces to support one-or-more system functions with standards-based data models and standards-based interface specifications, which may be implemented as services. An Information Model, for a project or enterprise, can be created from a semantic network of a BA's Capability data models, categorized using the six HL7 RIM foundation classes.
EHR-S FM
+ Direct Care+ Information Infrastructure+ Supportive Care
Behavioral Model
Functional Requirements
Use Case
realize
realize
EHR Future State Reference Architecture Adding ARRA and FHIMS
For Project Information, see http://hssp.wikispaces.com/Reference+Architecture
Slide 16
Slide 17EHR SD RM - EHR Way Forward … Future State Reference Architecture
Value Proposition of Standards Based Approach
Analysis Pre-Done: Analysts from throughout industry have vetted and contributed to the development of thorough specifications
Less Customization: COTS vendors are already building applications to meet these specifications.
Comprehensive View: Standards provide a way to ensure that requirements and design address all of the necessary issues
Lack of unexpected dependencies late in project: All functions and specifications have been pre-analyzed and defined
Better Interoperability: Standards based approaches will ensure development between all stakeholders are able to communicate at the project and technical level
Across Project Visibility: Normalized requirements and design would allow for “apples to apples” comparison across the portfolio
Slide 18EHR SD RM - EHR Way Forward … Future State Reference Architecture
PART II: HL7 SAEAF, Requirements Management and Governance
• The HL7 Services-Aware Enterprise Architecture Framework (SAEAF)
• HL7 SAEAF ECCF Specification Stack
• HITSP Within HL7 SAEAF ECCF Specification Stack
• HL7, HITSP, FHIMS and NHIN Within HL7 SAEAF ECCF Specification Stack
• Business Capability Lifecycle (BCL)
• Develop/ Update Reference Architecture
• Requirements Management Process
• BACKUP SLIDES: Example (Immunization and Adverse Event Reporting)
Slide 19EHR SD RM - EHR Way Forward … Future State Reference Architecture
The HL7 Services-Aware Enterprise Architecture Framework (SAEAF)
SAEAF 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.
SAEAF Principles: Applicable within each of HL7’s three Interoperability Paradigms (IPs),
– (i.e., messages, documents, and services). Provide support for measurable conformance and compliance. Define appropriate governance structures and processes. Provide support for directly implementable solutions. Address the growing disparity between the various solution sets emerging from HL7. Utilize existing V3/RIM artifacts and expertise to the maximum degree possible.
Slide 20EHR SD RM - EHR Way Forward … Future State Reference Architecture
HL7 SAEAF Conformance and Compliance Framework (ECCF) Specification Stack Views
Consistency
Traceable
ImplementationBehaviorContentPolicy
Slide 21EHR SD RM - EHR Way Forward … Future State Reference Architecture
HITSP WithinHL7 SAEAF ECCF Specification Stack
Topic
Specification
Enterprise / Business View
“WHY”
Information View
“WHAT”
Computational View
“HOW”
Engineering View
“WHERE”
Conceptual
Business Context, Reference Context
Domain Analysis (Information) Model
Collaboration Analysis, Functional Profile(s), Service Roles and
Relationships
Existing Platform capabilities
Platform-
Independent
Business Governance Project-oriented Domain Information Model,
Constrained Information Model, Localized Information Model, Hierarchical Message
Definition
Collaboration Types, Interface Specification and Functional
Groups, Interaction Types and Collaboration Participations,
Contracts Parts
Existing Platform models, libraries, etc.
Platform-
Specific
Rules, Procedures Localized Information Model, Transforms, Schema
Collaboration scripts, Orchestrations, Realized
Interfaces
Execution Context, Platform Bindings, Deployment Model
Consistency
Traceable
HITSP DAHITSP CAP
Harmonization Requests/ Use Case
HITSP CAP
HITSP T, TP and SCs
HITSP C
HITSP IS
ImplementationBehavior
HITSP Harmonization
Framework
EHR-S FM is EHR System Functional ModelEHR SD RM is EHR System Design Reference ModelRIM is Reference Information ModelFHIMS is Federal Health Information Model & StandardsDA is Data Architecture
21
ContentPolicy
Slide 22EHR SD RM - EHR Way Forward … Future State Reference Architecture
HL7, HITSP, FHIMS and NHIN WithinHL7 SAEAF ECCF Specification Stack
Topic
Specification
Enterprise / Business View
“WHY”
Information View
“WHAT”
Computational View
“HOW”
Engineering View
“WHERE”
Conceptual
Business Context, Reference Context
Domain Analysis (Information) Model
Collaboration Analysis, Functional Profile(s), Service Roles and
Relationships
Existing Platform capabilities
Platform-
Independent
Business Governance Project-oriented Domain Information Model,
Constrained Information Model, Localized Information Model, Hierarchical Message
Definition
Collaboration Types, Interface Specification and Functional
Groups, Interaction Types and Collaboration Participations,
Contracts Parts
Existing Platform models, libraries, etc.
Platform-
Specific
Rules, Procedures Localized Information Model, Transforms, Schema
Collaboration scripts, Orchestrations, Realized
Interfaces
Execution Context, Platform Bindings, Deployment Model
Consistency
Traceable
HL7 RIMFHA FHIMSHITSP DAHITSP CAP
Harmonization Requests/ Use Case
HITSP CAP
HITSP T, TP and SCs
HITSP C
HL7 EHR-S FM
HITSP IS
HL7 EHR SD RMHITSP
Harmonization Framework
EHR-S FM is EHR System Functional ModelEHR SD RM is EHR System Design Reference ModelRIM is Reference Information ModelFHIMS is Federal Health Information Model & StandardsDA is Data Architecture
NHIN ConnectServices
Tomcat, JBoss, J2SE, Eclipse,
GlassFish ESB, OpenSSO
22
ImplementationBehaviorContentPolicy
Slide 23EHR SD RM - EHR Way Forward … Future State Reference Architecture
HITSP and Immunization Use Case# Capability Patient Identification Data Retrieval and Update Decision Support1 Standards Org HL7
2 Service SpecificationIdentification Service
Functional Model Retrieve, Locate, Update SFM Decision Support SFM3 Standards Org OMG
4 Service SpecificationIdentification Service
Specification Retrieve, Locate, Update Spec Decision Support Service Spec5 Profile Org IHE6 SOA Profile SOA White Paper7 Profile Org IHE
8 Immunization ProfilePIX/PDQ SC110
PIX/PDQ SC110
Query for Existing
Data (QED) CAP123 SC113
Immunization Content (IC) CAP119 CAP133 SC112
Request for Clinical
Guidance CAP133
(IC payload) 9 Profile Org American Immunization Registry Association/CDC
10 Immunization ProfileDraft: 2.5 Impl Guide
Draft: 2.5 Impl Guide
11 Immunization Profile
2.3.1 Impl Guide
CAP131 CAP132 SC115
2.3.1 Impl Guide
CAP131 CAP132 SCII5
12 Standards Org HL7
13 Original Standard V2
V3 Patient Admin
messaging V2
V3 Care Record
messaging
V3 (POIZ) Immunization messaging
V3 Care Record CDA
V3 Care Record
messagingV3 POIZ
messaging
Slide 24EHR SD RM - EHR Way Forward … Future State Reference Architecture
Immunization Use Case - Simplified# Capability Patient Identification Data Retrieval and Update Decision Support1 Standards Org HL7
2 Service SpecificationIdentification Service
Functional Model Retrieve, Locate, Update SFMDecision Support
SFM
3 Standards Org OMG
4 Service SpecificationIdentification Service
Specification Retrieve, Locate, Update SpecDecision Support
Service Spec5 Profile Org IHE6 SOA Profile SOA White Paper7 Profile Org IHE/American Immunization Registry Association/CDC
8 Immunization ProfilePIX/PDQ SC110
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 Standards Org HL7
13 Original Standard V2
V3 Patient Admin
messaging V2
V3 Care Record
messagingV3 Care
Record CDAV3 Care Record
messaging
Slide 25EHR SD RM - EHR Way Forward … Future State Reference Architecture
Immunization Use Case WithinHL7 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)
6PIX/PDQ SC110
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 V2V3 Patient Admin msg V2
V3 Care Record msg
V3 Care Record CDA V3 Care Record mesg
Slide 26EHR SD RM - EHR Way Forward … Future State Reference Architecture
Service DefinitionRef: A Service-Oriented Architecture (SOA) View of IHE Profiles IHE 2009
Slide 27EHR SD RM - EHR Way Forward … Future State Reference ArchitectureCopyright 2009 Software Partners LLC
27
Meet in the Middle**Anna Orlova, Josh Painter, Alean Kirnak, “A SOA View of IHE Profiles” working drafts
Slide 28EHR SD RM - EHR Way Forward … Future State Reference Architecture
Cost Effectiveness Proposition Target cost function of healthcare IT connectivity
# of service consumers * # of services
Slide 29EHR SD RM - EHR Way Forward … Future State Reference Architecture
Cost Effectiveness Proposition Target cost function of healthcare IT connectivity
# of service consumers * # of services
Slide 30EHR SD RM - EHR Way Forward … Future State Reference Architecture
Approximately 75 U.S. Immunization Information Systems (IISs)
Completely connected point-to-point IIS network: 74 * 75 / 2 = 2775 connections
Assume 200 regional provider EHRs per IIS:200 * 75 = 15,000 connections
Each connection costs $10K-$30K per side $40K each * 17,775 =$711,000,000
Point to Point Messaging Economics
30
Copyright 2009 Software Partners
Slide 31EHR SD RM - EHR Way Forward … Future State Reference Architecture
Labs Meds Allergies Cancer Registries Joint Replacement Registries Chronic Disease Registries Adverse Event Reporting …etc. Intra-enterprise communication Provider-to-Provider communication ... 100 domains increases cost to $71,100,000,000
Expand to Multiple Domains
31
Copyright 2009 Software Partners
Slide 32EHR SD RM - EHR Way Forward … Future State Reference Architecture
Schools Drug stores Airports …
Growth of Points of Care
32
Copyright 2009 Software Partners
Slide 33EHR SD RM - EHR Way Forward … Future State Reference Architecture
Tethered Untethered Wireless devices …
Growth of Personal Health Records
33
Copyright 2009 Software Partners
Slide 34EHR SD RM - EHR Way Forward … Future State Reference Architecture
Bus architecture Plug-and-play connections Common information model
How to Solve?
34
Copyright 2009 Software Partners
Slide 35EHR SD RM - EHR Way Forward … Future State Reference Architecture
Bus architecture– Build common carrier once– hide routing, translation
Plug and play connections– Eliminates cost on one side of each connection
Common information model– Allows multiple platform-specific models for a single
platform-independent model
Cost Reduction Opportunities
35
Copyright 2009 Software Partners
Slide 36EHR SD RM - EHR Way Forward … Future State Reference Architecture
75 IISs each accessing one service 15,000 EHRs, 500 products @ 30 installations
ea = 500 connections Cost @$20K is per service consumer only
$20K * (500 + 75) =$11,500,000 + cost of carrier
Drive down the $20K
Cost Reduction Opportunities
36
Copyright 2009 Software Partners
Slide 37EHR SD RM - EHR Way Forward … Future State Reference Architecture
Meaningful Use Rules and Regs# Capability Patient Identification Data Retrieval and Update Decision Support1 Standards Org HL7
2 Service SpecificationIdentification Service
Functional Model Retrieve, Locate, Update SFM Decision Support SFM3 Standards Org OMG
4 Service SpecificationIdentification Service
Specification Retrieve, Locate, Update SpecDecision Support Service
Spec5 Profile Org IHE6 SOA Profile SOA White Paper7 Profile Org IHE
8 Immunization ProfilePIX/PDQ SC110
PIX/PDQ SC110
Query for Existing
Data (QED)
CAP123 SC113
Immunization Content (IC) CAP119 CAP133 SC112
Request for Clinical
Guidance CAP133 (IC
payload) 9 Profile Org American Immunization Registry Association/CDC
10 Immunization ProfileDraft: 2.5 Impl Guide
Draft: 2.5 Impl Guide
11 Immunization Profile
2.3.1 Impl Guide
CAP131 CAP132 SC115
2.3.1 Impl Guide
CAP131 CAP132 SCII5
12 Standards Org HL7
13 Original Standard V2V3 Patient Admin msg V2
V3 Care Record msg
V3 (POIZ) Immunization
msgV3 Care
Record CDA
V3 Care Record
messagingV3 POIZ
messaging
Slide 38EHR SD RM - EHR Way Forward … Future State Reference Architecture
Proposed Meaningful Use Comments Propose use of service interfaces to satisfy need for
transport layer standards for immunizations Fill gaps in immunization standards
– Include immunizations in medical summary– Use CAP133 Immunization Content in Table 2A– Include immunizations in decision support clausesNote the immunization use case includes patient identification
Slide 39EHR SD RM - EHR Way Forward … Future State Reference Architecture
Proposed 2.5.1 Immunization Guide Changes
Clarify use of HITSP and IHE constructs Consider a service definition that combines PIX/PDQ
and IZ data retrieval and update into a composed service
Slide 40EHR SD RM - EHR Way Forward … Future State Reference Architecture
Topics for Discussion
Slide 41EHR SD RM - EHR Way Forward … Future State Reference Architecture
BPMN Business Capability Lifecycle (BCL)
IV&V TeamIM
TeamPortfolio Team
Architecture Team
Develop/ Update Business Architecture
(BA)
Develop/ Update Business Architecture
(BA)
Develop/ Update Enterprise Information
Model (EIM)
Develop/ Update Enterprise Information
Model (EIM)
Develop/ Update Reference Architecture
(RA)
Develop/ Update Reference Architecture
(RA)
Integrate Business Architecture (BAI)
Integrate Business Architecture (BAI)
Develop/ Update Strategic Plan (SP)Develop/ Update
Strategic Plan (SP)
Perform Verification and Validation
Perform Verification and Validation
Perform Quality Assurance
Perform Quality Assurance
Perform Risk AssessmentsPerform Risk Assessments
Perform TestingPerform Testing
HL7 EHR-S FM & RIM, HITSP, LSS-TIQM,
KA and KE
HL7 EHR-S FM & RIM, HITSP, LSS-TIQM,
KA and KE
Perform Governance/ Configuration Management
Perform Governance/ Configuration Management
Manage PerformanceManage PerformanceBusiness Case AnalysisBusiness Case Analysis
LSS-TIQM is Lean Six Sigma Total Information Quality MethodologyKA is Knowledge AcquisitionKE is Knowledge Engineering
Update Investment Portfolio
Update Investment Portfolio
Price Investment Portfolio
Price Investment Portfolio
Prioritize Investment Portfolio
Prioritize Investment Portfolio
Monitor InvestmentsMonitor Investments
EHR-S FM is HL7 EHR System Functional ModelHL7 RIM is HL7 Reference Information ModelHITSP is Health Information Technology Standards Panel
Business Capability Lifecycle (BCL)
RED indicates where HL7 and HITSP artifacts
can be used
KEY PROCESS
Slide 42EHR SD RM - EHR Way Forward … Future State Reference Architecture
BPMN Develop/ Update Reference Architecture
Reference Architecture (RA) Team
Analyze BusinessAnalyze Business Analyze Enablers and Architecture
Standards
Analyze Enablers and Architecture
Standards
CategorizeCategorize Define Strategic Drivers and
Prioritize Segments
Define Strategic Drivers and
Prioritize Segments
ImproveImprove Map Enablers to Business Support
Services
Map Enablers to Business Support
Services
CATEGORIZE: Analyze standard segments, eliminate segment ambiguity, map investments to standard segments
ANALYZE BUSINESS (determine parameters): cross organization review, benchmark across organizations and with industry. Compare Segment spend and architecture best practices with industry best practices.
ANALYZE ENABLERS AND ARCHITECTURE STANDARDS : Capture the enablers that cross-cut all missions. Ensure that standards are used throughout to reduce silos.
IMPROVE: Service consolidation, Resource consolidation, federate (shared) services, elininate redundant spending. Emphasize information sharing and semantic interoperability.
MAP ENABLERS TO BUSINESS SUPPORT SERVICES: Identify foundational support services that cross cut organizations. This analysis provides a bottom up view of opportunities for internal and external federated reuse, resource and information sharing and information service management.
Enterprise Information Model
Future State Reference Architecture
Transition Plan
Modernization Blueprint
Investment Portfolio
Project BPM
EHR-S FM
HL7 RIM
HITSP Constructs
Federal Segment Architecture Methodology (FSAM)
EHR-S FM is HL7 EHR System Functional ModelHL7 RIM is HL7 Reference Information ModelHITSP is Health Information Technology Standards Panel
BCL Develop/ Update Reference Architecture
RED indicates where HL7 and HITSP artifacts
can be used
Slide 43EHR SD RM - EHR Way Forward … Future State Reference Architecture
BPMN Requirements Management Process
IM Functionals
IV&VREPOSITORY
GOVERNANCE/CMIntegration Process
Document Needs,Gaps and Technical
Opportunities
Document InitialRequirements-Design
Alternatives
Document SelectedRequirements-Design
Packages
Make ExecutionDecision
Make InvestmentDecision
Enterprise Architecture
Investment Portfolio
Change Requests
Requirements
Triage ProposedProjects
EA Views Approve Acquisition Packages
CONOPS B-CASEA
DBT Packages
Approval PackagesA
Change Request
SubmissionA
CONOPS B-CASE SPECS A
CDRLs
EA Derived Products
ROLE: Document to-be Enterprise Architecture (EA) content as incremental development packages for transition plan and investment portfolio.
Milestone Decision PackagesA
IV&VAlternativeSolutions
IV&V SpecifiedSolutions
IV&VAcquisitionPackages
IV&V CDRLS
IV&V ProposedProjects
Business Stakeholder ResponsibilityMHS Central ResponsibilityDocument Package
Legend
ROLE: Validation - "Are we meeting the users' needs?" and Verification " Are we building it according to specifications?
Define Needs, Gapsand TechnicalOpportunities
Create InitialRequirements-Design
Alternatives
Refine SelectedRequirements-Design
Packages
IV&V SelectedPackage
CDRLs
CDRL
EHR-S RM
HL7 RIM
HITSP Constructs
CCHIT Criteria
RefinementRefinement
Requirements Management Process
Slide 43
Slide 44EHR SD RM - EHR Way Forward … Future State Reference Architecture
Prototype
Vaccination and Adverse Event Reporting Prototype– AHIC Use Cases– EHR-S FM– HITSP Capabilities– Information Model
Slide 45EHR SD RM - EHR Way Forward … Future State Reference Architecture
Use Case 1: Immunization and Response Management (IRM) and Use Case 2: Public Health Case Reporting (PHCR)
– 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
– The Public Health Case Reporting AHIC Use Case and HITSP Interoperability Specification supports the bi-directional information exchanges of the Public Health Case Reporting process
– The Public Health Case Reporting Use Case addresses numerous domains which have similar content and processes at a high level, but which also are dissimilar in report content details and case management processes when considering any specific report
EHR-SD RM PrototypeRequirements from 2008 AHIC Use Cases
Slide 46EHR SD RM - EHR Way Forward … Future State Reference Architecture 46
EXAMPLE ARTIFACT: Vaccine and Drug Administration and Reporting Information Exchanges
Slide 47EHR SD RM - EHR Way Forward … Future State Reference Architecture
EXAMPLE ARTIFACT Vaccine and Drug Administration and Reporting Use Case
Full use case available at: http://healthit.hhs.gov/portal/server.pt?open=512&objID=1255&parentname=CommunityPage&parentid=1&mode=2&in_hi_userid=10741&cached=true
Slide 48EHR SD RM - EHR Way Forward … Future State Reference Architecture
EHR-SD RM PrototypeInformation Exchange Requirements (IERs)
Use Case 1: Immunization and Response Management (IRM)
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
Blue Italics indicates IERs,
which are common to 1-
IRM and 2-PHCR
Slide 49EHR SD RM - EHR Way Forward … Future State Reference Architecture
DR08 Unstructured Data DR11 Immunization response data DR12 Adverse Event Report DR13 Drug/Vaccine Inventory Data DR14 Drug/Vaccine Inventory Usage Data DR15 Drug/Vaccine Inventory Availability Data DR16 Supply Chain Management Vaccine Recall DR17 Decision Support Data DR18 Vaccination Data DR19 Medication Administration data DR20 Aggregate Inventory of Available Vaccine DR21 Terminology Data DR22 Generic Alert Data DR23 Consumer Vaccination View
EHR-SD RM PrototypeData Requirements (DRs)
Use Case 1: Immunization and Response Management (IRM)
For details, see HITSP IS 10 Immunization and Response
Management, available at www.HITSP.org
Blue Italics indicates common
across IRM and PHCR
Slide 50EHR SD RM - EHR Way Forward … Future State Reference Architecture
EHR-SD RM PrototypeIRM Information Exchange Requirements (IERs)
Use Case 2: Public Health Case Reporting (PHCR)
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
IER29 Send/receive electronic form for data capture
IER40 Query for existing data
IER42 Request/receive medical concept knowledge
IER49 Report confirmation For details, see HITSP IS 10 Immunization and Response
Management, available at www.HITSP.org
Blue Italics indicates common across 1-IRM and
2-PHCR
Slide 51EHR SD RM - EHR Way Forward … Future State Reference Architecture
EHR-SD RM PrototypeData Requirements (DRs)
Use Case 2: Public Health Case Reporting (PHCR)
DR08 Unstructured Data
DR17 Decision Support Data
DR21 Terminology Data
DR24 Case Report Pre-populate Data
DR22 Generic Alert Data
DR23 Consumer Vaccination View
DR24 Case Report Pre-populate Data
DR25 Case Report Content
DR26 Reporting Criteria Content
DR59 Generic Alert Data
For details, see HITSP IS 10 Immunization and Response
Management, available at www.HITSP.org
Blue Italics indicates common
across IRM and PHCR
Slide 52EHR SD RM - EHR Way Forward … Future State Reference Architecture
EHR-SD RM PrototypeInformation Exchange Requirements (IERs)
HITSP Security and Privacy
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
Blue Italics indicates common
across IRM and PHCR
Slide 53EHR SD RM - EHR Way Forward … Future State Reference Architecture
EXAMPLE ARTIFACT HL7 Requirements and Certification Criteria and HITSP Design
class EHR-S FM: CAP131 Update Immunization Registry
DC.1.8.2 (Manage Immunization Administration) CAP132 Retrieve Immunization Registry Information
CAP131 Update Immunization Registry
CAP133 Communicate Immunization Summary
HL7EHR System
Functional Model
HITSPInteroperability Specifications
Slide 54EHR SD RM - EHR Way Forward … Future State Reference Architecture
EXAMPLE ARTIFACT EHR-S Requirements
class DC.1.8.2 (Manage Immunization Administration)
+ 1.The system SHALL provide the ability to recommend required immunizations, and when they are due, during an encounter based on widely accepted immunization schedules.+ 1.The system SHALL provide the ability to recommend required immunizations, and when they are due, during an encounter based on widely accepted immunization schedules.+ 2.The system SHOULD provide the ability to recommend required immunizations based on patient risk factors.+ 2.The system SHOULD provide the ability to recommend required immunizations based on patient risk factors.+ 3.The system SHALL perform checking for potential adverse or allergic reactions for all immunizations when they are about to be given.+ 3.The system SHALL perform checking for potential adverse or allergic reactions for all immunizations when they are about to be given.+ 4.The system SHALL provide the ability to capture immunization administration details, including date, type, lot number and manufacturer.+ 4.The system SHALL provide the ability to capture immunization administration details, including date, type, lot number and manufacturer.+ 5.The system SHOULD provide the ability to capture other clinical data pertinent to the immunization administration (e.g. vital signs).+ 5.The system SHOULD provide the ability to capture other clinical data pertinent to the immunization administration (e.g. vital signs).+ 6.The system SHALL record as discrete data elements data associated with any immunization.+ 6.The system SHALL record as discrete data elements data associated with any immunization.+ 7.The system SHOULD provide the ability to associate standard codes with discrete data elements associated with an immunization.+ 7.The system SHOULD provide the ability to associate standard codes with discrete data elements associated with an immunization.+ 8.The system SHALL provide the ability to update the immunization schedule.+ 8.The system SHALL provide the ability to update the immunization schedule.+ 9.The system SHOULD provide the ability to prepare a report of a patient‘s immunization history upon request for appropriate authorities such as schools or day-care centers.+ 9.The system SHOULD provide the ability to prepare a report of a patient‘s immunization history upon request for appropriate authorities such as schools or day-care centers.+ 10.The system SHALL conform to function DC.1.4.1 (Manage Allergy, Intolerance and Adverse Reaction Lists).+ 10.The system SHALL conform to function DC.1.4.1 (Manage Allergy, Intolerance and Adverse Reaction Lists).+ 11.The system SHOULD transmit required immunization information to a public health immunization registry.+ 11.The system SHOULD transmit required immunization information to a public health immunization registry.+ 12.The system SHOULD receive immunization histories from a public health immunization registry.+ 12.The system SHOULD receive immunization histories from a public health immunization registry.
DC.1.8.2 Conformance Criteria
+ 1.The system SHALL provide the ability to recommend required immunizations, and when they are due, during an encounter based on widely accepted immunization schedules.+ 2.The system SHOULD provide the ability to recommend required immunizations based on patient risk factors.+ 3.The system SHALL perform checking for potential adverse or allergic reactions for all immunizations when they are about to be given.+ 4.The system SHALL provide the ability to capture immunization administration details, including date, type, lot number and manufacturer.+ 5.The system SHOULD provide the ability to capture other clinical data pertinent to the immunization administration (e.g. vital signs).+ 6.The system SHALL record as discrete data elements data associated with any immunization.+ 7.The system SHOULD provide the ability to associate standard codes with discrete data elements associated with an immunization.+ 8.The system SHALL provide the ability to update the immunization schedule.+ 9.The system SHOULD provide the ability to prepare a report of a patient‘s immunization history upon request for appropriate authorities such as schools or day-care centers.+ 10.The system SHALL conform to function DC.1.4.1 (Manage Allergy, Intolerance and Adverse Reaction Lists).+ 11.The system SHOULD transmit required immunization information to a public health immunization registry.+ 12.The system SHOULD receive immunization histories from a public health immunization registry.
Slide 55EHR SD RM - EHR Way Forward … Future State Reference Architecture
EXAMPLE ARTIFACT EHR-S FM Dependencies
class DC.1.8.2 (Manage Immunization Administration)
See Also
DC.1.3.2 (Manage Patient Advance Directives)
DC.1.4.4 (Manage Immunization List)
S.1.1 (Registry Notification)
S.2.2.2 (Standard Report Generation)
S.3.7.1 (Clinical Decision Support System Guidelines Updates)
IN.1.6 (Secure Data Exchange)
IN.1.7 (Secure Data Routing)
IN.2.4 (Extraction of Health Record Information)
IN.2.5.1 (Manage Unstructured Health Record Information)
IN.2.5.2 (Manage Structured Health Record Information)
IN.4.1 (Standard Terminologies and Terminology Models)
IN.3 Registry and Directory Services
IN.4.2 (Maintenance and Versioning of Standard Terminologies)
IN.4.3 (Terminology Mapping)
IN.5.1 (Interchange Standards)
IN.5.2 (Interchange Standards Versioning and Maintenance )
IN.6 Business Rules Management
Slide 56EHR SD RM - EHR Way Forward … Future State Reference Architecture
EXAMPLE ARTIFACTHITSP Interoperability Design Specifications
uc CAP131 Update Immunization Registry
CAP131 Update Immunization RegistryContent Consumer
Content Creator
Message Receiver
Message Sender
Request Patient Identification
Request HL7 Message
Respond to HL7 Message
HITSP/C72 Immunization Message Component
HITSP/T24 Pseudonymize
HITSP/SC110 - Request Patient Identifier
HITSP/SC115 – HL7 Messaging
Slide 57EHR SD RM - EHR Way Forward … Future State Reference Architecture
Sample HITSP C83 Data ModulesImmunizations Data Mapping Table – Requirements
CDA Data Location HITSP Data Element Identifier and Name O/R[1] Additional
Specification
cda:substanceAdministration[cda:templateId/@root ='2.16.840.1.113883.10.20.1.24']
Immunization Event Entry See Below[2]
@negationInd 13.01 - Refusal R/N
cda:effectiveTime 13.02 - Administered Date O/N
cda:entryRelationship[@typeCode='SUBJ']/cda:observation/cda:value
13.03 - Medication Series Number
O/N
cda:entryRelationship[@typeCode='CAUS']/cda:observation[cda:templateId/@root=
’2.16.840.1.113883.10.20.1.54’]
13.04 - Reaction O/Y
cda:performer/cda:assignedEntity 13.05 - Performer O/N
cda:consumable/cda:manufacturedProduct Medication Information R/Y
cda:manufacturedMaterial/cda:code/@code
13.06 - Coded Product Name R2/Y 2.2.2.13.1
cda:originalText 13.07 - Free Text Product Name R/N
cda:manufacturerOrganization 13.08 - Drug Manufacturer O/N
cda:manufacturedMaterial/cda:lotNumberText
13.09 - Lot Number R2/N
cda:entryRelationship[@typeCode=’RSON’]/cda:act[cda:templateId/@root=’2.16.840.1.113883.10.20.1.27’]
13.10 - Refusal Reason R2/N 2.2.2.13.2
Slide 58EHR SD RM - EHR Way Forward … Future State Reference Architecture
Sample of Standards used within HITSP Components within IS10
1. Standard: HITSP Construct2. Accredited Standards Committee (ASC) X12 Standards Release 004010 HITSP/C80 - Clinical Document and Message Terminology3. American Medical Association (AMA) Current Procedural Terminology (CPT®) Fourth Edition (CPT-4); CPT Evaluation and Management Codes HITSP/C80 - Clinical Document and Message
Terminology4. ASTM International Standard Guide for Electronic Authentication of Health Care Information: # E1762-95 (2003) HITSP/C26 - Nonrepudiation of Origin5. CDC Race and Ethnicity Code Sets HITSP/C80 - Clinical Document and Message Terminology6. Center for Disease Control and Prevention Implementation Guide for Immunizations Data Transaction using Version 2.3.1 of the Health Level Seven (HL7) Standard Protocol. Implementation
Guide Version 2.2 June 2006 HITSP/C70 - Immunization Query and Response, HITSP/C72 - Immunization Message, HITSP/C80 - Clinical Document and Message Terminology7. Digital Imaging and Communications in Medicine (DICOM) Part 3.12: Media Formats and Physical Media for Media Interchange HITSP/T33 - Transfer of Documents on Media8. European Telecommunications Standards Institute (ETSI) Technical Specification TS 101 903: XML Advanced Electronic Signatures (XadES) HITSP/C26 - Nonrepudiation of Origin9. Federal Information Processing Standards (FIPS) Codes for the Identification of the States, the District of Columbia and the Outlying Areas of the United States, and Associated Areas
Publication # 5-2, May, 1987 HITSP/C80 - Clinical Document and Message Terminology
10. Food and Drug Administration (FDA) - Unique Ingredient Identifier (UNII) HITSP/C80 - Clinical Document and Message Terminology11. Food and Drug Administration (FDA) - National Drug Code (NDC) HITSP/C80 - Clinical Document and Message Terminology12. Health Care Provider Taxonomy HITSP/C80 - Clinical Document and Message Terminology13. Health Level Seven (HL7) Clinical Document Architecture (CDA) Release 2.0 HITSP/C78 - Immunization Document, HITSPC83 - CDA Content
Modules14. Health Level Seven (HL7) Common Terminology Services (CTS) Release 1 HITSP/T66 - Retrieve Value Set15. Health Level Seven (HL7) Implementation Guide for CDA Release 2: History and Physical (H&P) Notes HITSP/C83 - CDA Content Modules16. Health Level Seven (HL7) Implementation Guide for CDA Release 2: Consultation Note HITSP/C83 - CDA Content Modules17. Health Level Seven (HL7) Implementation Guide: CDA Release 2 – Continuity of Care Document (CCD), April 01, 2007 HITSP/C83 - CDA Content Modules18. Health Level Seven (HL7) Standard Code Set CVX - Vaccines Administered HITSP/C80 - Clinical Document and Message Terminology19. Health Level Seven (HL7) Standard Code Set MVX - Manufacturers of Vaccines HITSP/C80 - Clinical Document and Message Terminology20. Health Level Seven (HL7) V3 RBAC, R1-2008, HL7 Version 3 Standard: Role Based Access Control (RBAC) Healthcare Permissions Catalog, Release 1, February 2008, HITSP/TP20 - Access
Control 21. Health Level Seven (HL7) Version 2.3.1 HITSP/C70 - Immunization Query and Response22. Health Level Seven (HL7) Version 2.3.1 Chapter 2 – Control, Chapter 3 – Patient Administration HITSP/TP22 - Patient ID Cross-Referencing23. Health Level Seven (HL7) Version 2.5, Chapter 2 – Control, Chapter 3 – Patient Administration, Chapter 5 – Query HITSP/TP22 - Patient ID Cross-Referencing24. Health Level Seven (HL7) Version 2.5, Chapter 2 – Control, Chapter 3 – Patient Administration, Chapter 5 - Query HITSP/T23 - Patient Demographics Query25. Health Level Seven (HL7) Version 2.5.1 HITSP/C80 - Clinical Document and Message Terminology26. Health Level Seven (HL7) Version 3.0 - Vocabularies and Value Sets HITSP/C80 - Clinical Document and Message Terminology27. Health Level Seven (HL7) Version 3.0 Context-Aware Information Retrieval Specification: URL Implementation Guide HITSP/T81 - Retrieval of Medical Knowledge
Slide 59EHR SD RM - EHR Way Forward … Future State Reference Architecture
Basic UML Legend class Basic UML Legend
Book
Preface
Chapter
Publisher
Biography
Author Legend
A book realizes an author's concept outline. A Concept Outline and a Book depends on an Author to be written. A Book "has-an" index and is composed of one or more chapters. A Biography "is-a" type of book. A Book is associated with a publisher. Association is a relationship between two classes, that may describes the reasons for the relationship and the rules that govern the relationship. Aggregation ("has-a") is a special form of an association that specifies a whole-part relationship between the aggregate (whole) and a component part. The parts can
exist on their own and are therefore shareable among multiple owner classes. Composition (a strong type of "uses a" relationship) is a form of aggregation which requires that a part instance be included in at most one composite at a time, and
that the composite object is responsible for the creation and destruction of the parts. A dependency is a type of relationship that signifies that one element, or group of elements, acting as the client depends on another element or group of elements that
act as a supplier. It is a weak relationship that denotes that if the supplier is changed the client may be affected. It is a unidirectional relationship. Realize is a relationship where a source object implements or Realizes its destination object. Realize connectors are used to express traceability and completeness in
the model. Generalization ("is-a") is a relationship in which one model element (the child) is based on another model element (the parent).
Concept Outline
dependency
aggregate1..*
compose
associate
generalize
realize
Slide 60EHR SD RM - EHR Way Forward … Future State Reference Architecture
Abbreviations
B-Case is Business Case
BPM is Business Process Model
CCD is Continuity of Care Document
CCHIT is Certification Commission for Health Information Technology
CDRL is Contract Deliverable
DBT is Defense Business Transformation
IHE is Integrating the Healthcare Enterprise
NHIN is National Health Information Exchange
PCC is Patient Care Coordination
RM-ODP is Reference Model of Open Distributed Processing
SOA is Service Oriented Architecture