Standards Harmonization Technical Committees Update documents/Standards... · Anonymize data...

Arlington, VAMay 4, 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 71Date: May 3, 2006

1Healthcare Information Technology Standards PanelHealthcare Information Technology Standards Panel

Table of Contents

Introduction

Standards Gap and Overlap Process Overview

HITSP Technical Committees Overview

Pool of Standards Required By The Use Case

Categories of Standards

Standards Gap and Overlap Analysis - By Technical Committee

Pool of Standards By Use Case

Assumptions Made In Creating The Pool Of Standards

Duplications and Overlaps In Standards

Identified Gaps In Standards

HITSP Comments

Next Steps


Introduction

The Biosurveillance, Consumer Empowerment and Electronic Health Record Technical Committees were charged with identifying and analyzing gaps and duplications within the standards industry as they relate to the events in their Use Case. Specifically, each Technical Committee has:

Prepared interoperability requirements based on the Use Case.

Created a Pool of Standards, including assumptions, that could meet the Use Case requirements

Provided a description of all duplications and overlaps among standards for the Use Case

Provided a description of the gaps, including missing or incomplete standards

Considered alternatives for resolving the gaps


Standards Gap and Overlap AnalysisProcess Overview

The work of the Technical Committees is initiated by the HITSP, informed by the work of the American Health Information Community (The Community), and has the oversight and backing of the Office of the National Health Information Technology Coordinator (ONC). The Community selected breakthrough areas to be worked across ONC contracts. The HITSP chartered Technical Committees to address three of the four break through areas. Harmonized Use Cases were received from ONC and the following tools were used to perform the Standards Gap and Overlap Analysis process over the past 6 weeks.

Conference calls

Face to Face meetings

SharePoint portal for document sharing

Enterprise Architect modeling tool

NetSpoke collaborative Web-based tool


HITSP Technical Committees Overview

•Biosurveillance

•63 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

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

Soloman I. Appavu, John H. Stroger Cook County Hospital -PresenterElaine A. Blechman PhD, Professor,

Univ. of Colorado-BoulderCharles Parisot, EHR Vendor

Association

•Electronic Health Record

•77 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


The Pool of Standards Required By The Use Case

The standards required to support each major Use Case event were organized within an agreed upon standards taxonomy. The definition and several examples of each category in the taxonomy are provided on the following slides. The standards selected for inclusion in the pool were examined using ‘HITSP approved’ Tier 1 Harmonization Readiness Criteria.



Category Description Example standards & specific elementsHL7 v3 Patient demographics

NCPDP Script

Those standards that regulate context by defining the relationship between data elements, and facilitate standardized data representation.

Those standards that define and facilitate communication between systems usually within well-defined domains. These standards regulate the messages and documents, including their format and interaction, sent between systems.

Those standards that enable the consistent definition of entities and attributes, usually with a specific domain, and therefore facilitate standardization of data representation. These standards include code sets, vocabularies, terminologies and nomenclatures.

Those standards that facilitate uniform protection of electronically maintained and transmitted healthcare information; and in addition ensure that healthcare information is used only by those authorized to do so.

ASTM E1239-04

ebXML

HL7 v2.5 Register a patient

X12N – 270/271

IHE XDS

ICD, CPT

SNOMED

LOINC

RxNorm

TLS

HTTPS

OASIS/WSS

SAML

Security & Privacy

Terminology

Information Interchange

Information Model


Category Description Example standards & specific elements

Those standards that facilitate the unique identification of individuals, providers and healthcare centers, etc.

Those standards that define how orders and results are processed, and provide feedback, in addition they relate to system states and transitions

Related policies/regulations

FEIN

HIPAA National Provider Identifier

Payor Identifier

ISO/IEC 24760

Functionality and Process Workflow

Clinical Guidelines

Other Standards HIPAA

Identifier (Individual and Organizational)



Biosurveillance Use CaseGap and Overlap Analysis Overview

The use case addressed in this document is for the transmission of essential data from:

ambulatory care visits

emergency department visits

resource utilization

lab result data

from electronically enabled healthcare delivery and public health systems in a standardized and anonymized format, to authorized Public Health Agencies with less than one day lag time.


Biosurveillance Use CaseGap and Overlap Analysis Overview

The system and processes must also support the ability for authorized public health personnel to go back to the data source to seek to re-link the anonymized biosurveillance data to the data source as part of an appropriate public health investigation by enabling:

The management of data to ensure proper routing, security, privacy and timely reporting

Potential architectural solutions to data flow issues

Other permutations of the previous two models


Pool of Standards for the Biosurveillance Use CaseTimeline and Approach -

Feb 21-23 TC Meeting and Subsequent TCONs:

Started with the HITSP Biosurveillance Use Case

Established Task Groups to focus on standards for each data source

Identified >570 standards (master list) covering:7 categories of standards (Context, Terminology, Information Exchange, Security, Identifiers, Workflow/Functionality, Other – not used)SDOs (Health Informatics, Non-Health Informatics)Profiling Organizations (Health Informatics, Non-Health Informatics)

Reviewed informally with SDO members (e.g. DICOM, IHE, IEEE), ongoing

March 19

Harmonized Use Case was received from ONC


Pool of Standards for the Biosurveillance Use Case

March 28-30 TC Meeting and Subsequent TCONs

Selected >250 standards from the master list based upon the reduced harmonized use case scope.

April 17-19 TC Meeting and Subsequent TCONs

Identified common building blocks and associated standards across the 3 HITSP Use Cases

Reduced the standards pool to 180:– Removed standards referenced by the common building blocks– Removed engineering standards already referenced in selected health informatics

standards

April 26 Deliverable to HITSP

Standards Gap and Overlap Analysis Document



Context/Information Model: – Need clarification on ‘essential data’ data dictionary to finalize the standards

pool– The standards pool remains primarily as in the master list pending clarification of

the data dictionary

Information Exchange: – The standards pool was reduced, but remains broad to accommodate local

communication capabilities (e.g. X12 for military, HL7 hospitals, etc.)

Terminology: – Core (e.g. SNOMED-CT, LOINC, ICD9-CM, CPT, NDF-RT / RxNorm, etc.)– Infrastructure (e.g. NIST GPS, FIPS, OWL, etc.)– Standards relevant to filtering criteria (e.g. GEM, GELLO, Arden, Prodigy, etc.)



Security: – Engineering (e.g. IETF, OASIS, ITU, WS0, ETSI, ECMA, etc.) – Health Informatics (e.g. ASTM E31.20, ISO TC215, IHE, DICOM, etc. )

Identifier: – Clinical Laboratory Improvement Amendments (CLIA) number – HIPAA National Provider Identifier (NPI)– Specifications/guides (e.g. DICOM, ISO TC215, ADA, ASTM E31, ISO/IEC, etc.)

Functionality/Workflow: – Biosurveillance Processes (e.g. Common Alerting Protocol (CAP), Health Alert

Network (HAN), National Notifiable Disease Surveillance System (NNDSS), etc.)– Health Informatics (e.g. IHE, HL7/OMG, ISO TC215, etc.)


Assumptions Made in Creating the Pool of Standards BiosurveillanceEventCode

Event Description

Major Assumptions

1.1.1.0

1.2.1.0

Filter existing data to identify data required by public health agencies

Security/communications policies between institutions are established using established standards for trust management, risk assessment and cross-jurisdiction information exchange.

Standards will differ by data source (Lab, Visit, Resource Utilization (Utilization))Machine-generated Radiology Results are included in data requirements for Lab

Results

1.1.2.0

1.2.2.0

Anonymize data required by public health agencies

Re-identification as needed is authorized for public health authorities

1.1.3.0

1.2.3.0

Format (transform) data required by public health agencies

Visit data is likely to be supplied through the admitting/registration systemTransformation includes formatting data into a message and content mappingStandards will differ by data source (Lab, Visit, Utilization)Machine-generated Radiology Results are included in data requirements for Lab

Results HL7 V2.6 will proceed to normative work in time to support this initiative


Assumptions Made in Creating the Pool of Standards Biosurveillance

EventCode

Event Description

Major Assumptions

1.1.5.0

1.2.5.0

Transmit relevant data topublic health agencies

Standards will differ by data source (Lab, Visit, Utilization)Machine-generated Radiology Results are included in data requirements

for Lab ResultsHL7 V2.6 will proceed to normative work in time to support this initiative.

1.3.2.0 Receive Biosurveillancedata

A separate response is sent from the BIS to the originating source indicating that a person or automated process has reviewed the data. This is more than an application acknowledgment that the data was received.

Architecture of Biosurveillance Information System (BIS) will in part dictate the security and access


Duplications and Overlaps in Standards - Biosurveillance

Event Code

Event Description

Standard Duplication/ Overlap Recommended Resolution

1.1.3.0

1.2.3.0

Format data required by public health agencies

1. Utilization- Information Exchange - Bed availability

HL7 V2.x:4 candidate messagespotential overlap: OASIS HAVE

2. Lab – Information Exchange – Lab Results Message: DICOM/HL7

3. Lab – Terminology -Specimen Site, Presumptive DX: HL7/SNOMED/ICD9/ICD10

4. Visit - Information Exchange – visit data messages: Potential Overlap HL7/X12

5. Lab, Visit, Utilization – Context – Possible overlap for information models: ASTM/HL7/DICOM/ADA/ISO etc.

1. Work with HL7 to assess recommendations for bed/resource availability. • address at the next meeting of HL7• name a liaison to carry the issue• Compare to OASIS HAVE

2. DICOM/HL7 selection criteria • for human analysis: HL7 Order Result • for machine analysis: DICOM

3. Review and assess relevant work to express Specimen Site and Presumptive DX

4. Work with SDOs to harmonize standards (e.g. translation mapping)

5. Identify the appropriate information model



Event Code/ EventDescription

Standard Duplication/ Overlap Recommended Resolution

General: Security

1.Multiple security standards identified do not represent overlapping standards in security. These standards and profiles may vary based upon architecture. ASTM E2085 and E2086 provide guidance for selection of engineering standards, but does not include guidance on newer technologies.

2.Possible overlap: ASTM E1985 with ANSI/INCITS 359

1.Review and update ASTM E2085 and E2086 to include guidance for new WS, ISO, and engineering standards.

2.Review and harmonize



Resolving Duplications and Overlaps -

When overlap is within the standard:– work with SDO to resolve internal issue (e.g. HL7 bed availability)

When overlap is across standards:– work with affected SDOs through joint meetings (e.g. SNOMED/LOINC)– translation mapping for data standards (e.g. CCR/CDA-2)– request SDOs to jointly conduct harmonization (e.g. SNOMED/LOINC)– Apply evaluation criteria (e.g. current use, ease of implementation for use

case, etc) to select standards for interoperability specification until harmonization between identified overlapping standards is complete

– Once harmonization is complete, update the interoperability specification accordingly


Identified Gaps in Standards - Biosurveillance

Event Code

Event Description Identified Gap in Standards

1.1.1.0

1.2.1.0

Filter existing data to identify data required by public health agencies

•Lab – Terminology –• Orders/Results (Test Batteries) • Possible Gap: Lab – indication /presumptive diagnosis/ reason for test

•Lab, Visit, Utilization - Functionality/ workflow/ process - Filtering process

1.1.2.0

1.2.2.0

Anonymize data required by public health agencies

•Lab, Visit, Utilization - Functionality/ workflow/ process – Need method for abstracting important concepts from free text records to effect anonymization

1.1.3.0

1.2.3.0

1.2.5.0

Format data required by public health agencies, Transmit relevant data to public health agencies

•Lab –Terminology - need granular ontology of body sites•Lab - Functionality /workflow/ process - need definition of data set to send to BIS•Lab, Visit, Utilization - Context – accurate information model for visit data•Lab, Visit, Utilization - Functionality/ workflow/ process -

• transformation, mapping of local/custom codes• to whom to send data



Event Code

Event Description

Identified Gap in Standards

1.3.1.0 Provide listing of required biosurveillance data

•Lab, Visit, Utilization –• Context - need definition of data set to send to BIS• Functionality /workflow/ process - need definition of data set to send to BIS• Information Exchange & Functionality/process/workflow - communication protocols; This is a paper/human process today

1.3.2.0 Receive biosurveillance data

•Lab, Visit, Utilization - Functionality/process/workflow – need consistency in the level of Acknowledgement (ACK)



Resolving Gaps: Work with SDO/Profiling Organizations -

When relevant current work is identified:– Establish Technical Committee (TC) Liaison to monitor, inform, and

participate in the development process to assure that the work fills the gap

When relevant pending work is identified:– Work with organization to request acceleration– Establish TC Liaison to inform and contribute to the new standard/profile

development process to assure that the work is established to fill the gap– Adjust the Biosurveillance Interoperability Specification roadmap to

accommodate estimated timeline for completion of pending work



Resolving Gaps: Work with SDO/Profiling Organizations -

When no current/pending efforts are identified:– Work with organization(s) to request new standard/profile– Establish TC Liaison to inform, and contribute to the new standard/profile

development process to assure that the work is established to fill the gap – Adjust the Biosurveillance Interoperability Specification roadmap to

accommodate estimated timeline for completion of pending work

When multiple organizations have current/pending work:– Request joint development and concurrent harmonization to assure that the work

is filling the gap and not introducing duplications– Establish TC Liaison with each affected organization to inform, harmonize, and

contribute to the concurrent development process to assure that the work fills the gap without introducing duplications

– Adjust the Biosurveillance Interoperability Specification roadmap to accommodate estimated timeline for completion of pending work


Biosurveillance Technical Committee - Summary

Pool of standards identified can support near-term implementation

Semantically interoperable data in mid/long-term will improve:– decision support– event detection– process efficiency

BIS must interoperate with existing systems (e.g. RHIOs, EMRs)

The Biosurveillance Use Case and associated pool of standards can be extended to address other use cases, e.g.:– case identification and management– pharmacovigilance– clinical trials– quality processes and quality measures

International standards must be considered as disease/pandemic episodes are not bound by national borders


HITSP Comments

The title of this Use Case should be “Population Health”. The term “Biosurveillance” is unduly alarmist and misleading. Prior to 9/11 2001 military health professionals had been discussing this subject for years during the cold war when the threats were arguably more real in terms of public health activities and data. A proposed global Process Model for healthcare uses the proposed new term which would be much more relevant to the subject matter developed than the present term and would be much better appreciated by the public. The new title would be much more quickly understood by the intended health professional discipline participants in the HITSP as well as AHIC.


HITSP Comments

Under the section on inclusions, #1 should specifically include that data captured during patient care by EMS “first responders”. This data has been clearly noted as part of the EHR (the primary source of data for population health and “public health” agencies) in existing EHR standards (ASTM E-1384, E-1744) addressing the Basic Care Scenario. This emergency care data was originally identified with respect to combat casualty care 30 yrs ago and was subsequently related to the conventions that arose in the civilian sector for “EMS Care”. A careful distinction (that is only presently implied) should be made relating to Resource Management data (e.g. Run Reports) in both the inclusion and exclusion paragraphs of this section. Inclusion #1 should be expanded to help make this clear. Specifically, this section should emphasize that the EHR Structure and Content (including associated value sets and terminologies used in the Patient Care functions being addressed by the EHR Use Case) are THE source of the reportable Population Health Data used in this Use Case. Thus, there is very close linkage and an essential need for consistency between these two use cases. There is also an essential link with the “Personal Health Record” of the “Consumer Empowerment”Use Case since it too receives captured data from the EHR but also includes uncontrolled direct patient-entered data. These statements will explicitly link the AHIC Use Cases to the coordinated work of the ANSI HITSP Technical Committees so that they maintain close and effective coordination on both the implications of the Conceptual Content and the approaches to its implementation within the technical infrastructure.


Consumer Empowerment Use CaseGap and Overlap Analysis Overview

Consumer Empowerment: 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. The Consumer Empowerment Use Case represents four unique perspectives: 1) Consumer, 2) Provider of Personal Health Record (PHR) Services, 3) Health Care Provider and 4) Data or Network System.

It also provides three (3) flow scenarios which describe the interactions between each of these perspectives:

Consumer creates account to host registration summary and medication history

Consumer visits Health Care Provider and provides registration summary information

Authorized Health Care Provider reviews medication history.


Pool of Standards Required for Consumer Empowerment

Used the “building block” approach to help identify common functions across Use Case events & actions

Organized detailed standards into categories which were identified via cross-breakthrough dialogues and shared across by all TC committees (e.g. Information Model, Information Interchange, etc)

Identified standards within each category applicable to each building block and used the BB -to- Use Case events/actions association to complete detailed Pool of Standards table

Common sets of standards listed in individual action “rows” of the table were extracted to a “table header” for simplifying its presentation – although it doesn’t reduce the breadth of standards potentially applicable to a specific event/action

Availability of consumer-related policies, e.g HIPAA, and their association to the implementation of an effective PHR solution is a critical component of realizing the Consumer Empowerment breakthrough


Assumptions Made in Creating the Pool of Standards Consumer Empowerment

Event Code Event Description Major Assumptions

2.1.1.0 Select a provider of PHR services

2.2.1.0 Create Account

2.1.2.0, 2.2.2.0 Establish/Change permissions

“Permissions” are provided to a caregiver’s organization within appropriate constraints (e.g. a doctor and associate practitioner’s nurse, or a covering physician) but not to the level of a specific individual.

2.1.3.0, 2.2.3.0 Log on to system A commonly available authentication mechanism is used at login (may be token or not).

2.1.4.0 View registration and medication data

Registration summary will be patient created by either entering info by the consumer (e.g. allergies) or obtained by the PHR service provider from a provider or a payer. It remains the responsibility of the providers to validate the consistency of this registration summary information with their own information or that of a payer.The PHR will offer a “blind aggregate” but not attempt clinical

reconciliation of information. Consumers and providers will need to assume this responsibility.An MPI and a Data Locator is required for the PHR to operate. If

the PHR system assumes this role, it requires all data sources to inform MPI & data locator of patient identities and data existence.

Authentication of consumer is performed by the PHR service provider according to “policy” set by appropriate authorities. We assumed that other parties that may release data to this PHR

service provider are part of a trusted environment.


Duplications and Overlaps in Standards- Consumer Empowerment

Event Code Event Description Standard Duplication/ Overlap

Recommended Resolution

2.1.4.0 2.1.5.02.2.2.02.2.3.02.2.4.02.3.1.02.3.2.02.3.3.02.4.1.0

View reg/med dataModify reg/med dataGather reg/med dataProcess request for reg/med dataView reg/med dataIntegrate reg data into EHR or otherProcess requested dataProcess request for reg/med data

Medication List may be conveyed in multiple ways:Message in HL7 V2Message in NCPDP/SCRIPTMessage in HL7 V3Persistent Object in CCRPersistent Object in CDA/CRS/IHE-XDS-MSPersistent Object in CDA/CCD

2.1.4.0 2.1.5.02.2.2.02.2.3.02.2.4.02.3.1.02.3.2.02.3.3.02.4.1.0

View reg/med dataModify reg/med dataGather reg/med dataProcess request for reg/med dataView reg/med dataIntegrate reg data into EHR or otherProcess requested dataProcess request for reg/med data

Registration Summary may be conveyed in multiple ways:Message in HL7 V2Message in X12 (270/271/834)Message in HL7 V3Persistent Object in CCRPersistent Object in CDA/CRS/IHE-XDS-MS Persistent Object in CDA/CCD


Duplications and Overlaps in Standards- Consumer Empowerment

Event Code Event Description Standard Duplication/ Overlap

Recommended Resolution

2.1.2.0, 2.2.1.0 Establish/change permissionsCreate account

Establishing / modifying access permissions may be conveyed in multiple ways:ebxml MS RegistryWeb ServicesHTTPMLLB

Almost all events

Many formats are used for the identification of the patient in both the information models and in the information exchange standards:HL7 V3 Patient Demographics; HL7 v2.5 Patient Mgmt; ASTM CCR E2369; X12N; IHE PDQ/PIX


Identified Gaps in Standards- Consumer Empowerment

Event Code

Event Description Identified Gaps Recommended Resolution

2.1.4.0 View Reg/Med data

Consumer oriented terminology for medications with mapping to clinical terminologies.

Identify and assemble ‘topic experts’ from TC members to describe requirement(s) of identified gap in more detail and submit same to HITSP panel for further attention by appropriate SDO WG’s

2.1.x.x, 2.2.x.x

Select Provider of PHR ServicesEstablish/Change permissions

A standard for increasing the consumer awareness and level of understanding of the PHR content is not available.




Event Code


2.1.2.0

2.2.1.0

Establish/Change Permissions

Create account

Permission management standards including role definitions are incomplete standards


2.3.1.0 View Reg/Med data

The federation of User Authentication is only partially covered by the existing standards of :SAML 2.0Liberty Alliance




Event Code


2.3.2.0 Integrate registration data into EHR system

A standardized topic hierarchy for processing acknowledgements of registration/medication updates in a data repository or EHR is not available.



HITSP Comments

Regarding the identified Gap: "Consumer oriented terminology for medications with mapping to clinical terminologies” - a request was received for further clarification as how this gap was identified, where in the use case this gap shows up and a more detailed understanding of what this gap means and implies? [John Kilbourne M.D., Medical Officer, NIH/NLM]

Response:

The gap was identified following open discussion at one/more of the TC meetings

The gap has been associated with Use Case event 2.1.4.0, View Registration / Medication Data

The gap is intended to highlight the absence of a uniform language for the presentation of medication history terminology to the consumer; emphasizing the use of non-clinical terminology, presenting generic and brand-name medications under a common name/group, and otherwise facilitating consumer understanding with regards to the specific medications they have been prescribed


Electronic Health Record Use CaseGap and Overlap Analysis Overview

The information in this document pertains to the EHR (Laboratory Result Reporting) Use Case: This use case will provide the following functionality for laboratory results reporting and notification, and is applicable to many types of laboratory tests, including but not limited to: clinical chemistry, hematology, serology, and microbiology:

Transmission of complete, preliminary, final and updated lab results to the EHR system (local or remote) of the ordering clinician.

Transmission of complete, preliminary, final and updated (or notification) to the EHR system (local or remote) or other clinical data system of designated providers of care (with respect to a specific patient).

Retrieval of historical lab results by providers of care.

Clinician access to test results respects privacy concerns, sensitivity designations or other attributes.

Clinician access to results respects access rules determined by policy (e.g., certain results categorized as sensitive and not normally made available).

Sending and accepting appropriate acknowledgement of receipt for interactions.


Pool of Standards Required for Electronic Health RecordCategories of Shared Standards:- Context (Information Model)

- Information Interchange

- Terminology

- Security

- Identifier (Individual and Organizational)

- Functionality and Process Workflow

Categories of Standards for Lab Reports and Results, Vocabularies and Codesets:

- Clinical Chemistry, Hematology, Serology, Microbiology, Blood-banking, and Surgical Pathology Reports

- Newborn screening, Genetics, Molecular Pathology

- Lab tests and Result Status Codes- Record Locator Services- Data Repository Services- Shared Medical Vocabularies

EHR Number of Standards- 149 Total standards identified in the EHR Use Case*

- 70+ standards identified as unique to EHR Use Case*

*Technical Committee is working to reduce these to a core set of standards for further analysis


Assumptions Made in Creating the Pool of Standards Electronic Health Record

Event Code

Event Description Major Assumptions

3.2.1.1 3.2.1.6 3.2.2.0 3.2.2.1 3.3.1.2 3.4.1.1 3.4.1.3 3.2.1.4 3.2.1.5 3.2.1.7.a

Laboratory System notification (patientid, labresults)

3.4.1.5 3.4.2.2 3.5.3.1

Data Repository. Notification (patientid, labresults)

The metadata in the Data Repository and in the Locator Service must be consistent and they may need to perform these interactions in a transaction.

The phrase carbon–copy as used in the use case identifies an exact copy of the results as sent to a pre–determined list of recipients (see issues)

Historical records will be available for clinical use, unaltered, in compliance with regulatory specifications for the duration of the records’ retention.

The range of lab results within the use case also includes: newborn screening terminology, genetics testing and anatomical pathology.

Vocabularies may require constraints in some situations, e.g., ability to limit the use of certain status codes based on the type of result being reported.

EHR Scenarios include merge, combine, and resolve discrepancies of results from multiple repositories (see open issues)

All system have Patient ID information


Assumptions Made in Creating the Pool of Standards Electronic Health Record

Event Code Event Description Major Assumptions

3.2.1.1

3.2.3.1 End–user authentication and authorization

User authentication and authorization will be unique to an application (EHRS or Web app).

All interactions All interactions Patients’ consent and provider access to medical information is assumed to be an application level implementation out of scope for this use case.

Immature standards

We assume that CMS, National Provider Identifier (NPI) are not mature enough, but it and/or the CMS Legacy Medicare provider number could be used in the interim.

Standards and practices for biometric identification of patientsare not mature enough to be in scope.


Duplications and Overlaps in Standards- Electronic Health Record

Event Code

Event Description Standard Duplication/ Overlap Recommended Resolution

SNOMED and clinical LOINC overlap in some metadata and test names HL7 Body site and SNOMED body structure – overlaps exist ICD and SNOMED overlap, but do have mapping from SNOMED to ICD only

Events that rely on standardized security

ISO 17799 and NIST SP800-30, -53 and others

Input from Panel members is sought by the EHR TC. EHR TC will conduct reviews of overlaps in upcoming meetings and panel members are encouraged to participate in this resolution process.

All events that rely on standard terminology


Identified Gaps in Standards- Electronic Health Record

Event Code Event Description Identified Gap in Standards Recommended Resolution

3.2.1.1 3.2.1.6 3.2.2.0 3.2.2.1 3.3.1.2 3.4.1.1 3.4.1.3 3.2.1.4 3.2.1.5 3.2.1.7.a

Lab notification States: A common description of states that may apply to lab results (i.e. preliminary vs. completed, pending, corrected, etc.)

AHIC Use Case Scope Statement (section 3)

Transmission of Unsolicited Results

Mechanism for referral trail or consulting physician trails.

Input from Panel members is sought by the EHR TC. EHR TC will conduct reviews of this gap in upcoming meetings and panel members are encouraged to participate in this gap resolution process.


Identified Gaps in Standards- Electronic Health Record

Event Code Event Description Identified Gap in Standards Recommended Resolution

3.2.4.5 Acknowledgements as per 3.2.4.5

No standard mechanism or terminology to indicate success/failure and error notification/resolution for receipt and use of Lab results.

AHIC Use Case Scope Statement (section 3)

Anatomic Pathology and Newborn Screening Terminology

Input from Panel members is sought by the EHR TC. EHR TC will conduct reviews of this gap in upcoming meetings and panel members are encouraged to participate in this gap resolution process.


May 5 – May 16 Technical Committees complete their analysis and the TC Leadership works in collaboration with TC members and the identified Panel members to develop strategies for resolving overlaps, duplications, and gaps

May 17 – May 23

May 24 - May 26

May 30

Publish the completed Standards Gap and Overlap Analysis for HITSP review and comment

Technical Committees address comments

Finalize and submit Standards Gap and Overlap Analysis to ONC

May 31June 1 – June 2

May 17 – June 2

Face to face meeting of TC Leadership – Chicago, IL Face to face meeting of Technical Committees – Chicago, IL

Use the Standards Harmonization Readiness Criteria– Level 2 to work with industry and government stakeholders to develop a draft list of selected standards

June 3 – June 12 Vet the lists of draft selected standards widely (SDOs, HHS ONC, NHIN Consortia, CCHIT, etc.) and refine the lists as appropriate; garner commitments from industry as appropriate

June 14 Present the draft selection of standards at the HITSP June 14th session for review and approval

June 15 – June 29 Refine and revise the lists of selected standards for publication on June 30

Next Steps

Standards Harmonization Technical Committees Update documents/Standards... · Anonymize data...

Documents

Transcript of Standards Harmonization Technical Committees Update documents/Standards... · Anonymize data...