|Home -> HL7 -> Archive -> AMIA 1996|
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.
|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.|
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)|
Þ "Add the transmitted data into your database"
|M01||Þ "Modify Master Table"||?|
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:
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.
|Segment||Identifier||Text||Name of Coding System|
|Veterans Military Status||PID||0172||-||-|
|R/U What Subject Definition||
The logical data type has been introduced to allocate tables to components in multiple component fields.
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.
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.
The real world event "Discharge a patient" is to "modify some parameters which define the patient status".
PID|||PATID1234^5^M|Jones^William^A^III||19610615|M||C|1200 N Elm Street^.........
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.
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
A18: Patient Information
|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.
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