Transcript 072007-HITSP-CCHIT-IS 03 Proper Use-FINAL

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
1
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 Construct Proper Use
2
HITSP Framework
Use Case or
Modification Request
Interoperability
Specification
Interoperability Specification
Transaction Package
(1..m transactions or composite standards)
For External
Use
TransactionPkg.
Pkg.
Transaction
(Composite)
(Composite)
Transaction
(1..n components or composite standards)
Transaction
Transaction
Component
Component
Component
(Composite)
(Composite)
(Composite)
(Composite)
(1..c base or composite standards)
For
For
InternalReuse
Reuse
Internal
Base
Standard
#1
Base
Standard
#2
Base
Standard
#3
HITSP Construct Proper Use
Base
Standard
#4
Base
Standard
#5
Base
Standard
#...
Base
Standard
#n
3
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 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
Actor Scoping
Subsetting
HITSP Optionality
HITSP Construct Proper Use
5
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
HITSP Construct Proper Use
6
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).
HITSP Construct Proper Use
7
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 Construct Proper Use
8
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).
HITSP Construct Proper Use
9
Topics
Objective
HITSP Constructs
Well-defined ways to Use HITSP Construct
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
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.
HITSP Construct Proper Use
11
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).
Business Actor
Personal Health Record (PHR) Service
Provider
Regional Health Information Organization
(RHIO or HIE)
Electronic Health Record (EHR) System
Health Plan/Intermediary
Pharmacy Benefit Manager (PBM)/Pharmacy
HITSP Construct Proper Use
Technical Actor(s)
Patient Identity Source
PIX Consumer
Patient Demographics Consumer
Document Repository
Document Source
Document Consumer
PIX Manager
Patient Demographics Supplier
Document Registry
Document Repository
Patient Identity Source
PIX Consumer
Patient Demographics Consumer
Document Consumer
Document Repository
Document Source
Patient Identity Source
PIX Consumer
Patient Demographics Consumer
Document Source
Patient Identity Source
PIX Consumer
Patient Demographics Consumer
Document Source
Req/Opt
Conditional
Conditional
Conditional
Optional
Required
Required
Required
Required
Required
Optional
Conditional
Conditional
Conditional
Required
Optional
Required
Conditional
Conditional
Conditional
Required
Conditional
Conditional
Conditional
Required
12
Example: Actor Scoping for an EHR Business Actor
Business Actor
Technical Actor(s)
Req/Opt
Patient Identity Source
Conditional
PIX Consumer
Conditional
Patient Demographics Consumer
Conditional
Document Consumer
Required
Document Repository
Optional
Document Source
Required
Conditional: Shall support: (1) Patient Identity Source + PIX Consumer, or (2) Patient Demographics Consumer, or (3) Both
Electronic Health Record (EHR) System
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
HITSP Construct Proper Use
13
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 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
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
HITSP Construct Proper Use
14
SourceMedication –
Coded
Subset
SourceConditions
and Allergy
Subset
R
R
R
R
R
R
R
R
Person Information
R
Language Spoken
R
R
Support
R
R
Healthcare Provider
R
R
Insurance Provider
R
R
R
R
C-32 (CCD) Content Modules
Type of Payor
Type of Payor - coded
SourceConditions
and AllergyCoded
Subset
SourceMedication
Subset
R
SourceRegistration
Subset
SourceRegistration
-Coded
Subset
Proposed Subset Definitions for Document Source
R
Pregnancy
R
R
Information Source
R
R
R
R
R
R
Comments
R
R
R
R
R
R
Advance Directives
R
R
R
R
R
R
Condition
Medications – Prescription and NonPrescription
Medications – Prescription
and Non-Prescription – coded
Allergies and Drug Sensitivity
Allergies and Drug Sensitivity coded
HITSP Construct Proper Use
R
R
R
R
15
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.
HITSP Construct Proper Use
16