JavaSIG - HL7



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.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download