Healthcare Information Technology Standards Panel Principles for Proper Use of HITSP Interoperability Specifications And Proposal for Proper Use of IS-03 CE Registration and Medication History July 20, 2007

Topics Objective HITSP Constructs Well-defined ways to Use HITSP Construct Proposal for use of HITSP IS-03 CE Registration and Medication History

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

HITSP Framework Component SDOs Use Case or Modification Request For External Use Interoperability Specification Component (Composite) Transaction Transaction Pkg. For Internal Reuse Interoperability Specification Component (Composite) Transaction Transaction Pkg. For Internal Reuse Transaction Package (1..m transactions or composite standards) Transaction (1..n components or composite standards) Component (1..c base or composite standards) SDOs Base Standard #1 Base Standard #2 Base Standard #3 Base Standard #4 Base Standard #5 Base Standard #... Base Standard #n

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

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 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 Conditional: Shall support: (1) Patient Identity Source + PIX Consumer, or (2) Patient Demographics Consumer, or (3) Both 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

Second selection: One or more subsets 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 Subset Definitions for Document Source

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.