The VMDB Veterinary HL7 Project is an open-source project to provide a code library to support veterinary medical messaging using the HL7 (Health Level 7) standard. Project documentation, source code, and products can be downloaded from, and developers can contribute to the project at the project homepage on SourceForge https://sourceforge.net/projects/vmdbhl7/
The premise behind HL7 is simple. If the software supports an interface standard, one set of interface routines can be written and then used with every other system needed to interoperate with it. Without the standard, routines must be written for each different system.
The reality--at least for veterinary medicine--has been much different. We keep seeing each system being hand coded to talk to one other system at a time. This sometimes even uses a standard or standards, but they are still all one-of-a-kind interfaces. None of the "network-effect" savings are being realized.
The HL7 standard has the capability of handling all the interactions any of our systems need to perform. And once one HL7 interface has been built, much of the work can be reused for other applications. But the standard is large and complex, and only very carefully matched implementations consistently interoperate. (HL7 and HIMSS have been working hard on interoperability testing of human medical systems to address this issue.) In veterinary medicine we are unlikely to ever have more than a small handful of HL7 experts. And most of our system vendors can ill afford to employ one even part-time. It looked pretty hopeless that we, as a profession, would ever be able to gain the full benefit of standards like HL7.
From this quandary was born the idea that component software design might offer a solution. If we could collaborate on the design and development of a software library to serve as the profession's reference implementation of HL7, we could gain interoperability while saving all of us who write applications for use in veterinary medicine from having to reinvent this very complicated wheel. I had some free time, and the core of a design, so I set out to produce a first rough draft of such a library. It is my hope that this will serve as the first pebble in a "stone soup. " The soldier in the old story inspired the villagers to each contribute a small but important part of what became a cauldron of soup big enough to feed the village. As a collective effort, this project has the potential to feed our need for standardization with no one individual or company having to invest more than they can afford.
The library is built upon some basic software design principles.
Abstraction: The "outside" of the library should present an interface that makes sense in the problem domain of the users (application developers in this case). The "inside" implementation should be independent of the outside interface.
This gains us at least two advantages. First, the application developers don't have to learn the ugly details of the implementation; neither the HL7 nor the actual library implementation code. Second, assuming the implementation isn't perfect, we can keep working on improving the implementation even as the users start working with the interface. Our fixing the implementation won't break their applications because the interface remains constant.
Recursive Composition: This is the "parts is parts" principle. HL7 consists of a large, but finite, number of data types, segments, and messages, that can be combined to produce an infinite number of applications. We want to define each component once, and build the larger components by combining these smaller objects. An object-oriented language such as Java or C++ supports this design easily.
System Independence: Unlike a purely single-enterprise application, we cannot dictate that our software will always be run in the same operating system, type of machine, or programming language. We must therefore try to support as many situations as is practical. In some cases this will require parallel development in multiple languages or porting from one to another. To the greatest extent possible this will retain identical interfaces in all versions. For systems that cannot support an object-oriented library, we will attempt to design a procedural subset of the library following as closely as possible the full interface. Initially, this involves a port from Java to C++. A planned command-line interface will allow most of the high-level methods to be called as commands via standard input and output. Other wrappers, object code packaging, and language ports (Microsoft's .NET?) will be considered as they come up and as support for development is available.
Validation: We will try to ensure that the generated HL7 will be correct according to both the standard and any veterinary-specific implementation rules, and any HL7 that is correct by the above standard will process properly. (Some unusual but legal elements may be ignored, but cannot "break" the implementation.) Also, HL7 that is not legal by the above standard will result in an error being indicated by an error return value, exception, etc.. (Further development is needed especially in validation of messages being built through the API. They must currently be re-parsed in order to be validated.)
Getting started: The best documentation available is currently the Javadoc web pages available for download from the project site or on-line at http://vmdbhl7.sourceforge.net/docs/index.html This documents all of the public interfaces and can be overwhelming. For a (relatively) quick introduction, read the overview and then navigate to the ORUMessage object. This is the highest level interface and provides 90 percent of what an application developer will use.
Application developers are welcome to work with the library at any time. To do so simply download a copy of the source code product. Please be aware that we are being honest about the designation "pre-alpha." Now is a good time to use the library in test code, experimentation with new features, etc. Because we are early in the design process, your feedback is sought and your suggestions are more likely to be incorporated quickly. Besides the requirements of the LGPL license, we ask that you provide us with feedback as to your experience. Of course if you'd like to contribute to the development of the library itself you are very welcome. To do so read on.
To contribute to the project, you will need a free account with SourceForge https://sourceforge.net/account/register.php. Once you have an account, contact one of the project administrators to be added to the developer group. You can then use CVS to check out and submit changes to the library. CVS Instructions
Library development will progress simultaneously "top down" and "bottom up." An interface design team weighted heavily in favor of application programmers, HL7 standards experts, and health information managers will evaluate the current interface and suggest refinements and additions. As new message sets are proposed, this group will design the high-level interface in domain-specific language. Releases of new interface definitions will be infrequent and thoroughly reviewed prior to release. Any methods removed from the interface will be deprecated for at least one major release prior to being removed. (During the pre-alpha stage we will be less strict on this.)
The implementation development will proceed with the "bottom up" development of the basic parsing and building machinery. Early attention will be paid to ensuring that individual components are correctly validated. This may lead to feedback to the interface design team on issues such as exception handling. Later development will focus on improving efficiency. To avoid maintaining multiple sets of documentation, the Java implementation will be the primary reference. The Javadoc comment tags will be used to document all methods. Additional comments and files will be added as needed to explain any language port-specific differences. (How to document methods that exist in a port implementation but not in Java is still an open question. In some cases, we may add the methods to the Java implementation simply to maintain consistency.) Individual developers may elect to contribute to the Java implementation, one or more ports, or both. If new functionality is added to a port before it exists in the Java, stub methods must be added to the Java as place-holders. Releases of the implementation will take place as often as needed to provide the best possible working code.