Java API to HL7 Version 3 RIM
HL7 JAVA SIG Co-Chair Dr. Peter Hendler 是我的一个朋友。Dr. Hendler 本人是Kaiser Permanente的医生。以下是他为下周HL7 San Diego 大会准备的一份简介。 参加大会的朋友，如果感兴趣的话，您可以直接到JAVA SIG 去找Peter. 其他朋友如有兴趣，我也可以进一步帮忙搭桥。谢谢。
Java SIG README for demo release, September 9, 2005
About the Java API to HL7 Version 3 RIM
---------------------------------------
HL7 Version 3 messages are all derived from the object-oriented data model called the RIM
(Reference Information Model).
There are a few dozen base RIM objects including ACT, PARTICIPATION, ROLE, and ENTITY.
The data model also includes various complex data types that are classes themselves with
methods as well as data.
Every domain (pharmacy, lab, clinical notes, administration) is free to subclass the main
RIM classes into more specialized "clone classes". For example, a blood glucose is a clone
of observation which itself is a clone of ACT.
Because the number of clone classes is extremely large and growing all the time, it would
not be practical for an API to include all of them.
The Java SIG made an early decision to limit our data model to the base RIM classes.
Any clone classes can be represented by their parent in the RIM. This allows our data model
to be stable without the need for endless updates or an unmanageably large data model.
When an HL7 domain committee such as Laboratory or Orders and Observations wants to create
a new message, for example glucose measurement, it creates a model of this message using
the classes and data types defined in the RIM. Then, using special tooling, it can generate
a definition of the message. Currently there are two formats for the meta-information that
defines a message type. The older one is called an HMD (Hierarchical Message Definition),
and the new one is called a MIF file (Message Information File). The HMD is being deprecated,
so our API is also changed to focus mainly on MIF files.
In order to convert a RIM model to its corresponding HL7 XML message instance, you need to
know the order of serialization of the classes, as well as the data types and values.
Similarly, in order to convert an HL7 V3 message instance into a RIM representation
(which we call a RIM graph), you need the meta-information included in the HMD or the MIF files.
There are two approaches to implementing these tasks. On the one hand, if your application
will rely on only one or a very few message types, then you can hard-code the meta-information
into your application. This is easy and fast but has the disadvantage of working only on the
few message types for which the application has been written.
On the other hand, a more versatile but more complex approach is to build a generic API that
can be fed both MIF files and message instances. In this approach an application can
intelligently know how to handle the message and thus load it into memory in its RIM graph
representation. Additionally -- and most usefully -- this information, once in memory, can
automatically be "persisted" into a database; no real-world applications deal only with
temporary data in memory that disappears as soon as the application exits.
So an ideal API for dealing with HL7 V3 XML messages should have the following features:
- It can handle any new or unknown type of message as long as the MIF file were available.
- It can transform an incoming XML message into a RIM graph representation in memory so that
the application can perform any required business logic.
- It can persist the RIM graphs to a database.
- In reverse, it can reconstruct the RIM graph from the database.
- It can create a new HL7 V3 XML message from the in-memory representation.
The Java SIG's project, the Java API to HL7 Version 3 RIM, has been in development since 2002.
This README introduces a demo version of our API. The API has all five of these features.
The object-to-relational database mapping is accomplished with the open-source Hibernate technology.
Running the Java API to HL7 Version 3 RIM Demo
----------------------------------------------
In order to run this demo, you must have ant and Java 1.5 pre-installed on your computer,
and you must set the environmental variables ANT_HOME and JAVA_HOME. (Naturally, you must be
somewhat familiar with Java and with ant.)
There are two demos in this package. One of them consists of the following ant targets:
loadDataMif
loadDataMif3
loadDataMif4
The first one, loadDataMif, parses an XML message into memory and then persists the message
into a database (Hypersonic database included with this demo). It then reverses the process
by re-creating the message from the database and outputting it to the screen.
As soon as this target has finished running, you can inspect the database by running a GUI tool.
Bring up the tool by running this ant target:
hsqldbManager
When the SQL manager starts up in its GUI window, select File->Connect. Then in the URL field
replace
jdbc:hsqldb:mem:.
with
jdbc:hsqldb:demohibernate
You may then enter an SQL statement such as this:
SELECT * FROM _ACT
Then click the "Execute SQL Statement" button. Note that it is not case-sensitive, and you do
not need trailing semicolons.
Once you have inspected the result, close the SQL manager GUI to free the connection to the database.
Thereafter, when you run loadDataMif3 or loadDataMif4 (or both), you append data to the database.
This simulates a real-life clinical situation such as appending lab data to a patient object in a
medical record system. Once you have appended the new data with these ant targets, you can bring up
hsqldbManage again and browse the database to see the new data.
The second demo illustrates how the Java API to HL7 Version 3 RIM can handle any type of message.
The second demo is actually a CDA document, which is based on the RIM, so it is simply just another
flavor of HL7 message.
The ant target to run for this demo is called
demoCDAMif207
It reads a CDA document and constructs the related RIM graph in memory. At this point it opens a
small GUI window that allows you to inspect this memory object. The GUI shows many Java internals
in addition to the CDA-related data, so this ant target provides only a crude way to inspect the
objects in memory (like a debugger).
At this point the program execution is suspended. When you close the GUI, the demo proceeds to the
next stage, in which the in-memory RIM graph is persisted via Hibernate to the database. Once this
has happened, the demo continues and reverses the process: it gets the data out of the database,
re-creates the in-memory RIM graph, and then re-creates the CDA document from the in-memory
representation.
Note that the re-created message is not quite the same as the original. This is because the API may
add some default values. (It may also be because not all the kinks have been worked out! This is a
demo, not a release.) Once this target has finished, then you may open the SQL tool as described
above and browse the CDA data in the database.
Final Words
-----------
The five features of the "ideal" API listed above are necessary for any significant clinical
application that is based on HL7 V3 messaging. There are significant person-years of effort
invested to bring the API to its current state. For developers who are more interested in
developing the specific functionality of a clinical application, and less in spending years
of effort building the "plumbing" of HL7 V3 messaging, using this API instead of trying to
duplicate its functionality from scratch should make their efforts noticeably more productive.
We believe that the Java API to HL7 Version 3 RIM is mature enough to release this demo, but
it still requires code clean-up and quality testing before it is ready to use "as is" to
develop a production application.
We are releasing this demo in order to introduce the functions and purpose of the API and,
if we're lucky, to recruit a few more committed developers who would like to contribute to
this effort.
Thank you for your interest.
Peter Hendler
Todd Freter
Java SIG co-chairs
September 9, 2005
