Historic Movements in HL7Copyright Ringholm bv © 2003,2009. All Rights Reserved. 1. Introduction
In HL7 the sending of a message is triggered by a real-world event. The corresponding HL7 event type,
which also identifies the message structure,
is contained within the HL7 message itself. A movement is an event describing a change of the situation of the patient in the context of the encounter. The HL7 v2.x standard currently offers no support for historic movements.
The IHE PAM Profile defines the concept of movement as follows: An event describing a change of the situation of the patient in the context of the encounter. This concept encompasses changes such as transfers of patient location, change of patient class, new attending doctor, new consulting doctor, new encounter starting, encounter closing, etc. The concept of Movement is a superset of the concept of �Transfer�. Movements are related to encounters, and are only used in the context of ADT messages (HL7 version 2, chapter 3). All ADT messages are triggered by real-world events, whereas only a subset of those events are considered to be movements. There is a 1 to many relationship between a movement and event. The last movement associated with a patient or a patient encounter is known as the current movement. Any movement that took place before the date/time of the current movement is known as an historic movement. A movement (current or historical) can be updated or cancelled at any point in time. Up to HL7 2.6 there is no support for historic movements in the HL7 standard. This paper describes how movements are currently dealt with in the Netherlands, Germany, France and the IHE ITI Framework. 2. Backloading of historic movements (Netherlands)If a new application is installed that needs to have detailed knowledge of the administrative history of the patient (e.g. a new HIS), messages related to all relevant historic events have to be sent to the new application. The only way this can be accomplished right now is by sending messages related to these historic events as if were current events, using messages and trigger events that don't identify the message as being part of a backloading process.In the Dutch context, a change in patient location and a change in patient class constitute a movement. A change of attending/consulting physician is not considered to be a movement. Note that updates and cancellations are also not considered to be movements. Example 1. Assume that the following sequence of (current) events resulted in the following sequence of messages:
In order to be able to send such data using a backloading mechanism HL7 Netherlands has considered 2 options:
2.1. Analysis Both solutions were deemed to be problematic. Currently the second option is being used for the process of backloading of patient data.Note that the use of ZBE-4 (as proposed by IHE), and seeting it to 'Y' in would solve this use-case. 3. Updates of historic movementsRevenue allocation and invoicing in Germany and France is partly based on the duration of the inpatient stay at individual wards. The location of a patient is notoriously hard to keep up to date. This has lead to a requirement to correct data related to the patient location. This applies to corrections related to the current location as well as any of the prior locations that have been transmitted in prior HL7 messages. Corrections of prior patient locations have no impact or relationship to the ongoing care process or the current patient location.The issue of corrections to prior patient locations is related to the concept of movements. Movements are a well-known concept in Germany and France. In Germany, a change of attending/consulting physician is not considered to be a movement, whereas in France this is considered to be a core part of a movement. An example scenario that illustrates the need to support updates on historical movements is the following: admit a patient to ward A (movement #1), transfer patient from ward A to ward B (movement #2), transfer patient from ward B to ward C (movement #3), cancel movement #2. Within both the sending and receiving system the current patient location should still be shown as being ward C. The list of movements in both systems only shows movements 1 and 3. HL7 version 2 supports the concept of 'current' and 'prior' location but not a list of prior locations. In order to be able to modify details of a particular movement a unique ID has to be assigned to each movement. This chapter describes the way in which movements are currently supported in various European countries. 3.1. Bewegungen (Germany)The German HL7 Affiliate has defined a movement-related Z-segment about 5 years ago. The ZBE segment can be used to identify a specific movement. The initial movement-ID will be generated by the system where the movement is registered. In order for this movement-identification mechanism to work all systems involved have to support the concept of movement-IDs and the ZBE segment itself.Field PV1-51 (Visit Indicator) is used to indicate whether or not the movement is a historical movement. The field will contain the value 'H' if the movement is an historic movement. The value of this field can be used by systems that don't support historical movements in order to avoid data related to historical movements from being interpreted as data related to the patient's current clinical situation.
PV1-51 Visit indicator (IS) 01226 3.1.1. ZBE-Segment (Bewegungsdaten)The ZBE segment was originally created by the HL7 German HL7 Affiliate in December 1998. The specification of the segment can be found below:
ZBE-1 Bewegungs-ID (EI) 49071 Example: The MEDOS application updates a movement that was originated by the SAP HIS system. ZBE-1 is valued as follows: 615^MEDOS~001345750034^SAP-ISH. The receiving system should use the value of MSH-5 to select its own movement-ID from the list of values.
ZBE-2 Zeitpunkt des Bewegungsbeginns (TS) 49072
ZBE-4 Verarbeitungszeichen (ST) 49074 In the example shown below the MEDOS system sends a transfer message (A02) to the SAP HIS system. Because of the fact that this message is related to a new movement the value of ZBE-4 is set to INSERT. Upon receiving this message the SAP system creates its own movement-ID. The SAP movement-ID and its relationship with the original MEDOS movement-ID is stored by SAP. If the movement is updated by the SAP HIS system at a later point in time both movement-IDs will be sent. MSH|^~\&|MEDOS|RAD|SAP-ISH||20030901164122||ADT^A02|1325-1|P|2.3|||| |D|8859/1|D EVN|A02|20030901164122||||20030901140000|| PID|||A24||Morgentau^Franz^^von^^Dr.|^^^^^|19480412|M|^^^^^|| Traberstraße 12^^Hanau^^63457^D^H^^^^^^^Franz@kawumm.de|| 06181/3288349|069/853-2345||||||||||||D|Pyrotechniker|D|| PV1||I|CHI2^^^1520|||CHI1^^^1500|||||||||||||003345750034||K||||||||||| ||||||||||||20030831080000|||||||| DG1|1|I9|541^^I9||20030901164122|VD||||||||||^BK||| ZBE|615^MEDOS|20030901140000||INSERTThe example below shows an update of the date/time of a transfer (EVN-6). Event A08 is used to indicate an update, one or more movement-IDs are contained in the ZBE segment.
MSH|^~\&|SAP-ISH||MEDOS||20030901164502||ADT^A08|88239743|P|2.3||| ||D|8859/1|D EVN|A08|20030901164502||||20030901163000|| PID|||A24||Morgentau^Franz^^von^^Dr.|^^^^^|19480412|M|^^^^^|| Traberstraße 12^^Hanau^^63457^D^H^^^^^^^Franz@kawumm.de|| 06181/3288349|069/853-2345||||||||||||D|Pyrotechniker|D|| NK1|""|^^^^^||^^^^^||||||||||||||||||||||||||||||||| PV1||I|CHI2^^^1520|||CHI1^^^1500|||||||||||||003345750034||K|| |||||||||||||||||||||20030831080000|||||||| DG1|1|I9|541^^I9||20030901164122|VD||||||||||^BK||| IN1|""|""|""| IN2|||Kawumm GmbH||O|| ZBE|0033457500340003^SAP-ISH~615^MEDOS|20030901163000||UPDATE In those cases where a communication server is involved it may be necessary to send the update using the original event trigger instead of A08. Instead of using the A08 event, as shown in the example above, an A02 event will be used with field ZBE-4 set to UPDATE. Most communication servers do not maintain a history of patient movements, some German receiver systems (notably SAP IS-H) however require the original event (and not A08) to be communicated when a movement is being updated. If field ZBE-4 contains UPDATE the receiving system can safely ignore the event code in the MSH segment. ZBE-1 uniquely identifies the original movement, and indirectly the event type of that movement.
MSH|^~\&|SAP-ISH||MEDOS||20030901164643||ADT^A02|1327-1|P|2.3||| ||D|8859/1|D EVN|A02|20030901164643||||20030901163500||| PID|||A24||Morgentau^Franz^^von^^Dr.|^^^^^|19480412|M|^^^^^|| Traberstraße 12^^Hanau^^63457^D^H^^^^^^^Franz@kawumm.de|| 06181/3288349|069/853-2345||||||||||||D|Pyrotechniker|D|| PV1||I|CHI2^^^1520|||CHI1^^^1500|||||||||||||A24-00001||K|||||||||||| |||||||||||20030831080000|||||||H| DG1|1|I9|541^^I9||20030901164122|VD||||||||||^BK||| ZBE|0033457500340003^SAP-ISH~615^MEDOS|20030901163500||UPDATE 3.1.2. AnalysisThe table shown below contains a summary of the way in which movements are used in German HL7 messages. The table identifies the characteristics of the way in which current/historical/planned movements are created, cancelled or updated.
Notes:
3.2. Mouvements (France)The concept of movements is used in France in the context of the IHE technical framework.
Prior to the creation of the IHE PAM Profile movements were primarily identified by the date/time of their occurrence, i.e. by means of the value of field EVN-6. There was discussion related to the use of PV1-50 as an identifier (a unique Transfer ID) for A01 or A02 movements. This approach may have been implemented by some systems, but it is expected that implementations will use the IHE approach in future.
The profile provides a means to uniquely identify any movement event conveyed in the ADT messages that are being exchanged. This identification method enables an update or cancellation of such events at any later point in time after they were initially reported.
This capability is supported by
ZBE-1 Movement-ID (EI) Example: The MEDOS application updates a movement that was originated by the SAP HIS system. ZBE-1 is valued as follows: 615^MEDOS~001345750034^SAP-ISH. The receiving system should use the value of MSH-5 to select its own movement-ID from the list of values.
ZBE-2 Start Movement Date/Time (TS)
ZBE-3 End Movement Date/Time (TS)
ZBE-4 Movement Action Code (ID)
ZBE-5 Historical Movement Indicator (ID)
ZBE-6 Original trigger Event Code (ID)
ZBE-7 Responsible Ward (CE) 3.3.1. AnalysisThe table shown below contains a summary of the way in which movements are used in the IHE HL7 messages. The table identifies the characteristics of the way in which current/historical/planned movements are created, cancelled or updated.
Notes:
4. Query for historical eventsHL7 2.5 contains a query QVR - query for previous events (Event Q17). A quote from paragraph 5.4.5.: "The Query for Previous Events is like a Query by Parameter with a Segment Pattern Response except that the response consists of zero to many messages of the type defined in the Query Conformance Statement rather than a single response message containing multiple iterations of the segment pattern. While the messages sent in response to a QVR will reflect events which occurred in the past, the time stamp in the message header will reflect the time the message is actually constructed (current time). It is also similar to the previous generation VQQ/RQQ Event Replay. While the response is similar to subscription messages, it differs from subscription in that the response messages are the result of interrogating the database rather than events being triggered in the current timeframe. "A higlighted note raises concern over the inability to identify historical events as such: "Note: If there is a concern that it will be difficult to distinguish these messages from any current realtime messages, e.g., if they are going down the same pipe, the data offerer might choose to designate a unique MSH-3 Sending application for the messages it sends in response to a QVR. This would allow downstream systems to recognize which messages were the result of the QVR, versus which are the result of current realtime activity on the sending system. For example, there may be 2 systems receiving pharmacy dispense messages. If system A wishes to issue a QVR to receive a historical load, s ystem B might misinterpret the QVR results coming over the pipe as actual live data. A separate Sending Application name would allow for easy differentiation." 4.1. Analysis There is a direct link between the need to identify historical events in the response messages to this query and the use-case described in chapter 2. Events need to be identified as being historical. The solution currently suggested ("use a different sending application in MSH-3") is rather out of whack with the intended purpose of the MSH-3 field.Note that the use of ZBE-4 (as proposed by IHE), and seeting it to 'Y' in would solve this use-case. 5. Notes on movements and HL7 version 3When it comes to extension to HL7 version 2.x it is always a good idea to look at the models present in HL7 version 3. These models are more consistent than the models underlying HL7 version 2.In HL7 version 3, an encounter Act can be composed of a sequence of (mini-)encounters. Each of these (mini-)encounters can be considered to represent the encounter state between movements. All encounter Acts have a unique identifier, and an effectivetime attribute which represents the interval of time that the act was valid. 5.1. AnalysisThe table shown below contains a summary of the way in which movements are used in HL7 Version 3 messages. The table identifies the characteristics of the way in which current/historical/planned movements are created, cancelled or updated.
6. AcknowledgementsWe would like to thank HL7 Deutschland for their permission to reprint excerpts of the German Z-Segment register. We also thank Peter Sachs (MEDOS, Germany), Marc-Olivier Gattegno (Siemens Medical Systems, France), Isabelle Gibaud (Syndicat Interhospitalier de Bretagne, France) and Francois Macary (Agfa ,France) for their comments.7. References[HL7 Z-Reg] "HL7 Deutschland Z-Register", http://www.hl7.de/zregister/zregister.html[IHE-Eur] "IHE-Europe", http://www.ihe-europe.net
About Ringholm bvRingholm bv is a group of European experts in the field of messaging standards and systems integration in healthcare IT. We provide the industry's most advanced training courses and consulting on healthcare information exchange standards. |