This paper describes the attempt to implement HL7 at the Universitätsklinikum Steglitz in Berlin as part of a larger hospital communication project. The aim of that project is to integrate of heterogeneous computer systems which exist in the various departments of the clinic. This project requires a standardized communication protocol.
The standardization of medical communication protocols is an ongoing effort which is taken on by many different standard groups. Naturally the diverse standard groups have different scopes depending on the special field where each standard has it's origin. Since late 1990, the US standard groups have been associated in the Healthcare Informatics Standards Planing Panel (HISPP) which is coordinated by the American National Standard Institute (ANSI). It's goal is to promote the convergence of the different standards, a process which is still at the beginning. However, as early as 1987 there was one standard group whose objective was to cover a wide range of data interchange in health care, including ADT, Finance and a variety of anciliary fields, like laboratory medicin or radiology.
In Europe, the Technical Board of the European Standardization Commitee (CEN) established the Technical Committee for Medical Informatics (TC 251) in March 1990; one of it's Working Groups (WG.3) is dedicated to health care communications.
Since the implementation of HL7 as presented here is embedded into a project that is seeking the integration of different standards it is conceptualized from a point of view that may be different from those of other implementors who may concentrate on mere HL7. The difference will become evident in the methods taken to build the implementation itself as well as in the final linkage between the communications protocol and the application software. Where it seems appropriate for the implementation which is centered on HL7 to stay completely within the concepts and terminology of HL7, this project seeks to go towards further generality in order to provide concepts and methods to serve as bridges between diverging standards, which are to be released in the same field.
An implementation of a communication standard is essentially a data structure, a builder and a parser. The data structure holds the data objects and reflects their relations among each other as assumed by the standard. The builder is to produce a valid representation of the data structure that is capable of being transported via electronic data interchange media. Finally the parser transforms this representation back into the data structure.
This implementation tries to assume models and methods of todays informatics technology. It's design is object oriented and is implementeted using C++. The code of the implementation is produced by a compiler whose input is a database which specifies the standard. The database is in turn compiled semi-automatically by scanning the text of the HL7 standard as is released by the HL7 Working Group. This method of generating the implementation directly from the textual description has the following advantages: correctness and customizability of both, the parser/builder methods and the definition of the standard itself.
Since the specifying database as well as the program code which implements the standard is not written manually but produced by a compiler, the output is assured to be correct, unless the compiler itself is incorrect. An incorrect compiler, however, will result in erroneous code but the errors tend to occur systematically rather than accidentially and are thus discovered more easily. Thus the method of ProtoGen/HL7 can be used to generate a HL7 reference implementation. On the other hand, it does reveal problems and errors in the standard definition itself, since a compiler will not guess the intended meaning of an amiguous or obviously incorrect passage as a human programmer would probably do.
The input database for the ProtoGen/HL7 compiler is customizable and allows the user to add new data elements quite easily. For example, a special Z-segment that is used by a site can be added to the standard just by adding a single line to the database. The implementation for this special segment is generated fully automatically as is the implementation of the whole standard.
On the other hand, the methods of the parser/builder may be customized in order to provide for different encoding rules or to speed up the implementation or tune it for size. These customizations are, however, not done very often and can currently only be done with a deeper understanding of the compiler itself since this requires the compiler program to be modified. Nevertheless, there are various applications that can be worth the effort ranging from modifications to HL7 coding or processing rules up to the implementation of a completely different standard. Since the UN EDIFACT encoding rules are quite similar to those of HL7 there could be an EDIFACT module added to ProtoGen with only a little to moderate effort.
Finally, the object oriented model of the HL7 standard that this implementation assumes helps to stay compatible with the new developement in the HL7 Working Group (version 3.0) in particular as well as health care data interchange standards of the future in general, such as MEDIX.
A communication protocol for medical applications tends to be rather complex, since medical communication includes a variety of diverse issues, such as ADT (admission discard transfer), accounting, reporting and documentation of findings, querying and ordering etc. In order to cope with this kind of complexity it is necessary to find methods of deriving the implementation from the specification of the standard automatically.
Besides the problem of complexity, modern software engineering has pointed out the need to automate the production and management of software. These concerns are reflected in the modern technologies by which communication protocols are implemented today, and which are formulated by the OSI standard.
In this Introduction we want to take a first look on HL7 and this implementation of it, concerning as to how we can cope efficiently with the complexity mentioned above.