The HL7 protocol generator being implemented should provide at least three services:
The result of this (sub-) project is a HL7 information base in Prolog, and a code generator, which produces C++ code for a HL7 Class Library for HL7 version 2.1. The above three requirements have been successfully met. The system that resulted from this work has got the name ProtoGen/HL7.
However, the latest experiences with the Class Library and discussions with HL7 e-mail list fellows have pointed out the need to support even further abstractions: While ProtoGen/HL7 is now much centered on static data modelling, I plan to emphasize operational aspects of HL7 in the future. A first step would be to add actions (events) to the Message classes. An other idea is to generate a remote procedure stub for each HL7 event. Thus an application programmer would not deal with the concept of a message (e.g. ADT^A01) anymore. (S)he would rather call procedures on given data (segments) which return results when result data is expected as in case of queries. However, instead of sending an ADT^A01 message and waiting for an ACK message, a single call to a function declared as
On the other hand, I am about to gain experience in applied HL7 standard in the real world, which is quite different from just implementing a library. I connected a proprietary HIS which came with a tiny HL7 interface, a self made DOS/dBase application which manages administrative patient data in the same departement. Then there is an Institution wide patient data server that I will integrate, as well as a laboratory roboter as an example of anciliary data communication. I was even thinking about radiology data, but there are technical as well as administrational difficulties.
One main handicap in the applicative part of my project is, that there are so few applications that already have HL7 interfaces. Actually there is currently only one. Thus, beside the communication server, there is a lot of need to develop HL7 communication endpoints.