Problems in Developing a Comprehensive HL7 Database

, Dipl.Inf.¹⁾,
Joachim Dudeck, M.D.¹⁾²⁾,
¹⁾ German HL7 User Group
²⁾ Institute for Medical Informatics, University of Giessen

Introduction

The German HL7 user group has edited a German adaptation of the version 2.1 and 2.2 of the HL7 standard. The careful analysis of the standard during the translation process and the attempt to map the standard into a comprehensive database has displayed some problems which should be taken into consideration in future developments in particular of version 2.3.

The general paradigm of HL7 is the exchange of messages which consist of sequences of mandatory or optional segments, fields, components and subcomponents. Fields represent the semantic content of the message. In the standard the meaning of these segments and the content of fields are explicitly described.

Messages are initiated by trigger events, i.e. real world event which require the transmission of a specific data set.

It became shortly aware that the chapters of the standard has been developed by different groups and that there have been no distinct rules or guidelines for the development of various parts of the standard. We started therefore to define a comprehensive database of the HL7 standard to allow consistency checks of items and to support also the application of the standard by the user.

Objects used in the HL7 Standard

Structure of a Message

Today´s Relation between Events and Messages

There is no distinct rule defining the relationship between events and messages. Sometimes the event type describes the structure and the function of the message. In other cases like Master Files it defines the target file the data in the message have to be transmitted to.

Example

Define the Standard by the Help of a Database

Problem

Developing an analytic object model for the definition of a comprehensive HL7 Database we became aware that two problems are not handled satisfactory in the standard:

1. the relationship between message types, event types and the structure of a message
2. the relationship between data items, data types, components and tables
   

The following analytic object model (AOM) has been established from the HL7 standard version 2.2

Tables are generally allocated to data items. But in multiple component fields attribute tables can also be allocated to components.

Problems arise it the components in a field are related to each other like in the data type CE (Coded Element). Coded Elements consist of three components which are related to each other and which are dependent on the chosen coding scheme.

CE ::= Identifier ^ Text ^ Name of coding system

In this multiple component field attribute tables have to be allocated to the field and not to the components. Introducing a "logical data type" multiple component fields can be handled as atomic information in the same way as single component data items.

Example (Matrix of assigned tables):

Logical Data Type:

The logical data type has been introduced to allocate tables to components in multiple component fields.

Relationship between Messages,
Message Types and Event Types

Problem

In the current versions of HL7 messages are characterized by message and event types which are transmitted as components of item 9 in the message header. But these two important descriptors of the message are unfortunately not unequivocally used within the standard. The message type describes sometimes the domain the message belongs to like ADT, sometimes the structure and the purpose of which is e.g. in the ADT domain defined by the event type. Each message requires a certain type of acknowledgment which is in version 2.3 allocated to the event type.

Recommendation

In order to determine the structure of the whole message by just reading the message header we recommend to characterize the message by four components:

the domain the message belongs to,
the structure of the message i.e. the sequence of segments and the contents of fields,
the purpose of the message and
the expected type of acknowledgment
>

Using these components for describing messages would decrease the number of messages to be defined in the standard, diminish implementation problems and would in particular make the standard more consistent.

To avoid irritations the standard has to define the allowed combinations of message structures and purposes.

Example

The real world event "Discharge a patient" is to "modify some parameters which define the patient status".

MSH|^~\&|HOST|MCM|LAB|MCM|195508181126||ADT^Modify^A03^ACK|MSG0001|P|2.2
EVN|01|198808181123||
PID|||PATID1234^5^M|Jones^William^A^III||19610615|M||C|1200 N Elm Street^.........
NK1|....
PV1|1|I|.....

The receiving systems expect to recognize easily the purpose and the structure of the message. The purpose characterizes the action to be initiated by the message in the receiving system like add, modify or delete specific data or assemble data in a message as a reaction to a query message. This is described by the trigger event. The structure defines the sequence of segments which should be expected in the received message which should be described by the message types. The domain and the acknowledgment definitions are useful extensions.

Recommendation

The proposed application of message and event types would decrease the number of necessary message definitions and would also alleviate the consistent implementation of messages.

The actions to be carried out with data of the same message type can be defined by the event types.

The event types A04, A05, A06, A07, A08, A13, A14, A28 and A31 belong to the "Admit" message type, the event types A03, A21, A22, A23, A25, A26, A27, A29, A32 and A33 to the "Modify" message type etc.

Conclusions

From our experiences we recommend that messages should be described in future versions by four components. With these four components an unambiguous description of the message will be possible which will decrease the implementation efforts remarkably. It will require a nearly complete redefinition of message and event types, but the advantages will be remarkable.

We also saw some problems in the allocation of tables to data items or to components in multiple component fields. In our database we found a solution by defining an additional level of objects, the "logical data type" but this will probably not be the generally applicable solution. The relationship between tables and data items or components have to be reconsidered in future versions to channel the increasing grow of multiple component fields.

The HL7 standard has been developed with only a very vague framework of development rules. Due to the increasing number of messages and application domains a more consistent framework is now necessary to avoid inconsistencies between different chapters. The discussed issues are some proposals which hint into this direction.  

Last Update : 06 März 2000