Please Send Suggestions for Improvement to [email protected], GovProjects;

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

Please Send Suggestions for Improvement [email protected], GovProjects;

[email protected], EHR, SOA, ArB

EHR SD RM SAIF Alpha Project

“EHR System-Design Reference-Model”

Constructing a Future StateEHR Reference Architecture

EHR Way Ahead Business Architecture

From HL7, HITSP and ARRA Artifacts

For presentation at HL7 Sydney Workgroup Meeting, 11 Jan 2011

Practical Guide: http://hssp.wikispaces.com/PracticalGuide EHR SD RM info: http://hssp.wikispaces.com/Reference+Architecture

http://hssp.wikispaces.com/PracticalGuide



Objective of this Presentation is toDiscuss the Following Next Step Questions …

How should the EHR-SD RM be represented?– Hypothesis: XML DB, DITTA documentation

Use cases for EHR-SD RM use?– Ad Hoc Reporting needs– Web based tools needs– Profile needs (e.g., domain adaption vs. local use adaption)

How to ballot the EHR-SD RM?– Part of EHR-S FM R2.1– Independent of EHR-S FM

Who will Participate?– Information Model sub-project– XML/XSL Technical expert– Subject Matter Experts (e.g., diabetes, Immunization, etc.)


EHR SD RM Milestones

2008 2009 2010

Healthcare SOA Reference

Architecture

(H-SOA-RA)

EHR SD RM Immunization &

Response Management

(IRM) Prototype

May

HSSP Practical Guide for SOA in

Healthcare Volume II: Immunization

Case StudyDSTU is Draft Standard for Trial Use (ANSI standards development)

EHR-S CI-IM is EHR System Computationally Independent Information Model

HF&EA is Harmonization Framework and Exchange Architecture

2011

May

EHR-S FM R2.0

With

EHR SD RM Informative Reference

Sep

EHR SD RM Integrated into

EHR-S FM

R2.1


2008 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




EntityServices

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

4


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


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

6

Capabilities, which orchestrate Core Business Services

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.

7

EHR System Design Reference Model (EHR SD RM) Supporting Requirements/ Architecture Development Cycle

EHR System Design Reference Model

EHR System Design Reference Model

RequirementsAnalysis

RequirementsAnalysis

Stakeholder Requirements

Definition


DefinitionRequirements Loop

Verification & ValidationLoop

SpecificationsLoop

PROCESS INPUTS-Required Capabilities-Environments-Constraints

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

Capabilities, Functions,Information and

Information Exchanges

Conformance CriteriaInterface

Specifications

TestLoop

Functions – Dependencies

Test Specifications

Test Specifications

Conformance is a recognition of formal

testing, that prove that a system provides 100% support for a

given standard.

Architectural Specifications

Architectural Specifications

8

EHR SD RM Supporting Requirements/ Architecture Development Cycle


– What is the system supposed to do?

Under what conditions will the products be used?

– Where will the products of the system be used?

– How often? How long?

– Who will use the products of the system?

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

– Analyze functions and Services

Decompose higher level functions to lower level functions

Allocate performance requirements to the functions

Architecture Design (Which hardware/ software elements)

– Define the physical architecture Each part must perform at least one function

Some parts may perform more than one function

Test Specifications

– How Requirements-Specifications are validated

Requirements Loop Ensure all requirements are covered by at least one

function Ensure all functions are justified by a valid requirement

(no unnecessary duplication)

Design Loop Ensure all functions are covered by at least one

hardware or software element Ensure all elements of physical architecture are

justified by a valid functional requirement (no unnecessary duplication)

Verification & Validation (V&V) Loop

Each requirement must be verifiable that the solution meets requirements and validated that it meets the user’s needs and expectations.

V&V can be accomplished by: Inspection, Analysis, Demonstration, Test

Test Loop Ensure all information is covered by test specifications Ensure all interfaces are covered by test specifications

9


2010 SAIF Alpha ProjectThe Practical Guide For SOA in Healthcare Volume II

Immunization Management Case Study

The Practical Guide for SOA in Healthcare Volume II presents a case study, which adds an Immunization Management Capability (IMC) to Volume I’s SampleHealth’s Service Oriented Architecture (SOA). We used the TOGAF Architecture Development Method (ADM) and HL7 Service Aware Interoperability Framework (SAIF) Enterprise Conformance and Compliance Framework (ECCF). Volume II demonstrates the use of HL7’s EHR System Design Reference Model (EHR-SD RM) linked artifacts (e.g., EHR System Functional Model, FHIM, HITSP, HITEC, HSSP, IHE, NIEM, etc) to provide an initial architectural baseline suitable for an EHR related SOA acquisition, development or certification project. We conclude with lessons learned.

Healthcare Services Specification Project (HSSP) Practical Guide: http://hssp.wikispaces.com/PracticalGuide


11

SAIF ECCF examples

Slide 12

EHR-S FM

BehavioralViewpoints

Conceptual Independent ModelPlatform Independent Model

Platform Specific Model

Information ViewpointsConceptual Independent Model

Platform Independent ModelPlatform Specific Model

Engineering/Technical Viewpoints

Conceptual Independent ModelPlatform Independent Model

Platform Specific Model

Example of SAIF Traceability Using HL7 EHR-S FM

FMIDs

FMIDsFMIDs

FMIDs

Business ViewpointsConceptual Independent Model

Platform Independent ModelPlatform Specific Model

Key to Traceability Traceability is achieved by using Functional Model Identifiers (FMIDs) as attributes to all SAIF artifacts.

This is analogous to a library system, which uses Dewey decimal numbers as book identifiers.

Investment Portfolio Line Items

Planning budget for new, improved or sunset capabilities

FMIDs

FMIDs Product Line Inventory

Inventory of systems and their capabilities and Functions


Immunization Management ECCF Specification Stack

SubjectSpecification

EnterpriseViewpoint

“Why”Policy

InformationViewpoint

“What”Content

ComputationalViewpoint

“How”Behavior

EngineeringViewpoint

“Where”Implementation

CIM(Conceptual)

Inventory ofo Use Caseso Capabilities-Services o Requirementso Contracts o Stakeholders

Business Scope Business Vision Business Objectives Policy & Regulations

Inventory of o Domain Entitieso Roles, o Activities, o Associations.

Information Modelso Conceptualo Domain

Inventories ofo Capabilities-Components,o Functions-Services.

Requirementso Accountability, Roleso Behaviors, Interactionso Functional Profiles, o Interfaces, Contracts

Conceptual Functional Service Specifications

Inventory of Platforms/ Environments.

PIM(Logical)

Applicable Rules Use Case Specs Governance. Technology Neutral

Standards Wireframes of

o architectural layers o Components ando Associations

Information Modelso Localizedo Constrainedo Project

Message Content Specifications

Use Case Specs Component. specs Interface Specs Interaction Specs Collaboration Participations Collaboration Types Function Types Interface Types Collaboration Scripts Service Contracts

Existing Platform models, Capabilities, Libraries and Versions.

PSM(Implementable)

Business Nodes Business Rules Business Procedures Business Workflow Technology Specific

Standards

Database Schemas Message Schemas Transformation

Schemas (e.g., XSD)

Automation Unit Technical Interfaces Technical Operations Orchestration Scripts

Application Specs. GUI Specifications Component Designs Deployment Topology Platform Bindings

13


Initiation

AnalysisPeer

Review“Ballot”

Design

EHR-S FM & EHR-S CI-IMEHR System

Function Model & EHR System

Computationally-Independent Information-

Model

DAM Domain Analysis Models CDA Clinical Document Architecture

CMET Common Model Element TypesD-MIM Domain Message Information ModelInteroperability Specifications for

• Messages and/or• Documents and/or• Services

HL7 Development Framework (HDF)

Implement& Test

Specifications for• Business Objects• Components• Capabilities• Applications• Systems

V&VCheckpoin

t

V&VCheckpoint

V&V CheckpointV&V is Verification and Validation

SAIF ECCF -Services Aware Interoperability Architecture - Enterprise Compliance and Conformance Framework

V&VCheckpoint

DSTU - Draft Standard for Trial Use “Prototype”

Draft Working Document; Not for Public Distribution

15


SAIF ECCFViewpoints CIMPSM

PIM

ECCF

CIM is Computationally Independent ModelPIM is Platform Independent Model

PSM is Platform Specific Model


16

InteroperabilitySpecification


EHR-S CI-IM (Started Jun 2010)

EHR System Computationally-Independent Information-Model

This project will produce a set of Constrained Information Models called EHR-S “data profiles”. Each EHR-S data profile corresponds directly with an EHR-S function profile and each EHR-S data profile will include one-or-more Reference Information Model classes. Pairs of EHR-S function profiles and data profiles can be used to define business objects, which can be composed into software components, capabilities, applications, systems and their message exchanges and/or document exchanges and/or services. The superset of EHR-S data profiles is called the EHR-S Computationally-Independent Information-Model, which supports the HL7 Development Process and Service Aware Interoperability Framework. The project will include the development and execution of a communication strategy to ensure that all affected stakeholders are engaged.

http://hssp.wikispaces.com/EHR-S+CI-IM

http://hssp.wikispaces.com/EHR-S+CI-IM


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.


Federal Health Information Model (FHIM) Person Model (Harmonized with RIM, HIPAA & HITSP)

Slide 20

EHR-S FM

DC x.y.z EHR-S Function Profile

…

SC x.y.z EHR-S Function Profile

…

IN x.y.z EHR-S Function Profile

…

Entity a.b.c

EHR-S Data Modules

…

1:1

Relationship between

Function Profiles

and

Data Profiles

For each EHR-S

Function, its Data

Profile = Set of RIM

Classes and their EHR-S

Data Modules

EHR-S CI-IM

Role a.b.c

EHR-S Data Modules

…

Act a.b.c

EHR-S Data Modules

…

Act Relationship a.b.c

EHR-S Data Modules

…

Role Link a.b.c

EHR-S Data Modules

…

Participation a.b.c

EHR-S Data Modules

…

Entity d.e.f

…

RIM Classes

Role d.e.f

…

Act d.e.f

…

Act Relationship d.e.f

…

Role Link d.e.f

…

Participation d.e.f

…

1:N

Relationship among

Data Profiles

and

RIM Classes

DC is Direct CareSC is Supportive CareIN is Infrastructure

HL7 EHR System Computationally-

Independent Information-Model

(EHR-S CI-IM) Project



EHR SD RM Status (Oct 2010)

Supporting EHR System Functional Model R2

– EHR SD RM foundation (linked XML version) Spring 2011 ballot

– HITSP (2010 completion)

– ARRA Meaningful Use Objectives/ Criteria (Jun 2010 Final Rule)

Sub Projects

– EHR Computationally Independent Information Model

– Harmonization Framework and Exchange ArchitectureSAIF Executive Summary and

Implementation Guide



Prototype Demonstration of Browser-Version XML with XSL & XSLT HTML Style Sheet

EHR-S FM R1.1 linked to

– US Meaningful Use Objectives and Criteria

– US Mandated Standards

– Information Model (TBD)


EHR SD RM Issue/Questions 2011 Planned Representation (Better Options?)

– Linked XML (most flexible for documentation, current preference)– EHR–S FM (R2) and it’s profiles (2011)

• ISSUE: Managing Profiles• ISSUE: Tracking Changes / Comments• ISSUE: Managing HL7 Domain Analysis Models (DAMS)? and • ISSUE: Managing Detailed Clinical Models (DCMs)?• ISSUE: DITTA Publishing? (Resources needed)• ISSUE: Data Base / Web version? (Resources Needed)

– EHR CI-IM - Computationally Independent Information Model • ISSUE: RIM/RIMBA expertise needed

– US HITSP (2010) Health & Human Services Selected Standards– US ARRA MU Meaningful Use Objectives & Criteria (2010)


Call for Participation

XSL style sheet expert for

– EHR-S FM R2

– EHR-S FM R2 with EHR SD RM additions

– Profiles

– Comment/Change tracking

EHR Computationally Independent Information Model

– Decomposed by EHR-S FM

– Traceable to RIM

Contact Information

Nancy Orvis

Chief Integration Architect


DoD Military Health System

Email: [email protected]

HOW TO PARTICIPATE:Coordinate with [email protected], 703-575-7912-cell.

We have a weekly telecom each Friday 1230-1330 EasternPHONE: +1 770-657-9270, CODE: 071582#WEB LINK: http://my.dimdim.com/hsspPROJECT WIKI: http://hssp.wikispaces.com/Reference+Architecture

Steve Hufnagel

Enterprise Architect, TIAG contract support


DoD Military Health System

Email: [email protected]

25Backup Slides Available at Web Site


Immunization Management Case StudyQuestions?

[email protected]

[email protected]

[email protected]

[email protected]

HOW TO PARTICIPATE:Coordinate with [email protected], 703-681-3929 or 703-575-7912-cell.

We have a weekly telecom each Friday 1230-1330 EasternPHONE: +1 770-657-9270, CODE: 071582#WEB LINK: http://my.dimdim.com/hsspPROJECT WIKI: http://hssp.wikispaces.com/Reference+Architecture