Transcript EHR SD RM Prototype Sep-09 - HSSP

HL7 Work Group Report
September 20 - 25, 2009 - Atlanta, GA USA
GovProjects, SOA, EHR, PHER
HL7 Project Prototype:
EHR System Design Reference Model
(EHR-SD RM)
Immunization and Adverse Event Reporting
Nancy Orvis, HL7 Project Co-Chair
Stephen Hufnagel PhD, HL7 Project Facilitator
September 22, 2009 presentation
October 10, 2009 update F
Contents
EHR System Design Reference Model
(EHR-SD RM)
•
Background
–
–
•
What Changed in 2009
–
–
–
–
•
Jan 2009 baseline project
Sep 2009 Information Model (IM) additions
2010 EHR SD RM Model with HITSP Capabilities, IM & ARRA
Vaccination and Adverse Event Reporting Prototype
–
–
–
•
ARRA (American Reinvestment and Recovery Act)
HITSP Harmonization Framework for reuse
HITSP Capabilities
•
Information Exchanges  Interface Standards Specifications
HITSP Service Collaborations
EHR SD RM Model
–
–
–
•
2008 Project Results
2009 HL7 EHR SD RM Project plan
AHIC Use Cases
EHR-S FM
HITSP Capabilities
Next Steps
2
Introduction
•
In 2004, Executive Orders 13335 set the objective for National Electronic
Healthcare Record (EHR) Interoperability by 2014
•
In 2006, Executive Order 13410 mandated Federal agencies to begin
transformation to Healthcare Information Technology Standards Panel (HITSP)
conformant EHR interoperable systems by 2007
•
We present a standards-based strategic approach for interoperability at the
service level to construct semantically consistent interoperable Enterprise
Architectures (EAs)
–
It builds upon the functional foundation of the HL7 EHR System Functional Model
(EHR-S) and the technical foundation of Thomas Erl’s Service Oriented
Architecture (SOA) model to specify a standard Healthcare SOA Reference
Architecture (H-SOA-RA)
–
Information Exchange Requirements (IERs) are used to identify services and as
the key to traceability from requirements to implementation, test and certification
3
HL7 Project Intent
•
Implement a step in HL7 roadmap
–
Identify gaps and overlaps in HL7’s portfolio
–
Identify gaps in the EHR-S FM
–
Pilot HL7 ARB SAEAF methodology
•
Create H-SOA-RA Version 2
•
Create Healthcare SOA EHR-SD Reference Model based on EHR System
Functional Model (EHR-S FM)
•
Create prototype architectural case study using HL7 HSSP Practical Guide for SOA
in Healthcare “sample health” and service specifications, EHR-S FM, EHR-SD RM,
AHIC Use Cases, HITSP Interoperability Specifications and NHIN services
•
Demonstrate standards-based Model Driven Architecture (MDA) approach
4
HL7 Project Scope
•
This project will mature the April 2008 H-SOA-RA version 1.0 into H-SOA-RA Version 2.0
and integrate it into an EHR-SD RM using
–
–
–
•
Emphasis will be placed on maintaining AHIC, HITSP, NHIN and CCHIT conformance by
maintaining IERs and Data Requirements (DRs) traceability
–
•
HL7 (SA)EAF,
HITSP Capabilities, and
EHR System Functional Model (EHR-S FM)
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 using the AHIC-HITSP Immunization and Response Management and Public Health
Case Reporting use cases
5
HL7 Project Schedule
•
Sep 2008 – Healthcare SOA Reference Architecture (H-SOA-RA)
•
Jan 2009 – harmonize and catalogue priority IERs, DRs and candidate services
•
Mar 2009 – map priority IERs, DRs and candidate services to EHR-S FM
•
Jun 2009 - Mappings of V2.5, V3 products to EHR-S FM
•
Jun 2009 - Present at HL7 SOA Conference (for peer feedback)
•
Sep 2009 – Report on Vaccination and Adverse Event Prototype
•
Oct 2009 – Healthcare SOA Reference Architecture (H-SOA-RA) version 2.0
•
Nov 2009 - HSSP Practical Guide for SOA in Health Care, Part II: Case Study
•
Jan 2010 - EHR-SD RM white paper for HL7 committee comments, to socialize the project.
•
Sep 2010 - EHR-SD RM Balloted as informative document
•
Sep 2011 - EHR-SD RM Balloted as a standard
6
2008 Project Goal
Healthcare SOA Reference Architecture (H-SOA-RA)
Identifying Opportunities to Leverage Technology and Alleviate
Redundancy or Agency IT Overlap
Key Business Driver
Patient Centric Processes
National
Federated
Key Architectural Objective
Standardized Technical
Solutions aligned with
Core Business Processes.
Healthcare Industry
VA/ DoD Interagency
DoD
TMA
Military Services
INTER-AGENCY
Joining Forces to Improve Effectiveness, Efficiency, and Service delivery
7
2008 Health SOA Reference
Model Glossary (example)
MHS/VA
PROPOSED
SERVICES
SOA SERVICE DEFINITIONS
Access to Care Functions
IDENTITY
Identify and/or lookup subjects-of-care, providers, payers, employers, material resources, and references to various parts of the EHR (hosted
locally and/or remotely).
Patient
Maintain current directory of patient information in accordance with relevant privacy and other applicable laws, regulations, and conventions,
including, when available, full name, address or physical location, alternate contact person, primary phone number, and relevant
health status. Provide the patient's location information within a facility's premises.
Guarantor
Collect, record, and update a core set of information to ensure accurate beneficiary guarantor identification and health plan information. Provide
information of Related by genealogy (blood relatives). Provide information of Related by insurance (domestic partner, spouse,
guarantor). Provide information of Related by other means (e.g. epidemiologic exposure)
Provider
Maintain a current directory of practitioners that, in addition to demographic information, contains data needed to determine levels of access
required by the EHR security system. Maintain current directory of provider information in accordance with relevant laws, regulations,
and conventions, including full name, address or physical location, and a 24x7 telecommunications address (e.g. phone or pager
access number) for the purposes of the following: Provide provider location or contact information on a facility's premises. Provide
provider location or contact information on a facility's premises. Provide provider location or contact information when on call. Provide
locations or contact information at which the provider practices, in order to direct patients or queries.
Next of Kin
Collect, record, and update a core set of information to ensure accurate next of kin identification and health plan information.
Supplier
Collect, record, and update a core set of information to ensure accurate Supplier Information.
Insurer
Collect, record, and update a core set of information to ensure accurate Insurer Information.
Facility
Collect, record, and update a core set of information to ensure accurate Facility Information.
8
2008 Healthcare SOA Framework
Based on HL7 EHR System Functional Model &
Thomas Erl’s SOA Layers
HL7 System
Functions
Direct Care
Supportive
Information
Infrastructure
Other
Business
Process
Value Chains
Composite
Services
(Svcs)
Federated Composition (e.g., Choreograph or Orchestration)
Within and Across Business Areas
Core Bus
Svcs
Functional Areas
+ Focal Classes
Functional Areas +
Focal Classes
Functional Areas +
Focal Classes
Functional Areas +
Focal Classes
Entity Svcs
IM
IM
IM
Info Reporting/IM
Agnostic
Svcs
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…)
App Svcs
Amb Care Sys,
In Pt Care Sys
Log Sys, Fin Sys,
Dec Support Sys
Data Marts
Repositories
Business Objects
Imp
Profiles
IHE Profiles
Analysis Profiles
Communications
Profiles/Stacks
Implementation
Profiles 9 9
Anatomy of Ancillary Systems
LABORATORY
RADIOLOGY
PHARMACY
CARDIOLOGY
OT/PT/SPEECH
s
CORE BUSINESS SERVICES
IDENTITY
TERMINOLOGY
AUTHORIZATION
SCHEDULING
SUPPLY CHAIN
(ORDER/CHARGE)
DOCUMENT
RECORDS MANAGEMENT
DECISION SUPPORT
PERFORMANCE
DATA MANAGEMENT
10
Contents
EHR System Design Reference Model
(EHR-SD RM)
•
Background
–
–
•
What Changed in 2009
–
–
–
–
•
Jan 2009 baseline project
Sep 2009 Information Model (IM) additions
2010 EHR SD RM Model with HITSP Capabilities, IM & ARRA
Vaccination and Adverse Event Reporting Prototype
–
–
–
•
ARRA (American Reinvestment and Recovery Act)
HITSP Harmonization Framework for reuse
HITSP Capabilities
•
Information Exchanges  Interface Standards Specifications
HITSP Service Collaborations
EHR SD RM Model
–
–
–
•
2008 Project Results
2009 HL7 EHR SD RM Project plan
AHIC Use Cases
EHR-S FM
HITSP Capabilities
Next Steps
11
HITSP 2009 Model for IERs
Information
Exchange
Number
Exchange
Action
Send
Send
Exchange
Content
Blood Lab
Report
Specimen
Lab Report
What System
initiates this
exchange?
What System (s)
consume this exchange?
Qualifier
Laboratory
Information
System
PHR System
EHR System
Public Health
Information System
TBD
Laboratory
Information
System
PHR System
EHR System
Public Health
Information System
TBD
Reusable Facets  Lexical Consistency
12
A new 2009 concept
HITSP Capability
•
A HITSP capability is an implementable business service that
specifies interoperable information exchanges using HITSP
constructs.
•
It is meant to supports stakeholder requirements and as part of its
design, it includes workflow, information content, infrastructure,
security and privacy.
•
Capabilities include constraints and operate on specific network
topologies (contexts)
•
Capabilities have options: subsets of the data content can be sent
or received as appropriate by a system implementing a capability.
The 2009 Refined HITSP Framework
Business Requirements
Constructs
HITSP Capabilities
Identifies interoperability
business needs
Service
Collaborations
Interoperability
Specification
• Identifies what HITSP
capabilities and
constructs to use to
meet Business Needs
• Defines Requirements,
Context and Constraints
for those capabilities
and constructs
Base
Standard
#1
Base
Standard
#2
Base
Standard
#...
Transaction
Constructs
Transaction
Package
Transaction
Package
Service
Collaboration
Transaction
Transaction
Component
Available for Internal
Component
reuse or repurposing
Base
Standard
#n
Composite
Standard
#1
Composite
Standard
#...
Composite
Standard
#m
14
2009 HITSP Reuse Framework
GREEN Elements are reusable!
15
HITSP Model To Link
Requirements to Design
Design
HITSP Constructs
• Transaction
• Transaction Packages
• Component
• Services
16
2009 HITSP Requirements
Analysis Framework
GREEN Elements are reusable!
17
2009 Design Specifications
Framework
GREEN Elements are reusable!
18
HITSP List of Priority
Information Exchanges
1.
Demographics
8.
Laboratory Results
2.
Problem List
9.
Microbiology
3.
Medications
10. Images
4.
Immunizations/ Adverse
Event Reporting
11. Administrative Transactions
5.
Allergies
6.
Progress Notes and Other
Narrative Documents (History and
Physical, Operative Notes, Discharge
Summary)
7.
(Benefits/Eligibility,
Referral/Authorization,
Claims/Remittance)
12. Quality Measures
13. Privacy and Security
Departmental Reports
(Pathology/Cytology, GI,
Pulmonary, Cardiology etc.)
19
HITSP List of Priority
Capabilities
1.
HITSP/CAP117
Communicate Ambulatory and Long
Term Care Prescription
14.
HITSP/CAP130
Specification
Communicate Quality Measure
2.
HITSP/CAP118
Communicate Hospital Prescription
15.
HITSP/CAP131
Update Immunization Registry
3.
HITSP/CAP119
Communicate Structured Document
16.
Retrieve Immunization Registry
4.
HITSP/CAP120
Document
Communicate Unstructured
HITSP/CAP132
Information
17.
HITSP/CAP133
Communicate Immunization Summary
HITSP/CAP121
Request
Communicate Clinical Referral
18.
HITSP/CAP135
Retrieve and Populate Form
19.
HITSP/CAP136
Communicate Emergency Alert
6.
HITSP/CAP122
Retrieve Medical Knowledge
20.
Communicate Encounter Information
7.
HITSP/CAP123
Retrieve Existing Data
HITSP/CAP137
Message
8.
HITSP/CAP124
Establish Secure Web Access
21.
HITSP/CAP138
Retrieve Pseudonym
9.
HITSP/CAP125
Retrieve Genomic Decision Support
22.
HITSP/CAP139
Communicate Resource Utilization
10.
HITSP/CAP126
Communicate Lab Results Message 23.
HITSP/CAP140
Communicate Benefits and Eligibility
11.
HITSP/CAP127
Communicate Lab Results Document 24.
HITSP/CAP141
Communicate Referral Authorization
12.
HITSP/CAP128
Communicate Imaging Information
25.
HITSP/CAP142
Retrieve Communications Recipient
13.
HITSP/CAP129
Communicate Quality Measure Data 26.
HITSP/CAP143
Consents
Manage Consumer Preference and
5.
20
Service Traceability
EHR-S, HITSP and CCHIT
21
Contents
EHR System Design Reference Model
(EHR-SD RM)
•
Background
–
–
•
What Changed in 2009
–
–
–
–
•
Jan 2009 baseline project
Sep 2009 Information Model (IM) additions
2010 EHR SD RM Model with HITSP Capabilities, IM & ARRA
Vaccination and Adverse Event Reporting Prototype
–
–
–
•
ARRA (American Reinvestment and Recovery Act)
HITSP Harmonization Framework for reuse
HITSP Capabilities
•
Information Exchanges  Interface Standards Specifications
HITSP Service Collaborations
EHR SD RM Model
–
–
–
•
2008 Project Results
2009 HL7 EHR SD RM Project plan
AHIC Use Cases
EHR-S FM
HITSP Capabilities
Next Steps
22
January 2009 EHR SD RM Project
EHR System Design Reference Model (EHR-SD RM)
23
HL7 SAEAF ECCF Specification Stack
Topic
Information
View
“WHAT”
Computational
View
“HOW”
Behavior
Implementation
Conceptual
Business Context,
Reference Context
Domain Analysis
(Information) Model
Collaboration
Analysis, Functional
Profile(s), Service
Roles and
Relationships
Existing Platform
capabilities
Platform-
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.
Rules, Procedures
Localized
Information Model,
Transforms, Schema
Collaboration scripts,
Orchestrations,
Realized Interfaces
Execution Context,
Platform Bindings,
Deployment Model
Specification
Policy
Independent
PlatformSpecific
Content
Consistency
Engineering
View
“WHERE”
24
Traceable
Enterprise /
Business View
“WHY”
Proposed
HITSP Compliance Framework
Based on HL7 SAEAF ECCF
ECCF View
Business
Informational
Computational
Engineering
Answers
WHY
WHAT
HOW
WHERE
HITSP Artifact
IS
CAP, C
CAP, SC, TP, T
Implementation
IS is Interoperability Specification
C is Component (e.g., data module(s))
CAP is Capability
T is Transaction
SC is Service Collaboration
TP is Transaction Package
SAEAF is Service Aware Enterprise
Architecture Framework
ECCF is Enterprise Conformance and
Compliance Framework
25
HITSP Within
HL7 SAEAF ECCF Specification Stack
Topic
Specification
Conceptual
Enterprise /
Business View
“WHY”
Information
View
“WHAT”
Computational
View
“HOW”
Engineering
View
“WHERE”
Policy
Content
Behavior
Implementation
Business Context,
Reference Context
Domain Analysis
(Information) Model
Collaboration
Harmonization
Analysis, Functional
Requests/
Case
Profile(s),Use
Service
Existing Platform
capabilities
Platform-
Business
Governance
Independent
HITSP
Harmonization
Framework
PlatformSpecific
Rules, Procedures
Roles and
Relationships
HITSP CAP
Project-oriented
Domain Information
Model, Constrained
Information
HITSPModel,
Localized
C
Information Model,
Hierarchical
Message Definition
Collaboration Types,
Interface Specification
and Functional
Groups,
Interaction
HITSP
Types and
T,Collaboration
TP and SCs
Participations,
Contracts Parts
Existing Platform
models, libraries,
etc.
Localized
Information Model,
Transforms, Schema
Collaboration scripts,
Orchestrations,
Realized Interfaces
Execution Context,
Platform Bindings,
Deployment Model
EHR-S FM is EHR System Functional Model
EHR SD RM is EHR System Design Reference Model
RIM is Reference Information Model
FHIMS is Federal Health Information Model & Standards
DA is Data Architecture
Consistency
26
Traceable
HITSP IS
HITSP DA
HITSP CAP
HL7, HITSP, FHIMS and NHIN Within
HL7 SAEAF ECCF Specification Stack
Topic
Specification
Conceptual
Information
View
“WHAT”
Computational
View
“HOW”
Engineering
View
“WHERE”
Policy
Business
Context,
HL7 EHR-S
FM
Content
Behavior
Domain Analysis
HL7 RIM
(Information) Model
Collaboration
Harmonization
Analysis, Functional
Requests/
Case
Profile(s),Use
Service
Implementation
Existing
Tomcat,Platform
JBoss,
capabilities
J2SE, Eclipse,
GlassFish ESB,
OpenSSO
Reference Context
HITSP IS
PlatformIndependent
Business
Governance
HL7
EHR SD RM
HITSP
Harmonization
Framework
PlatformSpecific
Rules, Procedures
FHA FHIMS
HITSP DA
HITSP CAP
Roles and
Relationships
HITSP CAP
Project-oriented
Domain Information
Model, Constrained
Information
HITSPModel,
Localized
C
Information Model,
Hierarchical
Message Definition
Collaboration Types,
Interface Specification
and Functional
Groups,
Interaction
HITSP
Types and
T,Collaboration
TP and SCs
Participations,
Contracts Parts
Existing Platform
models, libraries,
etc.
Localized
Information Model,
Transforms, Schema
Collaboration scripts,
Orchestrations,
Realized Interfaces
Execution Context,
Platform Bindings,
Deployment Model
NHIN Connect
Services
EHR-S FM is EHR System Functional Model
EHR SD RM is EHR System Design Reference Model
RIM is Reference Information Model
FHIMS is Federal Health Information Model & Standards
DA is Data Architecture
Consistency
27
Traceable
Enterprise /
Business View
“WHY”
2010 Information Model Project
Federal Health Information Model and Standards (FHIMS)
28
2010 Project
Integrated EHR-SD RM, FHIMS,
HITSP Capabilities and ARRA Meaningful Use
29
Benefits
1.
2.
3.
4.
5.
6.
Faster, Better, Cheaper Integrated Requirements-Design Process
Strategic Plan based on International and National Standards
Objective Investment Portfolio Cost Estimation
Minimize the Chance of Year of Execution Unfunded Requirements (UFRs)
IM and IT aligned on Consistent Catalogue of Services
MHS EHR Interoperability alignment with National Agenda
1. Manage Care Support Contractor (MCSC) interoperability
2. VA interoperability
7. Consistent with Enterprise Architecture
30
Prototype Approach
•
Build Integrated Requirements Design CONOPS package based on
–
Service Oriented Architecture categorized and populated by
• Candidate Services Derived from following Thomas Erl’s
Service Oriented Design Principles
• HL7 EHR System Functional Model Requirements and
• HITSP Interoperability Specifications
31
Contents
EHR System Design Reference Model
(EHR-SD RM)
•
Background
–
–
•
What Changed in 2009
–
–
–
–
•
Jan 2009 baseline project
Sep 2009 Information Model (IM) additions
2010 EHR SD RM Model with HITSP Capabilities, IM & ARRA
Vaccination and Adverse Event Reporting Prototype
–
–
–
•
ARRA (American Reinvestment and Recovery Act)
HITSP Harmonization Framework for reuse
HITSP Capabilities
•
Information Exchanges  Interface Standards Specifications
HITSP Service Collaborations
EHR SD RM Model
–
–
–
•
2008 Project Results
2009 HL7 EHR SD RM Project plan
AHIC Use Cases
EHR-S FM
HITSP Capabilities
Next Steps
32
EHR-SD RM Prototype
Requirements from 2008 AHIC Use Cases
•
•
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
33
EXAMPLE ARTIFACT: Vaccine and Drug Administration and Reporting Information Exchanges
34
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
35
EHR-SD RM Prototype
Information 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
Blue Italics
indicates IERs,
which are
common to 1IRM and 2PHCR
For details, see HITSP IS 10
Immunization and Response
Management, available at
www.HITSP.org
36
EHR-SD RM Prototype
Data Requirements (DRs)
Use Case 1: Immunization and Response Management (IRM)
•
•
•
•
•
•
•
•
•
•
•
•
•
•
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
Blue Italics
indicates common
across IRM and
PHCR
For details, see HITSP IS 10
Immunization and Response
Management, available at
www.HITSP.org
37 37
EHR-SD RM Prototype
IRM 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
Blue Italics
indicates common
across 1-IRM and
2-PHCR
For details, see HITSP IS 10
Immunization and Response
Management, available at
www.HITSP.org
38 38
EHR-SD RM Prototype
Data 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
Blue Italics
indicates common
across IRM and
PHCR
For details, see HITSP IS 10
Immunization and Response
Management, available at
www.HITSP.org
39 39
EHR-SD RM Prototype
Information 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
Blue Italics
indicates common
across IRM and
PHCR
For details, see HITSP IS 10
Immunization and Response
Management, available at
www.HITSP.org
40 40
EXAMPLE ARTIFACT
HL7 Requirements and Certification Criteria and HITSP Design
class EHR-S FM: CAP131 Update Immunization Registry
CAP131 Update Immunization Registry
DC.1.8.2 (Manage Immunization Administration)
CAP132 Retrieve Immunization Registry Information
CAP133 Communicate Immunization Summary
HL7
EHR System
Functional Model
HITSP
Interoperability
Specifications
41
EXAMPLE ARTIFACT
EHR-S Requirements
42
EXAMPLE ARTIFACT
EHR-S FM Dependencies
class DC.1.8.2 (Manage Immunization Administration)
See Also
DC.1.3.2 (Manage Patient Advance Directives)
DC.1.4.4 (Manage Immunization List)
IN.2.5.2 (Manage Structured Health Record Information)
IN.3 Registry and Directory Services
S.1.1 (Registry Notification)
IN.4.1 (Standard Terminologies and Terminology Models)
S.2.2.2 (Standard Report Generation)
IN.4.2 (Maintenance and Versioning of Standard Terminologies)
S.3.7.1 (Clinical Decision Support System Guidelines Updates)
IN.1.6 (Secure Data Exchange)
IN.4.3 (Terminology Mapping)
IN.5.1 (Interchange Standards)
IN.1.7 (Secure Data Routing)
IN.5.2 (Interchange Standards Versioning and Maintenance )
IN.2.4 (Extraction of Health Record Information)
IN.6 Business Rules Management
IN.2.5.1 (Manage Unstructured Health Record Information)
43
EXAMPLE ARTIFACT
HITSP Interoperability Design Specifications
uc CAP131 Update Immunization Registry
Content Consumer
Content Creator
CAP131 Update Immunization Registry
HITSP/C72 Immunization Message Component
Message Receiver
Message Sender
Request Patient Identification
HITSP/SC110 - Request Patient Identifier
HITSP/SC115 – HL7 Messaging
Request HL7 Message
Respond to HL7 Message
HITSP/T24 Pseudonymize
44
Sample of Standards used within
HITSP Components within IS10
1.
Standard:
2.
3.
Accredited Standards Committee (ASC) X12 Standards Release 004010
HITSP/C80 - Clinical Document and Message Terminology
American Medical Association (AMA) Current Procedural Terminology (CPT®) Fourth Edition (CPT-4); CPT Evaluation and Management Codes HITSP/C80 - Clinical Document and Message
Terminology
ASTM International Standard Guide for Electronic Authentication of Health Care Information: # E1762-95 (2003)
HITSP/C26 - Nonrepudiation of Origin
CDC Race and Ethnicity Code SetsHITSP/C80 - Clinical Document and Message Terminology
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 Terminology
Digital Imaging and Communications in Medicine (DICOM) Part 3.12: Media Formats and Physical Media for Media Interchange
HITSP/T33 - Transfer of Documents on Media
European Telecommunications Standards Institute (ETSI) Technical Specification TS 101 903: XML Advanced Electronic Signatures (XadES)
HITSP/C26 - Nonrepudiation of Origin
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
Food and Drug Administration (FDA) - Unique Ingredient Identifier (UNII)
HITSP/C80 - Clinical Document and Message Terminology
Food and Drug Administration (FDA) - National Drug Code (NDC)
HITSP/C80 - Clinical Document and Message Terminology
Health Care Provider Taxonomy
HITSP/C80 - Clinical Document and Message Terminology
Health Level Seven (HL7) Clinical Document Architecture (CDA) Release 2.0
HITSP/C78 - Immunization Document, HITSPC83 - CDA Content Modules
Health Level Seven (HL7) Common Terminology Services (CTS) Release 1
HITSP/T66 - Retrieve Value Set
Health Level Seven (HL7) Implementation Guide for CDA Release 2: History and Physical (H&P) Notes
HITSP/C83 - CDA Content Modules
Health Level Seven (HL7) Implementation Guide for CDA Release 2: Consultation Note
HITSP/C83 - CDA Content Modules
Health Level Seven (HL7) Implementation Guide: CDA Release 2 – Continuity of Care Document (CCD), April 01, 2007
HITSP/C83 - CDA Content Modules
Health Level Seven (HL7) Standard Code Set CVX - Vaccines Administered
HITSP/C80 - Clinical Document and Message Terminology
Health Level Seven (HL7) Standard Code Set MVX - Manufacturers of Vaccines
HITSP/C80 - Clinical Document and Message Terminology
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
Health Level Seven (HL7) Version 2.3.1
HITSP/C70 - Immunization Query and Response
Health Level Seven (HL7) Version 2.3.1 Chapter 2 – Control, Chapter 3 – Patient Administration
HITSP/TP22 - Patient ID Cross-Referencing
Health Level Seven (HL7) Version 2.5, Chapter 2 – Control, Chapter 3 – Patient Administration, Chapter 5 – Query
HITSP/TP22 - Patient ID Cross-Referencing
Health Level Seven (HL7) Version 2.5, Chapter 2 – Control, Chapter 3 – Patient Administration, Chapter 5 - Query
HITSP/T23 - Patient Demographics Query
Health Level Seven (HL7) Version 2.5.1
HITSP/C80 - Clinical Document and Message Terminology
Health Level Seven (HL7) Version 3.0 - Vocabularies and Value Sets
HITSP/C80 - Clinical Document and Message Terminology
Health Level Seven (HL7) Version 3.0 Context-Aware Information Retrieval Specification: URL Implementation Guide
HITSP/T81 - Retrieval of Medical Knowledge
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
HITSP Construct
45
Work Plans
EHR-SD RM Next Steps
1.
EHR SD RM Framework
–
2.
Information Model
–
–
3.
4.
5.
6.
Populate the framework with candidate healthcare Information Exchanges/ capabilities/
services, based on HL7 EHR-S Functional Model
Loosely-coupled top-down Framework
Rigorously specified bottom up structure/ content
Publish HL7 HSSP Practical Guide for SOA in Healthcare Part 2: Case Study
Socialize EHR SD RM
Collaborate with others
Informative ballot in 2010
46
Questions??
What was omitted?
Suggestions for improvement?
How should the model be represented?
What should be balloted in 2010?
47
Questions?
Contact us:
• [email protected]
• [email protected]
Project info available at:
• http://hitsp.wikispaces.com/HITSP+MODEL
• http://hssp.wikispaces.com/Reference+Architecture
48
Backup
49
Specification Stack Columns:
RM-ODP Viewpoints
ISO Standard (RM – ODP, ISO/IEC IS 10746 | ITU-T X.900 )
Enterprise View: concerned with the purpose, scope and policies
governing the activities of the specified system within the
organization of which it is a part
Information View: concerned with the kinds of information
handled by the system and constraints on the use and interpretation of
that information;
Computational View: concerned with the functional
decomposition of the system into a set of objects that
interact at interfaces – enabling system distribution;
Engineering View: concerned with the infrastructure required to, and distribution
of, the computing resources defined in the Computational View.
Technology View: concerned with the choice of technology
to support system distribution
Why?
What?
How?
Where?
True?
SAEAF Specification Stack is made up of Conformance Assertions and Compliance Validations.
In SAEAF, the artifacts are constructed via Constraint Patterns sorted by RM-ODP Viewpoints.
Candidate Services Sources
•
2008 H-SOA-RA: Identity, Terminology, Authorization, Scheduling,
Supply Chain (Order/charge), Document Records Management, Decision
Support, Performance, Data Management
•
DoD-VA Sharing Project: Pharmacy Data, Clinical Data (Theater), Allergy
Data, Lab Results, Discharge Summaries, SADR, Radiology Reports,
Assessments (Pre/Post), Inpatient Consults
•
NHIN Services: Subject Discovery, Query for Documents, Retrieve
Documents, Query Audit Log, Authorization Framework, Consumer
Preference Profile, Messaging Platform, Pseudonymization, Health
Information Event Messaging, NHIE Service Registry
•
HITSP Constructs as Services: Document Sharing, Patient Indexing,
Security, Content Definition, Healthcare Services, Health Coverage,
Decision Support, Dynamic Data, Data Aggregation, General
Communication
51
2008 Results
Healthcare SOA Reference Architecture
H-SOA-RA
• H-SOA-RA: Overall Goal
– Service Traceability
– EHR System Functional Model (EHR-S)
– Healthcare SOA Reference Architecture
– Notional Functional Example
52
HITSP Exchange Content
Contain Data Requirements (DRs)
Exchange
Content
Number
Exchange
Content
Name
Genomic
Decision
Support
Data
Definition of the Exchange
Content
Data Requirements
Information from
genetic/genomic
knowledge sources
and/or decision support
modules within EHRs
(including Fx HX and
Test Results)
DR1 Demographic Data
DR3 Clinical History
DR4 Personal genetic/genomic data
DR5 Family genetic/genomic information
DR8 Unstructured Data
CDA and ANSI X12 Data Modules
Reusable DRs  Lexical Consistency
53
HL7 EHR System Functional Model (EHR-S)
> 230 System Functions in 4 level categorization
(see separate spreadsheet for full enumeration)
Business
Choreography
System Functions
Business
Entity
(Information)
Business
Infrastructure
Entity
(Information)
Service Types
Choreography
Infrastructure
Infrastructure
Infrastructure
Business
Choreography
Other
O-1
Electronic Resource Planning (ERP)
O-2
Finances
O-3
Other
NOTE: “Other” Category - The EHR-S model does
NOT include Electronic Resource Planning (ERP) /
Logistics and Financial components, which are
54
needed for completeness of a military EHR.
SOA Layers
Business
Capabilities
and Services
Services
interface layer
Business
process layer
Focus on the Business Processes and Services [Thomas Erl]
orchestration service layer
business service layer
application service layer
Application
layer
System
Components
and Services
Source: Service-Oriented
Architecture, Thomas Erl
.NET
J2EE
Legacy
55
SOA Service Models
Potential Service Layers [Thomas Erl]
Service
Model
Application
Service
Business
Service
Controller
Service
Coordinator
Services
Description
A generic category used to represent services that contain logic derived from a
solution or technical platform. Services are generally distinguished as application
services when creating abstraction layers.
A generic category used to represent services that contain business logic. When
establishing specialized service layers, services that fall into the business service
layers are collectively referred to as business. However, individually these
services are classified as entity-centric (e.g., information) or task-centric business
services.
A Service that composes others. Variations of this model exist, depending on the
position of the controller in the composition hierarchy. The patent controller
service can be classified as the master controller and a service that composes a
subset of a larger composition can be labeled as sub-controller.
Three service models are derived from the concept of coordination: the
coordinator, the atomic transaction coordinator, and the business activity
coordinator. All three models are specific to the WS-Coordination specification and
related protocols.
56
SOA Service Models
Potential Service Layers [Thomas Erl] (cont)
Service
Model
Description
Entity-centric
Business
Service
A business process-agnostic variation of the business service that represents one or more
related business entities. This type of service is created when establishing a business
service layer.
Hybrid
Service
A service that contains both business and application logic. Most services created as part of
traditional distributed solutions fall into this category. When organizing services into
abstraction layers, hybrid services are considered part of the application service layer.
Integration
Service
An application service that also acts as an endpoint to a solution for cross-referencing
integration purposes.
Process
Service
A service that represents a business process as implemented by an orchestration platform
and described by a process definition. Process services reside in the orchestration service
layer.
Task-Centric
Business
Service
A business process-specific variation of the business service that represents an atomic unit
of process logic. Task-centric services are different from process services in that the
process logic is provided by the underlying service logic, not by a separate process
definition.
57
EHR Data Reuse Through H-SOA-RA
Across Episodes of Care
Current Episode
Of Care EHR
Previous Episode
Of Care EHR
Reusable Services
IDENTITY
• Patient Demographics
• Provider Demographics
• Insurer Demographic
Data Must Be Verified
And Updated
Terminology
• Chronic Diagnoses
• Procedure History
Document
• Patient History
• Summary Lists
- Medication List
- Allergy/Adverse Reaction List
- Immunization
58
Federated Services [1]
•
•
Federation is a state achieved by extending SOA into the realm of service-oriented
integration
•
A number of key WS-* extensions provide feature-sets that support the attainment of
federation
• Most notable among these are the specifications that implement the concepts of
orchestration and choreography
Establishing SOA within an enterprise does not necessarily require that you replace what you
already have
•
One of the most attractive aspects of this architecture is its ability to introduce unity
across previously non-federated environments
•
While web-services enable federation, SOA promotes this cause by establishing and
standardizing the ability to encapsulate legacy and non-legacy application logic and by
exposing it via a common, open, and standardized communications framework
• WSRP (Web Services for Remote Portals) is the cornerstone of federated services
• SAML (Security Assertions Markup Language) is commonly used
• ALSO: WS-Security, WS-Trust, WS-Policy, WS-Federation
• Additional info at: https://www120.livemeeting.com/cc/bea/viewReg
[1] SOA: Principles of Service Design, by Thomas Erl, Prentice Hall, July 07
59
Leveraging SOA Processing
in the Enterprise
Legacy
Application
Services
Business
Services
Information
Services
Choreographies
(Orchestration Services)
Infrastructure
Services
60
RECORDS MANAGEMENT
DECISION SUPPORT
PERFORMANCE
Agnostic
Services
DATA MANAGEMENT
ANALYTIC
SUPPORT
IT PLATFORM
INTEGRATED
REQUIREMENTS
DESIGNS:
Putting the
H-SOA-RA
Pieces Together
Federated
Business
Services
Inter-Service
Inter-Agency
Across
Providers
DOCUMENT
OUTPATIENT OTHER
SUPPLY CHAIN:
(ORDERS/CHARGES)
ER
SCHEDULING
ASU
AUTHORIZATION
CLINIC
Core Business
Services
TERMINOLOGY
INPATIENT
IDENTITY
TEST ONLY
Ancillary
Systems
Federated Services,
may be categorized by:
-- Encounter Types
-- CMS billing category
-- Record type
-- Care setting type
-- etc.
Data sets are defined for
each system functional61
capability-service module
CASE MANAGEMENT
ER
SCHEDULING
INPATIENT
AUTHORIZATION
TEST ONLY
TERMINOLOGY
Patient Encounter
Types
Core EHR-S
Services
SUPPLY CHAIN:
(ORDER/CHARGE)
ASU
Composite Services, which may be categorized
by:
-- CMS billing category
-- Record type
-- Care setting type
-- etc.
DOCUMENT
PERFORMANCE
CLINIC
DECISION SUPPORT
OUTPATIENT OTHER
RECORDS MANAGEMENT
DATA MANAGEMENT
ANALYTIC
SUPPORT
Data sets are defined for each service – application – encounter
type module
ACROSS SERVICES (SOAs)
IDENTITY
Federated
Services
ACROSS CARE CONTINUUM
Ancillary
Applications
IT PLATFORM
COORDINATION
62
Case Management
Coordination Across SOAs and the Continuum
c CARE, PROVIDERS and LOCATIONS
COORDINATION ` ACROSS LEVELS OF
Wartime
Theater
ER
Acute
Inpatient
Acute
Rehab.
Chronic
Rehab.
Skilled
Long
Term
Care
Custodial
Long
Term
Care
Home
Health
Outpatient
Prevention/
Wellness
Care Continuum
Coordination ACROSS SOAS
ASSESSMENT
CARE
PLANNING
ORDERS
&
SCHEDULING
BENEFIT
MANAGEMENT
AUTHORIZATION
&
UTILIZATION MGT.
COMMUNICATION
(FACILITATION
ADVOCACY)
DISCHARGE/
TRANSFER
PLANNING
REFERRAL
RECORD
EDUCATION.
TRANSPORT
ROLE OF CASE MANAGER
63
Potential Benefits:
Process Improvement through H-SOA-RA
Elimination of Process Obstacles would result in:
–
–
–
–
–
–
–
Length of Stay Reduction
Improved Patient Outcomes / Reduced Risk
Revenue Improvement
Staff Efficiencies
Improved Patient and Staff Satisfaction
Reduced IT Expenditure/Maintenance Costs
Improved Information Accuracy and Availability
64
Addressing Real Business
Issues Through H-SOA-RA
• Incomplete/Inaccurate Demographic Data
– Identity Service
• Incomplete/Inaccurate Insurance Information
– Authorization Service
• Unauthorized Service
– Authorization Service
• Diagnosis/Procedure Coding Errors
– Terminology Service
• Service Delays
– Scheduling Service
• Incomplete and Inefficient Charge Capture
– Supply Chain Service
65
Addressing Real Business
Issues Through H-SOA-RA
• Non-indicated or Contra-indicated Services
•
– Decision Support/Authorization Services
Delays in EHR Document Production and Provision
– Document Service)
•
Billing Delays and Errors
– (Supply Chain/ Billing/Collection Services)
•
Not fully coordinated Scheduling
– Scheduling Service)
•
Lack of fully integrated Patient Assessment and Treatment Plan
– (Document Service/ Decision Support Service)
•
Delayed or Lack of Medical Record Access
– (Record Service)
66