Component14/Unit 6 – Audio Transcript
Slide 1: Vendor Strategies for Terminology, Knowledge Management, and Data Exchange
In this unit we will discuss electronic health record vendor strategies for terminology, knowledge management, and data exchange.
Slide 2: Objective
Electronic health records have evolved to become increasingly complex. Under the HITECH legislation, Meaningful Use requirements include the use of standards, and the demonstrated ability for EHRs to exchange data effectively; that is, they should be interoperable.
Slide 3: After Completing this Unit, You Should be Able to:
After completing this unit, you will be able to first, define what is meant by interoperability; second, describe commercial EHR vendor strategies for terminology and knowledge management, and how these impact interoperability; and finally, describe how these concepts facilitate the use of personal health records.
Slide 4: Interoperability
Dr. John Halamka (pronounced Huh-LOM-ka), who chairs the Health Information Technology Standards Panel, or HITSP, provided the following explanation of what is meant by interoperability. “If I’m faxed a discharge summary which I can read, is that interoperable, since its human interpretable? If I’m sent an electronic note via email that notes “Allergy to MS”, is that interoperable? Of course MS could mean Morphine Sulfate, Magnesium Sulfate, or even Minestrone Soup. If I’m sent an electronic message, which has an agreed upon format, a standard vocabulary, and a set of business rules, which enable me to take action, is that interoperable? For example, your patient is allergic to medication NDC Code 123456789. Administration will cause a SEVERE reaction with HIGH CONFIDENCE. My e-Prescribing software could use this information to display a warning alerting me to the issue and could suggest an effective alternative medication.”
Slide 5: Three Types of Interoperability
Dr. Halamka’s description of interoperability can be analyzed at three different levels:
First, Technical interoperability,this refers to two systems transferring a message—the physical conveyance of a ‘payload’.
Second, Semantic interoperability, which suggests that the correct and consistent “meaning” of the message must be conveyed.
Finally, Process interoperability, which means that information is appropriately integrated into an actual work setting, assuring the systems’ usability and usefulness.
Slide 6: Technical Interoperability
Examples of Technical Interoperability are numerous. Consider the ability to send email or faxes between different computer operating systems or hardware devices. These technologies work because the software and hardware vendors adhere to standards for data transfer. The Internet relies on standards such as the Transfer Control Protocol/Internet Protocol (TCP/IP) to provide technical interoperability.
In Dr. Halamka’s example, sending an electronic note via email that describes an Allergy to MS may be considered Technical Interoperability.
Slide 7: Technical Interoperability: Messaging Standards
In the world of health information technology, the non-profit Health Level Seven (or HL7) organization has been involved for decades in the development of international standards for message exchange. HL7 and its members provide a framework (and related standards) for the exchange, integration, sharing, and retrieval of electronic health information.
The strange looking string of text shown here is an HL7 message that might be sent from a laboratory information system to an electronic health record. The format of the message is prescribed by the HL7 standard, so that a computer system parsing the message can know that (for example), the sixth field of the second line contains the patient’s name in the form “Last, First, Middle”.
Slide 8: Semantic Interoperability
HL7 also provides some expedient definitions that help ensure Semantic Interoperability. For example, the “F” that is highlighted here identifies the patient’s sex as “female”. HL7 created the lookup table shown here for identifying a patient’s sex. By providing this semantic definition, we can avoid the confusion and ambiguity that would exist if each vendor or healthcare institution used a separate identifier for patient sex (for example, “FE”, “female”, “0”, etc.).
Slide 9: Semantic Interoperability (cont.)
In Dr. Halamka’s example, his description of “MS” speaks to the importance of semantic interoperability. He calls for use of standard vocabularies, such as the one provided by the National Drug Code (NDC) Directory for medications. If all EHR vendors used NDC codes, and Morphine Sulfate was given code 123456789, this would facilitate semantic interoperability.
Slide 10: Semantic Interoperability: Terminology Standards
Terminology Standards are important for Semantic Interoperability. For example, clinicians use many different terms to convey nuances related to what a layperson would call a “heart attack”. Some of these include acute myocardial infarction, coronary infarction, AMI, coronary infarct, cardiac arrest, coronary thrombosis, and angina pectoris.
The meaning conveyed by these terms is easy for clinicians to understand, but hard for computer systems. To avoid a technical “Tower of Babel” situation, semantic interoperability requires that clinical information systems are able to “speak a common language”.
The richness and variety of medical concepts are barriers to formulating standardized clinical terminologies, and there are dozens of standards that exist to enumerate and categorize medical concepts. Among them are:
ICD-9: International Classification of Diseases, which was developed by the World Health Organization. In the United States, ICD codes are used extensively for diagnoses & billing.
CPT-4: Current Procedural Terminology, a code set maintained by the American Medical Association to document medical and surgical procedures that are used to support billing.
SNOMED-CT (pronounced Snow-Med) is the Systematized Nomenclature of Medicine, a vast library of medical concepts created by the College of American Pathologists and broadly licensed for use in the United States by the National Library of Medicine.
LOINC (pronounced Loynk) is a publicly available set of observation identifiers, names and codes used, among other things, for laboratory tests.
Slide 11: ICD-9 Codes
This slide shows a portion of the ICD-9 Code hierarchy for the diagnosis “Acute myocardial infarction”.
Slide 12: Transitions to ICD-10
ICD-9 has been used in the United State for over 3 decades. The federal government has mandated that October 1, 2013 is the day ICD‑10 CM (International Classification of Diseases, Tenth Revision, and Clinical Modification) and ICD‑10 PCS (Procedure Coding System) will take effect, replacing the 30‑year‑old ICD‑9 system. This change will impact every paper-based system and software application, information system, and functional department that currently uses or generates ICD-9 codes. In the health IT world, the transition to ICD-10 is somewhat similar to the Y2K event, where a considerable number of legacy systems had to be retired or redesigned to support 4 digits for the year 2000.
Slide 13: LOINC
This slide shows the freely available LOINC browser. LOINC is the de facto standard for defining laboratory tests. The code “15545” contained in the HL7 message shown here identifies a Blood Glucose measurement obtained after a 12 hour fast.
Slide 14: Process Interoperability
Beyond Technical Interoperability and Semantic Interoperability is Process Interoperability. Dr. Halamka’s example suggests a “set of business rules which enable the clinician to take action.”He describes how e-Prescribing software could use patient specific data and information from a knowledge base to display a warning alerting a physician to a potential drug-allergy interaction. An even more advanced system might even suggest an effective alternative medication for that patient.
Slide 15: Process Interoperability (cont.)
Process interoperability is the most complex and difficult to achieve, but it is the most important for patients and clinicians. Put simply, clinicians largely do not care how information is exchanged or how it is appropriately mapped using terminology standards to ensure semantic consistency—they simply need to get their work done, and they need EHRs to support their workflow.
Slide 16: Example: Cerner
EHR vendors have employed different approaches to managing vocabularies and knowledge bases. Cerner provides a variety of tools that can be used by clients to accomplish these tasks. For example, a “Nomenclature Tool” permits the creation and modification of nomenclature values and includes the ability to use and link to standard vocabularies. Cerner’s “Rules Editor” enables clients to create expert rules and can import standards-based rule formats such as Medical Logic Modules (MLMs).
Cerner also provides tools to link to automate linking to clinical knowledge sources. They provide an XML import tool for linking to external evidence based systems to supply expert rules and reminders.
Finally, in terms of clinical measurement, Cerner provides several levels of support, from their Discern Expert Rules Engine to HealthFacts, which links to aggregated data from other Cerner client sites.
Slide 17: Example: Eclipsys
The Eclipsys Sunrise EHR uses HL7 2.3 messaging to exchange results, documents, observations, and tasks with other systems.
Eclipsys has a vocabulary manager module to map internal concepts to terminologies such as ICD-9, CPT-4, and SNOMED.
Eclipsys (now Allscripts) has partnerships with third-party terminology solutions such as Multum (for medications) and Intelligent Medical Objects (for problems).
Eclipsys, along with most other vendors, supports sending and receiving patient summary information encoded using the HL7 Continuity of Care Document (CCD) standard.
Slide 18: Example eClinicalWorks
The EHR from eClinicalWorks uses a semi-uniform structured data model that permits identification of common data elements across multiple installations. It has predefined mappings for internal codes to LOINC, ICD-9, CPT-4, NDC, etc. and provides a manual mapping capability for users to add custom codes. eClinicalWorks uses Continuity of Care Record (CCR) and CCD standards for clinical document sharing with health information exchanges (HIEs).
Slide 19: Examples of Third Party Terminology Products
Because of the complexity of terminology and knowledge management, many third-party products have been developed which are either licensed by EHR vendors or purchased by EHR clients and integrated into their local installations.
Two vendors that provide tools for managing and updating standard and localized medical terminology are Intelligent Medical Objects, Inc., and Health Language, Inc.
There are several third-party systems providing solutions specific to medication management. These include: First Databank, Micromedex, MediSpan,and Multum.
Slide 20: Personal Health Records
In recent years there has begun to be a great deal of excitement surrounding Personal Health Records, or PHRs. A Personal Health Record allows patients to view, interact with, and manage their health information electronically. Commercial electronic health records are beginning to support data exchange with personal health records.
Some EHR vendors offer “tethered” patient portals that are tied only to their system, while other offerings provide an “untethered” alternative, where a person’s information resides in a separate online repository where the information and access to it are controlled by the patient. Examples of “untethered” PHRs include Google Health, Microsoft HealthVault, and Dossia.
Slide 21: Accuracy of EHR-PHR Data
EHR vendors, clients, and consumers are very concerned about the information that flows from an EHR to a PHR.
The Boston Globe article shown here tells the story of Dave DeBronkart:
“When Dave DeBronkart, a tech-savvy kidney cancer survivor, tried to transfer his medical records from Beth Israel Deaconess Medical Center to Google Health, a new free service that lets patients keep all their health records in one place and easily share them with new doctors, he was stunned at what he found.
Google said his cancer had spread to either his brain or spine - a frightening diagnosis DeBronkart had never gotten from his doctors - and listed an array of other conditions that he never had, as far as he knew, like chronic lung disease and aortic aneurysm. A warning announced his blood pressure medication required "immediate attention."
"I wondered, 'What are they talking about?' “said DeBronkart…
DeBronkart eventually discovered the problem: some of the information in his Google Health record was drawn from billing records, which sometimes reflect imprecise information plugged into codes required by insurers.”
This case demonstrates some of the challenges and opportunities associated with Personal Health Records.
Slide 22: Benefits of PHRs
PHRs can aggregate information from a variety of sources, such as hospitals, pharmacies, laboratories, and insurers.
Supplying information to patients has several potential benefits, including:
- A greater sense of patient empowerment
- Patients may become more engaged in their care
- Patients may experience higher satisfaction with their care
- Adherence by patients to their care plans may increase
- And patients may experience better health outcomes.
Slide 23: Barriers to Linking EHR and PHR Data
Like the example described in the Boston Globe article, there are several barriers to linking EHR and PHR Data. Among them are ensuring that patients are given correct and accurate information and concern on the part of clinicians about providing information about medical diagnoses, laboratory and radiology results before the physician can review them.
Clinicians have also expressed concern that they will have to change the way they document information if it will more likely be read by patients.
And of course, there are numerous privacy-related concerns for patients, institutions, especially for Web-based PHRs.
1
Component14/Unit 6Health IT Workforce Curriculum
Version 2.0/Spring 2011
This material was developed by Columbia University, funded by the Department of Health and Human Services, Office of the National Coordinator for Health Information Technology under Award Number 1U24OC000003.