Slide 0 EHR SD RM - EHR Way Forward … Future State Reference Architecture HL7 EHR SD RM Project EHR System Design Reference Model Constructing a Future

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

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

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

From HL7 and HITSP ArtifactsFor presentation at HL7 Phoenix Workgroup Meeting, January 2010

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

[email protected], Chief of Integration & [email protected], Architect & System Engineer

Alean Kirnak, President, Software Partners


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.


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

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

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

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

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

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

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


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


CONTENTS2. Constructing a Future State EHR Reference Architecture

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

4. Healthcare SOA Reference Framework

5. HL7 RIM (Reference Information Model)

6. HITSP Harmonization Framework

7. HITSP Constructs

8. HITSP Data Architecture

9. HITSP Clinical Document Components

10. HITSP/C83 Data Module Categories

11. EHR Way Forward Business Architecture Specification Framework

12. Future State EHR Reference Architecture Adding ARRA and FHIM

13. Basic UML Legend

14. Abbreviations

15. PART II: HL7 SAEAF, Requirements Management Process and Governance

16. PROTOTYPE: Immunization and Adverse Event Reporting


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


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


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

8


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.


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

constrains and orchestrates underlying constructs.

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

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

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

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

HITSP Transaction Packages/ Transactions/ Components (TP/T/Cs) are where standards-based Interface Design Specifications are specified are given and conformance requirements are defined.


HITSP Harmonization Framework

AddressingBusiness

Needs

ProvidingInfrastructure,

Security,Privacy

Data Architecture

Available for Independent Implementation

DefiningInformation

Content

IS = Interoperability Specification


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


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.


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


class EHR Business Architecture Specification

HITSP Constructs

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

HITSP Capability Requirements



+ Systems+ Exchange Content+ Exchange Action+ Exchange Attribute

Service

HITSP Capability Design


Interface

SOA Layers

+ Business Processes+ Composite Services+ Core Business Services+ Component Services+ Operational Services+ Implementation Profiles

requirementsdesign

Legend

EHR Business Architecture

Selected Standard

HL7 Reference Information Model (RIM)

+ Role+ Entity+ Act+ Participation+ Act relationship+ Role relationship

HL7 EHR SD RM

+ EHR-S FM+ FHIMS+ HITSP Capability Design+ SOA Layer

NHIN Connect Service

Behavioral Model

Functional Requirements

EHR-S FM

+ Direct Care+ Supportive Care+ Information Infrastructure

Use Case

realize

EHR Future State Reference

Architecture …

EHR Way ForwardBusiness

ArchitectureSpecificationFramework

Slide 15

Functional Analysis Object Analysis

Requirements Analysis

Interface Design Analysis

Service Analysis


class EHR Business Architecture Specification with ARRA & FHIMS

HITSP Constructs

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

HITSP Capability Requirements



+ Exchange Action+ Exchange Attribute+ Exchange Content+ Systems

Service

HITSP Capability Design


Interface

SOA Layers

+ Business Processes+ Composite Services+ Core Business Services+ Component Services+ Operational Services+ Implementation Profiles

requirementsdesign

Legend

EHR Business Architecture

Selected Standard

Certification Criteria

+ Capability

Federal Health Informations Model & Standards (FHIMS)

Federal Health Data Model

HL7 Reference Information Model (RIM)

+ Act+ Act relationship+ Entity+ Participation+ Role+ Role relationship

Clinical Document Architecture (CDA)

ARRA Meaningful Use Measures

+ Stakeholder

Agency Information Model

Agency Data Model

HL7 EHR SD RM

+ EHR-S FM+ FHIMS+ HITSP Capability Design+ SOA Layer

NHIN Connect Service

ARRA is American Recovery and Reinvestment Act of 2009FHIMS is Federal Health Information Model and StandardsEHR-S FM is EHR System Functional-ModelEHR SD RM is EHR System Design Reference-Model

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

A HITSP Capability (CAP) specifies interfaces for a set of information exchanges, grouped by system role (e.g., lab order prescriber, lab order filler).A HITSP conformant system implements the specified interfaces for the information exchanges which are required to support the selected system roles of each HITSP capability implemented within the system.

Functions vs. Services differ in that a services enforces encapsulation (e.g., information hiding), have associated governance and Distributed User Resource Sharing Agreements (DURSAs), which defines the business rules for a services' information exchanges.

A Health IT Business Architecture (BA) can be modeled as clinical stakeholders and their workflow-orchestration of system-functions, defined by the HL7 System Functional Model. HITSP Capabilities group and specify system roles, information exchanges and system interfaces to support one-or-more system functions with standards-based data models and standards-based interface specifications, which may be implemented as services. An Information Model, for a project or enterprise, can be created from a semantic network of a BA's Capability data models, categorized using the six HL7 RIM foundation classes.

EHR-S FM

+ Direct Care+ Information Infrastructure+ Supportive Care

Behavioral Model

Functional Requirements

Use Case

realize

realize

EHR Future State Reference Architecture Adding ARRA and FHIMS

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

Slide 16


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


PART II: HL7 SAEAF, Requirements Management and Governance

• The HL7 Services-Aware Enterprise Architecture Framework (SAEAF)

• HL7 SAEAF ECCF Specification Stack

• HITSP Within HL7 SAEAF ECCF Specification Stack

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

• Business Capability Lifecycle (BCL)

• Develop/ Update Reference Architecture

• Requirements Management Process

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


The HL7 Services-Aware Enterprise Architecture Framework (SAEAF)

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

– Interoperability Scenarios supporting the RM-ODP Computational Viewpoint

Governance Framework (GF)– Governance is the overarching policy structure and set of related processes by which a group

exercises its authority and demonstrates accountability for accepted responsibilities within a particular jurisdiction.

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

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


HL7 SAEAF Conformance and Compliance Framework (ECCF) Specification Stack Views

Consistency

Tra

ceab

le

ImplementationBehaviorContentPolicy


HITSP WithinHL7 SAEAF ECCF Specification Stack

Topic

Specification

Enterprise / Business View

“WHY”

Information View

“WHAT”

Computational View

“HOW”

Engineering View

“WHERE”

Conceptual

Business Context, Reference Context

Domain Analysis (Information) Model

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

Relationships

Existing Platform capabilities

Platform-

Independent

Business Governance Project-oriented Domain Information Model,

Constrained Information Model, Localized Information Model, Hierarchical Message

Definition

Collaboration Types, Interface Specification and Functional

Groups, Interaction Types and Collaboration Participations,

Contracts Parts

Existing Platform models, libraries, etc.

Platform-

Specific

Rules, Procedures Localized Information Model, Transforms, Schema

Collaboration scripts, Orchestrations, Realized

Interfaces

Execution Context, Platform Bindings, Deployment Model

Consistency

Tra

ceab

le

HITSP DAHITSP CAP

Harmonization Requests/ Use Case

HITSP CAP

HITSP T, TP and SCs

HITSP C

HITSP IS

ImplementationBehavior

HITSP Harmonization

Framework

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

21

ContentPolicy


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

Topic

Specification

Enterprise / Business View

“WHY”

Information View

“WHAT”

Computational View

“HOW”

Engineering View

“WHERE”

Conceptual

Business Context, Reference Context

Domain Analysis (Information) Model

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

Relationships

Existing Platform capabilities

Platform-

Independent

Business Governance Project-oriented Domain Information Model,

Constrained Information Model, Localized Information Model, Hierarchical Message

Definition

Collaboration Types, Interface Specification and Functional

Groups, Interaction Types and Collaboration Participations,

Contracts Parts

Existing Platform models, libraries, etc.

Platform-

Specific

Rules, Procedures Localized Information Model, Transforms, Schema

Collaboration scripts, Orchestrations, Realized

Interfaces

Execution Context, Platform Bindings, Deployment Model

Consistency

Tra

ceab

le

HL7 RIMFHA FHIMSHITSP DAHITSP CAP

Harmonization Requests/ Use Case

HITSP CAP

HITSP T, TP and SCs

HITSP C

HL7 EHR-S FM

HITSP IS

HL7 EHR SD RMHITSP

Harmonization Framework

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

NHIN ConnectServices

Tomcat, JBoss, J2SE, Eclipse,

GlassFish ESB, OpenSSO

22

ImplementationBehaviorContentPolicy


HITSP and Immunization Use Case# Capability Patient Identification Data Retrieval and Update Decision Support

1 Standards Org HL7

2 Service SpecificationIdentification Service

Functional Model Retrieve, Locate, Update SFM Decision Support SFM

3 Standards Org OMG


Specification Retrieve, Locate, Update Spec Decision Support Service Spec5 Profile Org IHE6 SOA Profile SOA White Paper7 Profile Org IHE

8 Immunization Profile

PIX/PDQ

SC110PIX/PDQ

SC110

Query for Existing

Data (QED)

CAP123 SC113

Immunization Content (IC)

CAP119 CAP133 SC112

Request for Clinical

Guidance

CAP133 (IC payload)

9 Profile Org American Immunization Registry Association/CDC

10 Immunization ProfileDraft: 2.5 Impl Guide

Draft: 2.5 Impl Guide


2.3.1 Impl Guide

CAP131 CAP132 SC115

2.3.1 Impl Guide

CAP131 CAP132 SCII5

12 Standards Org HL7

13 Original Standard V2

V3 Patient Admin

messaging V2

V3 Care Record

messaging

V3 (POIZ) Immunization

messagingV3 Care

Record CDA

V3 Care Record

messagingV3 POIZ

messaging


Immunization Use Case - Simplified# Capability Patient Identification Data Retrieval and Update Decision Support

1 Standards Org HL7


Functional Model Retrieve, Locate, Update SFMDecision Support

SFM

3 Standards Org OMG


Specification Retrieve, Locate, Update SpecDecision Support

Service Spec

5 Profile Org IHE

6 SOA Profile SOA White Paper

7 Profile Org IHE/American Immunization Registry Association/CDC


PIX/PDQ

SC110PIX/PDQ

SC110

Future Draft: 2.5 Impl Guide

Query for Existing

Data (QED)

CAP123 SC113


CAP119 CAP133 SC112

Request for Clinical Guidance

CAP133 (IC payload)


13 Original Standard V2

V3 Patient Admin

messaging V2

V3 Care Record

messagingV3 Care

Record CDAV3 Care Record

messaging


Immunization Use Case WithinHL7 SAEAF ECCF Specification Stack

# Patient Identification Data Retrieval and Update Decision Support

1 Enterprise View (Service Functional Models)

2Identification Service

Functional Model Retrieve, Locate, Update SFM Decision Support SFM

3 Computational View (Service Definitions)

4Identification Service

Specification Retrieve, Locate, Update SpecDecision Support

Service Spec

5 Information View (Payloads)

6

PIX/PDQ

SC110PIX/PDQ

SC110

Future Draft: 2.5 Impl

Guide

Query for Existing

Data (QED)

CAP123 SC113


CAP119 CAP133 SC112

Request for Clinical Guidance

CAP133 (IC payload)

7 Implementation View (Vendor Implementations)8 Base Standard

9 V2V3 Patient Admin msg V2

V3 Care Record msg

V3 Care Record CDA V3 Care Record mesg


Service DefinitionRef: A Service-Oriented Architecture (SOA) View of IHE Profiles IHE 2009

Slide 27EHR SD RM - EHR Way Forward … Future State Reference ArchitectureCopyright 2009 Software Partners LLC

27

Meet in the Middle**Anna Orlova, Josh Painter, Alean Kirnak, “A SOA View of IHE Profiles” working drafts


Cost Effectiveness Proposition

Target cost function of healthcare IT connectivity

# of service consumers * # of services


Cost Effectiveness Proposition

Target cost function of healthcare IT connectivity

# of service consumers * # of services


Approximately 75 U.S. Immunization Information Systems (IISs)

Completely connected point-to-point IIS network: 74 * 75 / 2 = 2775 connections

Assume 200 regional provider EHRs per IIS:200 * 75 = 15,000 connections

Each connection costs $10K-$30K per side $40K each * 17,775 =$711,000,000

Point to Point Messaging Economics

30

Copyright 2009 Software Partners


Labs Meds Allergies Cancer Registries Joint Replacement Registries Chronic Disease Registries Adverse Event Reporting …etc. Intra-enterprise communication Provider-to-Provider communication ... 100 domains increases cost to $71,100,000,000

Expand to Multiple Domains

31



Schools Drug stores Airports …

Growth of Points of Care

32



Tethered Untethered Wireless devices …

Growth of Personal Health Records

33



Bus architecture Plug-and-play connections Common information model

How to Solve?

34



Bus architecture– Build common carrier once– hide routing, translation

Plug and play connections– Eliminates cost on one side of each connection

Common information model– Allows multiple platform-specific models for a single

platform-independent model

Cost Reduction Opportunities

35



75 IISs each accessing one service 15,000 EHRs, 500 products @ 30 installations

ea = 500 connections Cost @$20K is per service consumer only

$20K * (500 + 75) =$11,500,000 + cost of carrier

Drive down the $20K

Cost Reduction Opportunities

36



Meaningful Use Rules and Regs# Capability Patient Identification Data Retrieval and Update Decision Support1 Standards Org HL7


Functional Model Retrieve, Locate, Update SFM Decision Support SFM3 Standards Org OMG


Specification Retrieve, Locate, Update SpecDecision Support Service

Spec5 Profile Org IHE6 SOA Profile SOA White Paper7 Profile Org IHE


PIX/PDQ

SC110PIX/PDQ

SC110

Query for Existing

Data (QED)

CAP123 SC113


CAP119 CAP133 SC112

Request for Clinical

Guidance CAP133 (IC

payload) 9 Profile Org American Immunization Registry Association/CDC

10 Immunization ProfileDraft: 2.5 Impl Guide

Draft: 2.5 Impl Guide


2.3.1 Impl Guide

CAP131 CAP132 SC115

2.3.1 Impl Guide

CAP131 CAP132 SCII5


13 Original Standard V2V3 Patient Admin msg V2

V3 Care Record msg

V3 (POIZ) Immunization

msgV3 Care

Record CDA

V3 Care Record

messagingV3 POIZ

messaging


Proposed Meaningful Use Comments

Propose use of service interfaces to satisfy need for transport layer standards for immunizations

Fill gaps in immunization standards– Include immunizations in medical summary

– Use CAP133 Immunization Content in Table 2A

– Include immunizations in decision support clausesNote the immunization use case includes patient identification


Proposed 2.5.1 Immunization Guide Changes

Clarify use of HITSP and IHE constructs Consider a service definition that combines PIX/PDQ

and IZ data retrieval and update into a composed service


Topics for Discussion


BPMN Business Capability Lifecycle (BCL)

IV&V TeamIM

TeamPortfolio Team

Architecture Team

Develop/ Update Business Architecture

(BA)

Develop/ Update Business Architecture

(BA)

Develop/ Update Enterprise Information

Model (EIM)

Develop/ Update Enterprise Information

Model (EIM)

Develop/ Update Reference Architecture

(RA)

Develop/ Update Reference Architecture

(RA)

Integrate Business Architecture (BAI)

Integrate Business Architecture (BAI)

Develop/ Update Strategic Plan (SP)Develop/ Update

Strategic Plan (SP)

Perform Verification and Validation

Perform Verification and Validation

Perform Quality Assurance

Perform Quality Assurance

Perform Risk AssessmentsPerform Risk Assessments

Perform TestingPerform Testing

HL7 EHR-S FM & RIM, HITSP, LSS-TIQM,

KA and KE

HL7 EHR-S FM & RIM, HITSP, LSS-TIQM,

KA and KE

Perform Governance/ Configuration Management

Perform Governance/ Configuration Management

Manage PerformanceManage PerformanceBusiness Case AnalysisBusiness Case Analysis

LSS-TIQM is Lean Six Sigma Total Information Quality MethodologyKA is Knowledge AcquisitionKE is Knowledge Engineering

Update Investment Portfolio

Update Investment Portfolio

Price Investment Portfolio

Price Investment Portfolio

Prioritize Investment Portfolio

Prioritize Investment Portfolio

Monitor InvestmentsMonitor Investments

EHR-S FM is HL7 EHR System Functional ModelHL7 RIM is HL7 Reference Information ModelHITSP is Health Information Technology Standards Panel

Business Capability Lifecycle (BCL)

RED indicates where HL7 and HITSP artifacts

can be used

KEY PROCESS


BPMN Develop/ Update Reference Architecture

Reference A

rchitecture (RA

) Team

Analyze BusinessAnalyze Business Analyze Enablers and Architecture

Standards

Analyze Enablers and Architecture

Standards

CategorizeCategorize Define Strategic Drivers and

Prioritize Segments

Define Strategic Drivers and

Prioritize Segments

ImproveImprove Map Enablers to Business Support

Services

Map Enablers to Business Support

Services

CATEGORIZE: Analyze standard segments, eliminate segment ambiguity, map investments to standard segments

ANALYZE BUSINESS (determine parameters): cross organization review, benchmark across organizations and with industry. Compare Segment spend and architecture best practices with industry best practices.

ANALYZE ENABLERS AND ARCHITECTURE STANDARDS : Capture the enablers that cross-cut all missions. Ensure that standards are used throughout to reduce silos.

IMPROVE: Service consolidation, Resource consolidation, federate (shared) services, elininate redundant spending. Emphasize information sharing and semantic interoperability.

MAP ENABLERS TO BUSINESS SUPPORT SERVICES : Identify foundational support services that cross cut organizations. This analysis provides a bottom up view of opportunities for internal and external federated reuse, resource and information sharing and information service management.

Enterprise Information Model

Future State Reference Architecture

Transition Plan

Modernization Blueprint

Investment Portfolio

Project BPM

EHR-S FM

HL7 RIM

HITSP Constructs

Federal Segment Architecture Methodology (FSAM)

EHR-S FM is HL7 EHR System Functional ModelHL7 RIM is HL7 Reference Information ModelHITSP is Health Information Technology Standards Panel

BCL Develop/ Update Reference Architecture

RED indicates where HL7 and HITSP artifacts

can be used


BPMN Requirements Management Process

IM F

un

ction

alsIV

&V

RE

PO

SIT

OR

YG

OV

ER

NA

NC

E/C

MIn

tegratio

n P

rocess

Document Needs,Gaps and Technical

Opportunities

Document InitialRequirements-Design

Alternatives

Document SelectedRequirements-Design

Packages

Make ExecutionDecision

Make InvestmentDecision

Enterprise Architecture

Investment Portfolio

Change Requests

Requirements

Triage ProposedProjects

EA Views Approve Acquisition Packages

CONOPS B-CASEA

DBT Packages

Approval PackagesA

Change Request

SubmissionA

CONOPS B-CASE SPECS A

CDRLs

EA Derived Products

ROLE: Document to-be Enterprise Architecture (EA) content as incremental development packages for transition plan and investment portfolio.

Milestone Decision PackagesA

IV&VAlternativeSolutions

IV&V SpecifiedSolutions

IV&VAcquisitionPackages

IV&V CDRLS

IV&V ProposedProjects

Business Stakeholder ResponsibilityMHS Central ResponsibilityDocument Package

Legend

ROLE: Validation - "Are we meeting the users' needs?" and Verification " Are we building it according to specifications?

Define Needs, Gapsand TechnicalOpportunities

Create InitialRequirements-Design

Alternatives

Refine SelectedRequirements-Design

Packages

IV&V SelectedPackage

CDRLs

CDRL

EHR-S RM

HL7 RIM

HITSP Constructs

CCHIT Criteria

RefinementRefinement

Requirements Management Process

Slide 43


Prototype

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


Use Case 1: Immunization and Response Management (IRM) and Use Case 2: Public Health Case Reporting (PHCR)

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

– The Interoperability Specification also allows for basic electronic information exchanges to enable requirement communications and alerting mechanisms and to lay the foundation for future clinical support capabilities

– The Public Health Case Reporting AHIC Use Case and HITSP Interoperability Specification supports the bi-directional information exchanges of the Public Health Case Reporting process

– The Public Health Case Reporting Use Case addresses numerous domains which have similar content and processes at a high level, but which also are dissimilar in report content details and case management processes when considering any specific report

EHR-SD RM PrototypeRequirements from 2008 AHIC Use Cases

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

EXAMPLE ARTIFACT: Vaccine and Drug Administration and Reporting Information Exchanges


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


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


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

EHR-SD RM PrototypeData Requirements (DRs)

Use Case 1: Immunization and Response Management (IRM)



Blue Italics indicates common

across IRM and PHCR


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



Blue Italics indicates common across 1-IRM and

2-PHCR


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




across IRM and PHCR


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



across IRM and PHCR


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


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.


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


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


Sample HITSP C83 Data ModulesImmunizations Data Mapping Table – Requirements

CDA Data LocationHITSP Data Element Identifier

and NameO/R[1] Additional

Specification

cda:substanceAdministration[cda:templateId/@root ='2.16.840.1.113883.10.20.1.24']

Immunization Event Entry See Below[2]

@negationInd 13.01 - Refusal R/N

cda:effectiveTime 13.02 - Administered Date O/N

cda:entryRelationship[@typeCode='SUBJ']/cda:observation/cda:value

13.03 - Medication Series Number

O/N

cda:entryRelationship[@typeCode='CAUS']/cda:observation[cda:templateId/@root=

’2.16.840.1.113883.10.20.1.54’]

13.04 - Reaction O/Y

cda:performer/cda:assignedEntity 13.05 - Performer O/N

cda:consumable/cda:manufacturedProduct Medication Information R/Y

cda:manufacturedMaterial/cda:code/@code

13.06 - Coded Product Name R2/Y 2.2.2.13.1

cda:originalText 13.07 - Free Text Product Name R/N

cda:manufacturerOrganization 13.08 - Drug Manufacturer O/N

cda:manufacturedMaterial/cda:lotNumberText

13.09 - Lot Number R2/N

cda:entryRelationship[@typeCode=’RSON’]/cda:act[cda:templateId/@root=’2.16.840.1.113883.10.20.1.27’]

13.10 - Refusal Reason R2/N 2.2.2.13.2


Sample of Standards used within HITSP Components within IS10

1. Standard: HITSP Construct2. Accredited Standards Committee (ASC) X12 Standards Release 004010 HITSP/C80 - Clinical Document and Message Terminology3. American Medical Association (AMA) Current Procedural Terminology (CPT®) Fourth Edition (CPT-4); CPT Evaluation and Management Codes HITSP/C80 - Clinical Document and Message

Terminology4. ASTM International Standard Guide for Electronic Authentication of Health Care Information: # E1762-95 (2003) HITSP/C26 - Nonrepudiation of Origin5. CDC Race and Ethnicity Code Sets HITSP/C80 - Clinical Document and Message Terminology6. Center for Disease Control and Prevention Implementation Guide for Immunizations Data Transaction using Version 2.3.1 of the Health Level Seven (HL7) Standard Protocol. Implementation

Guide Version 2.2 June 2006 HITSP/C70 - Immunization Query and Response, HITSP/C72 - Immunization Message, HITSP/C80 - Clinical Document and Message Terminology7. Digital Imaging and Communications in Medicine (DICOM) Part 3.12: Media Formats and Physical Media for Media Interchange HITSP/T33 - Transfer of Documents on Media8. European Telecommunications Standards Institute (ETSI) Technical Specification TS 101 903: XML Advanced Electronic Signatures (XadES) HITSP/C26 - Nonrepudiation of Origin9. Federal Information Processing Standards (FIPS) Codes for the Identification of the States, the District of Columbia and the Outlying Areas of the United States, and Associated Areas

Publication # 5-2, May, 1987 HITSP/C80 - Clinical Document and Message Terminology

10. Food and Drug Administration (FDA) - Unique Ingredient Identifier (UNII) HITSP/C80 - Clinical Document and Message Terminology11. Food and Drug Administration (FDA) - National Drug Code (NDC) HITSP/C80 - Clinical Document and Message Terminology12. Health Care Provider Taxonomy HITSP/C80 - Clinical Document and Message Terminology13. Health Level Seven (HL7) Clinical Document Architecture (CDA) Release 2.0 HITSP/C78 - Immunization Document, HITSPC83 - CDA Content

Modules14. Health Level Seven (HL7) Common Terminology Services (CTS) Release 1 HITSP/T66 - Retrieve Value Set15. Health Level Seven (HL7) Implementation Guide for CDA Release 2: History and Physical (H&P) Notes HITSP/C83 - CDA Content Modules16. Health Level Seven (HL7) Implementation Guide for CDA Release 2: Consultation Note HITSP/C83 - CDA Content Modules17. Health Level Seven (HL7) Implementation Guide: CDA Release 2 – Continuity of Care Document (CCD), April 01, 2007 HITSP/C83 - CDA Content Modules18. Health Level Seven (HL7) Standard Code Set CVX - Vaccines Administered HITSP/C80 - Clinical Document and Message Terminology19. Health Level Seven (HL7) Standard Code Set MVX - Manufacturers of Vaccines HITSP/C80 - Clinical Document and Message Terminology20. Health Level Seven (HL7) V3 RBAC, R1-2008, HL7 Version 3 Standard: Role Based Access Control (RBAC) Healthcare Permissions Catalog, Release 1, February 2008, HITSP/TP20 - Access

Control 21. Health Level Seven (HL7) Version 2.3.1 HITSP/C70 - Immunization Query and Response22. Health Level Seven (HL7) Version 2.3.1 Chapter 2 – Control, Chapter 3 – Patient Administration HITSP/TP22 - Patient ID Cross-Referencing23. Health Level Seven (HL7) Version 2.5, Chapter 2 – Control, Chapter 3 – Patient Administration, Chapter 5 – Query HITSP/TP22 - Patient ID Cross-Referencing24. Health Level Seven (HL7) Version 2.5, Chapter 2 – Control, Chapter 3 – Patient Administration, Chapter 5 - Query HITSP/T23 - Patient Demographics Query25. Health Level Seven (HL7) Version 2.5.1 HITSP/C80 - Clinical Document and Message Terminology26. Health Level Seven (HL7) Version 3.0 - Vocabularies and Value Sets HITSP/C80 - Clinical Document and Message Terminology27. Health Level Seven (HL7) Version 3.0 Context-Aware Information Retrieval Specification: URL Implementation Guide HITSP/T81 - Retrieval of Medical Knowledge


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


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