Figure 1: Generation process of the HL7 implementation
Today, there exist some tools which are dedicated to the OSI concept, most notably the ISODE, which is an almost complete development environment for OSI applications. Thus it seemed at the first glance appropriate to transform the HL7 notation to ASN.1 and feed the latter code to the various tools of the ISODE including the structure generator (pepsy) and the remote operation stub generator (rosy). However there is one single point which inhibits this rather convenient way to go:
ISODE supports only the OSI basic encoding rules (BER). Furthermore there is currently no other ASN.1 compiler, which supports the HL7 encoding rules. Even though, the HL7 encoding rules were meant as an `interim standard' for use until OSI standards are available, it is now a major point that makes it hard for the HL7 world to migrate towards OSI. Most existing HL7 applications use the HL7 encoding rules, and for compatibility, new HL7 applications will keep doing so.
Because HL7 encoding rules have several disadvantages (KUPERMAN (1991), p. 179) which will cause them not to survive for many years, adding support for HL7 encoding rules into existing ASN.1 compilers (ISODE or SNACC), though possible, seems not to be worth the effort.
This implementation has developed (and is still about to develop) its own means by which the program objects are automaitcally derived from the documenting text of the standard. Since the author of this paper happened to have the text of the HL7 specification in ASCII files, there was a reasonable chance to go this way from the very beginning. Before we start going along that way step by step, we'll first take a look on it from above. Figure 1 shows the process of generation of the implementation.
Figure 1: Generation process of the HL7 implementation
Let us start from the end, and answer the question where we want to go: We want to end with a set of definitions which are expressed in a common programming language plus an object library, which provides the actions corresponding to the definitions (the implementation in the closer meaning). This shall be further usable by applications to be built or to be extended with the HL7 interface. There is a need of compatibility in terms of platforms on which the programs are to be running if this implementation shall once pay off its effort.
The programming language that was cosen is C++. The important advantages of C are its widespread propagation on small computers like PCs as well as on workstations and minicomputers along with the naturally embedded operating system interfaces especially on UNIX platforms provide a base for compatible as well as efficient code. These advantages are shared by C++ since C++ is derived from C. Moreover, C++ provides new and powerful technologies of software design which we want to make use of here.
The steps towards the C++ code are taken by various means and methods. First we extract meaningful information from the HL7 document, this is done with AWK. The since most of this information is presented either in tables or in a simple formalism capable of expressing the message syntax, it is appropriate to process these information further by a method which is capable of handling both, relations and grammars. Prolog on the one hand expresses information in terms of relations, on the other hand it is powerful (and often used) for handling grammatical data. Moreover, analysis and generation of corresponding data can be mutually achieved by the same code. The tasks that are taken over by Prolog are the check for consistency of the information gathered from the document, and the final generation of the C++ code.
The C++ code is then compiled and packed into an object archive (a library). The C++ definitions in the header (`*.h') files provide the Interface for application programs, that will make use of HL7. It should be possible to provide availability to C programs (and programs of other programming languages also).
Even though, we try to provide an automatical tool of code production from the standard's document which is reasonably general to tolerate future changes of HL7, we however do not intend to make a general purpose compiler for the notation in which HL7 is defined. Remember, that this notation is mainly an unstructured text, which although contains machine extractable structured information, which we try to capture. Furthermore the way this structured information is presented, is unique to HL7 and not backed by any standard. So there is little use of a general purpose compiler for that notation. We rather keep the work as specific to HL7 as possible, to minimize work overhead for the sake of unused generality. This includes, that a considerably amount of the code has to be written manually. Again here come the advantages of C++ (over C) for help to minimize software management overhead.