Download Document 853608

Java SIG Goals
This document expresses the design goals for the HL7 Java SIG and its API. Our goals
are not necessarily limited to those described here. We are open to suggestions, but the
functionality described below appears to be necessary and basic to a Java API that will
facilitate the development of HL7 v3-compatible applications.
Our API will include three groups of classes and will provide four types of functionality.
In addition to the API we will supply a reference implementation and some simple
example applications.
Data types
The API will include classes that represent the HL7 v3 data types. These data types are
specific to HL7 and require functions that are not trivial to implement. For example, Java
provides for collections such as Vector and HashMap, but these collections can only store
objects of type java.lang.Object. When retrieving an object from a standard Java
collection, one must cast the object to its true type. Our API uses an extension to Java
(which will become standard in Java 1.5) that allows for generic data types or “pre-cast”
collections. Objects retrieved from these collections are already cast to the correct object
type.
The PQ or Physical Quantity data type can illustrate another difference between HL7 data
types and standard Java data types. Different countries use different units of measure, for
example centimeters vs inches. In lab observations the substance being measured may not
be represented with the same units in different countries or even different institutions. If a
data type implements an “equals()” method, it should return true if the actual quantity
referred to is equivalent, even if it is expressed in different units. These are two examples
illustrating why HL7 data types must be implemented specifically and why one cannot
use native Java data types to implement the intended functionality. The first group of
classes in our API will implement HL7 data types.
RIM classes
The Reference Information Model (RIM) represents thousands of person-hours of
development work. Various committees of domain experts have determined the optimal
object data model to represent the domain of healthcare. Any healthcare application
developed in Java will require an internal object data model. Therefore, the second
package of the Java SIG API will implement the RIM. Subclasses of the RIM, such as
DMIMs become too numerous and are constantly being developed. It would not be
practical to include DMIMs in an API because it would never be up to date. Because
DMIMs and all other specialization’s are all subclasses of the RIM, they can be derived
by extending RIM classes. A Java specification of the RIM will insure that Java
applications using this API will all share a similar object data model.
Utility classes (HMD loaders, message builders and
message parsers)
One of the main functions of HL7 is to define the messages that healthcare applications
use to communicate. In version 3 these messages will be defined by Hierarchical
Message Definitions (HMDs), which are built from graphs of RIM-based objects. XML
is the native format for HL7 version 3 message, and XML provides a format that is
particularly attractive for Java applications. The API being developed by the Java SIG
will have the ability to load an HMD specification (in the form of an XML document).
Once loaded the resulting utility classes will be able to refer to an in-memory graph of
RIM objects, and build an XML message. This message can be sent to a receiving
application, which will also use the Java SIG API. On the receiving end, a message parser
utility will be able to reverse the process and will be able to re-create the RIM object
graph from the HMD specification and from the XML message received from the
sending application. The third group of classes will therefore consist of the HMD
loaders, message builders, and message parser utilities that will make this functionality
possible. Using other format specifications (such as XML documents that specify the
format for CDA documents), the same classes will be able to create and parse CDA
documents.
Four types of functionality will automatically result from the above described API.
We
will provide the API for a common object data model that can be shared between
Java applications developed by different vendors and institutions.
The
API will provide the functionality needed to create, send, and receive HL7 v3 XML
(or other format) messages.
The
API will allow applications to transfer object models from within one application’s
memory space to another.
The
API will provide functionality to create and parse CDA documents.