Standards Harmonization Technical Committees Update documents/Standards... · Evaluation The...

Washington DCJune 14 2006

Standards Harmonization Technical Committees UpdateReport to the Healthcare Information Technology Standards Panel

Discussion Document

This briefing is being provided to HITSP.

This material is intended to facilitate discussions during the HITSP meeting.

All information contained in this briefing and the related documents is draft.

Document Number: HITSP 06 N 95Date: June 14, 2006

1Healthcare Information Technology Standards PanelHealthcare Information Technology Standards Panel

Table of Contents

Introduction

HITSP Technical Committees Overview

Standards Selection Process Overview

Building Block Overview

Standards Selection - By Technical Committee

HITSP Comments

Next Steps


HITSP Technical Committees Overview

•Biosurveillance

•65 members

Transmit essential ambulatory care and emergency department visit, utilization, and lab result data from electronically enabled health care delivery and public health systems in standardized and anonymized format to authorized Public Health Agencies with less than one day lag time.

Floyd P. Eisenberg, MD MPH, SIEMENS Medical Solutions Health Services - PresenterPeter L. Elkin MD FACP, Mayo Clinic

College of MedicineShaun Grannis, MD, The Regenstrief

Institute, Indiana University School of Medicine

•Consumer Empowerment

•67 members

Allow consumers to establish and manage permissions access rights and informed consent for authorized and secure exchange, viewing, and querying of their linked patient registration summaries and medication histories between designated caregivers and other health professionals.

Charles Parisot, EHR Vendor AssociationElaine A. Blechman PhD, Professor,

Univ. of Colorado-Boulder

•Electronic Health Record

•85 members

Allow ordering clinicians to electronically access laboratory results, and allow non-ordering authorized clinicians to electronically access historical and other laboratory results for clinical care.

Jamie Ferguson, Kaiser-Permanente - PresenterJohn Madden, MD, PhD, SNOMED

IntlSteve Wagner, Department of

Veterans Affairs


Introduction

The Healthcare Information Technology Standards Panel (HITSP) Technical Committees have begun the selection of named standards to be used in constructing the Interoperability Specifications.

The selected standards represent a continuation and refinement of the Gap Analysis delivered to HITSP and the Office of the National Coordinator (ONC) on May 30, 2006.

In this phase of its work, each Technical Committee is focusing on evaluating and selecting the specific standards to meet the requirements of its assigned Use Case.

In a future phase, the Technical Committees will provide input to the construction, testing and evaluation of Interoperability Specifications to meet the respective Use Case requirements.


Standards Selection Process Overview

Specifically, the Technical Committee has:

Simplified the set of actions to those requiring interoperable information interchange

Focused on the information interchange actions that directly support the Community breakthroughs

Evaluated the remaining standards using the prototype Tier 2 Readiness Criteria

Produced a preliminary list of selected (named) standards expected to be used in the forthcoming Interoperability Specifications.


Building Blocks Overview

In the analysis of their respective Use Cases, the Technical Committees have found it useful to group related actions into constructs called “Building Blocks.”

Building Blocks are sets of interoperability requirements delineating abstract systems, actors, transactions and content.

Grouping actions into Building Blocks also can be used to identify the supporting interoperability standards.

Building Blocks have facilitated reuse within a Use Case as well as simplified the task of coordination across the Technical Committees.

Building Blocks can be either Use Case specific or common across two or all three Use Cases.

The Building Blocks represent the current set of analytic constructs.


Key Strategies for Standards Selection

Simplification

Initial analysis of the Use Cases included an extensive number of events and action.– Many of the events and actions did not require interoperable information

interchange between systems.– Deferred such actions as necessary pre- or post-conditions that represent system

functional requirements but not system level interoperability. – Addressed only the remaining actions requiring information interchange.

Focus

Within this set of information interchange functions, the Technical Committee focused on those essential in support of the “breakthrough.”

– Focused on context (information model), the content to be exchanged and the information interchange method itself.

– This deferred work on infrastructure, security, workflow and policy issues.


Key Strategies for Standards Selection

Evaluation

The Technical Committee then evaluated all of the remaining standards using the Tier 2 Readiness Criteria.

These criteria are prototypes and as such, are under evaluation. They are designed to document the evaluation process and to show, but not calculate, justification for selecting a standard.

The criteria include ONC preference for use of standards named by the Consolidated Health Informatics (CHI) and other federal initiatives.

Selection

Based on the Tier 2 evaluations, named standards were selected.

It is important to understand that the standards selected here are within the context of the specific Use Case requirements and do not necessarily reflect selection in other contexts.

During the actual construction of Interoperability Specifications, the Technical Committee may need to refine this listing based on detailed analysis.


Biosurveillance Use CaseStandards Selection Overview

Simplification further performed at the Technical Committee

Feasibility to accomplish within the time frame• Relevance• Use in community• Meet requirements for use case

Number of standards by category(1) Context Information Model 17 (2) Information Exchange 46 (3) Terminology 28 (4) Security and Privacy 11 (5) Identifier (Individual and organization) 5 (6) Functionality and Process (workflow) 0 (7) Other 0107 Total does not equal the 92 total standards since some standards meet more

than one category, e.g. DICOM meets 5 categories


Number of standards by organization

14 IETF

11 OASIS

10 HL7

6 ASTM, ASC X12

5 DICOM

4 ISO, CMS

3 W3C, NIST

2 FDA, ANSI/ADA

1 16 organizations (VA, Sabacare, Regenstrief, NLM, NCI, ITU, IEEE, ICH, FDA/NCPDP, CDISC, CDC Biosense, CDC & States, CDC, Snomed, California Health Foundation, AMA)

Biosurveillance Use CaseStandards Selection Overview- Cont.


Building Blocks (Integration Profiles <IP>)• Components of use cases that are reusable

• Overlaps among the HITSP TCs potentially other efforts (e.g., IHE)

• Common vocabulary – hierarchies of standardization and functional requirements are identified in the building blocks as they relate to use cases

Biosurveillance- Building Blocks Overview


Patient Encounter(Lab, EMR)

Shared Document Resource(IP54) IHE-XDS

(Document Consumers:Public Health Systems/

Case Workers)XDS-Stored Query

Shared Document Resource (IP54) IHE-XDS

(Document Source)

Digitally Sign Documents

(Machine signature only)(IP4) IHE-DSG

Surveillance Document-based Data Submission

Laboratory Report Document(IP53)

IHE-Lab Report Doc Collect and Communicate Audit TrailProvide Node Authentication &

secured communication channel(IP2, IP25) IHE-ATNA

Add authorization vocabulary for log

Verify Patient Consent,

Authorizations, Advance Directives (IP15) IHE BPPC

(for reportable conditions, for policy override for PH Disclosure)

Maintain Consistent Time

across enterprises(IP22) IHE-CT

Verify authenticity of

transmission contents (IP46)

Encounter

Report Document (IP52) IHE-Medical Summary

Existing Work

Current Effort

Derivative of Current

New Work

Retrieve Form for Data Capture(IP39) IHE-RFDEvaluate ORM

(Optional)

Anonymize and PseudonymizeData (IP19) (Including managing free text)

Recipient inverse capability

Manage Provider CredentialsMachine only

(IP26)

Radiology Report Document(IP49)

IHE-Lab Report Doc


Patient Encounter(Lab, EMR)

Communicate Message-based

Encounter Summaries (IP42)(Includes wrapping – e.g. ebXML)

Surveillance Message-Based Data Submission

Digitally Sign Documents (suggest content)

(Machine Signature Only)

(IP4) IHE-DSG

Collect and Communicate

Audit Trail (IP2)

Identify Communication

Recipients (IP43)

Maintain Consistent Time

across enterprises(IP22) IHE-CT


Laboratory/Radiology Results (IP44)(Includes wrapping – e.g. ebXML)

Verify authenticity of

transmission contents (IP46)

Manage Provider CredentialsMachine only

(IP26)Retrieve Form for Data Capture(IP39) IHE-RFDEvaluate ORM

(Optional)

Public Health System:Secure point-to-point

messaging

(IP51) IHE-XDP(Document Recipient)

Secure point-to-point messaging

(IP51) IHE-XDP(Document Source)

Existing Work

Current Effort


New WorkVerify Patient Consent,

Authorizations, Advance Directives (IP15) IHE BPPC

(for reportable conditions, for policy override for PH Disclosure)

Anonymize and PseudonymizeData (IP19) (Including managing free text)

Recipient inverse capability


Laboratory/Radiology Orders (IP58)(Includes wrapping – e.g. ebXML)


ResourceSystem

Public Health System:Secure point-to-point

messaging

(IP51) IHE-XDP(Document Recipient)

Biosurveillance-Resource Management Document Transfer

Share Resource Information across enterprises

(IP55)

Secure point-to-point messaging

(IP51) IHE-XDP(Document Source)

Existing Work

Current Effort


New Work


Biosurveillance – Building Blocks Mapped to Events


Biosurveillance – Sample Tier 2 Analysis Process - IP55


Biosurveillance – Sample Tier 2 Analysis Process – IP39


Summary:1. Standard selection task completed based on building blocks – reusable components2. Implementation Guides were included for reference as experience from team

membership3. Many of the standards remain in scope until interoperability specification process to

determine field data mapping requirements4. Many hooks (security) deferred from the spreadsheet – will need further evaluation5. Efforts completed to date will inform further work6. Individual building blocks are not independent with respect to standard selection. 7. Pallets of standards to manage interdependencies among the building blocks and avoid

inconsistencies in completion of full use case workflow

Biosurveillance- Summary


Consumer Empowerment Standards Selection Overview – Table format

Name Event/Action Code

SDO Name Category Remarks

ASTM Patient ID 2.2.2.3, 2.2.3.3, 2.3.1.2, 2.3.2.1+, 2.3.3.3, 2.4.1.1, 2.4.1.4

ASTM 5 Underlying identifier def within ASTM CCR

ATNA (Audit Trail and Node Authentication)

2.1.4.3, 2.2.2.3, 2.2.2.4, 2.2.3.3, 2.3.1.2, 2.3.2.1+, 2.3.3.3, 2.4.1.1, 2.4.1.4

IHE 2

Core Phase 1 Rules (Eligibility & Benefits)

2.1.2.2, 2.1.4.2, 2.1.4.3, 2.1.5.2, 2.1.5.3, 2.1.5.5, 2.1.6.2a, 2.2.2.3, 2.2.2.4, 2.2.2.5, 2.2.3.3, 2.2.4.3a, 2.4.1.4

CAQH 1, 2, 3

ebXML 2.1.2.2 OASIS 2 Included in IHE XDS

HCPCS (Billing Codes) 2.1.4.3, 2.2.2.3, 2.2.3.3, 2.3.2.1+, 2.4.1.1, 2.4.1.4

CMS 3 Included in CORE Phase 1 Rules as well

HL7 2.x - OMP, RDS, RDE & ORM

2.1.4.3, 2.2.2.3, 2.2.2.4, 2.2.3.3, 2.3.1.2, 2.3.2.1+, 2.3.3.3, 2.4.1.1, 2.4.1.4

HL7 3 Included in HL7 v2.x

Category Descriptions

1 – Context (Information Model)

2 – Information Interchange

3 – Terminology

4 – Security and Privacy

5 – Identifier (Individual and Organization)

6 – Functionality, Process, & Workflow

7 - Other

Table extract

References back to Use Case

Consistent with Tier 2 Criteria, the term “standard” in SDO refers, but is not limited to:

• Specifications • Implementation Guides • Code Sets • Terminologies • Integration Profiles


N am e S D O N am e

C ategory R em arks

A S N .1 (A bstract S yntax N otation O ne) IS O 1 U nderly ing content def to m essaging S tandards

A S TM 2369 (C C R ) A S TM 1, 2, 3

A S TM P atient ID A S TM 5 U nderly ing identifier de f w ith in A S TM C C R

A TN A (A ud it T ra il and N ode A uthentication) IH E 2

C ore P hase 1 R ules (E ligib ility & B enefits ) C A Q H 1, 2, 3

ebX M L O A SIS 2 Inc luded in IH E X DS

H C P C S (B illing C odes ) C M S 3 Inc luded in C O R E P hase 1 R u les as w e ll

H L7 2.x - O M P , R D S , R D E & O R M H L7 3 Inc luded in H L7 v2.x

H L7 C D A R el2 H L7 1

H L7 C D A R el2 /C C D H L7 2 N ot yet a ba llo ted s tandard but looks prom is ing to rep lace C R S

H L7 E H R System Functional M odel H L7 6

H L7 R IM H L7 1

H L7 S O A H L7 2 R e lationsh ip to spec ific H L7 m essage s tandards needs clarif ication

H L7 S P L H L7 1 A ntic ipa ted pending legis la tion

H L7 v2.5 H L7 3 Im pl of v2.5 standard w ou ld be a trans itiona l so lution tow ards v3 or C D A

H L7 v2.5 A D R -A 19 P t Q uery R esponse H L7 2 Inc luded in H L7 v2.5

H L7 v2.5 P atient M gm t H L7 2 , 3 Inc luded in IH E P D Q & IH E PIX

H L7 v2.5 P ID H L7 5 U nderly ing identifier de f w ith in H L7 v2.5

H L7 v2.5 Q RY -A 19 P t Q uery H L7 2 Inc luded in H L7 v2.5

H L7 v2.5 R egis ter a P atien t (A 04) H L7 1 , 2

H L7 v2.5 U pdate P atien t In form ation (A 08) H L7 2 Inc luded in H L7 v2.5

H L7 v2.x (pre v2.5) H L7 3 S tandard in w ide-spread use but w ould be trans itional on ly

Consumer Empowerment Use CaseStandards Selection Table-part 1


Name SDO Name

Category Remarks

HL7 v3 PatientLivingSubject Info Revised (PRPA_IN201101UV01) HL7 2 Relationship to specific HL7 message standards needs clarification

Hl7 v3.0 HL7 3 Anticipated pending legislation for specific HL7 v3 standards

HL7 v3.0 Patient Demographic message QUPA_ IN/RM201203 HL7 1, 2 Included in HL7 v3.0

HL7 v3.0 Person ID HL7 5 Underlying identifier def within HL7 v3.0

HL7 v3.0 Person Mgmt HL7 2, 3 To be Included in IHE PDQ & IHE PIX

HL7 v3.0 QUPA MT201201 Query Pt Reg by Identifier HL7 1 Included in HL7 v3.0

HL7 v3.0 QUPA_ IN201201 Get Pt Demogr Query HL7 2 Included in HL7 v3.0

HL7 v3.0 QUPA_ IN201202 Get Pt Demographic Query Response HL7 2 Included in HL7 v3.0

HL7 v3.0 QUPA_ MT201203 Pt Demographic Message HL7 2 Included in HL7 v3.0

HL7 v3.0 QUPA_ RM201201 Pt Demographic HL7 1 Included in HL7 v3.0

HTTP - Hyper-Text Transfer Protocol W3C 2

IHE CT IHE 2

IHE MS (Included Strct HL7 med list)- CDA Rel2/CRS IHE 2, 3

IHE PDQ IHE 2, 3 Based on HL7 v2.5; support for v3.0 in progress

IHE PIX IHE 2, 3 Based on HL7 v2.5; support for v3.0 in progress

IHE XDS IHE 2, 3 Relevant if shared registry architecture assumed

IP Security (IPSec) IETF 2

National Provider Identifier (NPI) CMS 2, 3

NCPDP Script 8.1 (ePrescribing Included Med History) NCPDP 1, 2, 3




Name SDO Name

Category Remarks

NCPDP Telecom (Claims Processing & Eligibility) NCPDP 2 Needs to be x-mapped to X12N content

NCPDP-HL7 Electronic Prescribing Coordination Mapping Document; NCPDP/HL7 3 Required to assist in dual standard use in industry until harmonized

NDC (National Drug Codes) FDA 3 Included in CHI-named Med Terminology

NDF-RT (VA National Drug File Reference Terminology) VA 3 Included in CHI-named Med Terminology

RBAC Models OASIS 1

RFC 1510 Kerberos IETF 2

RFC 3164 (Syslog) IETF 2

RFC 3195 (Reliable Syslog) IETF 2

RFC 958 IETF 2

RLS (Record Location Services) Connecting for Health

2 Relevant if shared registry architecture assumed

Rx Norm NLM 3 Semantic Clinical Name of Med. Included in CHI-named Med Terminology

SAML (Security Assertion Markup Language) OASIS/Liberty Alliance

2

SDTM (Study Data Tabulation Model) CDISC 2 Currently not viewed as relevant to CEUC at this time

SMTP (Simple Mail Transfer Protocol) IETF 2

SP 800-63 NIST 2

UNII (Unique Ingredient Identifier) FDA 3 Included in CHI-named Med Terminology

Workflow Tech Standards in RBAC NIST 6

X12 834 Enrollment Transaction ASC X12 1, 2

X12N Eligibility Transaction (270/271) ASC X12 1, 2, 3 Included in CORE Phase 1 Rules

XACML RBAC Profile OASIS 1


Consumer Empowerment Use CaseTier 2 Criteria


Consumer Empowerment Use CaseBuilding Blocks: Organizing the Interoperability Specification development

Looking forward to creating Interoperability Specifications, the Building Block concept, although not necessarily any of the current constructs, will be used to create reusable modules of interoperability that support the overall Use Case requirements.

The Building Blocks will occupy a middle tier between the overall HITSP Interoperability Specification addressing a specific Use Case and underlying sets of standards.

These Building Blocks once refined and normalized, guide implementation of a discrete set of confined standards, and themselves become interoperability specifications to be tested and maintained.

Such Building Blocks then become available for reuse or modification by future Interoperability Specifications focused at other use cases.


Consumer Empowerment Use CaseBuilding Blocks – Initial analysis

Personal Health Record Content

[IPzz – m ay be outside scope of interoperability]

Consumer ID X-ref[IP8]

Use Case Scenario 2: Consum er visits Health Care Provider and provides registration sum m ary inform ation

M anage PHR Account and Perm issions

[IPxx]

Registration Sum mary Content

[IPyy]Point-to point Objects Interchange (Media or

Secure Em ail)[IP51]

or

Logging, Authentication and Infrastructure are not reflected in this diagram

M anage Sharing of Documents

[IP54 (f PHR)]

M anage and controldata access & verify consents

[IP10, IP15]

Current Effort


New W ork

M appingam ongalternativeform ats

M erge Registration Sum m ary into EM R

[IP outside scope of UC]

1.

2.3a.

3b.

4.

5.

6.

M appingam ongalternativeform ats


Electronic Health Record Standards Selection Overview

Building Block Process

Building blocks were useful to help identify suites or palates of standards that work well together. Initially, building blocks were drafted separately by each TC; later, standards in similar building blocks were aggregated across TCs. As a result, only a subset of standards named within a building block may apply to a particular use case scenario. Functional block diagrams were created in an increasingly consistent fashion by all TCs. The functional steps comprise one or more building blocks; they helped identify standards that work well together to accomplish use case scenarios

Implementation Guides and Profiles

Implementation guides and profiles (e.g., CHCF ELINCS, IHE PIX, etc.) were used to define building blocks, and to identify and select standards. These were not selected as standards per se, but appropriate sections of them may be chosen or incorporatedsubsequently in implementation guidance relevant to the selected standards.

Standards Selection Process

In previous work, a superset of candidate standards was determined. In selecting the standards from these, building blocks and functional step grouping together were useful to identify sets of standards that work well together. Selections also were based on Tier 2 criteria including relevance, adoption, and meeting use case requirements.

Current Status of Standards Selection: selections are in partially complete and further analysis is required as indicated by “TBD” in the following summary.


Electronic Health Record Standards Selection Tier 2 Rating Criteria – Example


Electronic Health Record Standards Selection –Table Example, Linking Standards To Use Case

Category Descriptions

1 – Context (Information Model)

2 – Information Interchange

3 – Terminology

4 – Security and Privacy

5 – Identifier (Individual and Organization)

6 – Functionality, Process, & Workflow

7 - Other

Table extract:

References back to Use Case

Consistent with Tier 2 Criteria, the term “standard” in SDO refers, but is not limited to:

• Specifications • Implementation Guides • Code Sets • Terminologies • Integration Profiles

Name Event/Action Code

SDO Name Category Remarks

ANSI/ADA 1000 3.2.4.3, 3.3.1.1, 3.4.1.5, 3.4.3.4

ANSI/ADA 5

ANSI/ADA 1039 3.2.4.3, 3.3.1.1, 3.4.1.5, 3.4.3.4

ANSI/ADA 5

ASTM 2436-05 3.2.3.2 ASTM Provisional. Further analysis required

ASTM E1239–04 3.1.1.1, 3.2.1.1a, 3.2.3.2, 3.2.3.2b, 3.2.4.5, 3.4.2.2, 3.5.1.1, 3.5.2.2

ASTM 3 Provisional. Further analysis required


Electronic Health Record Use Case Scenario 1Functional Steps And Building Blocks Overview

1 (IP57)

2a (IP18)

4 (IP23,IP47)

3a (IP15,IP44,IP47)

3b (IP15,IP44,IP47)

3c (IP15,IP54,IP47)

2b (IP8)

1. Identify the lab result terminology

2a Call terminology service

2b. Patient ID Cross referencing

2bc Structure result as lab report document

3a. Send results message to ordering clinician

3b. Send results message to other authorized providers

3c. Send document to repository, store, and register in data locator service

4. Notification of lab report availability

5. Send report to authorized providers of care

**Logging, Authentication, Infrastructure are all out of scope for this diagram

Use Case Scenario #1: (Providing new lab results to ordering clinician, other authorized providers and data repositories)

2bc (IP53)

5 (IP54,IP47)


Electronic Health Record Use Case Scenario 2Functional Steps And Building Blocks Overview

3c (IP15,IP54,IP47)

4 (IP23, IP47)

6b (IP54, IP47)

8 (IP53)

7 (No IP for interoperability)

6a (IP54, IP47)

Use Case Scenario #2: Query Repository for Retrieval of Historical Lab Results

3c. Send document to repository, store, and register in data locator service

4. Notification of lab report availability

6a. Query data locator service for lab results location and retrieve from repository

6b. Query repository and retrieve lab report directly from repository

7. Merge lab results into EHR

8. View lab results from a web application


Electronic Health Record Standards Selection Functional Step 1:Identify Lab Result Terminology

IP 57Define Lab Terminology

Selected Standards:SNOMED CT, Laboratory LOINC

Provisional Selections Requiring Further Analysis:CPT, HCPCS, ICD-9-CM, CDISC SDS, TBD (TBD indicates further analysis still in process)


Electronic Health Record Standards Selection Functional Step 2a:Call Terminology Service

IP 18Terminology Service

Selected Standards:HL7 CTS

Provisional Selections Requiring Further Analysis:HL7 CTS II


Electronic Health Record Standards Selection Functional Step 3a:Send Lab Result Message To Ordering Clinician

IP 15, 44, 47Verify Patient Consent Authorizations and Advance DirectivesCommunicate Message-Based Lab ResultsAcknowledge Receipt of Clinical Data

Selected Standards:HL7 v2.5 Chapters 2, 3, and 5HL7 v2.5 Lab MessageHL7 ACK

Provisional Selections Requiring Further Analysis:HL7 v2.6 Lab Message, CDISC SDS, CDISC ODM, TBD


Electronic Health Record Standards Selection Functional Step 2b:Patient ID Cross-Referencing

IP 8Uniquely Identify Patient Across Enterprises

Selected Standards:HL7 v2.5 Patient Management, HL7 v3 Person Management, OMG PIDS

Provisional Selections Requiring Further Analysis:TBD


Electronic Health Record Standards Selection Functional Step 3b:Send Lab Results Message To Other Authorized Providers Of Care

IP 15, 44, 47Verify Patient Consent Authorizations and Advance DirectivesCommunicate Message-Based Lab ResultsAcknowledge Receipt of Clinical Data

Selected Standards:HL7 v2.5 Chapters 2, 3, and 5HL7 v2.5 Lab MessageHL7 ACK

Provisional Selections Requiring Further Analysis:HL7 v2.6 Lab Message, CDISC SDS, CDISC ODM, TBD


Electronic Health Record Standards Selection Functional Step 2bc:Structure Lab Result As Lab Report Document

IP 53Laboratory Report Document

Selected Standards:HL7 v3 CDAr2



Electronic Health Record Standards Selection Functional Step 3c:Send Lab Result Document To Data Repository, Store Document, and Register Lab Result Document In Data Locator Service

IP 15, 47, 54Verify Patient Consent Authorizations and Advance DirectivesAcknowledge Receipt of Clinical DataManage Document Sharing (Shared Document Resource)

Selected Standards:HL7 v2.5 Chapters 2, 3, and 5HL7 CDAr2HL7 CDA Lab DocumentHL7 ACK



Electronic Health Record Standards Selection Functional Step 4:Notification Of Lab Report Document Availability

IP 23, 47Publish Information and Notifications, and Subscribe to TopicsAcknowledge Receipt of Clinical Data

Selected Standards:OMG Data Distribution Service DDS, HL7 ACK

Provisional Selections Requiring Further Analysis:IETF ATOM, TBD


Electronic Health Record Standards Selection Functional Step 5:Send Lab Report Document To Authorized Providers Of Care

IP 47, 54Acknowledge Receipt of Clinical DataManage Document Sharing (Shared Document Resource)

Selected Standards:HL7 ACK,HL7 CDAr2HL7 CDA Lab Document



Electronic Health Record Standards Selection Functional Step 6a:Query Data Locator Service For Lab Results And Retrieve Results From Data Repository



Provisional Selections Requiring Further Analysis:Several TBD


Electronic Health Record Standards Selection Functional Step 6b:Query Data Repository And Retrieve Lab Result Directly From Data Repository





Electronic Health Record Standards Selection Functional Step 7:Merge Lab Results Into EHR For Use In Clinical Care





Electronic Health Record Standards Selection Functional Step 8:View Lab Results From A Web Application (Without EHR) For Use In Clinical Care

IP 53Laboratory Report Document

Selected Standards:HL7 CDAr2HL7 CDA Lab Document



Electronic Health Record Standards Selection Summary

• Standard selections are based on Tier 2 criteria, applied to individual standards from building blocks grouped in a functional step analysis, in the context of the use case

• Implementation Guides and Profiles were used to inform the selection of standards and may be included in subsequent implementation specifications

• Many standards remain in scope pending further analysis• Efforts completed to date will inform further work• Individual building blocks are not independent with respect to

standard selection, for some functional steps


HITSP Comments Process Overview

Feedback form was modified and distributed to HITSP members along with the Standards Selection documents for a 5 business day comment period per the HITSP Charter

Comments were submitted to [email protected]

Comments were consolidated by a single point of contact, and forwarded to the appropriate group – Technical Committee, project team, or ONC - for disposition

88 comments received as of 9:00PM June 13 (comment window now closed)

Comments related to Standards Selection will be addressed by the Technical Committees

Comments related to the Use Cases and/or policy will be forwarded to ONC

Comments related to the process will be addressed by the HITSP Project Team

http://[email protected]/


Next Steps

May 31 – June 6 Use the Tier 2 Standards Harmonization Readiness Criteria and work with industry and government stakeholders to develop draft lists of selected standards for each Use Case.

June 6 Publish the draft lists of selected standards for HITSP review and comment.

June 6 – June 13 Vet the draft lists of selected standards with stakeholders and refine as appropriate; garner commitments from industry as appropriate.

June 14 Present the draft lists of selected standards at the HITSP June 14th

session for review and approval.

June 15 – June 26 Refine and revise the draft lists of selected standards based onconditions of approval.

June 26 – June 29 Prepare final lists of selected standards for publication.

June 29 Submit Final Selected Standards to ONC.

September 29 Submit Final Interoperability Specifications to ONC

Standards Harmonization Technical Committees Update documents/Standards... · Evaluation The...

Documents

Transcript of Standards Harmonization Technical Committees Update documents/Standards... · Evaluation The...