HL7: Standards in Interoperability : Susan Thomas, eHealth
Hospitals typically have many different computer systems used for everything from billing records to patient tracking. In most cases there is little or no communication among them. However, ideally, all of these systems should communicate (or “interface”) with each other when they receive new information.
The HL7 protocol was developed to address this need for data sharing among medical applications. It is a computer communication “language” that allows clinical applications to communicate essential information about patients demographics, medical history, financial information, diagnosis and procedures at different facilities.
Simply put – HL7 provides standards for exchange, management and integration of data that supports clinical processes and patient care, along with management, delivery, and uation of healthcare services.
Features
HL7 refers to the highest level of the International Standards Organization’s (ISO) communications model for Open Systems Interconnection (OSI). The application level addresses definition of the data to be exchanged, the timing of the interchange, and the communication of certain errors to the application. It also supports functions such as security checks, participant identification, availability checks, exchange mechanism negotiations and, most importantly, data exchange structuring.
The HL7 protocol is an ANSI-accredited standard. Although recent advances in technology (such as the use of XML as alternative syntax for HL7) promise to dramatically simplify the implementation of HL7 interfaces, those advances are yet to be realised. When they are done, the hope of “plug and play” interfaces may become a reality. In the meantime, interfaces between ‘HL7 compliant’ vendors are tedious, if not nearly impossible to configure.
Versions of HL7 Standard
Standards are developed by Health Level 7 (HL7), and are used as messaging specifications for exchanging data between health information systems. The various versions of the HL7 standard are as given below:
-
HL7 Version 2.x
-
HL7 2.x Backward Compatibility
-
HL7 Version 3.0
-
HL7 Version 3.0 Resources
HL7 Version 3 is a HL7 messaging standard. Version 3 uses a Reference Information Model (RIM) as a common source for the information content of specifications. As part of Version 3, the HL7 Vocabulary Technical Committee developed methods that allow HL7 specifications to draw upon codes and vocabularies from a variety of sources. The V3 vocabulary work assures that the systems implementing HL7 specifications have an unambiguous understanding of the code sources and code value domains they are using.
The HL7 Version 3 development methodology is a continuously evolving process that seeks to develop specifications that facilitate interoperability between healthcare systems. The HL7 RIM, vocabulary specifications, and model-driven process of analysis and design combine to make HL7 Version 3 as the methodology for development of consensus-based standards for healthcare information system interoperability.
The HL 7 Development Framework (HDF) is the most current rendition of the HL7 V3 development methodology. The HDF documents the processes, tools, actors, rules, and artifacts relevant to development of all HL7 standard specifications, not just messaging. The HDF is expected to encompass all of the HL7 standard specifications, including any new standards resulting from analysis of electronic health record architectures and requirements.
How It Works
When HL7 organizes data from one application or system in order to transfer to another, it does so by placing the information into an Hierarchical Message Description (HMD) and an Implementation Technology Specification (ITS), which forms the actual “coded message” that is transferred. The mechanism for transmitting a message to another system or application is not determined by HL7. Transmission occurs across the Internet via TCP/IP, for instance. (Remember that HL7 is designed to operate in the top Application Level of any network architecture.) An HL7 compliant application or system receiving a “coded message” interprets the data because it understands the various models incorporated in the message structure.
Figure I illustrates the various models and specifications that are used to build the Hierarchical Message Description (HMD). The collection of HMD is how HL7 packages the appropriate data transferred to another HL7 compliant system or application when combined with an Implementation Technology Specification (ITS), such as XML.
Basically, HL7 V3 translates everything into “building block” models which are then transformed into a Hierarchical Message Description (HMD). Once a message is transmitted to another HL7 V3-compliant system, the recipient system is able to interpret the message because it uses the same model specifications.
Advantages of Using HL7
Open Systems vs. Closed Systems
Following a standard protocol proves to be an advantage in connecting to any system that supports this particular part of the standard, both now and in the future. For example, Internet Explorer or Netscape can connect to any existing and future web server using HTTP and HTML standard protocols.
Adhering to a standard protocol is called “open system architecture”. Anybody can interface with an open system using appropriate protocols, independent of its vendor. When using HL7, the interface allows for numerous systems to be added to a single HL7 feed. New systems can be added without having to modify the original source system as demonstrated in figure II and III.
“Closed” and “Proprietary” are used interchangeably to mean that characteristics of the system are hidden by the vendor from public domain. Although the closed-system model is easier to design and initially costs less to implement, closed systems have greater reliability on single vendors and more reliance on specific applications and technologies.
Although the worldwide trend is to follow an open-system architecture, there are still tradeoffs in following a standard protocol when developing interfaces. For instance, a greater initial investment is required. Time and money must be spent to understand the standard and create the infrastructure required to support the standard, such as a parsing framework and networking code.
However, the benefits are abundant. For example, it will be easier to answer user requirements because HL7 is considered the standard for exchanging data between healthcare systems. In addition, because HL7 is the standard, it will be easier to create a system that can interface with an open system now and in the future.
post_id:uld_count:
Cookie not set
Like
Dislike
Value 1: 0
Value 2: 10
