XXXX/MSSNY Grant Interoperability Project - Interoperability Specifications DRAFT VERSION 0.3

MSSNY Grant Interoperability Project

HIE Interoperability Specifications

DRAFT Version 0.3

December 11, 2008

ii

February 14, 2008 Prepared for BAPHIE by Fairchild Consulting, Inc.

Confidential

XXXX/MSSNY Grant Interoperability Project - Interoperability Specifications DRAFT VERSION 0.3

Table of Contents

Purpose of Document 1

Project Overview 1

Project Timeline 2

Project Scope 2

Use Case Descriptions for All Phases 3

Use Case Details for Phase One: 3

Technical Specifications 6

Leveraged Integration Profiles 6

Clinical Data Exchange Specifications 6

EMR to EMR Referral Specifications 8

Community Vocabulary Standards 10

Enterprise Wide Identifiers 10

Patient identifiers 10

Lab Test Order Identifiers 11

Physician Identifiers 11

Location Identifiers 11

Roles and Responsibilities 11

HIE responsibilities 11

“To practice” Responsibilities 11

“From practice” Responsibilities 12

Participant responsibilities 12

Additional Related Documentation 13

Clinical Data Exchange: 13

Referral Processing 13

i

December 11, 2008 XXXX/ Buffalo Area Physicians Health Information Exchange (BAPHIE) MSSNY Project

MSSNY Grant Interoperability Project - Interoperability Specifications DRAFT VERSION 0.3

Purpose of Document

The purpose of this document is to offer a “straw person” starting point, to begin the technical design discussions regarding the XXXX/ MSSNY Grant Interoperability Project. This document at this time (November 2008) is intended to be a catalyst for the creation of a collaborative formal design specification to be shared between vendors and the community. Additions, corrections and increased amounts of technical specification are not only invited, but considered required to create the type of specification necessary to guide the numerous constituents in this initiative, remove ambiguity and create a successful program. It is the intent that the XXXX/MSSNY solution leverage existing standards and CCHIT certification requirements so that the vendors involved in the HIE implementation, will have solutions they can leverage in other markets, and maintain current CCHIT certifications for EHRs and HIEs.

Project Overview

XXXX has established an agreement with MSSNY to design, develop, and implement EHR to EHR interoperability using the CCD. XXXX is responsible for carrying out the goals and objectives outlined in the MSSNY grant. XXXX in collaboration with the members of the Buffalo Area Physicians Health Information Exchange (HIE) intends to establish Electronic Health Record (EHR) exchange of clinical data between Buffalo, NY regional physician practices, to enable referrals and patient medical summaries to be made available to physicians in their EHR systems at the point of care for clinically available.

The desires of XXXX/HIE are to provide community based, physician specific IT tools which work in collaboration with the XXXXX RHIO which is consistent with the strategic direction of the State of New York. It is important to keep in mind that although the clinical exchange of data is foundational, it is not the end-point for HIE. The practicing physicians represented by HIE need the ability to provide community-based IT tools which aggregate, analyze, measure and report data in order to stimulate rapid improvement in preventive health screening and adherence to best practices for treating patients with chronic conditions. This is to be done through evidenced base care and monitoring of healthcare quality indicators to demonstrate improved quality of care. In doing this, they also need the ability to define the key performance indicators for their coalition of practicing physicians, so the community of physicians can use a common set of metrics across all providers that potentially treat a given patient. HIE believes that in today’s world of advanced medicine, a given person will see many specialists; all of which should be held to the same standard of performance, and all measured against their collective patients.

The HIE pilot includes four physician practices using different EMRs, as listed below:

·  EMR1:Practice 1

·  EMR2:Practice 2

·  EMR3:Practice 3

·  EMR4:Practice 4

Project Timeline

The following diagram is the high level timeline for the project.

Project Scope

The scope of the HIE MSSNY Interoperability includes the use cases depicted here. These use cases are at a system level, showing the interoperability between EMRs and the HIE. At the business use case level, these are part of a larger use case which is part of the patient care coordination.

What each specific EMR does with the interoperability data, is beyond the scope of this project. The way EMRs handle the presentation and acceptance of clinical data into a specific patient’s medical record varies by vendor.

The scope of this project involves the interoperability between EMRs in the Buffalo area through the XXXXXX Health Information Exchange (HIE). It is the intent that the solution leverage existing standards and CCHIT certification requirements so that the vendors involved in the HIE implementation, will have solutions they can leverage in other markets, and maintain current CCHIT certifications for EHRs and HIEs.

Use Case Descriptions for All Phases

The initial scope of the HIE Interoperability Project includes the following use cases which are anticipate to be implemented in two phases.

Phase One use cases leverage the Continuity of Care Documents (CCD), as defined in the HITSP C32 specification for clinical data exchange.

Use Case # / Use Case Description / Notes
UC1a: / Send Patient History Summary / Physician’s EMR sends CCD to HIE with Available Patient History from encounter. HIE routes CCD to intended Physician’s EMR.
“Put CCD”

Phase Two use cases leverage the HITSP Interoperability Specification IS 09 “HITSP Consultations and Transfers of Care Interoperability Specification.

Use Case # / Use Case Description / Notes
UC2: / Physician Refers Patient to Consulting Physician (Sends Available Patient History with Referral) / Physician’s EMR sends an HL7 ORM (order) to the consulting physician along with a Medical Summary.
UC3 / Consulting Physician Sends Updates to Referring Physician (Returns Available Patient History after Consult/Treatment is complete) / At the conclusion of the encounter, the consulting physician’s EMR returns patient consult notes, which reference the original order identification number so that the referring physician’s EMR can tie the notes to the original referral.

Future Phase (TBD) use cases leverage the HITSP Interoperability Specification IS 09 “HITSP Consultations and Transfers of Care Interoperability Specification.

Use Case # / Use Case Description / Notes
UC1b: / Send Patient History Summary / Physician’s EMR sends CCD to HIE with Available Patient History from encounter.
HIE parses and stores discreet medical information from CCD.
If addressed to another Physician, routes CCD to EMR.
“Put CCD” Enhanced
UC4 / Physician Requests Available Patient History (to include Lab results, Radiology reports, Medication orders, Selected progress notes) / Physician’s EMR requests a CCD from the HIE to get available patient history.
“Get CCD”
UC5 / Time to get Available Patient History / Unsolicited request to send patient history to EMR. This may be based on a scheduling event, or a relationship between another physician and the active patient. Data is exchanged using the CCD format (HITSP C32).

Use Case Details for Phase One:

Use Case One – Referring EMR sends CCD to Consulting EMR

Use Case Description: Dr. Jones in Practice A refers patient Jonathan Smith to Dr. Anderson in Practice B and sends a CCD with patient clinical data to Dr. Anderson.

Scenario “A” – Referring Practice does not have an enterprise wide ID#

Key Data Items:

Patient Jonathan Smith MR# 1001 in Practice A, MR# JS2004 in Practice B

Dr. Jones NPI # 101.

Dr. Anderson NPI # 205.

Use Case Flow of Events:

  1. Dr. Jones uses his EMR to request sending a CCD to Dr. Anderson for the patient he is referring to her.
  2. EMR creates a CCD using Dr. Jones with NPI #101 as the referring physician (the “from” physician), Dr. Anderson with NPI #205 as the consulting physician (the “To” physician), and Jonathan Smith with MR#1001 but no enterprise patient ID since one is not available yet
  3. EMR sends an HL7 CCD to Elysium
  4. Elysium parses the CCD to validate the “To physician” using the NPI as the unique provider identifier
  5. Elysium parses the CCD to attempt to match the patient to a known HIE-wide unique identifier (enterprise patient id) using patient data in CCD since no enterprise patient identifier is present.
  6. If this is a new patient for the HIE, Elysium creates an enterprise unique patient id; if patient exists in HIE already, uses the existing enterprise patient ID
  7. Elysium adds the enterprise patient ID to the CCD
  8. Elysium logs the CCD transaction (inbound and outbound)
  9. Elysium routes the CCD to Practice B
  10. EMR at Practice B receives the CCD and pulls it into Dr. Anderson’s task list (for future viewing) and may parse the CCD into discrete data elements depending on capabilities.
  11. EMR cross references the enterprise patient ID into their system to see if this is a new patient or existing patient
  12. If new patient, EMR adds them generating an EMR patient ID which is cross referenced to the HIE enterprise patient ID from the CCD they received.

Scenario “B” – Referring Practice has an enterprise wide patient ID#

Key Data Items:

Patient Jonathan Smith MR# 1001 in Practice A, MR# JS2004 in Practice B, Enterprise Wide ID# 00001

Dr. Jones NPI # 101.

Dr. Anderson NPI # 205.

Use Case Flow of Events:

  1. Dr. Jones uses his EMR to request sending a CCD to Dr. Anderson.
  2. EMR creates a CCD using Dr. Jones with NPI #101 as the referring physician (the “from” physician), Dr. Anderson with NPI #205 as the consulting physician (the “To” physician), and Jonathan Smith with MR#1001 and Enterprise ID# 00001
  3. EMR sends an HL7 CCD to Elysium
  4. Elysium parses the CCD to validate the “To physician” using the NPI as the unique provider identifier
  5. Elysium parses the CCD to validate the patient to a known HIE-wide unique identifier (enterprise patient id) using the enterprise ID# in CCD since the enterprise patient identifier is present.
  6. Elysium logs the CCD transaction (inbound and outbound)
  7. Elysium routes the CCD to Practice B
  8. EMR at Practice B receives the CCD and pulls it into Dr. Anderson’s task list (for future viewing) and may parse the CCD into discrete data elements depending on capabilities.
  9. EMR cross references the enterprise patient ID into their system to see if this is a new patient or existing patient
  10. If new patient, EMR adds them generating an EMR patient ID which is cross referenced to the HIE enterprise patient ID from the CCD they received

Use Case Two – Consulting EMR returns CCD to Referring EMR

Use Case Description: Dr. Anderson in Practice B completes the referral consult for patient Jonathan Smith and sends a CCD with patient clinical information from the referral back to Dr. Jones in Practice A.

Scenario “A” – Consulting Practice does not have an enterprise wide ID#

Key Data Items:

Patient Jonathan Smith MR# 1001 in Practice A, MR# JS2004 in Practice B

Dr. Jones NPI # 101.

Dr. Anderson NPI # 205.

Use Case Flow of Events:

  1. Dr. Anderson uses her EMR to request sending a CCD to Dr. Jones at the completion of her patient referral consult.
  2. EMR creates a CCD using Dr. Jones with NPI #101 as the referring physician (the “To” physician), Dr. Anderson with NPI #205 as the consulting physician (the “from” physician), and Jonathan Smith with MR#1001 but no enterprise patient ID since one is not available yet
  3. EMR sends an HL7 CCD to Elysium
  4. Elysium parses the CCD to validate the “To physician” using the NPI as the unique provider identifier
  5. Elysium parses the CCD to attempt to match the patient to a known HIE-wide unique identifier (enterprise patient id) using patient data in CCD since no enterprise patient identifier is present.
  6. If this is a new patient for the HIE, Elysium creates an enterprise unique patient id; if patient exists in HIE already, uses the existing enterprise patient ID
  7. Elysium adds the enterprise patient ID to the CCD
  8. Elysium logs the CCD transaction (inbound and outbound)
  9. Elysium routes the CCD to Practice B
  10. EMR at Practice A receives the CCD and pulls it into Dr. Jones’s task list (for future viewing) and may parse the CCD into discrete data elements depending on capabilities.
  11. EMR cross references the enterprise patient ID into their system to see if this is a new patient or existing patient
  12. If new patient, EMR adds them generating an EMR patient ID which is cross referenced to the HIE enterprise patient ID from the CCD they received.

Scenario “B” – Consulting Practice has an enterprise wide patient ID#

Key Data Items:

Patient Jonathan Smith MR# 1001 in Practice A, MR# JS2004 in Practice B, Enterprise Wide ID# 00001

Dr. Jones NPI # 101.

Dr. Anderson NPI # 205.

Use Case Flow of Events:

  1. Dr. Anderson uses his EMR to request sending a CCD to Dr. Jones.
  2. EMR creates a CCD using Dr. Jones with NPI #101 as the referring physician (the “to” physician), Dr. Anderson with NPI #205 as the consulting physician (the “From” physician), and Jonathan Smith with MR#1001 and Enterprise ID# 00001
  3. EMR sends an HL7 CCD to Elysium
  4. Elysium parses the CCD to validate the “To physician” using the NPI as the unique provider identifier
  5. Elysium parses the CCD to validate the patient to a known HIE-wide unique identifier (enterprise patient id) using the enterprise ID# in CCD since the enterprise patient identifier is present.
  6. Elysium logs the CCD transaction (inbound and outbound)
  7. Elysium routes the CCD to Practice A
  8. EMR at Practice A receives the CCD and pulls it into Dr. Jones’s task list (for future viewing) and may parse the CCD into discrete data elements depending on capabilities.
  9. EMR cross references the enterprise patient ID into their system to see if this is a new patient or existing patient
  10. If new patient, EMR adds them generating an EMR patient ID which is cross referenced to the HIE enterprise patient ID from the CCD they received.

Technical Specifications

Leveraged Integration Profiles

The underlying profiles for the exchange of medical summary data and referral requests leverages existing interoperability standards which are part of Healthcare Information Technology Standards Panel (HITSP), Integrating the Healthcare Enterprise (IHE), and Health Language 7 (HL7) Clinical Document Architecture (CDA). The following is a list of standards documents which will form the basis of the technical specifications for the HIE MSSNY Interoperability project.