This is the home page for the HAPI project. HAPI (HL7 application programming interface; pronounced "happy") is an open-source, object-oriented HL7 2.x parser for Java. HL7 (http://hl7.org) is a messaging specification for healthcare information systems. This project is not affiliated with the HL7 organization; we are just writing some software that conforms to their specification. The project was initiated by University Health Network (a large multi-site teaching hospital in Toronto, Canada).
A new beta (1.0-beta1) of HAPI has been uploaded to the downloads area. This should allow people to try out some of the new features that are coming up, and to report any bugs that are found.
This release features an overhaul of PipeParser, various speed improvements, and a number of new convenience methods, all of which are outlined on the what's new page.
Also worth mentioning, a new release of hUnit has been released as well. The new release features shiny new UI for defining tests.
A few announcements on the HAPI front:
OSGi Support
I wanted to let you all know of an exciting new development in the HAPI world: the development of a set of OSGi bundles, enabling HAPI to be deployed in an OSGi container.
Development is ongoing, led by Niranjan Sharma from GE Healthcare. At this point, we have a mostly working set of unit tests and a basic plan of attack for getting the bundles to do something useful. Naturally, HAPI's use of reflection and a few scattered classloaded resource issues are causing some minor hassles, but I'm sure it can all be worked out.
If anyone is interested in contributing some time in development, testing, documentation, etc., please by all means get in touch with either myself or Niranjan. I'm really excited to see where this is all leading, in my opinion (and many others) OSGi is the future of Java, and it will be really nice to see HAPI playing well in that sandbox.
Upcoming Version of HAPI
Just to keep anyone who is interested posted on the development of the core HAPI library, a new version is in the works. I'm still not sure when it will be released, but it is looking promising. Two major things have changes for this cycle:
hUnit
hUnit, a new subproject of HAPI, has finally come along far enough for some public consumption. hUnit is an HL7 application unit testing framework, currently geared towards unit testing HL7 ESB applications (i.e. message transformations within interface engines) as well as message procesing applications. hUnit has been developed at UHN to provide repeatable unit tests for our JavaCAPS HL7 message translations, and we are quickly adding features to support our internal needs. At this point, it is starting to become stable enough that it could be publicly consumed- stay tuned (or get in touch if this sounds like something of particular interest to you).
Check it out at hUnit's Site.
HAPI 0.6 has been relased! This release is the first release incorporating support for HL7 v2.5.1 and v2.6.
Note that a number of things have changed with this release:
We owe a huge thanks to Frank Oemig and Karen Van Hentenryck for their help in providing an updated HL7 database, from which HAPI's source libraries are built.
There are several ways you can get involved and help this project along. See details here.
Please send development-related questions to the mailing list at mailto:hl7api-devel@lists.sourceforge.net. For anything else, please contact mailto:jamesagnew@users.sourceforge.net
HAPI is a parser and encoder for HL7 version 2.x messages. HL7 is a widely used messaging specification for healthcare information systems. For more information on HL7 please visit hl7.org.
Prior to HAPI, we parsed HL7 messages using very generic objects (e.g. "Message", "Segment"). However there are many different types of messages and segments defined in the HL7 specification. Each has a different structure, of which the generic objects were unaware. This made development very slow, for the following reasons:
The HAPI object model defines Java classes for every HL7 2.x data type, segment, and message. This means that we can take a lot if mistakes that previously would have resulted in invalid messages and turn them into compile-time errors or Java Exceptions, which are apparent much more quickly. For example, to create an ADT_A01 message (a message that a registration system sends when a patient is admitted to hospital), and set it's time to right now, we would use code like this:
ADT_A01 testMessage = new ADT_A01();
testMessage.getMSH().getDateTimeOfMessage().setValue("foo"); //throws exception because "foo" is not a valid date
testMessage.getMSH().getDateTimeOfMessage().setValue(ValidTS.toHL7TSFormat(System.currentTimeMillis())); //OK
// ... set other fields ...
Parser parser = new PipeParser();
existingWriter.write(parser.encode(testMessage)); //assuming "existingWriter" belongs to a socket that points to a remote system
If it compiles and runs without error, we know the message structure is valid. Likewise, when incoming messages (from other systems) are parsed, we do not have to check the message structure ourselves because the parser throws meaningful exceptions if there is a problem. The other advantage of encoding message structures directly in Java is that we can use code completion and JavaDocs most of the time, instead of flipping through the specification.
The API is composed of a group of core classes that are hand-written, and hundreds of version-specific classes that are generated automatically. The automatically generated classes correspond to specific messages, segments, and datatypes. HL7 defines all of these components in a relational database. We have simply written scripts that create Java source code from the database entries (see ca.uhn.hl7v2.sourcegen.SourceGenerator) instead of writing all of this code by hand.