HL7 “EHR SD RM” Project “EHR System Design Reference Model”

44
Slide 1 EHR SD RM - EHR Way Forward … Future State Reference Architecture HL7 “EHR SD RM” Project “EHR System Design Reference Model” Constructing a Future State EHR Reference Architecture EHR Way Ahead Business Architecture Healthcare SOA Reference Architecture Enterprise Information Model From HL7 and HITSP Artifacts For presentation at HL7 Rio Workgroup Meeting, 18 May 2010 Details available at www.HSSP.wikispaces.com/Reference+Architecture [email protected], Dir Health Stds Participation [email protected], Architect & System Engineer Last Updated 24 March 2010

description

HL7 “EHR SD RM” Project “EHR System Design Reference Model” Constructing a Future State EHR Reference Architecture EHR Way Ahead Business Architecture Healthcare SOA Reference Architecture Enterprise Information Model From HL7 and HITSP Artifacts - PowerPoint PPT Presentation

Transcript of HL7 “EHR SD RM” Project “EHR System Design Reference Model”

Page 1: HL7 “EHR SD RM” Project  “EHR System Design Reference Model”

Slide 1EHR SD RM - EHR Way Forward … Future State Reference Architecture

HL7 “EHR SD RM” Project “EHR System Design Reference Model”

Constructing a Future State EHR Reference Architecture • EHR Way Ahead Business Architecture • Healthcare SOA Reference Architecture• Enterprise Information Model

From HL7 and HITSP ArtifactsFor presentation at HL7 Rio Workgroup Meeting, 18 May 2010

Details available at www.HSSP.wikispaces.com/Reference+Architecture

[email protected], Dir Health Stds [email protected], Architect & System Engineer

Last Updated 24 March 2010

Page 2: HL7 “EHR SD RM” Project  “EHR System Design Reference Model”

Slide 2EHR SD RM - EHR Way Forward … Future State Reference Architecture

Federal Enterprise Architecture (FEA)www.whitehouse.gov/omb/egov

Performance Reference Model - The FEA PRM is a framework to measure the performance of major IT initiatives and their contribution to program performance. The PRM leverages performance measurement best practices from the public and private sectors, including the Balanced Scorecard, Baldrige Criteria, Value Measurement Methodology, program logic models, the value chain, and the theory of constraints. There is an increased emphasis placed on linkage of investment to agency program performance and the PRM will help agencies produce enhanced performance information. Furthermore, the PRM will assist in: improving the alignment of program goals and objectives with Mission Area goals and objectives; improving communication of program contributions such as technology (input) to outputs and outcomes; and in identifying improvement opportunities that span traditional organizational boundaries.

Business Reference Model - The Business Reference Model (BRM) is a functional-driven framework for describing and organizing the day-to-day business operations of the Federal Government into Lines of Business (LOBs), independent of the agencies that perform the business operation. The BRM is the first layer of the Federal Enterprise Architecture and it is the organizing construct for the analysis of the other four reference models: performance, service components, data, and technology.

Service Component Reference Model - The Service Component Reference Model (SRM) is a functional framework to evaluate to identify government-wide opportunities to leverage IT investments and assets from a service perspective. This model helps understand the services delivered by the government and assess if there is an opportunity to group like services and create leverage opportunities, such as reuse or shared services.

Data Reference Model - The Data Reference Model (DRM) describes at an aggregate level, the data and information required to support the Lines of Business (LOBs). The three elements of data exchange that have been standardized include data description, data context, and data sharing. Establishing a common data model streamlines the information exchange process within and across the Federal Government and facilitates the ability to identify duplicative data resources.

Technical Reference Model - The Technical Reference Model (TRM) establishes a common technical framework for categorizing standards, specifications, and technologies that support and enable the delivery of services. This framework can be leveraged to support the development, delivery, and exchange of business and application components (Service Components) that may be leveraged in a Component-based or Service Oriented Architecture (SOA). Furthermore, it also serves as the foundation to advance the re-use of technology and best practices from each of the Service Components on a government-wide basis.

Page 3: HL7 “EHR SD RM” Project  “EHR System Design Reference Model”

Slide 3EHR SD RM - EHR Way Forward … Future State Reference Architecture

EHR-SD RM Project Description and PlanPROJECT DESCRIPTION: HL7 EHR System Design Reference Model (EHR SD RM) This project will mature the April 2008 Healthcare Services

Oriented Reference Architecture (H-SOA-RA) version 1.0 into H-SOA-RA Version 2.0, for HL7 Architecture Review Board (ArB) consideration, and then integrate it into an EHR System Design Reference Model (EHR-SD RM), using the HL7 SOA-Aware Enterprise Architecture Framework (SAIF), HITSP Multi-Enterprise Architecture of Networked Services Standards (MEANS), EHR System Functional Model (EHR-S FM). Emphasis will be placed on maintaining AHIC, HITSP, NHIN and CCHIT conformance by maintaining Information Exchange Requirements (IERs) and Data Requirements (DRs) traceability. Mapping and analysis of the HL7 product portfolio against the EHR-S FM will be used to integrate the reference architecture with HL7 product lines and initially mature the resulting model as a technical white papers, then an informative reference model and finally a standard reference model. An HSSP based prototype case study architectural specification will be built to validate the effort.

Phases: For Project Information, see http://hssp.wikispaces.com/Reference+Architecture

1. EHR SD RM Framework– Populate the framework with HL7 EHR-S Functional Model content, candidate healthcare Information

Exchanges, HITSP capabilities/ services and data architecture 2. Information Model

– Loosely-coupled top-down Framework– Rigorously specified bottom up structure/ content based on HITSP Data Architecture

3. Socialize EHR SD RM (HL7 Meeting, Jan 2010)4. Collaborate with others within HL7 (ongoing)5. Publish HL7 HSSP Practical Guide for SOA in Healthcare Part 2: Case Study (May 2010)6. Solicit public comment; collaborate with IHE; HL7/OMG SOA Conference (May to Sept)7. HL7 Informative ballot (Oct 2010)8. HL7 Normative ballot (Oct 2011)

Page 4: HL7 “EHR SD RM” Project  “EHR System Design Reference Model”

Slide 4EHR SD RM - EHR Way Forward … Future State Reference Architecture

EHR SD RM Milestones

2008 2009 2010

Healthcare SOA

Reference Architecture

(H-SOA-RA)

EHR SD RM Immunization & Response Management

(IRM) Prototype

HSSP Practical Guide for SOA in

Healthcare Volume II: IRM Case

Study __________

EHR SD RM Informative

DSTU

DSTU is Draft Standard for Trial Use (ANSI standards development)

2011

EHR SD RM Normative Standard

Page 5: HL7 “EHR SD RM” Project  “EHR System Design Reference Model”

Slide 5EHR SD RM - EHR Way Forward … Future State Reference Architecture

class Capability

seq Capability

Business Goal

Business Process Model

Core Business Area

Business

Mission Segment

Cost Benefits Analysis

- cost- benefits- AOA

Solution

+ Actor+ Application Specification+ Logical Data Model+ Scenario+ Software (notional)+ Use Case+ Use Case Association+ Use Case Step+ Versioned Specification

Alternatives

Bold indicates addition/change to CBDI

Legend

Software/Service (Notional)

+ Inter Software Relationship+ Nonsoftware Services+ Proposed Operation+ Software Classification+ Software Classification Group+ Software Function+ Software Service+ Software/Service (notional)

User Outcome

Policy

Organization

Enterprise Information Model

+ Business Rules+ Code Set+ Data Module+ Data Structure+ Grammar+ Morphology+ Ontology+ Syntax+ Vocabulary-Terminology

Operational Activity

+ Level 1: Business+ Level 2: Component+ Level 3: Detail

Specification

Security and Privacy

Reference Architecture

Exchange Architecture

Deployment

Strategic Objectives

supportsderived from

«import»

«import»

«import»

describes

«import»

«import»

supports

derived from

supports

«import»

1..*

derived from

constrained by

«import»

«import»

«import»

Linking Business and Technical Architectures

Page 6: HL7 “EHR SD RM” Project  “EHR System Design Reference Model”

Slide 6EHR SD RM - EHR Way Forward … Future State Reference Architecture

CONTENTS2. Constructing a Future State EHR Reference Architecture

3. HL7 EHR System Functional Model (EHR-S FM)

4. Healthcare SOA Reference Framework

5. HL7 RIM (Reference Information Model)

6. HITSP Harmonization Framework

7. HITSP Constructs

8. HITSP Data Architecture

9. HITSP Clinical Document Components

10. HITSP/C83 Data Module Categories

11. EHR Way Forward Business Architecture Specification Framework

12. Future State EHR Reference Architecture Adding ARRA and FHIM

13. Basic UML Legend

14. Abbreviations

15. PART II: HL7 SAIF, Requirements Management, Architecture and Governance Processes

16. PART III: Prototype (Immunization and Adverse Event Reporting)

Page 7: HL7 “EHR SD RM” Project  “EHR System Design Reference Model”

Slide 7EHR SD RM - EHR Way Forward … Future State Reference Architecture

Constructing a Future State EHR Reference Architecture

OBJECTIVE: A system agnostic Future State EHR Business Architecture (BA) specified with a lexicon, based upon HITSP’s data architecture, HL7’s System Functional Model (EHR-S FM) and HL7’s Reference Information Model (RIM).

A Health IT EHR BA can be modeled as clinical stakeholder requirements and their workflow-orchestration of

HL7 RIM compliant HITSP data modules manipulated by

HL7 EHR-S FM functions.

An EHR Information Model, for a project or enterprise, can be constructed from the HITSP data models managed by the EHR Functions used within the EHR BA, categorized using the HL7 RIM Entity, Role and Action foundation classes.

These concepts are the topic of this presentation

Page 8: HL7 “EHR SD RM” Project  “EHR System Design Reference Model”

Slide 8EHR SD RM - EHR Way Forward … Future State Reference Architecture

HL7 EHR System Functional Model (EHR-S)> 160 System Functions in 4 level categorization

(separate spreadsheet available for full enumeration)

NOTE: “Other” Category - The EHR-S model does NOT include Electronic Resource Planning (ERP) / Logistics and Financial components, which are needed for completeness of a Health IT Enterprise.

Other O-1 Electronic Resource Planning (ERP)

O-2 Finances

O-3 Other

Sys

tem

Fu

nct

ion

s

EHR-S FM functions can be grouped into Service Components … aka Capabilities

(e.g., Lab Order Capability, which

does eligibility and authorization

function as well as lab order function).

Page 9: HL7 “EHR SD RM” Project  “EHR System Design Reference Model”

Slide 9EHR SD RM - EHR Way Forward … Future State Reference Architecture

Healthcare SOA FrameworkBased on HL7 EHR System Functional Model & Thomas Erl’s SOA Layers HL7 System Functions Direct Care Supportive Information

InfrastructureOther

Business Process

Value Chains

CompositeServices Federated Composition (e.g., Choreograph or Orchestration) Within and Across Business Areas

Core BusinessServices

Functional Areas + Focal Classes

Functional Areas + Focal Classes

Functional Areas + Focal Classes

Functional Areas + Focal Classes

EntityServices

Information Management

Information Management

Information Management

Information Reporting and Management

Agnostic Services C r o s s T e c h n I c a l “Common S e r v I c e s”(e.g., Security, Privacy, Auditing, Logging…)

ApplicationServices

Ambulatory Care Systems,In Patient Care Systems

Logistics SystemsFinancial Systems

Decision Support Systems

Data MartsRepositories

Business Objects

ImplementationProfiles

Integrated Healthcare Enterprise (IHE) Profiles

Analysis Profiles Communications Profiles/Stacks

Implementation Profiles

9

Page 10: HL7 “EHR SD RM” Project  “EHR System Design Reference Model”

Slide 10EHR SD RM - EHR Way Forward … Future State Reference Architecture

HL7 EHR_S-Based Functional Architecture/Services Analysis

Security

Unique ID, Registry, and DirectorTerminology

Information and Records Management

Interoperability

ETCSupport Knowledge Access

Support Clinical Communication Clinical Workflow TaskingClinical Decision Support

Record Patient Specific Instructions Documentation of Care, Measurement, and Results

Orders and Referral Management Care Plans, Treatment Plans, Guidelines, and Protocols

Management of AssessmentSummary Lists

Preferences, Directives, Consents, and Authorizations Manage Patient History

Record Management

Manage Business RulesETC

Pri

mar

y C

are

Cri

tica

l/Em

erg

ency

Car

e

Den

tal

No

n-S

urg

ical

Sp

ecia

lty

Car

e

Lab

ora

tory

Nu

rsin

g

Ph

arm

acy

Po

pu

lati

on

Hea

lth

Beh

avio

ral H

ealt

h

ET

C.

Cro

ss-C

utt

ing

Dir

ect

Car

e/S

up

po

rt F

un

ctio

ns

Infra

stru

ctur

e

Func

tions

Lines of Business

InfrastructureServices•Security•Policy•Records Management•Audit•Terminology•Registry•Workflow•Business Rules•etc

Core ClinicalServices•Entity Identification•Resource Location and Updating Services•Decision Support•Orders Management•Scheduling•Image Management•Etc.

Page 11: HL7 “EHR SD RM” Project  “EHR System Design Reference Model”

Slide 11EHR SD RM - EHR Way Forward … Future State Reference Architecture

SUPPLY CHAIN (ORDER/CHARGE)

ANATOMY OF AN ANCILLARY SYSTEM

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

11

Page 12: HL7 “EHR SD RM” Project  “EHR System Design Reference Model”

Slide 12EHR SD RM - EHR Way Forward … Future State Reference ArchitectureIT 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 module 12In

ter-

Age

ncy

Inte

r-S

ervi

ceA

cros

sP

rovi

ders

Page 13: HL7 “EHR SD RM” Project  “EHR System Design Reference Model”

Slide 13EHR SD RM - EHR Way Forward … Future State Reference Architecture

HL7 RIM (Reference Information Model)Six Core Classes Defining a Semantic Framework which

Maintains Clinical Data Context

The HL7 RIM expresses the data content needed in a specific clinical or administrative context and provides an explicit

representation of the semantic and lexical connections that exist between the information carried in the fields of HL7 messages.

Role link

Act relationship

Participation

The HL7 RIM supports EHR interoperability; an EHR may needs additional foundation classes (e.g., Responsibility)

Language /

communication

ACT (aka ACTION)ROLEENTITY

ACT – something that has happened or may happenEntity – a person, animal, organization, or thingRole – a responsibility of, or part played by, an EntityParticipation – the involvement of a Role in an ActAct Relationship – a relationship between two ActsRole Link – a relationship between two Roles.

Page 14: HL7 “EHR SD RM” Project  “EHR System Design Reference Model”

Slide 14EHR SD RM - EHR Way Forward … Future State Reference Architecture

HITSP Constructs A HITSP Interoperability Specification (IS) defines a business context, supports a business

workflow, constrains and orchestrates underlying constructs.

A HITSP Capability (CAP) is a specification that assembles HITSP constructs to fulfill a business need for information exchanges. To use a Capability, an Interoperability Specification or an implementation conformance statement must assign Systems to one or more Capability System Roles and identify how the Capability Options are to be addressed. The use of a Capability shall:

– for each assigned Capability System Role, the responsibilities of the assigned System Role must be supported, including all interfaces specified by the underlying HITSP constructs according to the conditions specified for the assigned System Role.

– If a Capability option is selected, the implementation must conform to the Capability’s specifications for that option.

A HITSP Service Collaboration (SC) binds communications infrastructure, security and privacy constructs together.

A HITSP Transaction Package (TP), Transaction (T), Component (C) is where standards-based Interface Design Specifications are specified and conformance requirements are defined.

Page 15: HL7 “EHR SD RM” Project  “EHR System Design Reference Model”

Slide 15EHR SD RM - EHR Way Forward … Future State Reference Architecture

HITSP Harmonization Framework

AddressingBusiness

Needs

ProvidingInfrastructure,

Security,Privacy

Data Architecture

Available for Independent Implementation

DefiningInformation

Content

IS = Interoperability Specification

Base and Composite Standards

Page 16: HL7 “EHR SD RM” Project  “EHR System Design Reference Model”

Slide 16EHR SD RM - EHR Way Forward … Future State Reference Architecture

class Data Architecture

EHR System Interoperability Specifications

Capability

Data Architecture

Data Module

Data Element

Value Set

HITSP Constructs

Component (C)

Transaction Package (TP)

Transaction (T)

Service Collaboration (SC)

Selected Standard

HITSP/C83 - CDA Content Modules Component

HITSP/C154 - HITSP Data Dictionary

HITSP/ C80 - Clinical Document and Message Terminology Component

HITSP/TN903 - Data Architecture Technical Note

HITSP/TN904 - Harmonization Framework and Exchange Architecture Technical Note

HITSP/TN901 - Technical Note for Clinical Documents

Data Requirement (DR)

+ Data Module

Capability Requirements

+ Information Exchange+ option+ Scenario+ system role

ARRA Requirement for Certified EHR Systems

Information Exchange Requirement (IER)

+ Systems+ Exchange Content+ Exchange Action+ Exchange Attribute

ARRA Meaningful Use Measures

+ Stakeholder

Regulatory Guidance

Scenario

+ conditions

Certification Criteria

+ Capability

Capability Design

+ conditions+ optionality+ system role

requirementsdesign

Legend

HITSP Data Architecture within

HITSP Harmonization Framework

GREEN indicates reusable elements

HITSP Documents are available at www.HITSP.orgDetailed HITSP Data Architecture is available online at www.USHIK.org

Page 17: HL7 “EHR SD RM” Project  “EHR System Design Reference Model”

Slide 17EHR SD RM - EHR Way Forward … Future State Reference Architecture

HITSP Clinical Document Components

HITSP Reuse Paradigm: With HITSP/Capability 119 - Communication of Structured

Documents, a HL7 Clinical Data Architecture (CDA) document can be

composed, from any group of C83 data modules, and then it can be

communicated. Benefit: agile system interoperability.

Page 18: HL7 “EHR SD RM” Project  “EHR System Design Reference Model”

Slide 18EHR SD RM - EHR Way Forward … Future State Reference Architecture

HITSP/C83 Data Module CategoriesModule Category Description

Personal Information The personal information includes name, address, contact information, personal identification information, ethnic and racial affiliation and marital status of a person

Support Support includes the patient's sources of support, such as immediate family, relatives and/or guardians. This includes next of kin, caregivers, support organizations, and key contacts relative to healthcare decisions. Support providers may include providers of healthcare related services, such as a personally controlled health record, or registry of emergency contacts

Healthcare Providers This includes a list of the healthcare providers and organizations that provide or have provided care to the patient

Insurance Providers and Payers

Insurance providers include data about the organizations or individuals who may pay for a patient's healthcare, and the relationships, demographics and identifiers of those individuals with respect to the payer. Such organizations or individuals may be health insurance plans, other payers, guarantors, parties with financial responsibility, some combination of payers or the patient directly

Allergies and Drug Sensitivities

This includes the allergy or intolerance conditions, severity and associated adverse reactions suffered by the patient

Conditions This includes relevant clinical problems and conditions for which the patient is receiving care, including information about onset, severity, and providers treating the condition. Conditions are broader than, but include diagnoses

Medications This includes the patient's prescription or non-prescription medications and medication history, and may include prescriptions, fulfillments and medication administration activities

Immunizations This includes data describing the patient's immunization history

Vital Signs This includes data about the patient’s vital signs

Test Results This includes data about current and historical test results from laboratory or other diagnostic testing performed on the patient

Encounter This includes data describing the interactions between the patient and clinicians. Interaction includes both in-person and non-in-person encounters such as telephone and email

Procedures This includes data describing procedures performed on a patient

Family History Data defining the patient’s genetic relatives in terms of possible or relevant health risk factors that have a potential impact on the patient’s health

Social History Data defining the patient’s occupational, personal (e.g. lifestyle), social, and environmental history that have a potential impact on the patient’s health

Medical Equipment Medical Equipment includes implanted and external medical devices and equipment that a patient’s health status depends on, as well as any pertinent equipment or device history

Functional Status Data defining the patient’s functional status with respect to, ambulatory ability, mental status or competency, activities of daily living, including bathing, dressing, feeding, grooming, home/living situation having an effect on the health status of the patient, and ability to care for self

Plan of Care The plan of care contains data defining prospective or intended orders, interventions, encounters, services, and procedures for the patient

Page 19: HL7 “EHR SD RM” Project  “EHR System Design Reference Model”

Slide 19EHR SD RM - EHR Way Forward … Future State Reference Architecture

Functional Analysis Object Analysis

Requirements Analysis

Interface Design Analysis Service Analysis

EHR Future State Reference Architecture

Page 20: HL7 “EHR SD RM” Project  “EHR System Design Reference Model”

Slide 20EHR SD RM - EHR Way Forward … Future State Reference Architecture

Value Proposition of Standards Based Approach

Analysis Pre-Done: Analysts from throughout industry have vetted and contributed to the development of thorough specifications

Less Customization: COTS vendors are already building applications to meet these specifications.

Comprehensive View: Standards provide a way to ensure that requirements and design address all of the necessary issues

Lack of unexpected dependencies late in project: All functions and specifications have been pre-analyzed and defined

Better Interoperability: Standards based approaches will ensure development between all stakeholders are able to communicate at the project and technical level

Across Project Visibility: Normalized requirements and design would allow for “apples to apples” comparison across the portfolio

Page 21: HL7 “EHR SD RM” Project  “EHR System Design Reference Model”

Slide 21EHR SD RM - EHR Way Forward … Future State Reference Architecture

Basic UML Legend class Basic UML Legend

Book

Preface

Chapter

Publisher

Biography

Author Legend

A book realizes an author's concept outline. A Concept Outline and a Book depends on an Author to be written. A Book "has-an" index and is composed of one or more chapters. A Biography "is-a" type of book. A Book is associated with a publisher. Association is a relationship between two classes, that may describes the reasons for the relationship and the rules that govern the relationship. Aggregation ("has-a") is a special form of an association that specifies a whole-part relationship between the aggregate (whole) and a component part. The parts can

exist on their own and are therefore shareable among multiple owner classes. Composition (a strong type of "uses a" relationship) is a form of aggregation which requires that a part instance be included in at most one composite at a time, and

that the composite object is responsible for the creation and destruction of the parts. A dependency is a type of relationship that signifies that one element, or group of elements, acting as the client depends on another element or group of elements that

act as a supplier. It is a weak relationship that denotes that if the supplier is changed the client may be affected. It is a unidirectional relationship. Realize is a relationship where a source object implements or Realizes its destination object. Realize connectors are used to express traceability and completeness in

the model. Generalization ("is-a") is a relationship in which one model element (the child) is based on another model element (the parent).

Concept Outline

dependency

aggregate1..*

compose

associate

generalize

realize

Page 22: HL7 “EHR SD RM” Project  “EHR System Design Reference Model”

Slide 22EHR SD RM - EHR Way Forward … Future State Reference Architecture

Abbreviations

B-Case is Business Case

BPM is Business Process Model

CCD is Continuity of Care Document

CCHIT is Certification Commission for Health Information Technology

CDRL is Contract Deliverable

DBT is Defense Business Transformation

IHE is Integrating the Healthcare Enterprise

NHIN is National Health Information Exchange

PCC is Patient Care Coordination

RM-ODP is Reference Model of Open Distributed Processing

SOA is Service Oriented Architecture

Page 23: HL7 “EHR SD RM” Project  “EHR System Design Reference Model”

Slide 23EHR SD RM - EHR Way Forward … Future State Reference Architecture

PART II: HL7 SAIF, Requirements Management and Architectural Processes

• The HL7 Services-Aware Interoperability Framework (SAIF)

• HL7 SAIF ECCF Specification Stack

• HITSP Within HL7 SAIF ECCF Specification Stack

• HL7, HITSP, FHIMS and NHIN Within HL7 SAIF ECCF Specification Stack

• Business Capability Lifecycle (BCL)

• Develop/ Update Reference Architecture

• Requirements Management Process

• BACKUP SLIDES: Example (Immunization and Adverse Event Reporting)

Page 24: HL7 “EHR SD RM” Project  “EHR System Design Reference Model”

Slide 24EHR SD RM - EHR Way Forward … Future State Reference Architecture

EHR SD RM supporting Requirements & Architectural Processes

2010 slide

Page 25: HL7 “EHR SD RM” Project  “EHR System Design Reference Model”

Slide 25EHR SD RM - EHR Way Forward … Future State Reference Architecture

System Development

‘V’DE

SIG

N

FAB

, IN

TEG

RA

TE &

TE

ST

SFR

PDRTRR

SVR

EHR SD RM (Architecture Development Cycle)

EHR SD RMEHR SD RM

RequirementsAnalysis

RequirementsAnalysis

Architecture Design

Architecture Design

Stakeholder Requirements

Definition

Stakeholder Requirements

DefinitionRequirements Loop

VerificationLoop

DesignLoop

PROCESS INPUTS-Required Capabilities-Environments-Constraints

PROCESS OUTPUTS-System Architecture, -System & Test Specifications-Configuration Management Baselines

Test Criteria Analysis

Test Criteria Analysis

Page 26: HL7 “EHR SD RM” Project  “EHR System Design Reference Model”

Slide 26EHR SD RM - EHR Way Forward … Future State Reference Architecture

EHR SD RM (Architecture Development Cycle)

Stakeholder Requirements

– What is the system supposed to do?

– Where will the products of the system be used?

– Under what conditions will the products be used?

– How often? How long?

– Who will use the products of the system?

Requirements Analysis (“HOW?” using “Action Verbs”)

– Analyze functions and Services

Decompose higher level functions to lower level functions

Allocate performance requirements to the functions

Architecture Design (Which hardware/ software elements)

– Define the physical architecture

Each part must perform at least one function

Some parts may perform more than one function

Requirements Loop

Ensure all requirements are covered by at least one function

Ensure all functions are justified by a valid requirement (no unnecessary duplication)

Design Loop

Ensure all functions are covered by at least one hardware or software element

Ensure all elements of physical architecture are justified by a valid functional requirement (no unnecessary duplication)

Verification Loop

Each requirement must be verifiable that the solution meets requirements

Verification can be accomplished by: Inspection, Analysis, Demonstration, Test

Page 27: HL7 “EHR SD RM” Project  “EHR System Design Reference Model”

Slide 27EHR SD RM - EHR Way Forward … Future State Reference Architecture

The HL7 Services-Aware Interoperability Framework (SAIF)

SAIF Contains: Enterprise Conformance and Compliance Framework (ECCF) is based on RM-ODP Behavioral Framework (BF)

– Interoperability Scenarios supporting the RM-ODP Computational Viewpoint Governance Framework (GF)

– Governance is the overarching policy structure and set of related processes by which a group exercises its authority and demonstrates accountability for accepted responsibilities within a particular jurisdiction.

SAIF Principles: Applicable within each of HL7’s three Interoperability Paradigms (IPs),

– (i.e., messages, documents, and services). Provide support for measurable conformance and compliance. Define appropriate governance structures and processes. Provide support for directly implementable solutions. Address the growing disparity between the various solution sets emerging from HL7. Utilize existing V3/RIM artifacts and expertise to the maximum degree possible.

Page 28: HL7 “EHR SD RM” Project  “EHR System Design Reference Model”

Slide 28EHR SD RM - EHR Way Forward … Future State Reference Architecture

HL7 SAIF ResponsibilitiesConformance and Compliance Framework (ECCF)

Consistency

Tra

ceab

le

Implementation“Where”

Behavior“How”

Content“What”

Policy“Why”

Page 29: HL7 “EHR SD RM” Project  “EHR System Design Reference Model”

Slide 29EHR SD RM - EHR Way Forward … Future State Reference Architecture

HL7 SAIF Specification Stack ViewsConformance and Compliance Framework (ECCF)

Consistency

Tra

ceab

le

ImplementationBehaviorContentPolicyTopic

Specification

Enterprise / Business View

“WHY”

Information View

“WHAT”

Computational View

“HOW”

Engineering View

“WHERE”

Conceptual

Business Context, Reference Context

Domain Analysis (Information) Model

Collaboration Analysis, Functional Profile(s), Service Roles and

Relationships

Existing Platform capabilities

Platform-

Independent

Business Governance Project-oriented Domain Information Model,

Constrained Information Model, Localized Information Model, Hierarchical Message

Definition

Collaboration Types, Interface Specification and Functional

Groups, Interaction Types and Collaboration Participations,

Contracts Parts

Existing Platform models, libraries, etc.

Platform-

Specific

Rules, Procedures Localized Information Model, Transforms, Schema

Collaboration scripts, Orchestrations, Realized

Interfaces

Execution Context, Platform Bindings, Deployment Model

Page 30: HL7 “EHR SD RM” Project  “EHR System Design Reference Model”

Slide 30EHR SD RM - EHR Way Forward … Future State Reference Architecture

HITSP WithinHL7 SAIF ECCF Specification Stack

Topic

Specification

Enterprise / Business View

“WHY”

Information View

“WHAT”

Computational View

“HOW”

Engineering View

“WHERE”

Conceptual

Business Context, Reference Context

Domain Analysis (Information) Model

Collaboration Analysis, Functional Profile(s), Service Roles and

Relationships

Existing Platform capabilities

Platform-

Independent

Business Governance Project-oriented Domain Information Model,

Constrained Information Model, Localized Information Model, Hierarchical Message

Definition

Collaboration Types, Interface Specification and Functional

Groups, Interaction Types and Collaboration Participations,

Contracts Parts

Existing Platform models, libraries, etc.

Platform-

Specific

Rules, Procedures Localized Information Model, Transforms, Schema

Collaboration scripts, Orchestrations, Realized

Interfaces

Execution Context, Platform Bindings, Deployment Model

Consistency

Tra

ceab

le

HITSP DAHITSP CAP

Harmonization Requests/ Use Case

HITSP CAP

HITSP Transaction,

Transaction Package and Service

Collaboration

HITSP Component

HITSP IS

ImplementationBehavior

HITSP Harmonization

Framework

EHR-S FM is EHR System Functional ModelEHR SD RM is EHR System Design Reference ModelRIM is Reference Information ModelFHIMS is Federal Health Information Model & StandardsDA is Data Architecture

ContentPolicy

Page 31: HL7 “EHR SD RM” Project  “EHR System Design Reference Model”

Slide 31EHR SD RM - EHR Way Forward … Future State Reference Architecture

HL7, HITSP, FHIMS and NHIN WithinHL7 SAIF ECCF Specification Stack

Topic

Specification

Enterprise / Business View

“WHY”

Information View

“WHAT”

Computational View

“HOW”

Engineering View

“WHERE”

Conceptual

Business Context, Reference Context

Domain Analysis (Information) Model

Collaboration Analysis, Functional Profile(s), Service Roles and

Relationships

Existing Platform capabilities

Platform-

Independent

Business Governance Project-oriented Domain Information Model,

Constrained Information Model, Localized Information Model, Hierarchical Message

Definition

Collaboration Types, Interface Specification and Functional

Groups, Interaction Types and Collaboration Participations,

Contracts Parts

Existing Platform models, libraries, etc.

Platform-

Specific

Rules, Procedures Localized Information Model, Transforms, Schema

Collaboration scripts, Orchestrations, Realized

Interfaces

Execution Context, Platform Bindings, Deployment Model

Consistency

Tra

ceab

le

HL7 RIMFHA FHIMSHITSP DAHITSP CAP

Harmonization Requests/ Use Case

HITSP Capability

HITSP Transaction,

Transaction Package and Service

Collaboration

HITSP Component

HL7 EHR-S FMHITSP

Harmonization Framework

HL7 EHR SD RM

HITSP IS

EHR-S FM is EHR System Functional ModelEHR SD RM is EHR System Design Reference ModelRIM is Reference Information ModelFHIMS is Federal Health Information Model & StandardsDA is Data Architecture

NHIN ConnectServices

Tomcat, JBoss, J2SE, Eclipse,

GlassFish ESB, OpenSSO

31

ImplementationBehaviorContentPolicy

Page 32: HL7 “EHR SD RM” Project  “EHR System Design Reference Model”

Slide 32EHR SD RM - EHR Way Forward … Future State Reference Architecture

PART III Prototype EXAMPLE

Vaccination and Adverse Event Reporting Prototype– AHIC Use Cases– EHR-S FM– HITSP Capabilities– Information Model

Page 33: HL7 “EHR SD RM” Project  “EHR System Design Reference Model”

Slide 33EHR SD RM - EHR Way Forward … Future State Reference Architecture

The IRM AHIC Use Case and HITSP Interoperability Specification are intended to support current interoperability approaches between EHRs and Immunization Information Systems while allowing for a migration toward emerging interoperability implementations and document sharing environments where PHRs are able to be included in the information flow

The Interoperability Specification also allows for basic electronic information exchanges to enable requirement communications and alerting mechanisms and to lay the foundation for future clinical support capabilities – Scenario 1: Vaccine and Drug Administration and Reporting and– Scenario 2: Vaccine and Drug Inventory Reporting

EHR-SD RM Prototype [2008 AHIC Use Cases] Immunization and Response Management (IRM)

Page 34: HL7 “EHR SD RM” Project  “EHR System Design Reference Model”

Slide 34EHR SD RM - EHR Way Forward … Future State Reference Architecture 34

EXAMPLE ARTIFACT: Vaccine and Drug Administration and Reporting Information Exchanges

Page 35: HL7 “EHR SD RM” Project  “EHR System Design Reference Model”

Slide 35EHR SD RM - EHR Way Forward … Future State Reference Architecture

EXAMPLE ARTIFACT Vaccine and Drug Administration and Reporting Use Case

Full use case available at: http://healthit.hhs.gov/portal/server.pt?open=512&objID=1255&parentname=CommunityPage&parentid=1&mode=2&in_hi_userid=10741&cached=true

Page 36: HL7 “EHR SD RM” Project  “EHR System Design Reference Model”

Slide 36EHR SD RM - EHR Way Forward … Future State Reference Architecture

EHR-SD RM PrototypeInformation Exchange Requirements (IERs)

Vaccine and Drug Administration and Reporting Use Case

IER10 Identify patient IER13 Send/receive notification of document availability IER18 Send/receive clinical document IER26 Identify communication recipients IER27 Send non-patient notification message or alert IER40 Query for existing data IER42 Request/receive medical concept knowledge IER54 Query/response for clinical message data IER67 Send/receive clinical message IER78 Send/receive Vaccine Inventory Requirements IER79 Query/response for inventory usage data IER80 Send/receive Vaccine Inventory Data

For details, see HITSP IS 10 Immunization and Response

Management, available at www.HITSP.org

Page 37: HL7 “EHR SD RM” Project  “EHR System Design Reference Model”

Slide 37EHR SD RM - EHR Way Forward … Future State Reference Architecture

DR08 Unstructured Data DR11 Immunization response data DR12 Adverse Event Report DR13 Drug/Vaccine Inventory Data DR14 Drug/Vaccine Inventory Usage Data DR15 Drug/Vaccine Inventory Availability Data DR16 Supply Chain Management Vaccine Recall DR17 Decision Support Data DR18 Vaccination Data DR19 Medication Administration data DR20 Aggregate Inventory of Available Vaccine DR21 Terminology Data DR22 Generic Alert Data DR23 Consumer Vaccination View

EHR-SD RM PrototypeData Requirements (DRs)

Vaccine and Drug Administration and Reporting Use Case

For details, see HITSP IS 10 Immunization and Response

Management, available at www.HITSP.org

Page 38: HL7 “EHR SD RM” Project  “EHR System Design Reference Model”

Slide 38EHR SD RM - EHR Way Forward … Future State Reference Architecture

EHR-SD RM PrototypeHITSP Security and Privacy

Vaccine and Drug Administration and Reporting Use Case

IER01 Provide authorization and consent

IER02 Send data over secured communication channel

IER03 Create audit log entry

IER04 Synchronize system time

IER05 Verify entity identity

IER06 Provide proof of document integrity and origin

IER55 Anonymize patient identifiable data

IER56 Pseudonymize patient identifying information For details, see HITSP IS 10 Immunization and Response

Management, available at www.HITSP.org

Page 39: HL7 “EHR SD RM” Project  “EHR System Design Reference Model”

Slide 39EHR SD RM - EHR Way Forward … Future State Reference Architecture

EXAMPLE ARTIFACT HL7 Requirements and Certification Criteria and HITSP Design

class EHR-S FM: CAP131 Update Immunization Registry

DC.1.8.2 (Manage Immunization Administration) CAP132 Retrieve Immunization Registry Information

CAP131 Update Immunization Registry

CAP133 Communicate Immunization Summary

HL7EHR System

Functional Model

HITSPInteroperability Specifications

Page 40: HL7 “EHR SD RM” Project  “EHR System Design Reference Model”

Slide 40EHR SD RM - EHR Way Forward … Future State Reference Architecture

EXAMPLE ARTIFACT EHR-S Requirements

class DC.1.8.2 (Manage Immunization Administration)

+ 1.The system SHALL provide the ability to recommend required immunizations, and when they are due, during an encounter based on widely accepted immunization schedules.+ 1.The system SHALL provide the ability to recommend required immunizations, and when they are due, during an encounter based on widely accepted immunization schedules.+ 2.The system SHOULD provide the ability to recommend required immunizations based on patient risk factors.+ 2.The system SHOULD provide the ability to recommend required immunizations based on patient risk factors.+ 3.The system SHALL perform checking for potential adverse or allergic reactions for all immunizations when they are about to be given.+ 3.The system SHALL perform checking for potential adverse or allergic reactions for all immunizations when they are about to be given.+ 4.The system SHALL provide the ability to capture immunization administration details, including date, type, lot number and manufacturer.+ 4.The system SHALL provide the ability to capture immunization administration details, including date, type, lot number and manufacturer.+ 5.The system SHOULD provide the ability to capture other clinical data pertinent to the immunization administration (e.g. vital signs).+ 5.The system SHOULD provide the ability to capture other clinical data pertinent to the immunization administration (e.g. vital signs).+ 6.The system SHALL record as discrete data elements data associated with any immunization.+ 6.The system SHALL record as discrete data elements data associated with any immunization.+ 7.The system SHOULD provide the ability to associate standard codes with discrete data elements associated with an immunization.+ 7.The system SHOULD provide the ability to associate standard codes with discrete data elements associated with an immunization.+ 8.The system SHALL provide the ability to update the immunization schedule.+ 8.The system SHALL provide the ability to update the immunization schedule.+ 9.The system SHOULD provide the ability to prepare a report of a patient‘s immunization history upon request for appropriate authorities such as schools or day-care centers.+ 9.The system SHOULD provide the ability to prepare a report of a patient‘s immunization history upon request for appropriate authorities such as schools or day-care centers.+ 10.The system SHALL conform to function DC.1.4.1 (Manage Allergy, Intolerance and Adverse Reaction Lists).+ 10.The system SHALL conform to function DC.1.4.1 (Manage Allergy, Intolerance and Adverse Reaction Lists).+ 11.The system SHOULD transmit required immunization information to a public health immunization registry.+ 11.The system SHOULD transmit required immunization information to a public health immunization registry.+ 12.The system SHOULD receive immunization histories from a public health immunization registry.+ 12.The system SHOULD receive immunization histories from a public health immunization registry.

DC.1.8.2 Conformance Criteria

+ 1.The system SHALL provide the ability to recommend required immunizations, and when they are due, during an encounter based on widely accepted immunization schedules.+ 2.The system SHOULD provide the ability to recommend required immunizations based on patient risk factors.+ 3.The system SHALL perform checking for potential adverse or allergic reactions for all immunizations when they are about to be given.+ 4.The system SHALL provide the ability to capture immunization administration details, including date, type, lot number and manufacturer.+ 5.The system SHOULD provide the ability to capture other clinical data pertinent to the immunization administration (e.g. vital signs).+ 6.The system SHALL record as discrete data elements data associated with any immunization.+ 7.The system SHOULD provide the ability to associate standard codes with discrete data elements associated with an immunization.+ 8.The system SHALL provide the ability to update the immunization schedule.+ 9.The system SHOULD provide the ability to prepare a report of a patient‘s immunization history upon request for appropriate authorities such as schools or day-care centers.+ 10.The system SHALL conform to function DC.1.4.1 (Manage Allergy, Intolerance and Adverse Reaction Lists).+ 11.The system SHOULD transmit required immunization information to a public health immunization registry.+ 12.The system SHOULD receive immunization histories from a public health immunization registry.

Page 41: HL7 “EHR SD RM” Project  “EHR System Design Reference Model”

Slide 41EHR SD RM - EHR Way Forward … Future State Reference Architecture

EXAMPLE ARTIFACT EHR-S FM Dependencies

class DC.1.8.2 (Manage Immunization Administration)

See Also

DC.1.3.2 (Manage Patient Advance Directives)

DC.1.4.4 (Manage Immunization List)

S.1.1 (Registry Notification)

S.2.2.2 (Standard Report Generation)

S.3.7.1 (Clinical Decision Support System Guidelines Updates)

IN.1.6 (Secure Data Exchange)

IN.1.7 (Secure Data Routing)

IN.2.4 (Extraction of Health Record Information)

IN.2.5.1 (Manage Unstructured Health Record Information)

IN.2.5.2 (Manage Structured Health Record Information)

IN.4.1 (Standard Terminologies and Terminology Models)

IN.3 Registry and Directory Services

IN.4.2 (Maintenance and Versioning of Standard Terminologies)

IN.4.3 (Terminology Mapping)

IN.5.1 (Interchange Standards)

IN.5.2 (Interchange Standards Versioning and Maintenance )

IN.6 Business Rules Management

Page 42: HL7 “EHR SD RM” Project  “EHR System Design Reference Model”

Slide 42EHR SD RM - EHR Way Forward … Future State Reference Architecture

EXAMPLE ARTIFACTHITSP Interoperability Design Specifications

uc CAP131 Update Immunization Registry

CAP131 Update Immunization RegistryContent Consumer

Content Creator

Message Receiver

Message Sender

Request Patient Identification

Request HL7 Message

Respond to HL7 Message

HITSP/C72 Immunization Message Component

HITSP/T24 Pseudonymize

HITSP/SC110 - Request Patient Identifier

HITSP/SC115 – HL7 Messaging

Page 43: HL7 “EHR SD RM” Project  “EHR System Design Reference Model”

Slide 43EHR SD RM - EHR Way Forward … Future State Reference Architecture

class IS10 IRM

HITSP/IS10 Immunization and Response Management

Standards

Core HITSP Constructs

Privacy and Security

HITSP/TP20 - Access Control

HITSP/TP13 Manage Sharing of Documents

HITSP/TP21 Query for Existing Data

HITSP/TP22 Patient ID Cross-Referencing

HITSP/TP30 - Manage Consent Directives

HITSP/T15 - Collect and Communicate Security

Audit Trail

HITSP/T16 - Consistent Time

HITSP/T17 - Secured Communication Channel

HITSP/T23 Patient Demographics Query

Transaction

HITSP/T24 Pseudonymize

HITSP/T29 Notification of Document Availability

HITSP/T31 Document Reliable Interchange

Transaction

HITSP/T33 Transfer Documents on Media

HITSP/T63 Emergency Message Distribution

Element

HITSP/T64 Identify Communications

Recipients

HITSP/T66 Retrieve Value Set Transaction

HITSP/C19 - Entity Identity Assertion

HITSP/C26 - Nonrepudiation of Origin

HITSP/C62 Unstructured Document

HITSP/C70 Immunization Query and Response

HITSP/C72 Immunization Message Component

HL7 CDA Template

Vocabulary

HL7 CCD

HL7 v2.5 or v2.51 Vocabulary

ICD-9

RxNorm

SNOMED CT HL7 CDAHL7 v2.3.1

NCPDP Script 10.xHL7 v2.5.1

IS10 IRM HITSP

Constructs Mapped to Standards

Page 44: HL7 “EHR SD RM” Project  “EHR System Design Reference Model”

Slide 44EHR SD RM - EHR Way Forward … Future State Reference Architecture

Contact Information

Nancy Orvis

Chief Integration Architect

Office of the Chief Information Officer

DoD Military Health System

Email: [email protected]

Steve Hufnagel

Enterprise Architect, TIAG contract support

Office of the Chief Information Officer

DoD Military Health System

Email: [email protected]