In the previous post, I discussed "care measurement and process standards," which are data standards dealing with diagnosing health problems, determining treatments, and assessing care quality and provider performance. [ C lick here for first post in series ]
In this post, I turn to technology standards, and to "messaging format" standards in particular. Whereas data standards focus on making information understandable and useful to humans, messaging format standards focus on enabling the exchange, or interoperability, of data and information (i.e., "transactions") across healthcare systems.
HL7 Messaging Standard
The Health Level Seven (HL7) Messaging Standard is the most recognized. It specifies the technical aspects of sending messages so that one software program can exchange information with another, so the information is "understood" by the receiving machine. This standard handles information related to order entry, scheduling, medical record and image management, patient administration, observation reporting, financial management, and patient care transactions.[1]
For example, an HL7 formatted message delivering data about a patient's EKG would be written like this: "OBX2ST93000.1^VENTRICULAR RATE(EKG)91/MIN60-100". Here's what it means:
- OBX = The message is a report of an observation/result
- 2ST = The data value is a two character string
- 93000.1^VENTRICULAR RATE(EKG) = The code number and name of the EKG test
- 91/MIN = The observation value and units (beats/minute)
- 60-100 = The reference or normal range for this test.
Note that this HL7 message standard just provides a message structure (syntax), i.e., the use of pipe symbols ("") to separate message elements, and the order in which the elements appear; none of the content (codes, terminologies, values) is defined by this HL7 standard. Also note that the next version of HL7 (version 3) will be tied to specific terminologies, thereby adding semantic capabilities that enable different data systems to communicate with each other.
HL7 Version 3 messages are XML documents, which use a very complex and verbose structure of "markup tags" to identify the data values. These tags are strings of characters surrounded by angle brackets, which are depicted in the figure below. The figure is a small section of an HL7 clinical document in XML, which includes the use of the SNOMED CT terminology standard in which the terms "Osteoarthritis", "finding site" and "right knee" are used to define the medical history note that the patient is "complaining of disabling osteoarthritis of the right knee."[2]
The beauty of XML is that anything can be defined using the markup tags. A down side is that XML if very inefficient. For example, in the XML document above, it takes about 700 characters to record an observation that's only about 100 characters in length. Furthermore, such XML documents are complex to write and difficult for humans to read.
This concludes my description of standards used in healthcare. In the
next post, I'll delve into the problems with today's standards and will the offer innovative strategiesfor solving those problems.
References:
[1] http://en.wikipedia.org/wiki/XML
[2] Dolin, R.H., et. al. HL7 Clinical Document Architecture, Release 2. J Am Med Inform Assoc. 2006 Jan-Feb; 13(1): 30-39.
In the previous post, I discussed "care measurement and process standards," which are data standards dealing with diagnosing health problems, determining treatments, and assessing care quality and provider performance. [ C lick here for first post in series ]
In this post, I turn to technology standards, and to "messaging format" standards in particular. Whereas data standards focus on making information understandable and useful to humans, messaging format standards focus on enabling the exchange, or interoperability, of data and information (i.e., "transactions") across healthcare systems.
HL7 Messaging Standard
The Health Level Seven (HL7) Messaging Standard is the most recognized. It specifies the technical aspects of sending messages so that one software program can exchange information with another, so the information is "understood" by the receiving machine. This standard handles information related to order entry, scheduling, medical record and image management, patient administration, observation reporting, financial management, and patient care transactions.[1]For example, an HL7 formatted message delivering data about a patient's EKG would be written like this: "OBX2ST93000.1^VENTRICULAR RATE(EKG)91/MIN60-100". Here's what it means:
Note that this HL7 message standard just provides a message structure (syntax), i.e., the use of pipe symbols ("") to separate message elements, and the order in which the elements appear; none of the content (codes, terminologies, values) is defined by this HL7 standard. Also note that the next version of HL7 (version 3) will be tied to specific terminologies, thereby adding semantic capabilities that enable different data systems to communicate with each other.
HL7 Version 3 messages are XML documents, which use a very complex and verbose structure of "markup tags" to identify the data values. These tags are strings of characters surrounded by angle brackets, which are depicted in the figure below. The figure is a small section of an HL7 clinical document in XML, which includes the use of the SNOMED CT terminology standard in which the terms "Osteoarthritis", "finding site" and "right knee" are used to define the medical history note that the patient is "complaining of disabling osteoarthritis of the right knee."[2]
The beauty of XML is that anything can be defined using the markup tags. A down side is that XML if very inefficient. For example, in the XML document above, it takes about 700 characters to record an observation that's only about 100 characters in length. Furthermore, such XML documents are complex to write and difficult for humans to read.
This concludes my description of standards used in healthcare. In the next post, I'll delve into the problems with today's standards and will the offer innovative strategiesfor solving those problems.
References:
[1] http://en.wikipedia.org/wiki/XML
[2] Dolin, R.H., et. al. HL7 Clinical Document Architecture, Release 2. J Am Med Inform Assoc. 2006 Jan-Feb; 13(1): 30-39.