| There is a surreal level of excitement this year at HIMSS’s annual conference. The recent passage of the HITECH Act promises billions of dollars to providers for the implementation of an EHR system. A record number of EHR vendors have applied for CCHIT certification in hope that this will be the new Federal Standard. (See cchit.org/about/news/releases/2009/Certification-Commission-Experiences-Surge-in-Applications.asp.) Vendors, providers, credentialing organizations and consultants are trying to divine precisely how to meet yet undefined Federal standards for the implementation of EHR systems. Electronic health records in some form have been around for some time however, the challenge of interoperability of these systems remains unresolved. Interoperability currently is and will likely continue to be a key requirement to receive any payments under the HITECH Act for the implementation of an EHR system, however, an unrealistic focus on universal interoparability will only impair the impelmentation/ impede of EHR systems. |
 |
HIMSS defines an electronic health record as-
a longitudinal electronic record of patient health information generated by one or more encounters in any care delivery setting. Included in this information are patient demographics, progress notes, problems, medications, vital signs, past medical history, immunizations, laboratory data and radiology reports. The EHR automates and streamlines the clinician’s workflow. The EHR has the ability to generate a complete record of a clinical patient encounter – as well as supporting other care-related activities directly or indirectly via interface – including evidence-based decision support, quality management, and outcomes reporting..
(http://www.himss.org/ASP/topics_ehr.asp).
In the Electronic Healthcare Record world “HL-7″ is the most common standard in use today to define the content of a message or a packet of health information belonging to someone’s EHR record. On a macro scale HL-7 is a significant advancement over more traditional models of interoperability including paper and scanned documents. HL-7 is the next level sophistication, machine organizable data files (e.g. comma delimited files). (See Table 1 below). The most common communication standard in use today by EHR’s is called HL-7 version 2. HL-7 version 2.x is a protocol defining how to format and represent medical information from many different sources. Seven in HL-7 refers to the protocol layer within the OSI (Open Systems Interconnection Reference Model). Other common (Layer 7) Application layer protocols include FTP, Bittorent, Lightweight Directory Access Protocol (“LDAP”), and Simple Object Access Protocol (“SOAP”). SOAP is functionally similar to HL-7. SOAP is a protocol specification for exchanging structured data using Extensible Markup Language (XML) as the message format, and other level 7 protocols including Remote Procedure Call (RPC) and HTTP. ANSI X12 refers to Electronic Data Interchange (EDI) standards developed by ANSI (American National Standards Institute). Those familiar with the HIPAA Transactions and Codeset Regulations may also be familiar with X12. The following X12 EDI transaction formats are mandated under HIPAA: 270 Eligibility, Coverage, or Benefit Inquiry 271 Eligibility, Coverage, or Benefit Information 276 Health Care Claim Status Request 277 Health Care Information Status Notification 278 Health Care Services Review Information 820 Payment Order / Remittance Advice 834 Benefit Enrollment & Admittance 835 Health Care Claim Payment/Advice 837 Health Care Claim (separate IGs for Dental, Institutional, or Professional).
OSI Seven Layer Network Model
| Protocol Layer |
Description |
Data Unit |
| Layer 7 – Application |
Network process to application |
Data |
| Layer 6 – Presentation |
Data representation and encryption |
Data |
| Layer 5 – Session |
Interhost communication |
Data |
| Layer 4 – Transport |
End-to-end connections and reliability |
Segment |
| Layer 3 – Packet |
Path determination and logical addreessing |
Packet |
| Layer 2 – Data Link |
Physical addressing |
Frame |
| Layer 1 – Physical |
Media, signal and binary transmission |
Bit |
A sample HL-7 message (relating to a patient’s immunization data) is illustrated by the following:
MSH|^~\&||GA0000||VAERSPROCESSOR|20010331605||ORU^RO1|20010422GA03|T|2.3.1|||AL|PID|||1234^^^^SR~1234-12^^^^LR~00725^^^^MR||Doe^John^Fitzgerald^JR^^^L||20001007|M||2106-3^White^HL70005|123 Peachtree St^APT 3B^Atlanta^GA^30210^^M^^GA067||(678) 555-1212^^PRN|NK1|1|Jones^Jane^Lee^^RN|VAB^Vaccine administered by (Name)^HL70063|NK1|2|Jones^Jane^Lee^^RN|FVP^Form completed by (Name)-Vaccine provider^HL70063|101 Main Street^^Atlanta^GA^38765^^O^^GA121||(404) 554-9097^^WPN|ORC|CN|||||||||||1234567^Welby^Marcus^J^Jr^Dr.^MD^L|||||||||Peachtree Clinic|101 Main Street^^Atlanta^GA^38765^^O^^GA121|(404) 554-9097^^WPN|101 Main Street^^Atlanta^GA^38765^^O^^GA121|OBR|1|||^CDC VAERS-1 (FDA) . . .
I have omitted the rest of the sample HL-7 sample message to save space (however this example and others can be found at http://www.dt7.com/cdc/sampmsgs.html). Those who are familiar with comma delimited files in Excel or simple database exports may find the above example familiar. An HL-7 message is a collection of data related to a health-care event. The communication connection between two computers sending HL7 messages is called an interface. For the more technically inclined an-open source HL-7 programming interface and HL-7 parser can be found at http://hl7api.sourceforge.net/. HL-7 version 3 is meant to make the leap to the final level of interoperability from version 2
Table 1 Interoperability Level by Data Type
|
Method
|
Context
|
|
Non-electronic data Paper, mail, and phone call.
|
Traditional method had been in use of 100+ years.
|
|
Machine transportable data Fax, email, and unindexed documents.
|
Scanned Documents, rudimentary searching capacity of OCR’ed documents.
|
|
Machine organizable data (structured messages, unstructured content) HL7 messages and indexed (labeled) documents, images, and objects.
|
Current Standard. HL7 Version 2.x (a delimited text file); highly flexible but poor interoperability.
|
|
Machine interpretable data (structured messages, standardized content) Automated transfer from an external lab of coded results into a provider’s EHR. Data can be transmitted (or accessed without transmission) by HIT systems without need for further semantic interpretation or translation.
|
Future Standard. HL7 Version 3, less flexible but designed to result in interoperable EHR systems.
|
HL-7 version 3 (per the official website http://www.hl7.org/) is meant to replace the free form ad-hoc approach and flexibility that defines HL-7 version 2. Unfortunately the flexibility of version 2 has come at a cost, the design has hindered interoperability with a more rigid structure of version 3 should solve interoperability issues encountered within HL-7 version 2.
[Version 2] [w]hile providing great flexibility, its optionality also makes it impossible to have reliable conformance tests of any vendor’s implementation and also forces implementers to spend more time analyzing and planning their interfaces to ensure that both parties are using the same optional features. Version 3 addresses these and other issues by using a well-defined methodology based on a reference information (i.e., data) model. It will be the most definitive standard to date. Using rigorous analytic and message building techniques and incorporating more trigger events and message formats with very little optionality, HL7’s primary goal for Version 3 is to offer a standard that is definite and testable, and provide the ability to certify vendors’ conformance. Version 3 uses an object-oriented development methodology and a Reference Information Model (RIM) to create messages. The RIM is an essential part of the HL7 Version 3 development methodology, as it provides an explicit representation of the semantic and lexical connections that exist between the information carried in the fields of HL7 messages.
(see http://www.hl7.org/index.cfm version 3 messaging standard)
HL-7 covers a broad range of health related activities (as illustrated by Table 2).
Table 2 – Typical HL-7 Data Categories
| Category |
Description |
| Patient Administration |
Admit, Discharge, Transfer, and Demographics. |
| Order Entry |
Orders for Clinical Services and Observations, Pharmacy, Dietary, and Supplies. |
| Financial |
Patient Accounting and Charges. |
| Observation |
Observation Report Messages. |
| Scheduling |
Appointment Scheduling and Resources. |
| Patient Referral |
Primary Care Referral Messages. |
| Patient Care |
Problem-Oriented Records. |
With HL-7 version 3 we may have the language and grammar for describing an electronic health record, however, we still have difficulty in visualizing (mentally incorporating the concept of) a medical record that exists as an abstraction of relationships between health care related objects each combination of objects differing from patient to patient as the medical condition and treatments for any given individual varies. This intellectual obstacle is illustrated by one presenters comment on the topic of e-discovery of health care records– that the only way to produce a “legal” medical record is by producing electronic images of the paper files. The extreme variation within HL-7 version 2 implementations illustrate the most fundamental problem of interoperability: if two organizations are using different variations of the HL-7 standards, the entities will be unable to communicate. Specialized interfaces — programs the translate between two different standards — can be implemented on a case by case basis however this solution is not scalable and requires continuous maintenance and testing to ensure that the system is reliable.
Many believe semantic ontologies are required for effective interoperability. Ontology is a philosophical concept that for our purposes can be viewed as a formal representation (abstraction) of a set of concepts (objects) within a domain and the relationships between those concepts. Ontologies are used to reason about the properties of that domain, and may be used to define the domain. Ontologies include Individual instances or objects; classes which are sets or collections of objects; attributes that define properties, characteristics, or parameters of an objects (or class); relations between classes and individual objects to one another; and events that change attributes or relations of objects or classes. However, ontological based machine learning has remained an unsolvable problem for the last 60 years. We will likely have to accept that universal interoperability will not be possible for some time to come.
“I do not pretend to start with precise questions. I do not think you can start with anything precise. You have to achieve such precision as you can, as you go along.” Quotation of Bertrand Russell
The Nuts and Bolts of EHRs and Interoperability
HIMSS defines an electronic health record as-
a longitudinal electronic record of patient health information generated by one or more encounters in any care delivery setting. Included in this information are patient demographics, progress notes, problems, medications, vital signs, past medical history, immunizations, laboratory data and radiology reports. The EHR automates and streamlines the clinician’s workflow. The EHR has the ability to generate a complete record of a clinical patient encounter – as well as supporting other care-related activities directly or indirectly via interface – including evidence-based decision support, quality management, and outcomes reporting..
(http://www.himss.org/ASP/topics_ehr.asp).
In the Electronic Healthcare Record world “HL-7″ is the most common standard in use today to define the content of a message or a packet of health information belonging to someone’s EHR record. On a macro scale HL-7 is a significant advancement over more traditional models of interoperability including paper and scanned documents. HL-7 is the next level sophistication, machine organizable data files (e.g. comma delimited files). (See Table 1 below). The most common communication standard in use today by EHR’s is called HL-7 version 2. HL-7 version 2.x is a protocol defining how to format and represent medical information from many different sources. Seven in HL-7 refers to the protocol layer within the OSI (Open Systems Interconnection Reference Model). Other common (Layer 7) Application layer protocols include FTP, Bittorent, Lightweight Directory Access Protocol (“LDAP”), and Simple Object Access Protocol (“SOAP”). SOAP is functionally similar to HL-7. SOAP is a protocol specification for exchanging structured data using Extensible Markup Language (XML) as the message format, and other level 7 protocols including Remote Procedure Call (RPC) and HTTP. ANSI X12 refers to Electronic Data Interchange (EDI) standards developed by ANSI (American National Standards Institute). Those familiar with the HIPAA Transactions and Codeset Regulations may also be familiar with X12. The following X12 EDI transaction formats are mandated under HIPAA: 270 Eligibility, Coverage, or Benefit Inquiry 271 Eligibility, Coverage, or Benefit Information 276 Health Care Claim Status Request 277 Health Care Information Status Notification 278 Health Care Services Review Information 820 Payment Order / Remittance Advice 834 Benefit Enrollment & Admittance 835 Health Care Claim Payment/Advice 837 Health Care Claim (separate IGs for Dental, Institutional, or Professional).
A sample HL-7 message (relating to a patient’s immunization data) is illustrated by the following:
MSH|^~\&||GA0000||VAERSPROCESSOR|20010331605||ORU^RO1|20010422GA03|T|2.3.1|||AL|PID|||1234^^^^SR~1234-12^^^^LR~00725^^^^MR||Doe^John^Fitzgerald^JR^^^L||20001007|M||2106-3^White^HL70005|123 Peachtree St^APT 3B^Atlanta^GA^30210^^M^^GA067||(678) 555-1212^^PRN|NK1|1|Jones^Jane^Lee^^RN|VAB^Vaccine administered by (Name)^HL70063|NK1|2|Jones^Jane^Lee^^RN|FVP^Form completed by (Name)-Vaccine provider^HL70063|101 Main Street^^Atlanta^GA^38765^^O^^GA121||(404) 554-9097^^WPN|ORC|CN|||||||||||1234567^Welby^Marcus^J^Jr^Dr.^MD^L|||||||||Peachtree Clinic|101 Main Street^^Atlanta^GA^38765^^O^^GA121|(404) 554-9097^^WPN|101 Main Street^^Atlanta^GA^38765^^O^^GA121|OBR|1|||^CDC VAERS-1 (FDA) . . .
I have omitted the rest of the sample HL-7 sample message to save space (however this example and others can be found at http://www.dt7.com/cdc/sampmsgs.html). Those who are familiar with comma delimited files in Excel or simple database exports may find the above example familiar. An HL-7 message is a collection of data related to a health-care event. The communication connection between two computers sending HL7 messages is called an interface. For the more technically inclined an-open source HL-7 programming interface and HL-7 parser can be found at http://hl7api.sourceforge.net/. HL-7 version 3 is meant to make the leap to the final level of interoperability from version 2
Table 1 Interoperability Level by Data Type[1]
Method
Context
Non-electronic data Paper, mail, and phone call.
Traditional method had been in use of 100+ years.
Machine transportable data Fax, email, and unindexed documents.
Scanned Documents, rudimentary searching capacity of OCR’ed documents.
Machine organizable data (structured messages, unstructured content) HL7 messages and indexed (labeled) documents, images, and objects.
Current Standard. HL7 Version 2.x (a delimited text file); highly flexible but poor interoperability.
Machine interpretable data (structured messages, standardized content) Automated transfer from an external lab of coded results into a provider’s EHR. Data can be transmitted (or accessed without transmission) by HIT systems without need for further semantic interpretation or translation.
Future Standard. HL7 Version 3, less flexible but designed to result in interoperable EHR systems.
HL-7 version 3 (per the official website http://www.hl7.org/) is meant to replace the free form ad-hoc approach and flexibility that defines HL-7 version 2. Unfortunately the flexibility of version 2 has come at a cost, the design has hindered interoperability with a more rigid structure of version 3 should solve interoperability issues encountered within HL-7 version 2.
[Version 2] [w]hile providing great flexibility, its optionality also makes it impossible to have reliable conformance tests of any vendor’s implementation and also forces implementers to spend more time analyzing and planning their interfaces to ensure that both parties are using the same optional features. Version 3 addresses these and other issues by using a well-defined methodology based on a reference information (i.e., data) model. It will be the most definitive standard to date. Using rigorous analytic and message building techniques and incorporating more trigger events and message formats with very little optionality, HL7’s primary goal for Version 3 is to offer a standard that is definite and testable, and provide the ability to certify vendors’ conformance. Version 3 uses an object-oriented development methodology and a Reference Information Model (RIM) to create messages. The RIM is an essential part of the HL7 Version 3 development methodology, as it provides an explicit representation of the semantic and lexical connections that exist between the information carried in the fields of HL7 messages.
(see http://www.hl7.org/index.cfm version 3 messaging standard)
HL-7 covers a broad range of health related activities (as illustrated by Table 2).
Table 2 – Typical HL-7 Data Categories
With HL-7 version 3 we may have the language and grammar for describing an electronic health record, however, we still have difficulty in visualizing (mentally incorporating the concept of) a medical record that exists as an abstraction of relationships between health care related objects each combination of objects differing from patient to patient as the medical condition and treatments for any given individual varies. This intellectual obstacle is illustrated by one presenters comment on the topic of e-discovery of health care records– that the only way to produce a “legal” medical record is by producing electronic images of the paper files. The extreme variation within HL-7 version 2 implementations illustrate the most fundamental problem of interoperability: if two organizations are using different variations of the HL-7 standards, the entities will be unable to communicate. Specialized interfaces — programs the translate between two different standards — can be implemented on a case by case basis however this solution is not scalable and requires continuous maintenance and testing to ensure that the system is reliable.
Many believe semantic ontologies are required for effective interoperability. Ontology is a philosophical concept that for our purposes can be viewed as a formal representation (abstraction) of a set of concepts (objects) within a domain and the relationships between those concepts. Ontologies are used to reason about the properties of that domain, and may be used to define the domain. Ontologies include Individual instances or objects; classes which are sets or collections of objects; attributes that define properties, characteristics, or parameters of an objects (or class); relations between classes and individual objects to one another; and events that change attributes or relations of objects or classes. However, ontological based machine learning has remained an unsolvable problem for the last 60 years. We will likely have to accept that universal interoperability will not be possible for some time to come.
“I do not pretend to start with precise questions. I do not think you can start with anything precise. You have to achieve such precision as you can, as you go along.” Quotation of Bertrand Russell
[1] NAHIT Levels of EHR Interoperbility. “What is interoperability?”. National Alliance for Health Information Technology. Retrieved on 2007-04