Transcript HITSP Overview for CCHIT FINAL - American National Standards

Healthcare Information
Technology Standards Panel
General Introduction
June 15, 2007
Topics
HITSP Mission within ONC Interoperability Initiatives
HITSP Organization
HITSP Process
Introduction to Current Interoperability Specifications
HITSP 2007/2008 Work Plan
1
HHS 2005 Contracts
Evaluation of Standards Harmonization Process for HIT
2
The American Health Information Community
The Certification
Commission for
Healthcare
Information
Technology
(CCHIT)
Healthcare
Information
Technology
Standards Panel
(HITSP)
American
Health
Information
Community
The Health
Information
Security and
Privacy
Collaboration
(HISPC)
HITSP includes 323 different
member organizations and is
administered by a Board of
Directors
19 SDOs
263 Non-SDOs
28 Govt. bodies
13 Consumer groups
Nationwide
Health
Information
The Community is a federally-chartered
Network
commission and will provide input and
Architecture
Projects (NHIN) recommendations to HHS on how to make
Evaluation of Standards Harmonization Process for HIT
health records digital and interoperable,
and assure that the privacy and security of
those records are protected, in a smooth,
market-led way.
3
President’s Executive Order
August 22, 2006
Executive Order: Promoting Quality and Efficient Health Care in Federal
Government Administered or Sponsored Health Care Programs
Sec. 3. Directives for Agencies. Agencies shall perform the following
functions:
Health Information Technology - For Federal Agencies. As each agency
implements, acquires, or upgrades health information technology
systems used for the direct exchange of health information between
agencies and with non-Federal entities, it shall utilize, where available,
health information technology systems and products that meet
recognized interoperability standards.
Evaluation of Standards Harmonization Process for HIT
4
HITSP Mission and Role
Mission:
To harmonize relevant
standards in the health
care industry to enable
and advance
interoperability
The standards
harmonization process is
an open, inclusive,
collaborative, use case
driven process
www.hitsp.org
1. Identify a pool of standards for a
general breakthrough area
2. Identify gaps and overlaps for a
specific context
3. Make recommendations for resolution
of gaps and overlaps
4. Develop interoperability specifications
for using the selected standard for a
specific context
5. Test the instruction for using the
standard
Evaluation of Standards Harmonization Process for HIT
5
Technical Standards Not Policy
HITSP focuses on technical standards and NOT on policy definition
A standard specifies a well defined approach that supports a business
process and . . .
– has been agreed upon by a group of experts
– has been publicly vetted
– provides rules, guidelines, or characteristics
– helps to ensure that materials, products, processes and services are fit for
their intended purpose
– is available in an accessible format
– is subject to ongoing review and revision process
Harmonization is required when a proliferation of standards prevents
progress rather than enables it
Evaluation of Standards Harmonization Process for HIT
6
Topics
HITSP Mission within ONC Interoperability Initiatives
HITSP Organization
HITSP Process
Introduction to Current Interoperability Specifications
HITSP 2007/2008 Work Plan
7
HITSP Governance Model
HITSP Panel
– The Panel brings together experts from across the healthcare IT community
– All strategic decisions are made by consensus within the Panel
HITSP Board of Directors
– A Board of Directors provides governance and administrative guidance
Technical and Coordination Committees
– Much of the work is accomplished by volunteers that lead and serve on
Technical Committees and Coordination Committees
Project Team
– The project team defines and manages the HITSP process in accordance
with the ONCHIT1 contract from the U.S. Department of Health and Human
Services
Evaluation of Standards Harmonization Process for HIT
8
HITSP Overview
Current
Focus
The Community
HHS Secretary
Mike Leavitt, Chair
HHS ONCHIT1
PO, Dr. John Loonsk
Eleven Tasks are included in this contract:
HITSP
Dr. John Halamka, Chair
Member populated
Technical Committees
Project Management Team
Executive in Charge, F. Schrotter, ANSI
Program Manager, L. Jones GSI
Deputy PM, J Corley, ATI
Project Manager, Julie Pooley, Booz Allen
Panel Secretariat
and Coordination
Committee Mgmnt
Michelle Deane,
ANSI
Technical
Committee
Management
Joyce Sensmeier,
HIMSS
1.
2.
3.
4.
Comprehensive Work Plan
Conduct a Project Start Up Meeting
Deliver Recommended Use-Cases
Participate in related meetings and
activities, including AHIC Meetings
5. Develop a Gap Analysis
6. Standards Selection, Evaluations and
Testing
7. Define a Harmonization Approach
8. Develop Interoperability Specifications
9. Develop and Evaluate a Business Plan
for the self-sustaining processes
10. Submit Monthly Reports
11. Assist with communications
Evaluation of Standards Harmonization Process for HIT
9
HITSP Technical Committees
HITSP Care Delivery Technical Committee
– James Ferguson, Kaiser Permanente
– Steve Hufnagel, Department of Defense/Medical Health System
– Steve Wagner, Department of Veterans Affairs
– Current focus is on Emergency Responder EHR, Laboratory Message,
Medications Management
HITSP Consumer Empowerment Technical Committee
– Elaine Blechman, PhD, University of Colorado, Boulder
– Charles Parisot, EHR Vendor Association
– Scott Robertson, Kaiser Permanente
– Current focus is on Consumer Access to Clinical Information
Evaluation of Standards Harmonization Process for HIT
10
HITSP Technical Committees (continued)
HITSP Population Health Technical Committee
– Floyd Eisenberg, MD, MPH, Siemens Medical Solutions
– Peter Elkin, MD, Mayo Clinic College of Medicine
– Shaun Grannis, MD, Department of Family Medicine, Indiana University
School of Medicine
– Current focus is on Quality
HITSP Security and Privacy Technical Committee
– Glen Marshall, Siemens Medical Solutions
– John Moehrke, GE Healthcare
– Walter Suarez, MD, Institute for HIPAA/HIT Education and Research
– Current focus is on Security and Privacy constructs for EHR, BIO, and
CE Interoperability Specifications
Evaluation of Standards Harmonization Process for HIT
11
HITSP Coordination Committees
Foundations Committee
– Steve Wagner, Department of Veteran Affairs
– Bob Dolin, Kaiser Permanente
– Current focus is on Security and Privacy framework and small scale
harmonization of demographic data
HITSP Process Review Committee
– Lynne Gilbertson, NCPDP
– Erik Pupo, Vangent Inc.
– Current focus is on HITSP process definition and evaluation
HITSP-CCHIT Joint Work Group
– Jamie Ferguson, Kaiser Permanente
– Current focus is on alignment of HITSP and CCHIT schedules,
processes, and products
Evaluation of Standards Harmonization Process for HIT
12
HITSP Coordination Committees (continued)
Harmonization Readiness Committee
– Lynne Gilbertson, NCPDP
– Current focus is on updated Tier 2 criteria
Business Plan Committee
– Steve Lieber, HIMSS
International Landscape Committee
– Bill Braithwaite, HL7
Fairly inactive in 2007
Governance Committee
– Michael Aisenberg, EWA Information and
Infrastructure Technologies Inc
Evaluation of Standards Harmonization Process for HIT
13
HITSP Project Team
HITSP activities are led by the American National Standards Institute
(ANSI), a not-for-profit organization that has been coordinating the
U.S. voluntary standardization system since 1918
ANSI’s strategic partners include
– Healthcare Information and Management Systems Society (HIMSS)
– Advanced Technology Institute (ATI)
– Booz Allen Hamilton
– Numerous subcontracting organizations
Funding for the Panel is being provided via the ONCHIT1 contract
award from the U.S. Department of Health and Human Services
Evaluation of Standards Harmonization Process for HIT
14
Topics
HITSP Mission within ONC Interoperability Initiatives
HITSP Organization
HITSP Process
Introduction to Current Interoperability Specifications
HITSP 2007/2008 Work Plan
15
Standards Harmonization Process Steps
Receive
Request
I
II
Harmonization
Request
Requirements
Analysis
III
IV
Identification
of Candidate
Standards
Gaps,
Duplications
and
Overlaps
Resolution
V
VI
Standards
Selection
Construction
of
Interoperability
Specification
VII
Inspection
Test
VIII
Interoperability
Specification
Release
and
Dissemination
IX
Program Management
Begin
Support
Evaluation of Standards Harmonization Process for HIT
16
Standards Harmonization Work Plan Tasks
PROCESS
I
II
Harmonization
Request
Requirements
Analysis
III
IV
Identification
of Candidate
Standards
Gaps,
Duplications
and
Overlaps
Resolution
V
VI
VII
VIII
Standards
Selection
Construction
of
Interoperability
Specification
Inspection
Test
Interoperability
Specification
Release
and
Dissemination
IX
Program Management
TASKS
Requirements, Design,
and Standards
Selection
3 months
DOCUMENTATION
Comment
Interoperability
Period Specification Construct
Development
4 weeks
Inspect.
Test,
Comnt
Period
Comment
Resolution and
Panel Approval
Implementation
Support and
Testing
4 weeks
2 months
On-going
3 months
Requirements Consolidated
Design &
comments
Standards
Selection
IS Docs
Consolidated
Review Draft comments
Summary of
comment
resolution
Evaluation of Standards Harmonization Process for HIT
IS Docs
V 1.0
Annual
Updates as
Required
Summary of
comment
resolution
17
AHIC Use Cases Analysis
 HITSP receives Use Cases and Harmonization Requests from AHIC
 The Use Case or Request defines perspectives (scenarios),
business actors, and business and functional/interoperability
requirements as events and actions
 HITSP analyzes the Use Case to define the Interoperability
Specification requirements
– Identify candidate business Actors (Stakeholders)
– Identify candidate technical Actors (Sys. Components)
– Identify candidate data sets
– Identify candidate requirements
– Identify candidate standards
– Identify interactions where policies are required
Evaluation of Standards Harmonization Process for HIT
18
Requirements Analysis
 Build Use Case Analysis Diagrams (Functional analysis)
 Map Data Sets to Activities
 Map Candidate Standards to Data Sets and Identify Gaps
– Transport
– Content
 Build Use Case Roles Diagram (Object analysis)
 Build Use Case Sequence Diagram (s)
Evaluation of Standards Harmonization Process for HIT
19
Requirements Analysis and UML Modeling
UML Development Step
1.
Define actors & activities
2.
Refine associations
3.
Assign data, std., priorities
4.
Design transaction sets
5.
Repeat

Iterate

drill down

divide and conquer.
Ambiguous
Use Case
UML Diagram
Use-Case: functional analysis
Use-Case: object (role) analysis
Sequence
HITSP RDSS
Document
Class / Component / Sequence
Fill out RDSS templates
Data sets refinement
Unambiguous
HITSP IS
Evaluation of Standards Harmonization Process for HIT
Candidate standards refinement
Tier 2 standards selection criteria
20
Defines and
Narrows Context
HITSP Framework
Use Case/Modification Request
(1..m transactions or composite standards)
Base
Standard
#1
Base
Standard
#2
Base
Standard
#3
Base
Standard
#4
Evaluation of Standards Harmonization Process for HIT
Base
Standard
#5
Transaction
(Composite)
Standard
Component (1..c base or composite standards)
Component
(Composite)
Standard
Transaction (1..n components or composite standards)
Base
Standard
#6
Base
Standard
#7
Potential for Reuse in Other Contexts
Transaction Package
Transaction Package
(Composite) Standard
Interoperability Specification
21
HITSP Harmonization Framework
HITSP decomposes the Use Case requirements into
scenario(s) and then into transactions providing context:
technical actors, actions and content
It may create or reuse a transaction or a grouping of
transactions (transaction package) based on commonality at
this level
Transactions are logical groupings of actions that are
decomposed into components, which are groupings of base
standards that work together, such as message and terminology
Evaluation of Standards Harmonization Process for HIT
22
HITSP Harmonization Framework (continued)
Each HITSP construct, i.e., transaction package, transaction or
component, may constrain the construct or standard below it.
Constraints are specified in each construct as appropriate,
additional constraints may be imposed by higher level
constructs to control optionality in a specific scenario
Transaction packages, transactions and components all are
potential candidates for reuse if a new set of requirements and
context are successful fulfilled by the existing construct
While reuse is a HITSP goal, it is established in the context of a
Use Case and its functional/interoperability requirements
HITSP constructs are version controlled and uniquely identified
Evaluation of Standards Harmonization Process for HIT
23
Definitions and Rules
Level
Definition
Example
Use Case or
Harmonization
Request
Defines business and
functional requirements
Sets Context
ONC Harmonized
EHR Use Case
Interoperability
Specification
Models business/
functional/
interoperability
requirements
Identifies
technical/system
requirements to meet
use-case
Identifies how to use
one or more HITSP
constructs to meet usecase requirements
HITSP EHR
Interoperability
Specification
Evaluation of Standards Harmonization Process for HIT
Rules
Uses UML diagram to
identify technical actors
and actions
Sets context
Testable functional
requirements
Ids transactions or
transaction packages
24
Definitions and Rules (continued)
Level
Definition
Example
Rules
Transaction
Package
Defines how two or
more transactions are
used to support a
stand-alone
information
interchange within a
defined context
between two or more
systems
Record
Locator
Service
Entity
Identification
Service
Thin context and interoperability requirements
Testable
Based on analysis of like technical actors,
context and content harmonized across
transactions
May be fulfilled by one or more transactions or
composite standard
Expresses constraints on transactions or
composite standard
Transaction
Logical grouping of
actions, including
necessary content
and context, that
must all succeed or
fail as a group.
Query lab
result
Send lab
result
Fulfills all actions between two or more
systems needed to meet one or more
interoperability requirements
Testable
May be fulfilled by components or composite
standard
Expresses constraints on components or
composite standard
Evaluation of Standards Harmonization Process for HIT
25
Definitions and Rules (continued)
Level
Component
Definition
Example
 An atomic construct
Lab result
used to support an
message
information interchange Lab result
or to meet an
context
infrastructure
requirement (e.g.,
security, logging/audit)
Evaluation of Standards Harmonization Process for HIT
Rules
 Typically will use one “primary”
standard and may have other
“secondary” standards
 Expresses constraints on base
or composite standards
26
Definitions and Rules (continued)
Level
Definition
Example
Rules
Base
Standard
A standard capable of
Messaging
fulfilling a discrete function
standard
within a single category
Security standard
produced and maintained by Code set.
a single standards
organization.
Composite
Standard
Grouping of coordinated
Integration profiles Per Definition above
base standards, often from Implementation
multiple standards
guides
organizations, maintained by Health transaction
a single organization. In
services
HITSP, it can serve as a
component, transaction or
transaction package
functional requirements.
Evaluation of Standards Harmonization Process for HIT
Per HITSP definition the term
“standard” refers, but is not limited
to:
–Specifications
–Implementation Guides
–Code Sets
–Terminologies
–Integration Profiles
27
Design and Standards Selection
Once requirements have been defined, HITSP scopes the set of
constructs to address them
HITSP designs the constructs based on Technical Actors and
Transactions
– New constructs
– Existing constructs to be reused
HITSP identifies the pool of candidate standards
HITSP evaluates the candidate standards against Tier 1 and Tier 2
criteria to define the selected standards
The Requirements, Design, and Standards Selection (RDSS)
document is published for a four week comment period
Evaluation of Standards Harmonization Process for HIT
28
Tier 1 Standards Readiness Criteria
The standards required to
support each major Use
Case event were organized
within an agreed upon
standards taxonomy
The standards selected for
inclusion in the pool were
examined using ‘HITSP
approved’ Tier 1 and Tier 2
Harmonization Readiness
Criteria
Evaluation of Standards Harmonization Process for HIT
29
Tier 2 Standards Readiness Criteria
Suitability
– The standard is named at a proper level of specificity and meets technical
and business criteria of use case
Compatibility
– The standard shares common context, information exchange structures,
content or data elements, security and processes with other HITSP
harmonized standards or adopted frameworks as appropriate
Preferred Standards Characteristics
– Approved standards, widely used, readily available, technology neutral,
supporting uniformity, demonstrating flexibility and international usage are
preferred
Standards Development Organization and Process
– Meet selected criteria including balance, transparency, developer due
process, stewardship and others
Total Costs and Ease of Implementation
– Deferred to future work
Evaluation of Standards Harmonization Process for HIT
30
Interoperability Specification Development,
Inspection Testing and Public Comment
Once the RDSS is published, HITSP begins to define and document
the Interoperability Specification constructs
Comments on the RDSS are feed into the Interoperability
Specification development process – the RDSS is not republished
The Interoperability Specification constructs are published for a 4week period of public comment and inspection testing
Inspection Testing is a focused desktop review of the constructs
– Inspection Testers are recruited from the HITSP membership and other
interested stakeholders
– Inspection Testers are given a set of specific criteria to be used to evaluate
the Interoperability Specification construct
Evaluation of Standards Harmonization Process for HIT
31
Inspection Testing Objectives
Objective
To validate that the IS….
Process
Meets Use Case
Requirements
 Validate that the IS when implemented will meet the specific
requirements as defined in the use case and contains
accurate references and data
Is Technically Valid
 Check the specification to determine the existence of the
following:
― Ambiguities/ lack of specificity
― Inconsistencies
― Gaps and overlaps
― Testability
― Completeness
― Internal consistency
― Ability to implement
Evaluation of Standards Harmonization Process for HIT
32
Resolution and Publication
The public comments and the results of the Inspection Testing are
reviewed and dispositioned by the HITSP Technical Committees
– Content changes are: Accepted, Accepted with modification, Rejected
(non-persuasive)
– Process-related changes are referred to Process Review Committee
– Project-related changes are referred to the Project Team
The Interoperability Specification constructs are republished and
presented to the Panel for approval
Upon approval by the Panel, the Interoperability Specifications are
advanced to AHIC, ultimately to be accepted and then recognized
(one year later) by the HHS Secretary
Evaluation of Standards Harmonization Process for HIT
33
Implementation Testing
Once the specifications are released HITSP enlists partners to:
– develop test plans, data and suites to test the implementation
– support a program for progressive testing, feedback and deployment of
implementations
Feedback from test implementers is used by the Technical Committees
to revise and republish the Interoperability Specifications
The HITSP implementation support and testing process does NOT
involve any kind of determination of a products “conformance”
HITSP is currently working with NIST, CCHIT, and ONC to define an
overall integrated interoperability testing strategy
– As a first step, HITSP has worked with NIST to establish an Implementation
Testing and Support website, which provides links to existing test resources
Evaluation of Standards Harmonization Process for HIT
34
HIT Implementation Testing Web Site Preview
Evaluation of Standards Harmonization Process for HIT
35
Maintenance Process
HITSP documents are maintained through a structured release and
publication process; with on-going “major” or “minor” releases
Major - Any change that introduces a requirement where a modification
to an implementation MUST occur in order to remain conformant to the
Interoperability Specification, or a component thereof, is to be
considered a major change
– Major releases go through inspection testing, public comment, and Panel
approval
– Major releases are versioned as (1.0, 2.0, 3.0 etc)
Minor - Any change that loosens restrictions, clarifies use or intent but
does not require any action for an implementation to remain
conformant is considered a minor change
– Minor releases are issued by consensus at the Technical Committee Level
– Minor releases are versioned as 2.1, 2.2, 2.3, etc
Evaluation of Standards Harmonization Process for HIT
36
Topics
HITSP Mission within ONC Interoperability Initiatives
HITSP Organization
HITSP Process
Introduction to Current Interoperability Specifications
HITSP 2007/2008 Work Plan
37
Consumer Empowerment Registration and
Medication History
Scope
– Deploy to targeted populations a pre-populated, consumer-directed and
secure electronic registration summary. Deploy a widely available prepopulated medication history linked to the registration summary
Addresses core consumer empowerment enabling “connected PHRs”
Now recognized to be also applicable to EHR-to-EHR information
exchange for interoperable patient charts with meds, allergies,
problems, registration info.
A successful collaboration between HITSP and several HITSP
member organizations developing base standards and
implementation guides/profiles: ASTM, CAQH, CDC, FMT, HL7, IHE,
NCPDP, X12, SNOMED
Evaluation of Standards Harmonization Process for HIT
38
Consumer Empowerment Registration and
Medication History
class CE Interoperability Specification
«interoperability specification»
Consumer Empow erment
+
docId = IS03
contains
+
«transaction package»
Manage Sharing of
Documents
«component»
Registration and Med History
Document Content
docId = TP13
+
constrains
«composite standard»
IHE XDS
+
+
+
+
contains
contains
Provide & Register Document Set: ITI-15
Query Registry: ITI-16
Register Document Set: ITI-14
Retrieve Document: ITI-17
«transaction package»
Patient ID CrossReferencing
docId = C32
constrains
+
«base stand...
LOINC
«composite stand...
IHE PIX
constrains
«composite standard»
Federal Medication
Terminologies
constrains
-
«base stand...
X12N 270/271
docId = T23
constrains
«composite stand...
IHE PDQ
PIX Query: ITI-9
«base standard»
NCPDP SCRIPT
constrains
constrains
references
«transaction»
Patient Demographics
Query
+
constrains
implements
«base standard»
ISO 15000 ebRS
docId = TP22
constrains constrains
«composite stand...
CAQH CORE
contains
constrains
«base standard»
HL7 V2.5 Message
«base stand...
ASTM/HL7 CCD
uses
«base standard»
NDC RxNorm SPL
constrains
«base stand...
HL7 CDA R2
Evaluation of Standards Harmonization Process for HIT
«base standard»
ASTM E2369
39
Biosurveillance
Scope
– Transmit essential ambulatory care and emergency department visit,
utilization, and lab result data from electronically enabled health care
delivery and public health systems in a standardized and anonymized
format to authorized public health agencies with less than one day lag time
IS maximizes data sources and provides stringent data management
to ensure proper routing, security, privacy, and timely reporting
– IS provides support for any variant of architectural environments
– IS includes full options of standards to maximize data and information
exchange
Addressing gaps with referrals to SDOs through the Foundations
Committee
Actively aligning with other public health industry initiatives
Evaluation of Standards Harmonization Process for HIT
40
Biosurveillance
class Bio Interoperability Specification
«component»
Resource Utilization Message
+
«interoperability specificat...
Bio-surv eillance
contains
+
docId = C47
«transaction,interoperabi...
Pseudonimize
contains
+
docId = IS02
docId = T24
+
contains
contains
contains
contains
contains
+
«component»
Encounter Message
+
«transaction package»
Encounter Document
docId = C39
+
«component»
Acknow ledgements
docId = TP48
+
contains
+
docId = C45
+
docId = C41
+
contains
«component»
Lab Report Document
Structure
docId = TP13
uses
+
+
«composite stand...
IHE XDS-MS
constrains
+
+
+
+
«composite standard»
IHE PIX
«component»
EHR Lab
Terminology
PIX Query: ITI-9
+
docId = C35
constrains
«composite standard»
IHE XD*-Lab
Provide & Register Document Set: ITI-15
Query Registry: ITI-16
Register Document Set: ITI-14
Retrieve Document: ITI-17
implements
«base stand...
XForms
constrains
«composite standard»
IHE XDS
implements
docId = TP22
references
-
«composite stan...
IHE XDS-I
constraints
constrains
contains
«composite stan...
IHE NAV
implements
«composite stan...
IHE RFD
«transaction package»
Patient ID CrossReferencing
docId = C37
docId = TP49
«base stand...
DICOM 2003
constrains
docID = C36
references
«transaction package»
Sharing Radiology Results
+
docId = TP50
«component»
Lab Report Message
«component»
Radiology Message
«transaction package»
Manage Sharing of
Documents
docId = T25
«transaction packag...
Retriev e Form for Data
Capture
contains
contains
contains
«transactions»
Anonymize
contains
constrains
constrains
«base stand...
LOINC
«base stan...
HL7 V2.5 Code
Sets
constrains
constrains
«base stand...
HL7 CDA R2
«base standard»
ISO 15000 ebRS
constrains
constrains
constrains
«base stand...
HL7 V2.5
Message
«base stand...
HL7 V3 Lab
«base stand...
HL7 V3.0 Code
Sets
constrains
«base stand...
SNOMED-CT
constrains
constrains
constrains
constrains
«base stand...
HL7 V2.5.1
Message
Evaluation of Standards Harmonization Process for HIT
41
Electronic Health Record (EHR) Laboratory
Results Reporting
Scope
– Deploy standardized, widely available, secure solutions for accessing
laboratory results and interpretations in a patient-centric manner for clinical
care by authorized parties
IS addresses lack of harmonization among data interoperability
standards including vocabulary and laboratory and other messaging
standards
– IS accommodates both laboratory message transaction and document
sharing paradigms
– IS selects standards with wide coverage to address gaps and provide
mapping between standards to address overlaps
HL7 and HITSP Lab WG are coordinating activities to complete a lab
message implementation guide to meet the use case requirements
Evaluation of Standards Harmonization Process for HIT
42
Electronic Health Record (EHR) Laboratory
Results Reporting
class EHR Interoperability Specification
«interoperability specification»
EHR - Laboratory
«transaction package»
Send Lab Results
contains
+
docId = IS01
+
contains
contains
contains
contains
contains
«transaction package»
View Lab Results from a Web
Application
contains
+
«transaction package»
Manage Sharing of
Documents
+
«component»
Lab Report Document
Structure
+
docId = TP13
«component»
Lab Report Message
+
«transaction package»
Patient ID CrossReferencing
docID = C36
docId = C37
+
docId = TP18
«transaction»
Patient Demographics
Query
docId = TP22
constrains
docId = TP14
+
docId = T23
constrains
uses
Secure Web Connection
+
docId = C44
constrains
uses
«base standard»
HL7 V2.5.1 Message
uses
constrains
«composite stand...
IHE PIX
-
«composite stand...
IHE PDQ
«base stand...
IETF HTTPS
PIX Query: ITI-9
«composite stand...
IHE NAV
constrains
constrains
«base standard»
HL7 V2.5 Message
«composite standard»
IHE XDS
+
+
+
+
Provide & Register Document Set: ITI-15
Query Registry: ITI-16
Register Document Set: ITI-14
Retrieve Document: ITI-17
implements
«base standard»
ISO 15000 ebRS
«component»
EHR Lab Terminology
references
references
constrains
+
«composite standard»
IHE XD*-Lab
constrains
constrains
constrains
«base stand...
LOINC
«base stand...
SNOMED-CT
docId = C35
constrains
«base stand...
HL7 V3.0 Code
Sets
constrains
«base stand...
HL7 V2.5 Code
Sets
«base stand...
HL7 CDA R2
Evaluation of Standards Harmonization Process for HIT
43
Use of HITSP’s Interoperability Specifications
 A HITSP IS addresses the communication of health information among a
number of Business Actors within the context of a specific Use Case.
 There are two dimensions to the use/implementation of a HITSP IS by a set
of “real world systems”. Each system may chose to support:
– One or more of the Use Case Subsets, if any are defined
– One or more Business Actors and options, if any are defined.
Evaluation of Standards Harmonization Process for HIT
44
Use of HITSP’s Interoperability Specifications
 A “real world system” may chose to support:
– One or more of the Use Case Subsets
– One or more Business Actors and options, if any
 Choice of a Use Case Subset (if defined by the IS) implies support of:
– A Subset of Business and/or Technical Actors
– A Subset of transactions and/or components
 Choice of a Business Actor implies support of:
– All Technical Actors defined as required to support the selected Business
Actor.
– All Transactions or Components (Document Content, Terminology Value
Sets, etc.) specified as required originating or terminating with each
Technical Actor
– If any specified, the options associated with each technical actor.
Evaluation of Standards Harmonization Process for HIT
45
Example: Use of the EHR-Lab Results IS
 The HITSP EHR-Lab IS addresses two use case “subsets”:
– Returning Lab results to the ordering provider
Laboratory
Patient Id
Service
Lab Result Msg
EHR
Option: Copy to
Lab Result Msg
Patient Id
Query
Option:
Copy to Lab Result
incl Pt Id Service
(Lab, EHR, Pt Id)
– Sharing and accessing historical lab results
Laboratory Option: Notification of
Availability
EHR
Lab
Result Doc
Lab
Result Doc
Pt Id Query
Patient Id
Service
Option:
Notification of
Results Availability
(Lab, EHR)
Repository
& Locator
Business Actor
Technical Actor
Evaluation of Standards Harmonization Process for HIT
46
Example: Use of the CE-Reg/Med IS
 The HITSP CE-Reg/Med IS has no use case “subsets”:
PHR
EHR
PBM/
Pharmacy
Health Plan
Reg/Med Doc Pt Id Query Patient Id
Service
Register
Doc
Registry
Business Actor
Option:
Registration Info
(PHR, Health Plan,
EHR)
Option: Med &
Allergies Info
(EHR,PHR,
PBM/Pharmacy)
Repository
Technical Actor
Evaluation of Standards Harmonization Process for HIT
47
Topics
HITSP Mission within ONC Interoperability Initiatives
HITSP Organization
HITSP Process
Introduction to Current Interoperability Specifications
HITSP 2007/2008 Work Plan
48
HITSP 2007 Timeline (as of June 2007)
02/05/07
HITSP Board
02/12/07
HITSP Panel
JAN
FEB
04/23/07
HITSP Board
03/19/07
HITSP Panel
MAR
MAY
JUN
JUL
AUG
6/18 – 6/20
TC Face to Face
San Diego CA
5/08 – 5/10
TC Face to Face
Arlington VA
03/06 – 03/08
TC Face to Face
Chicago IL
09/07/07
HITSP Panel
07/16/07
HITSP Panel
05/11/07
HITSP Panel
APR
10/09/07
HITSP Board
07/09/07
HITSP Board
10/15/07
HITSP Panel
SEP
OCT
NOV
DEC
09/04 – 09/06
TC Face to Face
Arlington VA
Activity 1 – Version 2.0 of Existing EHR, CE, BIO ISs
EHR, CE and BIO v 2.0
Implementation Support and Testing
(includes minor document updates)
On-going
Support
Activity 2 – Security and Privacy for All Use Cases
Activity 3 – New Emergency Responder EHR Use Case
Requirements, Design,
Standards Selection
02/15 – 05/16
04/13 – 05/16
Public Input
on S&P
S&P and EHR-ER v 1.0
05/17 – 06/14
Public
Comment
IS Construct Development
05/17 – 07/19
Inspect Test
and Public
Comment
07/20 – 08/16
Comment Resolution and
Panel Approval
Implementation Support and
Testing
(with annual updates as required)
08/17 – 10/15
Activity 4 –New Use Cases from AHIC
Detail Schedule to be Established Upon Review of the Use Cases
Evaluation of Standards Harmonization Process for HIT
49