The HL7 Standard, the HL7 API, and the HL7

 

Message Profile Constraint Analyzing Tool

 

David Kong, 372-8620

 

CISC 499*

 

Queen's University

 

August 2002

 

TABLE OF CONTENTS

 

 

I.                   INTRODUCTION

 

II.                THE HL7 MESSAGE STANDARD

I.                    What is HL7?

 

II.                 Why use HL7?

 

III.               The HL7 Message Structure

 

IV.              Transmission of HL7 Messages

 

V.                 Further Information on HL7

 

 

III.             THE HL7 API (HAPI)

I.                    The HL7 v2.x Parser API (HAPI)

 

i.                     The HAPI Message Model

ii.                   The HAPI Source Code Generator

iii.                  The HAPI Parser/Encoder

iv.                 The HAPI Sample Interface Application

 

II.                 Examples of HAPI Use

 

III.               HAPI - Future Goals

 

 

IV.              HL7 CONFORMANCE – MESSAGE PROFILES

I.                    The Need for Conformance

 

II.                 HL7 Message Profiles

 

i.                     The Structure of a Message Profile

ii.                   Customizing Message Profiles

 

III.               Ensuring Message Profile Conformance with HL7

 

 

V.                 THE HL7 MESSAGE PROFILE CONSTRAINT ANALYZING TOOL (CAT)

I.                    The Problem

 

II.                 The HL7 Message Profile Constraint Analyzing Tool (CAT)

 

i.                     Message Profile Constraint Rules

ii.                   Sample Message Profiles

iii.                  The Parsing Application

iv.                 Message Profile Storage Data Structure

v.                   Message Profile Validation – Traversal Method

vi.                 Representation of Message Profile Constraint Rules

vii.                Constraint Rule Application in the Constraint Analyzing Tool

 

III.               The Code

 

IV.              Technical Details

 

V.                 Future Considerations

 

 

VI.              REFERENCES

 

VII.           APPENDICES

A.                 Original Project Proposal

B.                 BNF Representation of Common HL7 Message Event Triggers (Appendix D, HL7 Standard v2.3.1)

C.                 HAPI Message Object Model Components

D.                 HAPI Sample Application Architecture

E.                  The HL7 Conformance DTD

F.                  Message Profile Constraint Rules

G.                 Sample Message Profiles

H.                 UML Diagrams – Constraint Analyzing Tool

I.                    Javadoc - Constraint Analyzing Tool

J.                   Source Code – Constraint Analyzing Tool

K.                HL7 Version 2.5, Chapter 2.

 

 

VIII.        FINAL REMARKS

Introduction

 

            As more healthcare organizations choose to implement computer-based healthcare information systems, the data that used to be consolidated in a paper-based medical record becomes partitioned between the information systems.  Although this partitioning is ideal from a database perspective, clinicians require a unified collection of medical data in order to provide quality healthcare.   As a result, healthcare organizations have begun to integrate their information systems, and are discovering that many of their systems are not compatible, and a standard protocol to exchange data is required.    An example of such a protocol is the HL7 Message Standard, a globally recognized messaging standard for exchanging healthcare data.

The purpose of the CISC 499* project was to investigate the HL7 Message Standard, to review the HL7 API (HAPI), an open-source parsing/encoding API for HL7 v2.x messages, to examine how HL7 messages are currently being tested for HL7 conformance, and to develop a tool that would automatically validate whether an HL7 specification conforms to the HL7 Message Standard.

 

 

 

The HL7 Message Standard

 

What is HL7?

            The Health Level 7 (HL7) Standard is an ANSI-accredited specification for describing healthcare information in a structured and domain-specific way, facilitating the exchange of healthcare data between two or more healthcare information systems (Blobel, Dudeck, & Heitmann, 1999).     Developed in 1987 by volunteers at Stanford University Hospital, it has since been established as worldwide standard for healthcare data exchange.

 

Why use HL7?

            To reduce costs and improve quality of care, an increased number of computer-based information systems are appearing in healthcare organizations.  Unfortunately this often partitions healthcare data, which conflicts with a clinician's desire to access all patient information from a single source.    Thus, to achieve this unified clinical environment, the information systems must be integrated, and a common protocol for data exchange is required.  The HL7 Standard provides this capability because it standardizes message structures (abstract message definitions of how data should be formatted), it describes how messages should be transmitted (encoding rules), and it defines standard trigger events that generate HL7 messages (e.g., a patient is admitted) (Blobel et al., 1999).  As well, it allows for modifications of the Standard to suit an organization's needs.   This is advantageous because it increases data consistency and reliability, and having a common message protocol minimizes the number of interfaces that are needed to integrate the systems.  Overall, system integration will be faster because development, analysis, and implementation time is reduced.

 

The HL7 Message Structure

HL7 messages are modeled after real-life events occurring in a healthcare organization (Blobel et al., 1999). For example, when a patient is admitted into a hospital, patient demographics are obtained (e.g., name, date of birth, address information, etc.) and recorded in the patient registration system.  The event "patient admission" leads to the exchange of data between the patient registration system and another system, so patient demographics are made known to other system (e.g., a laboratory information system).  This event is called a trigger

event in HL7.   See Figure 1 below.

Figure 1.  A trigger event initiating data exchange between two systems.

 

An HL7 message can be generated from each trigger event.   In this case, an ADT_A01 HL7 message would be created.  There is an extensive range of trigger events described by the HL7 Standard.  These include events based on ADT (patient admit/discharge/transfer), database queries, order entry (e.g., pharmacy orders, laboratory orders, etc.), finance (e.g., tracking the costs of laboratory tests), results (e.g., laboratory results, etc.), medical record documentation (e.g., dictated notes), scheduling, patient referrals and patient care events.  An HL7 message is defined as the single unit of information that gets transferred between information systems.  It consists of several message segments, where each segment corresponds to a set of related data (e.g., patient address information, patient laboratory results, etc.). 

The presence of most message segments is dependent upon the trigger event that generated the message.   For example, if a patient admission trigger event occurs, one would not expect to see laboratory result segments in the HL7 message.   A special case is the MSH segment, or message header segment, which is always present in a message (HL7 Organization, 1999).  It defines the message type, the trigger event type that caused the message to be sent, and the separator characters used when defining the message components.  In Figure 2, the three-letter code "ADT" signifies that this message was a result of an admit/discharge/transfer trigger

event.

Figure 2.  An example of HL7 message structure.

 

            A message segment is a logical grouping of data fields.   Shown in Figure 3, segments can be required or optional, and may repeat.   Segments are identified by a three-letter code located at the beginning of the segment, and are followed by the group of data fields.  A segment separator, usually a carriage return, separates each segment in a message.

            The content of the message is transferred in the fields of a segment.  Fields can be of variable length and are distinguished by a data field separators (e.g., "|").   They can be required or optional, and individual fields can be repeated.  Fields also can refer to specific HL7 code tables for their values (e.g., a given field may reference a table of country codes), and are given unique numeric identifiers and a name.   Figure 3 illustrates a field in a message.

Each field has an HL7 datatype assigned to it (e.g., ST = String, TS = Time Stamp, etc.) These datatypes can be primitive (single datatype) or compound (composed of several datatypes, including compound ones).   Compound datatypes are separated by a component separator (e.g., "^").  For example, the value of an "MO" or "money" datatype consists of a numeric (NM) primitive datatype, a component separator, and an HL7 coded value (ID) primitive.


Thus, a "MO" datatype in a field would have the following structure: |<quantity (NM)>^<denomination (ID)>|.   Therefore, $500.00 USD would be represented as |500.00^USD|.  Figure 3 shows a compound field.

Figure 3.  A message segment, with its component parts highlighted.

 

Transmission of HL7 Messages

HL7 messages are transmitted using a lossy message transfer protocol (acknowledgement-receipt), where it is assumed that the network is error-free, complete transmission of the message will occur, and that there are no restrictions on message length (Blobel et al., 1999).  If this is unavailable, HL7 messages can be "wrapped" in other protocols, such as the ASCII lower-level protocol, Simple Object Access Protocol (SOAP), and eXtensible Markup Language (XML).

 

Further Information on HL7

            The complete v2.3.1 HL7 Standard can be found on the accompanying CD, or on the HL7 Organization web site at www.hl7.org.   A BNF representation of some common HL7 message event triggers can be found in the Appendix B.

 

 

The HL7 v2.x Parser API (HAPI)

 

What is HAPI?

            Traditionally, when a developer is creating an HL7 interface application, he/she must create an object model to store the message elements, create a custom parsing object to parse and encode HL7 messages, and create an object that facilitates data transmission between two information systems (e.g., a TCP/IP client-server interface).   As well, the developer must frequently refer to the "developer unfriendly" HL7 Standard document to ensure the interface application is HL7 conformant.   This process is often time-consuming and costly for healthcare organizations, and sometimes exceeds the budget of smaller healthcare organizations.

            The HL7 API (HAPI) addresses the requirements for parsing, encoding, encrypting, and handling of HL7 v2.x messages in JAVA (Tripp, B., 2002a). It was conceived by a group of developers at the University Health Network (UHN), led by Bryan Tripp, and has since been released as an open-source project on Sourceforge.net.  HAPI defines a set of generic constructs in the form of abstract JAVA classes and interfaces, that process and handle HL7 messages.  This allows developers to implement existing HAPI classes, or extend the abstract classes and interfaces to build new objects.  As well, HL7 messages are described as JAVA objects (java.object.class) rather than being placed in a data structure of generic objects.  Thus, developers can directly access the message, its constructs, and its data, using pre-defined objects.

 

The HAPI Message Model

The HAPI message model is a set of interfaces, abstract JAVA classes, and utility classes that describe a generic HL7 message construct.  By using a JAVA object model, the HAPI message model offers an object-oriented representation of an HL7 message, and provides useful error trapping and logging capabilities (i.e., if a data type mismatch occurs in a field that is nested in several layers of message segments, a JAVA exception can be thrown immediately to identify exactly where the error has occurred).    An HL7 message construct consists of a message object, segment objects, group objects (to represent segment groups, fields, etc.), datatype objects, primitive objects, and composite objects (objects that are made up of more than one primitive object).  Figure 4 illustrates the basic HAPI message object model.  A description of the components in the HAPI message object model can be found in Appendix C. 


Figure 4.  The HAPI message object model.

 


In order to create a particular instance of a HL7 message in HAPI, the desired message object must be instantiated and populated with the necessary data.  For example, if one wished to create an acknowledgement message object and transmit it, the JAVA code (Tripp, B., 2002a) would look like:

ACK testMessage = new ACK(); // create a new Acknowledgement HL7 messagetestMessage.getMSH().getDateTimeOfMessage().setValue(ValidTS.toHL7TSFormat(System.currentTimeMillis()))); // set the Date and time of the message in the message header

//…

// fill in more fields as necessary

//…

// create a new parser object to encode the ACK object.

Parser parser = new myParser();

myWriter.write(parser.encode(testMessage));

// where myWriter is an object that will transmit the encoded message object to a remote system

 

 

The HAPI Source Code Generator

HAPI does not include the message objects for a complete definition of an HL7 specification.   They must be created prior to use, either manually or by using the source code generator tool supplied in the API.    The source code generator tool is large script that reads HL7 specifications that are in a given format (e.g., a normative relational database), and generates the related HAPI message objects.   Currently, the source code generator tool works with commercially available HL7 normative databases.  Support for HL7 message profiles, a new format for defining HL7 specifications, will be included in a future version. 

 

The HAPI Parser/Encoder

            The HAPI message parser/encoder is described as an abstract class, thereby allowing developers to implement different types of parsers.  The implemented parsers must handle string input and output, convert incoming text to the related HAPI message object, and convert an outgoing message object into the appropriate encoded text data.   As of HAPI v0.3, an XML parser and an ASCII lower-level protocol (pipe-delimited) parser are included in the HAPI JAR distribution.  Parsers for other protocols, like SOAP (Simple Object Access Protocol), are in development. 

 

The HAPI Sample Interface Application

HAPI also provides a sample interface application to demonstrate how the API can be used.  It consists of a TCP/IP server that listens for connections on a particular TCP/IP port, and an interface application that is responsible for encoding, decoding, sending, and receiving HL7 messages.

The sample interface application is a user interface that demonstrates the process of sending and receiving HL7 messages between two systems.   It allows one to parse and encode pipe-delimited HL7 messages into the associated JAVA message objects, send and receive the HL7 messages, and process the incoming HL7 messages (i.e., generate a response message, etc.).

The TCP/IP server is a Runnable JAVA class that listens to a specific TCP/IP port.  When a connection is established, the server evokes an event-based message handling system, beginning with the creation of a ConnectionManager object that associates itself with the TCP/IP socket.   The ConnectionManager determines what parser to use to process incoming messages on this connection, and proceeds to convert any incoming  messages into the related HAPI message objects.   Then, it routes the message object to the appropriate message object handler that has been pre-defined and customized by the developer. The architecture of the sample interface application and server is illustrated in Appendix D.

 

Examples of HAPI Use

The HL7 API (HAPI) has been successfully used in several applications.  For example, the University Health Network has used the HL7 API to route HL7-based queries to and from a federated electronic patient record database, and also to synchronize a web-based letter authoring system to a health information system (Tripp, B., n.d.).  Other organizations are beginning to develop their own applications as well.  However, the API is still in development and is not recommended for production system use.

 

HAPI - Future Goals

Some future considerations for the HL7 API include integrating HAPI into the JAVA 2 Enterprise Edition architecture, adding an encryption support (e.g., PGP), adding run-time message validation of HAPI message objects (e.g., checking HL7 conformance), and adding support for HL7 message profiles (e.g., validating HL7 conformance, and enabling the source code generator to handle HL7 message profiles) (Tripp, B., personnal correspondence , 2002).

 

               

HL7 Conformance – Introducing HL7 Message Profiles

 

The Need for Conformance

The tendency for healthcare organizations and application developers to use subsets or extensions of the HL7 Standard, raises issues about HL7 Conformance.   Customizing the HL7 Standard is openly encouraged.  In fact, the HL7 Standard contains optional fields and user-defined message segments for this purpose.  However, customized specifications are not documented in a standard way.   This can be problematic when attempting to develop interfaces for systems using customized message specifications, or when attempting to check whether the specifications conform to the HL7 Standard. 

For example, if an organization with a customized message specification wishes to share data with a neighbouring institution, custom interfaces must be built to either support the specifications of both organizations', or a common specification must be agreed upon.  If the specifications are not documented properly, interface development may be difficult.  As well, the specifications would need to be checked for HL7 conformance.  In most cases, this  is a manual process.   Thus, the integration process could become costly and time-consuming.  However, if the semantics of the message specification were standardized, interface development time may be reduced (an "easy-to-read" specification), and specifications could be checked for HL7 conformance automatically.

 

HL7 Message Profiles

The HL7 Conformance Special Interest Group (HL7 Conformance SIG) has addressed these issues by introducing the concept of HL7 message profiles.   A message profile is defined as an unambiguous and precise specification for a standard HL7 message, that follows the W3C Document Object Model (DOM) architecture (HL7 Organization, 2000). This offers several immediate benefits, including a consistent method to document message profiles, the ability to validate the grammar and semantics of a message profile with a Document Type Definition (DTD), the opportunity to use existing DOM parsing technology to create third-party applications (e.g., an automated message profile validation tool that uses a DOM parser), and it creates a layer of abstraction that relates a set of message profiles to a particular process within a healthcare organization.

 

The Structure of a Message Profile

            The structure of a message profile must follow the standard DTD published by the HL7 Conformance Group (see the Appendix E).  A message profile must consist of a use case definition that describes the scope of the message profile (the trigger event, the actors in the event, etc.), a dynamic definition that defines the interaction between the sending and recipient systems (analogous to a UML sequence diagram), and a static definition that explicitly describes the structure of the HL7 message (HL7 Organization, n.d.).   Figure 5, excerpted from chapter 2 of the v2.5 HL7 Standard, illustrates the components of a typical message profile.


 


Figure 5.  Components of a message profile

 

 

Customizing Message Profiles

            The HL7 Conformance SIG has defined three message profile types to allow for customization, while maintaining HL7 conformance: "standard" message profiles, "constrainable" message profiles, and "implementation" message profiles.

            Standard message profiles are templates for the creation of all other message profiles, and reflect the published HL7 Standards (HL7 Organization, n.d.).  They have optional elements, limited constraints on segment and field cardinalities, and define the maximum length for segments and fields.  Standard message profiles cannot be implemented in a production environment.  As of July 2002, the standard message profiles for HL7 have not been released.  An example of a standard ADT_A01 message profile can be found in Appendix G.

            Constrainable message profiles are message profiles that can be customized by organizations and application developers (HL7 Organization, n.d.).  Similar to standard message profiles, they have optional elements, limited constraints on segment and field cardinalities, and define the maximum length of segments and fields.  Constrainable message profiles cannot be implemented.   They differ from standard profiles because their "optionality"/usage, cardinality, and length attributes can be constrained.  For example, a segment in the standard message profile may have a cardinality of [0..*] and a maximum length of 24, however in a constrainable message profile, the cardinality may be constrained to [1..4], and the length to 10. Implementation message profiles and other constrainable message profiles can be created from this message profiles type.  An example of  a constrainable ADT_A01 message profile can be found in Appendix G.

Implementation message profiles are message profiles that have been customized by organizations and application developers, and have been fully constrained (i.e., they have explicit definitions of the message structure) (HL7 Organization, n.d.).  Implementation profiles cannot have any optional elements, segment and field cardinalities are explicitly defined, and encoding and field value code sets are defined (e.g., encoding methods are defined, and all user-defined or HL7 tables are referenced).  Implementation message profiles can be used to develop interface applications.  They do not act as templates for the other message profile types.

 

Ensuring Message Profile Conformance with HL7

A "conformant" HL7 message profile is defined as message profile that successfully validates against the standard Conformance DTD and is a constrained version of the associated HL7 standard message profile (HL7 Conformance SIG mailing list correspondence, 2002.).  The Conformance SIG plans to address the issue of message profile conformance by offering a profile registry service, where healthcare organizations and application developers can register and validate their message profiles (HL7 Organization, n.d.).  This central repository will also act as a distribution centre of certified message profiles.  Thus, if an organization is installing a new information system, the HL7 message profile associated with the system can be downloaded and used when creating an interface application.  Unfortunately, this registry service is currently being developed, so testing HL7 conformance has been limited to manual analysis. The HL7 message profile Constraint Analyzing Tool developed for this project is an attempt to automate HL7 conformance validation.

The HL7 Message Profile Constraint Analyzing Tool

 

The Problem

            The concept of HL7 message profiles was introduced by the HL7 Conformance SIG, to ensure that customized HL7 message standards can be documented in a consistent manner, and can be easily tested for conformance to the HL7 Standard.  Unfortunately, validating conformance of HL7 message profiles is presently limited to applying the standard Conformance DTD to a message profile, and manually verifying that it conforms to the HL7 Standard.  For large message profiles this can be labour-intensive and error-prone process.

 

The HL7 Message Profile Constraint Analyzing Tool (CAT)

The focus of the CISC 499* project was to develop a tool that automatically performs HL7 conformance validation on HL7 message profiles, thus removing the need for manual analysis.  After reviewing the HL7 Standard, the HL7 API (HAPI), and HL7 Conformance documentation, it was determined that a Constraint Analyzing Tool (CAT) should consist of the following components: a set of rules that represent how HL7 message profiles can be constrained, a set of HL7 message profiles (for testing), a parsing application to parse HL7 message profiles, a data structure to store a parsed HL7 message profile, a method to traverse the data structure that would allow for HL7 conformance validation, a data structure to represent the message profile constraint rules, and a method to logically group and apply the constraint rules to the message profiles being examined.   JAVA was the development language of choice, due to its platform-independent nature.

 

Message Profile Constraint Rules

            At the time of writing, the constraint rules for HL7 message profiles have not been fully specified by the HL7 Conformance Special Interest Group.  The rule set that was developed for the project should be treated as an interpretation of the core rules, extracted from the preliminary HL7 Message Profiling Specification v2.2 (HL7 Organization, 2000), chapter 2 of the HL7 v2.5 Standard currently in ballot (HL7 Organization, n.d.), and from correspondence with members of the HL7 Conformance Special Interest Group.  It is likely that these rules will change.   The complete set of constraint rules that were created for the project can be found in Appendix F.

 

Sample Message Profiles

            Three ADT_A01 message profiles were developed for application testing, one for each message profile type (i.e., standard, constrainable, and implementation).   All three can found in Appendix G.  Variations of these message profiles were also created to test various rules that are implemented in the demonstration Constraint Analyzer Tool.  Two examples of these variations are included in Appendix G, along with the other message profiles.  All message profiles were hand-coded.

 

The Parsing Application

            HL7 message profiles follow the Document Object Model (DOM) and rely on a standard Document Type Definition (DTD) for validating semantics and grammar.   This permits the use of a validating DOM parser to process message profiles.  Rather than develop a W3C conformant DOM parser, the message profile Constraint Analyzing Tool uses a validating DOM parser from the public domain Xerces XML API.

 

Message Profile Storage Data Structure


            A tree data structure should be used to store incoming message profiles to retain the profile's message hierarchy.   In the demonstration application, whose structure is illustrated in Figure 6, each node in the tree describes a single message profile element (e.g., a segment).  Child nodes are stored in an ArrayList, so they can be easily retrieved and allows the node to have a variable number of children.  Each node posses an ArrayList of Attribute objects, where the attributes of a message profile element can be stored.

Figure 6.  Demo application storage tree.

 

 

Message Profile Validation – Traversal Method

            A variation of depth-first tree traversal was chosen as the traversal method.  It allows for the concurrent traversal of message profiles (thereby allowing for node-to-node application on constraint rules), it allows for the validation of the HL7 concept of "presence" (e.g., if a message segment has a usage/optionality of "required", there must be at least one child field in that segment that also shares the "required" usage/optionality value), and permits verification of

"optional" elements in constrainable message profiles (e.g., when testing whether a given profile B constrains another profile A, a case may occur where profile A possesses optional elements that do not appear in profile B.   The traversal method determine if the missing elements are optional in profile A. If they are, further constraint validation along that branch of profile B is impossible (there are no elements in profile B to compare).  If the elements are not optional, then the traversal method must halt and indicate the non-conformant element.).

Concurrent node traversal must also define how child nodes are selected for comparison. Traversal must occur, such that, for a given child node selected from a profile A node's child ArrayList, the same type of child node is selected from a profile B node's child ArrayList.  For example, a profile A child node may represent a message profile segment element, and this must be compared against a profile B child node that also represents a segment element.  Conditional logic in the traversal method must be in place to ensure that this occurs.   The traversal method in the demonstration applications conforms to all the requirements expressed above.

 

Representation of Message Profile Constraint Rules

A key requirement for the Constraint Analyzing Tool was to provide a generic representation of constraint rules, to allow developers to customize existing constraint rules and create their own.  To accomplish this, message profile constraint rules are represented as JAVA objects (RuleObject) rather than conditional statements hard-coded within the tree traversal method.  The RuleObject is an abstract class, thus the code that describes the rule and how it is to be executed is configurable by the user.  The execution of a RuleObject always returns a boolean value.  Thus, if desired, the rule objects can be linked with boolean logic to construct more complex rules.  All rules are expected to return a value of "true" if HL7 conformance occurs.

Groups of rules with similar behaviour are defined in Ruleset objects (e.g., rules that act on message elements are found in a MessageRuleset, etc.), and every rule object must belong to at least one rule set.  The demonstration application provides Ruleset objects for every element type described in the Conformance DTD, and includes a generic Ruleset that is applied to every node, regardless of what element it represents.  The Ruleset object is defined as an abstract class to facilitate customized rule sets.


The data model for representing rules is shown in Figure 7.

Figure 7.  The RuleObject and Ruleset object model.

Constraint Rule Application in the Constraint Analyzing Tool

Constraint rules are applied during the traversal of the message profile trees.  Similar to the HAPI message object model, RuleObjects are only instantiated and executed when the rule must be applied.  During each recursive call in the traversal method, a large Ruleset object is constructed and contains references to the all the RuleObjects that must be applied to the current nodes.  For example, if the current nodes represent a segment element, the Ruleset would contain all rule references from the GenericRuleset (that contains rules that are applied to all  nodes) and all rule references from the SegmentRuleset.    After the large Ruleset is acquired, the rules are instantiated and executed in sequential fashion.  The boolean values returned from each RuleObject are "AND"ed together with a "checkpoint" boolean variable.  Thus, if a rule fails, it will be detected and a JAVA exception can be thrown and/or logged.  In the demonstration application, all rule failures cause the application to terminate.

 

The Code

The demonstration application is pre-alpha version of the Constraint Analysis Tool, and is not a complete application.  It demonstrates the key features of the CAT model and methodology, but and should not be used in any production or development environment.  The complete source code listing for the demonstration application, associated Javadoc documentation, and UML diagrams for the Constraint Analyzing Tool can be found in appendices H, I, and J.  They are also included on the accompanying CD.   The demonstration Constraint Analyzing Tool JAR file, also on the CD, can be executed as follows:

 

java –jar domparser.jar <path and filename of profile A> <path and filename of profile B>

 

You must provide the pathname and filename of the two HL7 message profiles you wish to validate.  The standard Conformance DTD must  be in the same directory as the profiles, and each profile must reference the Conformance DTD in a <!DOCTYPE> tag.  You may also need to specify the classpath to the Xerces XML API JAR and the HAPI JAR prior to executing the Constraint Analyzing Tool JAR.

 

Technical Details

The Constraint Analyzing Tool was developed in JAVA 2 SE v1.3.1-b24, using the Borland Jbuilder 7 Personal IDE. Xerces XML API v2.0.1. and HAPI v0.2 were used.   A Pentium II 450Mhz, 384MB was used during development.   The Xerces and HAPI JAR files and their associated Javadoc documentation can be found on the accompanying CD.

 

Future Considerations

Future development of the Constraint Analyzer Tool will include: allowing for the automatic generation of Ruleset objects from a given Conformance DTD, developing an interface (GUI) that will allow users to create and modify rule objects and define rule sets, and revising the data structure for storing parsed message profiles.   Eventually, it is envisioned that the Constraint Analyzer Tool will pair with the HAPI message object model source generator, so HAPI message object models can be generated from an implementation message profile after it has been successfully validated for conformance.

FINAL REMARKS

               

Working on this project was a rewarding and enlightening experience.  It provided me with the opportunity to work on a "real world" application, and experience all the trials and tribulations that can befall a software developer – changes to specifications, miscommunication, and working with evolving documentation.     It was interesting, to say the least.

I believe my research of the HL7 Standard and HL7 Conformance has also provided me with a solid foundation to use HL7 in the future.  This will be particularly useful when I join the University Health Network this Fall, where I  may be involved in interface application development or will be exposed to HL7.   I plan to continue to develop the Constraint Analyzing Tool, as the demonstration application merely demonstrates the concept and does not realize all of the issues of HL7 Conformance.   A more legitimate version of the Constraint Analyzing Tool (with proper coding, user interface, etc.) will be released at the end of the month.  By that time I am hoping the HL7 Conformance SIG will have agreed upon a standard set of conformance rules.

            I would like to thank Prof. Juergen Dingel and Prof. Robin Dawes of Queen's University for allowing me to attempt this project during the summer, to Bryan Tripp and Jim Forbes of the University Health Network for sponsoring the project and helping me understand HL7 and HL7 Conformance, and to the HL7 Conformance SIG for providing the documentation necessary to complete this project.


REFERENCES

            Blobel, D., Dudeck, J., Heitmann, K. (1999).  HL7 Communication standard in medicine – short introduction and information.  Cologne: Hundt Druck GmbH.

Harrington, J. (n.d.).  Message Profile Tutorial.  On HL7 webpage [online]. Available:

http://www.hl7.org/Library/Committees/Conf/ProfileTutorial%2Epdf (August 7, 2002). 

            HL7 Conformance SIG.  (2000, November).  HL7 Conformance Framework.  On HL7webpage [online].  Available: http://www.hl7.org/Library/Committees/Conf/ConfMeth%2D11%2D06%2D2000%2Dc%2Edoc (August 7, 2002).

            HL7 Conformance SIG.  (2001, May).  HL7 Conformance User Guide – Draft.  On HL7 webpage [online].  Available: http://www.hl7.org/Library/Committees/Conf/Hl7ConformanceUserGuide%2Edoc (August 7, 2002).

HL7 Organization. (1999).  HL7 Version 2.3.1.  Available: http://www.hl7.org/Library/General/v231.zip (August 7, 2002).

            HL7 Organization.  (2000, November).   Health Level 7 Version 2.x Message Profiling Specification v2.2. On HL7 webpage [online]. Available: http://www.hl7.org/Library/Committees/Conf/HL7%5FProfile%5FV2r2%2Edoc (August 7, 2002).

            HL7 Organization. (n.d.).  HL7 Version 2.5, Chapter 2.  Not available, as this version of HL7 has not been released.  Included in Appendix K.

Singureanu, E., Killdara, M. A. (2001, January).  HL7 2.X Conformance Tutorial.  On HL7 webpage [online]. Available: http://www.hl7.org/Library/Committees/Conf/ConformanceTutorial%2Eppt (August 7, 2002).

            Stevens, H. (2002).  HL7 Version 2.x & 2.xml Implementation.  On HL7 Canada webpage [online]. Available: http://secure.cihi.ca/cihiweb/en/downloads/event_hl7_06112002.pdf  (August 7, 2002).

            Tripp, B. (2002). HAPI Overview.  On HAPI webpage [online].  Available: http://hl7api.sourceforge.net/overview.html (August 7, 2002).

            Tripp, B. et al. (2002).  HAPI Javadoc Documentation.  On HAPI webpage [online].  Available: http://prdownloads.sourceforge.net/hl7api/hapi_docs_0.2.zip?download (August 7, 2002).

            Tripp, B. (n.d.).  HL7 2.X Processing with HAPI.  On HAPI webpage [online].  Available: http://hl7api.sourceforge.net/june_slides/hapi.htm (August 7, 2002).

 

            Other information was obtained through email correspondence with Bryan Tripp and  Jim Forbes, of the University Health Network, and from memebers of the HL7 Conformance Special Interest Group mailing list.