AMIA 96

Home -> HL7 -> Archive -> AMIA 1996
 

Problems in Developing a Comprehensive HL7 Database

, Dipl.Inf.1),
Joachim Dudeck, M.D.1)2),
1) German HL7 User Group
2) 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

Event: The occurrence of an event triggers the assembling and transmission of a message e.g. the admission of a patient is an event.
Message: The message is the smallest object exchange between applications. It consists of a concatenation of segments which can be optional or repeatable.
Segment: A segment is an aggregation of data items logically belonging together. Segments can be used in different messages.
Data item: A character string representing the data to be transmitted.
Data type: The data type defines the format of the data item. Atomic and composite data types can be distinguished. Composite data types consist of different components.
Component: A component is part of a data item.
Subcomponent: Components can consist of subcomponents.
Table: Some data items or components require the use of special values which are defined by standard or user defined tables.

Structure of a Message

Todays 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.

Event sent by sending application sent by receiving application (response)
A01 ADT ACK
...

A19 QRY ACK
...

Q01 QRY DST
...

Q05 UDM ACK
...

M01 MFN
MFD
MFQ
MFK
ACK
MFR
...

Example

Event:
A01

"Add the transmitted data into your database"
        

M01 "Modify Master Table" ?

including the second segment (MFI)


"Update or modify table xyz"

Z??-segment with data for table xyz

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):

Coded Element


Data Item

Segment Identifier Text Name of Coding System
Veterans Military Status PID 0172 - -
Accommodation Code PV2 0129 - -
R/U What Subject Definition

URD

0048 - -
... ... ... - -

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.

message domain message type (structure) event type (purpose) expected acknowledgment
ADT: Administration Discharge and Transfer Admit
Modify
Tracking
Swap
Merge
Query
Bed status
Link
Change PID
A01: Admit
A02: Transfer
A09: Depart
A17: Swap
A18: Patient Information
A19: Patient
A20: Update
A24: Link
A39: Change
ACK: general acknowledgment
ADR: patient query response
BAR: Finance

ACK: general acknowledgment
DSR: display response
... ...

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 Mrz 2000