IHE USA Response to ONC RFI on PCAST Report

Introduction

This document describes in detail the capabilities provided by IHE profiles to address the nine use cases described in the PCAST report. IHE profiles use established standards such as DICOM, HL7, Oasis and W3C, to address specific clinical use cases. They define structured medical documents and other information objects, as well as the transactions used to exchange them. Many use HL7 CDA documents and reference appropriate coded value sets and terminologies (such as CPT, LOINC and SNOMED) for specific data elements and metadata in these documents. IHE also defines a shared infrastructure for health information exchange networks and specifies the transactions used to publish, locate and retrieve information, as well as the types of information to be exchanged. Taken together these profiles provide many of the features of the “universal exchange language” and Data Element Access Service (DEAS) envisioned in the PCAST report.

Most of the profiles we reference in this response are deployed in commercial HIT products in use today. Many have been demonstrated at events like the HIMSS Interoperability Showcases. IHE profiles have been widely implemented and proven effective in HIEs in the USA and in national projects around the world.

Addressing the Use Cases

The PCAST report identified 9 different use cases calling for data exchange. Our feedback focuses on identifying the IHE implementation guides (profiles) that use a common language for Healthcare to exchange information, meeting the intent of the “universal exchange language” called for by PCAST.

Use Case 1

A patient on warfarin, a blood thinner, strains his calf muscle during a tennis match and cannot remember whether it is safe to take Advil or Motrin. He types “Advil” into his personal health record list to see if there are any potential interactions with the list of medications in his record [1]. Indeed, taking either Advil or Motrin would significantly increase his risk for serious bleeding. He emails his physician, who recommends cold packs and acetaminophen [2]. The next day a discoloration and increased swelling occurs. He sends another email to the physician’s office, where he is connected to a nurse practitioner who recommends a blood coagulation test [3]. He is able to select times online [4] for the test [5], for follow-up with the physician, and for possible further tests and physical therapy [6].

1. The IHE Request for Clinical Guidance Profile (RCG) can be used by the patient’s PHR to interface with a clinical decision support service that may be free-standing or included in the EHR to determine that use of Advil would not be appropriate for a patient with his conditions. The profile uses the HL7 Care Record Standard, which uses much of the same XML found in the HL7 Clinical Document Architecture Standard to communicate the patient’s conditions, allergies, and medications (and other necessary clinical data). The clinical decision support service can determine that there is a potential adverse reaction and present guidance on what alternative treatments are available. The PHR can evaluate and present the responses from the Clinical Decision Support application.

1.2. The PHR can make use of the protocols (e.g., Direct or CONNECT) supported by the US Nationwide Health Information Network, sending his physician updated information about his injury and current medications and diagnoses in an attached CCD document using the HITSP C32 specification. The C32 specification relies on the IHE XPHR profile for CDA sections and entries. That document, and any other relevant data can be packaged an IHE XDM package for easy inclusion in and access from the e-mail. The physician’s response can be sent back the same way.

1.3. Step three is a repetition of step 2 with different data.

1.4. Online Electronic Scheduling is indeed a gap in the current set of IHE profiles. There are several applicable standards that might be used from the HL7 Version 3 Scheduling and Patient Administration domains, or using IETF standards for communicating scheduling information. These have not yet been profiled by IHE for this purpose. Many EHRs presently support online scheduling through web portals.

1.5. The results of the Laboratory Test can be communicated using the IHE Exchange of Laboratory Reports (XD-LAB) profile. The results appear in a CDA Document using the same language for results as is already found in the HITSP C32 specification, and may be communicated to the Physician’s EHR and Patient’s PHR. Moreover, the HITSP C37 specification which builds on the IHE XD-LAB profile has already been reconciled with national requirements for communication of laboratory identifiers, laboratory directory identification, et cetera, as required by the CLIA act.

1.6. The IHE Cross Enterprise Exchange of Medical Summaries profile, which includes a referral feature that can be used to communicate appropriate information and test results for the referral to Physical Therapy.

Use Case 2

A 70-year-old woman with a newly diagnosed lung mass suspicious for lung cancer discovered on a CAT scan [1]in a small community hospital is referred [2] to a large academic center in a metropolitan area two hours away. The patient’s local hospital automatically makes available her electronic health record, enabling the cancer surgeon to pull up the CAT scan images [2] and radiologist report [4] at the patient’s consultation. She doesn’t remember all her medications, but her electronic record has recently been updated and verified [5]. She may need a lung biopsy, and her record notes that she has an unusual cardiac arrhythmia [6] that has been treated by a cardiologist in the past but that she is no longer taking medication. The biopsy is positive for lung cancer, and she will need both surgery and radiation. She is able to receive some of this treatment closer to one of her children, who lives in another state 1,200 miles away, with real-time communication electronically [7] between her oncology team and her primary care physician. During this time, she is weakened and falls, sustaining a hip fracture [8]. She is taken to the emergency room, where all her information is immediately available [9] to sort out the otherwise confusing picture of cardiac arrhythmia, anemia from cancer treatment, and recent surgical scars [10].

1. The CT Scan image and report can be shared via the IHE XDS-I profile.

1.2. The hospital can make use of the Referral feature of the IHE XDS-MS profile, and the Document-based Referral Request (DRR) profile to communicate referrals to the academic medical center

1.3. XDS-I is used to access the scan images.

1.4. XDS-SD can be used to read the report.

1.5. Patient medications can be reconciled and verified using the RECON profile [a work in progress for 2011].

1.6. The ECG profile can be used to format the ECG content and it can be exchanged using XDS [transport] and XDS-SD [content].

1.7. The DSUB profile can be used to automatically route information between the patient’s home practice and the hospital where she receives care.

1.8. The patient’s physician can use the IHE ED Referral profile to communicate information directly to the ED where she is taken.

1.9. Access to all of the patient’s information is available using IHE’s Cross Enterprise Document Sharing (XDS) profile.

1.10. ED Treatment reports and results can be exchanged using the IHE ED Encounter Summary (EDER) profile; and, for data outside the local community, IHE’s Cross-Community Access (XCA) profile.

Use Case 3

A general internist decides to seek approval for her practice to be designated a patient-centered medical home (PCMH) under Medicare because she cares for a large number of patients with chronic illness [1], including diabetes, heart disease, and hypertension. This requires her to submit a large number of data entry forms [2] and quality measures, including descriptions of her patients, their disease profiles, and their demographics. Her office staff is able to do this easily by extracting the information from her EHR system [3], and she receives the designation [4]. Her office is also able to file quality of care and utilization reports on a regular basis to 10 other payers apart from Medicare, and create reports that aggregate her patient population [5] across all payers. This allows her to identify gaps in preventive measures or diabetes and hypertension control and create reports to maintain specialty board certification and hospital privileges. When she identifies areas for improvement, she implements changes in her practice and later re-measures. For example, she and her partners have increased the rate of elderly patients who received preventive falls assessments, and were able to do the follow-up measures electronically [6] because they share EHR data with the two retirement homes and several nursing homes in the region. In doing this, they drew on patient-specific risk profiles and guidelines available electronically [7] from the National Institutes of Health and the American Geriatric Society decision support [8] programs.

1. The IHE Care Management (CM) profile is designed to support care for patients with Chronic Illness and uses the HL7 Version 3 Care Record standard, which has highly compatible XML with the HL7 CDA.

1.2. The Request Form for Data Capture (RFD) is designed to automate forms based processing from an EHR.

1.3. The IHE Query for Existing Data (QED) profile (also using the HL7 Care Record standard) can be used to extract discrete data from an EHR system.

1.4. The IHE Document Subscription (DSUB) profile will allow her to automatically gather data on here patients from other providers as it becomes available through Cross Enterprise Sharing (XDS).

1.5. The IHE Cross Enterprise Sharing (XDS) and Multi-patient query (MPQ) profiles can support multi-patient queries for developing aggregate reports.

1.6. The Care Management profile enables easy updates by automatically identifying information that needs to be communicating, eliminating interface rework.

1.7. Guidelines can identify information that needs to be shared in the IHE Care Management (CM) profile.

1.8. The IHE Request for Clinical Guidance (RCG) profile uses the same standards and the IHE CM and QED profiles to support CDS.

Use Case 4

A small group practice provides online access to each patient’s medical record [1] and communicates regularly with its patients via email [2]. The practice has recently implemented an open access scheduling system [3] and is curious to learn how patients feel about the change, so they email all patients with a recent office visit a web link to complete a focused satisfaction survey [4]. They also participate in the Consumer Assessment of Healthcare Providers and Systems (CAHPS) survey authorized by Medicare but would like to add more specific questions related to ’patient’s own conditions [5] such as: “Did the nurse follow up with you about managing your new glucometer?” “Did your questions get answered?” They are able to personalize aspects of this survey and at the same time have only the needed aggregate data reported to payers.

1. The IHE XPHR profile is designed to support exchanges of information between EHR and PHR systems using the XDS profile.

1.2. XPHR and other IHE Content profiles can be used with the IHE XDM profile in direct communications between the provider and the patient using e-mail.

1.3. Scheduling is indeed a gap, see previous notes.

1.4. The IHE Request Form for Data Capture (RFD) profile allows synchronization of information between EHR/PHR and other data gathering systems using Web-based forms.

1.5. Other surveys can also be supported by RFD.

Use Case 5

A group of cardiology clinics in the Southwest, separated by significant distance, decides to work together to improve the care of patients [1] who recently experienced a myocardial infarction (heart attack) [2]. They link [3] information from each clinic’s electronic medical records to track progress [4], learn what quality interventions work best, and create composite measures that help to distinguish what constitutes the best overall care. They are able to identify which sites have the best outcomes in certain areas, and they learn from each other how to apply these findings through webinars engaging all the staff in each clinic.

1. Patients can be identified across practices using the IHE Cross-Community Patient Discovery (XCPD) profile.

1.2. The IHE Query for Existing Data (QED) or Multi-Patient Query (MPQ) profiles can be used to help identify patients with specific conditions.

1.3. The IHE XCPD and/or PIX and PDQ can be used to help link multiple patient identities within or across healthcare communities.

1.4. The IHE Document Subscription (DSUB) profile or the MPQ profile can be used to support progress reporting.

Use Case 6

A family physician embeds electronic reminders that alert her when the patient she is seeing during an office visit needs preventive care [1]. Each fall, the clinic queries the electronic record [2] to see which patients will need an influenza vaccine and to automatically generate a reminder email and/or text message sent to the patient [3]. When an unusual pandemic strain appears, with different risk groups, the database can be queried [4] to identify and communicate with those patients who are at highest risk.

1. The IHE Request for Clinical Guidance Profile (RCG) can be used to query a clinical decision support service for alerts and care reminders.

1.2. The IHE Query for Existing Data (QED) profile or the Immunization Content (IC) profile can be used to see whether a patient has recently received an appropriate flu vaccination (as data or as a document).

1.3. Care Reminders and current patient data can be communicated to the patient using the Direct protocol and the IHE XDM profile.

1.4. The IHE Multi-patient Query (MPQ) profile can be used to query for multiple patients supporting communication with high-risk groups.

The Value of Population Data for Research and Public Health

The IHE Quality, Public Health and Research Domain was formed in 2007 to addresses the infrastructure and content necessary to share information relevant to quality improvement in electronic patient care and health care records, improves the liaison between the primary care system and clinical research and it serves in cases where population base surveillance is needed. The three components addressing the different aspects of the QRPH domain have all in common the secondary or the repurposing of data.

Use Case 7

A physician treating a patient with rheumatoid arthritis using TNF (tumor necrosis factor) inhibitors enters the patient into the database of a national clinical study [1]. Because the patient’s clinical [2] and genetic information [3] are both known, the physician is able to use specific characteristics [4] to predict outcomes and reduce toxicity [5] without relying on the traditional trial and error process. This information is available to all physicians and patients and is continually updated.

1. The IHE Retrieve Protocol Process for Execution profile and the Request for Data Capture (RFD) profile can be used to integrate automate the workflow of study discovery, patient enrollment and trial activity execution between collaborating care providers and researchersthe EHR with the clinical trial information systems. The Clinical Research Document (CRD) profile can be used to communicate standardized clinical information data from the primary care EHR to the Clinical Trial systems.

1.2. The IHE XPHR profile can be used to communicate the patient’s clinical data.

1.3. The IHE XD-LAB profile can be used to communicate genetic laboratory results to the EHR and subsequently the Clinical Trials.

1.4. The IHE QED profile can also be used to access data on specific patient characteristics.

1.5. The IHE Request for Clinical Guidance (RCG) Profile can be used to provide clinical decision support on outcomes and toxicity.

Use Case 8

An FDA Commissioner is able to launch a real-time assessment of every patient [1] taking newly approved drugs and aggregate clinical patterns [2] to identify adverse side effects of medications. A robust post-marketing electronic registry [3] allows much earlier detection of important adverse events for discrete subpopulations of patients and at negligible additional cost to FDA.

1. The IHE Query for Existing Data (QED) profile can be used to location patients taking specific medications or with specific conditions.

1.2. The IHE Multi-patient Query (MPQ) can be used to locate additional data relevant for patients that have been identified.

1.3. The IHE Drug Safety Content (DSC) can be used to report adverse events to public health agencies.

Use Case 9

For a particular year, ambitious new goals are set to improve health measures [1]. Communities, regions, and states are able to provide comprehensive and accurate annual reports [2] on each of these goals, identifying gaps where special focus is needed and key areas for focus in coming years. This process does not require extensive additional data gathering by state and local public health entities. Rather, it uses the flow of de-identified [3] information generated by regular population health and healthcare activities.

1. The IHE Quality Case Reporting (new for 2011) profile can be used to identify quality data and provide patient level quality data to quality reporting systems.

1.2. Use of the IHE XDS profile allows HIEs in communities, regions and states to gather and provide comprehensive quality reports.

1.3. The IHE Redaction profile (new for 2011) can be used to support de-identification of clinical data. The IHE ITI Domain has developed a Pseudonymization cookbook that describes the issues around de-identification and pseudonymization and how to apply IHE profiles to support these processes.

IHE USA Committee