Top Banner
HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA 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-D
65

HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

Mar 26, 2015

Download

Documents

Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

HL7 Work Group ReportSeptember 20 - 25, 2009 - Atlanta, GA USA

HL7 Project Prototype:

EHR System Design Reference Model

(EHR-SD RM)

Immunization and Adverse Event Reporting

Nancy Orvis, HL7 Project Co-ChairStephen Hufnagel PhD, HL7 Project Facilitator

September 22, 2009-D

Page 2: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

ContentsEHR System Design Reference Model

(EHR-SD RM)

• Background– 2008 Project Results– 2009 HL7 EHR SD RM Project plan

• What Changed in 2009– 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– 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– AHIC Use Cases– EHR-S FM– HITSP Capabilities

• Next Steps 2

Page 3: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

3

• 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

Introduction

Page 4: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

4

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

Page 5: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

5

• 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 – HL7 (SAEAF, – HITSP MEANS, and – EHR System Functional Model (EHR-S FM)

• Emphasis will be placed on maintaining AHIC, HITSP, NHIN and CCHIT conformance by maintaining 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 using the AHIC-HITSP Immunization and Response Management and Public Health Case Reporting use cases

HL7 Project Scope

Page 6: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

6

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

Page 7: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

7

2008 Project GoalHealthcare SOA Reference Architecture (H-SOA-RA)

NationalFederated

Healthcare Industry

VA/ DoD Interagency

DoD

TMA

Military Services

INTE

GR

ATIO

N

Joining Forces to Improve Effectiveness, Efficiency, and Service delivery

CO

LLA

BO

RA

TIO

N

INTER-AGENCY

Key Business DriverPatient Centric Processes

Key Architectural ObjectiveStandardized Technical Solutions aligned with

Core Business Processes.

Identifying Opportunities to Leverage Technology and Alleviate Redundancy or Agency IT Overlap

Page 8: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

88

2008 Health SOA Reference Model Glossary (example)

MHS/VAPROPOSEDSERVICES

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.

Page 9: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

9

2008 Healthcare SOA FrameworkBased on HL7 EHR System Functional Model &

Thomas Erl’s SOA Layers

9 9

HL7 System Functions

Direct Care Supportive Information Infrastructure

Other

Business Process

Value Chains

CompositeServices

(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 MartsRepositories

Business Objects

ImpProfiles

IHE Profiles Analysis Profiles Communications Profiles/Stacks

Implementation Profiles

Page 10: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

10

SUPPLY CHAIN (ORDER/CHARGE)

Anatomy of Ancillary Systems

AUTHORIZATION

DOCUMENT

RECORDS MANAGEMENT

DECISION SUPPORT

PERFORMANCE

DATA MANAGEMENT

SCHEDULING

IDENTITY

TERMINOLOGY

LABORATORY RADIOLOGY PHARMACY CARDIOLOGY OT/PT/SPEECH

s

CO

RE

B

US

INE

SS

S

ER

VIC

ES

Page 11: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

ContentsEHR System Design Reference Model

(EHR-SD RM)

• Background– 2008 Project Results– 2009 HL7 EHR SD RM Project plan

• What Changed in 2009– 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– 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– AHIC Use Cases– EHR-S FM– HITSP Capabilities

• Next Steps 11

Page 12: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

12

Information Exchange Number

Exchange Action

Exchange Content

What System initiates this exchange?

What System (s) consume this exchange? Qualifier

SendBlood Lab Report

Laboratory Information System

PHR System EHR System Public Health Information System TBD

SendSpecimen Lab Report

Laboratory Information System

PHR System EHR System Public Health Information System TBD

HITSP 2009 Model for IERs

Reusable Facets Lexical Consistency

Page 13: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

A new 2009 conceptHITSP 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.

Page 14: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

The 2009 Refined HITSP Framework

Business RequirementsIdentifies interoperability business needs

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#n

Base Standard#2

Base Standard#...

CompositeStandard#1

CompositeStandard#...

CompositeStandard#m

SDOs

Component

Transaction

Transaction Package

Available for Internal reuse or repurposingComponent

TransactionConstructs

Transaction

Transaction Package

HITSP ConstructsHITSP Capabilities

Component

ServiceCollaborations

ServiceCollaboration

TransactionConstructs

Transaction

Transaction Package

14

Page 15: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

1515

2009 HITSP Reuse Framework

GREEN Elements are reusable!

Page 16: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

16

HITSP Model To Link Requirements to Design

HITSP Constructs• Transaction• Transaction Packages• Component• Services

Page 17: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

1717

2009 HITSP Requirements Analysis Framework

GREEN Elements are reusable!

Page 18: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

1818

2009 Design Specifications Framework

GREEN Elements are reusable!

Page 19: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

19

HITSP List of Priority Information Exchanges

1. Demographics

2. Problem List

3. Medications

4. Immunizations

5. Allergies

6. Progress Notes and Other Narrative Documents (History and

Physical, Operative Notes, Discharge Summary)

7. Departmental Reports (Pathology/Cytology, GI, Pulmonary, Cardiology etc.)

8. Laboratory Results

9. Microbiology

10. Images

11. Administrative Transactions (Benefits/Eligibility, Referral/Authorization, Claims/Remittance)

12. Quality Measures

13. Privacy and Security

Page 20: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

20

HITSP List of Priority Capabilities

1. HITSP/CAP117 Communicate Ambulatory and Long Term Care Prescription

2. HITSP/CAP118 Communicate Hospital Prescription

3. HITSP/CAP119 Communicate Structured Document

4. HITSP/CAP120 Communicate Unstructured Document

5. HITSP/CAP121 Communicate Clinical Referral Request

6. HITSP/CAP122 Retrieve Medical Knowledge

7. HITSP/CAP123 Retrieve Existing Data

8. HITSP/CAP124 Establish Secure Web Access

9. HITSP/CAP125 Retrieve Genomic Decision Support

10. HITSP/CAP126 Communicate Lab Results Message

11. HITSP/CAP127 Communicate Lab Results Document

12. HITSP/CAP128 Communicate Imaging Information

13. HITSP/CAP129 Communicate Quality Measure Data

14. HITSP/CAP130 Communicate Quality Measure Specification

15. HITSP/CAP131 Update Immunization Registry

16. HITSP/CAP132 Retrieve Immunization Registry

Information

17. HITSP/CAP133 Communicate Immunization Summary

18. HITSP/CAP135 Retrieve and Populate Form

19. HITSP/CAP136 Communicate Emergency Alert

20. HITSP/CAP137 Communicate Encounter Information Message

21. HITSP/CAP138 Retrieve Pseudonym

22. HITSP/CAP139 Communicate Resource Utilization

23. HITSP/CAP140 Communicate Benefits and Eligibility

24. HITSP/CAP141 Communicate Referral Authorization

25. HITSP/CAP142 Retrieve Communications Recipient

26. HITSP/CAP143 Manage Consumer Preference and Consents

Page 21: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

2121

Service Traceability EHR-S, HITSP and CCHIT

Page 22: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

ContentsEHR System Design Reference Model

(EHR-SD RM)

• Background– 2008 Project Results– 2009 HL7 EHR SD RM Project plan

• What Changed in 2009– 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– 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– AHIC Use Cases– EHR-S FM– HITSP Capabilities

• Next Steps 22

Page 23: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

23

Approach

• Service Oriented Architecture based on– Thomas Erl’s SOA layers (De Facto Standard)

• Business Process Value Chains, Composite Services• Core Business Services, Entity Services• Agnostic Services, Application Services, Implementation Profiles

– HL7 EHR System Functional Model (EHR-S FM)• 160+ Standardizes EHR system functions

– Requirements and Test criteria standardized at National Level– Objective Strategic Planning and Investment Portfolio line

costing.– HITSP Capabilities and Interoperability Specifications

• Federal Mandate for Design Interoperability Specifications• Traceable to Enterprise Architecture

– ARRA Meaningful Use Measures

Page 24: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

24

January 2009 EHR SD RM ProjectEHR System Design Reference Model (EHR-SD RM)

class EHR-SD RM (Base Project)

HITSP Constructs

+ Component (C)+ Transaction (T)+ Transaction Package (TP)+ Service Collaboration (SC)

Information Exchange Requirement (IER)

+ Exchange Action+ Exchange Attribute+ Exchange Content+ Systems

EHR-SD RM

+ Clinical Document Architecture (CDA)+ EHR SD RM+ MHS/VA Data Model+ MHS/VA Information Model+ Reference Information Model (RIM)

Service

Design Specification

+ Capability+ conditions+ metadata

Interface

Thomas Erl SOA Layers

+ Business Process Value Chains+ Composite Services+ Core Business Services+ Entity Services+ Agnostic Services+ Application Services+ Implementation Profiles

EHR-S FM

+ EHR-S FM+ Direct Care+ Supportive+ Information Infrastructure

Selected Standard

Realize relationship: a source object implements or Realizes its destination object. Realize connectors are used to express traceability and completeness in the model.

Functions and Services differ in that a service enforces encapsulation (e.g., information hiding), has associated governance and a distributed user resource sharing agreement (DURSA), which defines the business rules for a service's information exchanges.

EHR-S FM is EHR System Functional-ModelEHR-SD RM is EHR Software-System-Service Design Reference-Model

MHS IM/IT

+ Capability

VA IM/IT

+ Capability

requirementsdesign

Legend

realize

HITSPCapabilities/Services

Page 25: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

25

2010 Information Model ProjectFederal Health Information Model and Standards (FHIMS)

class EHR-SD RM (FHIMS)

HITSP Constructs

+ Component (C)+ Transaction (T)+ Transaction Package (TP)+ Service Collaboration (SC)

HITSP Capability

+ Information Exchange+ option+ Scenario

EHR-SD RM

+ Clinical Document Architecture (CDA)+ EHR SD RM+ MHS/VA Data Model+ MHS/VA Information Model+ Reference Information Model (RIM)

Service

Design Specification

+ Capability+ conditions+ metadata

Interface

EHR-S FM

+ EHR-S FM+ Direct Care+ Supportive+ Information Infrastructure

requirementsdesign

Legend

Requirement

Selected Standard

Realize relationship: a source object implements or Realizes its destination object. Realize connectors are used to express traceability and completeness in the model.

Proposed Federal Health Information Model

Proposed Federal Health Data Model

Functions and Services differ in that a service enforces encapsulation (e.g., information hiding), has associated governance and a distributed user resource sharing agreement (DURSA), which defines the business rules for a service's information exchanges.

EHR-S FM is EHR System Functional-ModelEHR-SD RM is EHR Software-System-Service Design Reference-Model

Reference Information Model (RIM)

NEW

Clinical Document Architecture (CDA)

Information Exchange Requirement (IER)

+ Exchange Action+ Exchange Attribute+ Exchange Content+ Systems

MHS/VA Information Model

NEW

MHS/VA Data Model

NEW

Certification Criteria

+ Capability

ARRA Meaningful Use Measures

+ Stakeholder

NEW

realize

Page 26: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

26

2010 ProjectIntegrated EHR-SD RM, FHIMS,

HITSP Capabilities and ARRA Meaningful Useclass EHR-SD RM

HITSP

HL7

HITSP Constructs

+ Component (C)+ Transaction (T)+ Transaction Package (TP)+ Service Collaboration (SC)

HITSP Capability

+ Scenario+ Information Exchange+ option

Information Exchange Requirement (IER)

+ Systems+ Exchange Content+ Exchange Action+ Exchange Attribute

Service

Design Specification

+ Capability+ conditions+ metadata

Interface

Thomas Erl SOA Layers

+ Business Process Value Chains+ Composite Services+ Core Business Services+ Entity Services+ Agnostic Services+ Application Services+ Implementation Profiles

EHR-S FM

+ EHR-S FM+ Direct Care+ Supportive+ Information Infrastructure

requirementsdesign

Legend

Requirement

Selected Standard

Certification Criteria

+ Capability

Realize relationship: a source object implements or Realizes its destination object. Realize connectors are used to express traceability and completeness in the model.

MHS IM/IT

+ Capability

VA IM/IT

+ Capability

Proposed Federal Health Information Model

Proposed Federal Health Data Model

A HITSP Capability is in the interoperability space between systems.

Functions and Services differ in that a service enforces encapsulation (e.g., information hiding), has associated governance and a distributed user resource sharing agreement (DURSA), which defines the business rules for a service's information exchanges.

EHR-S FM is EHR System Functional-ModelEHR SD RM is EHR Software-System-Service Design Reference-Model

EHR-SD RM

+ Clinical Document Architecture (CDA)+ EHR SD RM+ MHS/VA Data Model+ MHS/VA Information Model+ Reference Information Model (RIM)

Reference Information Model (RIM)

NEW

NEW

Clinical Document Architecture (CDA)

Meaningful Use Criteria

+ StakeholderARRA Requirement for Certified EHR Systems

NEW

MHS/VA Information Model

MHS/VA Data Model

realize

HITSPCapabilities/Services

Page 27: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

27

Benefits

1. Faster, Better, Cheaper Integrated Requirements-Design Process2. Strategic Plan based on International and National Standards3. Objective Investment Portfolio Cost Estimation4. Minimize the Chance of Year of Execution Unfunded Requirements (UFRs)5. IM and IT aligned on Consistent Catalogue of Services6. MHS EHR Interoperability alignment with National Agenda

1. Manage Care Support Contractor (MCSC) interoperability2. VA interoperability

7. Consistent with Enterprise Architecture

Page 28: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

28

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

Page 29: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

ContentsEHR System Design Reference Model

(EHR-SD RM)

• Background– 2008 Project Results– 2009 HL7 EHR SD RM Project plan

• What Changed in 2009– 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– 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– AHIC Use Cases– EHR-S FM– HITSP Capabilities

• Next Steps 29

Page 30: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

30

EHR-SD RM PrototypeRequirements 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

Page 31: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

31

EXAMPLE ARTIFACT: Vaccine and Drug Administration and Reporting Information Exchanges

Page 32: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

32

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

Page 33: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

33

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

Page 34: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

34

• 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

34

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

Page 35: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

35 35

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

Page 36: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

36 36

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

Page 37: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

37 37

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

Page 38: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

38

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

Page 39: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

39

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.

Page 40: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

40

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

Page 41: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

41

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

Page 42: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

42

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

Page 43: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

43

Work PlansEHR-SD RM Next Steps

1. EHR SD RM Framework– Populate the framework with candidate healthcare Information Exchanges/ capabilities/

services, based on HL7 EHR-S Functional Model

2. Information Model– Loosely-coupled top-down Framework– Rigorously specified bottom up structure/ content

3. Publish HL7 HSSP Practical Guide for SOA in Healthcare Part 2: Case Study4. Socialize EHR SD RM5. Collaborate with others6. Informative ballot in 2010

Page 44: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

44

Questions??

What was omitted?

Suggestions for improvement?

How should the model be represented?

What should be balloted in 2010?

Page 45: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

45

Questions?

Contact us:

[email protected]

[email protected]

Project info available at:

• http://hitsp.wikispaces.com/HITSP+MODEL

• http://hssp.wikispaces.com/Reference+Architecture

Page 46: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

46

Backup

Page 47: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

47

Learning Objective

• Understand how to leverage SOA and Information Exchange Requirements (IER) in the System Design Reference Model

– Audience: Developers and Managers

– Analytic Process: How to integrate a healthcare system design or acquisition specification, with national standards • HL7, HITSP and CCHIT standards

– Benefits: Understand what is needed to create standards-based EHR interoperability at the Service level • Management level understanding supports funding justification

– Understanding of services as automating business functions

– Consistent reqmts, design-specs and implementations

– Better costing

Page 48: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

48

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

Page 49: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

49

Discussion Topics

• H-SOA Reference Architecture Project deliverables

• 2009 HITSP work on Information Exchanges (IEs) among Use Cases

• Building content of System Domain Reference Model (RM)

– From HL7, HITSP, DOD components

• Use Case Public Health & Emergency Response (PHER)

• System Domain (SD) analysis on PHER

Page 50: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

50

2009 Tasks

• 2009 Work Through HITSP

• Prototype

• HITSP IER Model

• Candidate Services

• Next Steps / Work Plan

Page 51: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

51

2008 ResultsHealthcare 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

Page 52: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

52

Exchange Content Number

Exchange Content Name

Definition of the Exchange Content Data Requirements

Genomic Decision Support Data

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

HITSP Exchange Content Contain Data Requirements (DRs)

CDA and ANSI X12 Data ModulesReusable DRs Lexical Consistency

Page 53: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

53

HL7 EHR System Functional Model (EHR-S)> 230 System Functions in 4 level categorization(see separate spreadsheet 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 military EHR.

Other O-1 Electronic Resource Planning (ERP)

O-2 Finances

O-3 Other

Business

Entity(Information)

Choreography

Infrastructure

Choreography

Business

Business

Infrastructure

Infrastructure

Infrastructure

Entity(Information)

Ser

vice

Typ

es

Sys

tem

Fun

ctio

ns

Choreography

Business

Page 54: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

54

Ap

plic

atio

n la

yer

Se

rvic

es

inte

rfa

ce la

yer

Bu

sin

ess

p

roce

ss la

yer

SOA LayersFocus on the Business Processes and Services [Thomas Erl]

.NET J2EE Legacy

Source: Service-Oriented Architecture, Thomas Erl

orchestration service layer

business service layer

application service layer

SystemComponentsand Services

Business Capabilities and Services

Page 55: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

55

SOA Service ModelsPotential Service Layers [Thomas Erl]

Service Model DescriptionApplication Service

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.

Business Service

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.

Controller Service

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.

Coordinator Services

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.

Page 56: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

56

SOA Service ModelsPotential Service Layers [Thomas Erl] (cont)

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.

Service Model Description

Page 57: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

57

EHR Data Reuse Through H-SOA-RAAcross Episodes of Care

• Patient Demographics• Provider Demographics• Insurer Demographic

IDENTITY

Terminology

Document

• Chronic Diagnoses• Procedure History

• Patient History• Summary Lists - Medication List - Allergy/Adverse Reaction List - Immunization

Current EpisodeOf Care EHR

Previous EpisodeOf Care EHR

Reu

sabl

e S

ervi

ces Data Must Be Verified

And Updated

Page 58: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

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

Page 59: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

59

Leveraging SOA Processing in the Enterprise

BusinessServices

Information Services

InfrastructureServices

ApplicationServices

Choreographies(Orchestration Services)

Legacy

Page 60: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

60IT PLATFORM

SUPPORT

ANALYTIC

DATA MANAGEMENT

PERFORMANCE

DECISION SUPPORT

RECORDS MANAGEMENT

DOCUMENT

SUPPLY CHAIN: (ORDERS/CHARGES)

SCHEDULING

AUTHORIZATION

TERMINOLOGY

IDENTITY

RADIOLO

GY

LABORATORY

PHARMACY

CLI

NIC

AS

U

T

ES

T O

NLY

O

UT

PA

TIE

NT

OT

HE

R

INP

AT

IEN

T E

R

CARDIOLO

GY

PT/O

T/SPEECH

DIETARY

SPECIALTY CARE

Ancillary Systems

Co

re B

usi

nes

s S

ervi

ces

INTEGRATEDREQUIREMENTS

DESIGNS: Putting the H-SOA-RA

Pieces Together

RESPIRATORY

Fed

erat

ed B

usi

nes

sS

ervi

ces

Ag

no

stic

S

ervi

ces

Federated Services, may be categorized by: -- Encounter Types -- CMS billing category -- Record type -- Care setting type -- etc.

Data sets are defined for each system functional-

capability-service moduleIn

ter-

Age

ncy

Inte

r-S

ervi

ceA

cros

sP

rovi

ders

Page 61: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

61

IT PLATFORM

SUPPORT

ANALYTIC

DATA MANAGEMENT

PERFORMANCE

DECISION SUPPORT

RECORDS MANAGEMENT

DOCUMENT

SUPPLY CHAIN:

(ORDER/CHARGE)

SCHEDULING

AUTHORIZATION

TERMINOLOGY

IDENTITY

RADIOLO

GY

LABORATORY

PHARMACY

CLI

NIC

AS

U

T

ES

T O

NLY

O

UT

PA

TIE

NT

OT

HE

R

INP

AT

IEN

T

ER

CARDIOLO

GY

PT/OT/H

SPEECH

DIETARY

SPECIALT

Y CARE

AncillaryApplications

Co

re E

HR

-S S

ervi

ces

RESPIRATORY

Patient Encounter Types

Fed

erat

ed

Ser

vice

s

Composite Services, which may be categorized by: -- CMS billing category -- Record type -- Care setting type -- etc.

Data sets are defined for each service – application – encounter type module

CASE MANAGEMENT

COORDINATION

AC

RO

SS

CA

RE

CO

NT

INU

UM

AC

RO

SS

SE

RV

ICE

S (

SO

As)

Page 62: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

62

Case Management Coordination Across SOAs and the Continuum

ASSESSMENTCARE

PLANNING

ORDERS &

SCHEDULING

BENEFITMANAGEMENT

AUTHORIZATION &

UTILIZATION MGT.

COMMUNICATION(FACILITATION

ADVOCACY)

DISCHARGE/TRANSFERPLANNING

REFERRAL RECORD TRANSPORT

ROLE OF CASE MANAGER

AcuteInpatient

ChronicRehab.

OutpatientWartimeTheater

ER AcuteRehab.

SkilledLongTerm Care

CustodialLongTermCare

HomeHealth

Prevention/Wellness

Care Continuum

Coordination ACROSS SOAS

cCOORDINATION ` ACROSS LEVELS OF CARE, PROVIDERS and LOCATIONS

EDUCATION.

Page 63: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

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

Page 64: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

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

Page 65: HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

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)