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

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

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

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

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

6. Different Types Of External Use of an I.S. and Associated Constructs
Actor Scoping
Subsetting
HITSP Optionality

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

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

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

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

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

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

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

15. 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:

16. Proposed Subset Definitions for Document Source

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