Healthcare Information Technology Standards Panel Principles for Proper

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 4 Objective 4 HITSP Constructs 4 Well-defined ways to Use HITSP Construct 4 Proposal for use of HITSP IS-03 CE Registration and Medication History 1

Objective of this Proposed Definition of Principles for Proper Use of HITSP Constructs 4 To clarify principles for appropriate, consistent use of HITSP Interoperability Specifications and other HITSP construct specifications by intended users. 4 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 Construct Proper Use 2

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

General Perspective on types of Proper Use 4 Use of a HITSP Interoperability Specification and Associated Constructs. – HITSP Technical Committees defines ways users can appropriately use an IS and associated constructs 4 Longer term questions that will require definition of welldefined 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 HITSP Construct Proper Use 4

Different Types Of External Use of an I. S. and Associated Constructs 4 Actor Scoping 4 Subsetting 4 HITSP Optionality HITSP Construct Proper Use 5

Different Types Of External Use of an I. S. and Associated Constructs - Actor Scoping 4 For entire Interoperability Specification (IS), meet requirements for selected subset of Business and supporting Technical Actors. 4 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 HITSP Construct Proper Use 6

Different Types Of External Use of an I. S. and Associated Constructs - Subset 4 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 4 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 V 2. 0 of EHR-Lab, Consumer Empowerment, and Biosurveillance Interoperability Specifications (IS-01, 02 and 03). HITSP Construct Proper Use 7

Different ways to subset 4 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 4 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 4 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 Construct Proper Use 8

HITSP Optionality 4 External entity may elect to exercise optionality identified by a HITSP IS or construct. 4 HITSP identifies optionality to support a domain choice (e. g. , policy) rather than an individual implementation. 4 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). HITSP Construct Proper Use 9

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

Proposal for Actor Scoping and Subsets Definition for the Normal Usage of HITSP IS-03 4 This proposal is under development by the HITSP CE Technical Committee. 4 Goals are to allow implementations of subsets of HITSP IS-03, while ensuring smooth evolution towards the implementation of the complete use case. 4 Address real world needs, without introducing fragmentation which would be counter to the goal of interoperability. 4 Further input is welcome, especially from CCHIT. HITSP Construct Proper Use 11

First selection: Actor Scoping 4 A specific IT system selects one or more business actor(s) 4 Selects among the optional corresponding technical actors (those required shall be implemented). HITSP Construct Proper Use 12

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 4 An EHR shall support the following Technical Actors: – – Document Source Document Consumer 4 An EHR shall support either: – – – A Patient Identity Source and a Patient ID Cross-Referencing Consumer A Patient Demographics Consumer Both of the above 4 An EHR may support the following Technical Actor: – Document Repository HITSP Construct Proper Use 13

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

Proposed Subset Definitions for Document Source HITSP Construct Proper Use 15

Actor Scoping and Subsets Definition for the Normal Usage of HITSP IS-03 4 This proposal is under development by the HITSP CE Technical Committee. 4 Goal is to include in next revision of the IS-03 and to ensure that subset definition meets market need and CCHIT certification roadmap. 4 Cooperation with CCHIT is welcome in the next few weeks to define and approve. HITSP Construct Proper Use 16