July 20, 2007 Healthcare Information Technology Standards Panel Principles for Proper Use of HITSP Interoperability Specifications And Proposal for Proper

July 20, 2007

Healthcare Information Technology Standards Panel

Principles for Proper Use of HITSP Interoperability SpecificationsAndProposal for Proper Use of IS-03 CE Registration and Medication History

2

Topics

Objective

HITSP Constructs

Well-defined ways to Use HITSP Construct

Proposal for use of HITSP IS-03 CE Registration and Medication History

3HITSP Construct Proper Use

Objective of this Proposed Definition of Principles for Proper Use of HITSP Constructs

To clarify principles for appropriate, consistent use of HITSP Interoperability Specifications and other HITSP construct specifications by intended users.

Intended users include, for example: – HITSP Committees (e.g., in new work efforts)– CCHIT– Health Information Exchanges– Healthcare stakeholders (e.g., during IT systems procurements)– Healthcare IT Vendors– Healthcare Information policy makers


Component (Composite)

Transaction (Composite)

Transaction Pkg.(Composite)

For Internal Reuse

HITSP FrameworkUse Case orModification Request

Interoperability Specification

Transaction Package (1..m transactions or composite standards)

Transaction (1..n components or composite standards)

Component (1..c base or composite standards)

Base Standard

#1

Base Standard

#4

Base Standard

#2

Base Standard

#3

Base Standard

#5

Base Standard

#...

Base Standard

#n

SDOs

For External Use

InteroperabilitySpecification

Component (Composite)

Transaction (Composite)

Transaction Pkg.(Composite)

For Internal Reuse


General Perspective on types of Proper Use

Use of a HITSP Interoperability Specification and Associated Constructs.– HITSP Technical Committees defines ways users can appropriately

use an IS and associated constructs

Longer term questions that will require definition of well-defined processes – Managing "internal consistency" across HITSP constructs below

construct level – e.g., consistent vocabulary value set, same micro data structure for describing an allergy, use of OIDs in certain fields

– External reuse/repurposing of a HITSP Construct that is not an Interoperability Specification


Different Types Of External Use of an I.S. and Associated Constructs

Actor Scoping

Subsetting

HITSP Optionality


Different Types Of External Use of an I.S. and Associated Constructs - Actor Scoping

For entire Interoperability Specification (IS), meet requirements for selected subset of Business and supporting Technical Actors.

Implement set of transactions and information components involving a specific sub-set of Actor(s) in IS. – E.g., for EHR-lab, implement information exchange for the

laboratory information system Business Actor


Different Types Of External Use of an I.S. and Associated Constructs - Subset

A subset is partial implementation of an Interoperability Specification– Must include at least two actors and a transaction.

– May involve all or some of the IS defined Actors.

– May be defined based on a subset of scenarios, information content, or semantic richness in the Interoperability Specification

Appropriate subsets are identified by HITSP Technical Committees to notify users what is allowed for a specific IS or construct. – Note: subsets will be documented in a later release for V2.0 of EHR-Lab,

Consumer Empowerment, and Biosurveillance Interoperability Specifications (IS-01, 02 and 03).


Different ways to subset

Scenario/workflow– Implement a subset of available scenarios for the I.S.

– e.g., EHR-Lab use case has two sub-workflows: lab results to ordering providers and sharing historical lab results

Information content– Implement a portion of the information content of an I.S.

– e.g., implement IS 03 Consumer Empowerment with only registration information and no medication information

Semantic richness– Add a well-defined alternative to a less constrained field

– e.g., use of an optional coding system in addition to textual concepts


HITSP Optionality

External entity may elect to exercise optionality identified by a HITSP IS or construct.

HITSP identifies optionality to support a domain choice (e.g., policy) rather than an individual implementation.

Optionality may be for a field in a message (e.g. laboratory phone number in a returned lab result that is optional in C-36).

11

Topics

Objective

HITSP Constructs

Well-defined ways to Use HITSP Construct

Proposal for use of HITSP IS-03 CE Registration and Medication History


Proposal for Actor Scoping and Subsets Definition for the Normal Usage of HITSP IS-03

This proposal is under development by the HITSP CE Technical Committee.

Goals are to allow implementations of subsets of HITSP IS-03, while ensuring smooth evolution towards the implementation of the complete use case.

Address real world needs, without introducing fragmentation which would be counter to the goal of interoperability.

Further input is welcome, especially from CCHIT.


First selection: Actor Scoping

Business Actor Technical Actor(s) Req/Opt Patient Identity Source Conditional PIX Consumer Conditional Patient Demographics Consumer Conditional Document Repository Optional Document Source Required

Personal Health Record (PHR) Service Provider

Document Consumer Required PIX Manager Required Patient Demographics Supplier Required Document Registry Required

Regional Health Information Organization (RHIO or HIE)

Document Repository Optional Patient Identity Source Conditional PIX Consumer Conditional Patient Demographics Consumer Conditional Document Consumer Required Document Repository Optional

Electronic Health Record (EHR) System

Document Source Required Patient Identity Source Conditional PIX Consumer Conditional Patient Demographics Consumer Conditional

Health Plan/Intermediary

Document Source Required Patient Identity Source Conditional PIX Consumer Conditional Patient Demographics Consumer Conditional

Pharmacy Benefit Manager (PBM)/Pharmacy

Document Source Required

A specific IT system selects one or more business actor(s) Selects among the optional corresponding technical actors (those required shall

be implemented).


Example: Actor Scoping for an EHR Business Actor

An EHR shall support the following Technical Actors:– Document Source– Document Consumer

An EHR shall support either:– A Patient Identity Source and a Patient ID Cross-Referencing Consumer– A Patient Demographics Consumer– Both of the above

An EHR may support the following Technical Actor:– Document Repository

Business Actor Technical Actor(s) Req/Opt Patient Identity Source Conditional PIX Consumer Conditional Patient Demographics Consumer Conditional Document Consumer Required Document Repository Optional

Electronic Health Record (EHR) System

Document Source Required Conditional: Shall support: (1) Patient Identity Source + PIX Consumer, or (2) Patient Demographics Consumer, or (3) Both


Second selection: One or more subsets

Proposed IS-03 Subsets for

Document Consumer

Dependency

Source-Registration None

Source-Registration-Coded Subset Requires above subset

Source-Medication Subset None

Source-Medication-Coded Subset Requires above subset

Source-Conditions and Allergy Subset None

Source-Conditions and Allergy-Coded Subset Requires above subset

Subsets are focused on the content of the registration and medication history document. All rely on the same document sharing transactions (TP-13) and patient identification (TP-22 or T-23). A specific IT system for the Technical Actor it supports shall select one or more subsets among:

Proposed IS-03 Subsets for

Document Source

Dependency

Consumer-Document Display None

Consumer-Document Import Requires Document Display

Consumer-Discrete Data Import Requires Document Display


Proposed Subset Definitions for Document Source

C-32 (CCD) Content Modules

Sour

ce-

Reg

istr

atio

n Su

bset

Sour

ce-

Reg

istr

atio

n-C

oded

Su

bset

Sour

ce-

Med

icat

ion

Subs

et

Sour

ce-

Med

icat

ion

–C

oded

Su

bset

Sour

ce-

Con

ditio

ns

and

Alle

rgy

Subs

et

Sour

ce-

Con

ditio

ns

and

Alle

rgy-

Cod

ed

Subs

et

Person Information R R R R R R

Language Spoken R R

Support R R

Healthcare Provider R R R R R R

Insurance Provider R R

Type of Payor R R

Type of Payor - coded R

Pregnancy R R

Information Source R R R R R R

Comments R R R R R R

Advance Directives R R

Condition R R

Medications – Prescription and Non-Prescription

R R

Medications – Prescription and Non-Prescription – coded

R

Allergies and Drug Sensitivity R R

Allergies and Drug Sensitivity - coded

R


Actor Scoping and Subsets Definition for the Normal Usage of HITSP IS-03

This proposal is under development by the HITSP CE Technical Committee.

Goal is to include in next revision of the IS-03 and to ensure that subset definition meets market need and CCHIT certification roadmap.

Cooperation with CCHIT is welcome in the next few weeks to define and approve.

Documents

July 20, 2007 Healthcare Information Technology Standards Panel Principles for Proper Use of HITSP Interoperability Specifications And Proposal for Proper