---

1. Introduction

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:

• A01, admitting physician = A (movement 1)
• A08, change admitting physician to B
• A02, (movement 2)
• A12, cancel transfer
• A02, transfer time = 10:00 (movement 3)
• A08, change transfer time to 10:30
• A03, (movement 4)

The events that caused these messages to be sent are each associated with the then current movement.

In order to be able to send such data using a backloading mechanism HL7 Netherlands has considered 2 options:

• Create a new message and a new message trigger event for the purpose of backloading. The new message should allow for a repeating PV1 segment to be associated with 1 PID segment (i.e. "PID { PV1 }"). This way data related to all movements can be sent in 1 message.
  • PID
  • PV1, inpatient with admitting physician B (movement 1)
  • PV1, inpatient, new location, transfer time 10:30 (movement 3)
  • PV1, nulled patient class, discharge time (movement 4)
• Resend all messages as if they were current events. (note that movement 2 was deleted)
  • A01, with admitting physician B (movement 1)
  • A02, with transfer time 10:30 (movement 3)
  • A03, (movement 4)

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 movements

Revenue 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
Definition: This field specifies the level on which data are being sent. It is the indicator used to send data at two levels, visit and account. HL7 recommends sending an �A� or no value when the data in the message are at the account level, or �V� to indicate that the data sent in the message are at the visit level. The value of this element affects the context of data sent in PV1, PV2 and any associated hierarchical segments (e.g. DB1, AL1, DG1, etc.).

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:

Seq	Table	Item#	r/o/c	Rep#	Description	Data type
1		49071	R	Y	Bewegungs-ID Movement-ID	EI
2		49072	O		Zeitpunkt des Bewegungsbeginns Movement start time	TS
3		49073	O		Zeitpunkt des Bewegungsendes Movement end time	TS
4		49074	O		Verarbeitungskennzeichen Update mode	ST

ZBE-1 Bewegungs-ID (EI) 49071
Definition: Contains one or more identifiers of the movement. This is a repeating field. If a system refers to a movement-ID assigned by another system, then the movement-ID of that system has to be contained in the message.

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
Definition: The date/time the movement occurred.

ZBE-4 Verarbeitungszeichen (ST) 49074
Definition: The way in which this movement related transaction should be dealt with by the receiving application (INSERT , UPDATE , DELETE).

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||INSERT

The 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. Analysis

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

	Current (Actual)	Historical	Planned (Future)
Create	ADT event, not A08. ZBE-1 holds movement number, ZBE-2 holds movement time.	ADT event, not A08. ZBE-1 holds movement number, ZBE-2 holds movement time. PV1-51 set to H.	"Pending xxx" ADT event. ZBE segment is not used.
Cancel	ADT "Cancel xxx" event, not A08. ZBE-1 holds original movement number.	ADT "Cancel xxx" event, not A08. ZBE-1 holds original movement number. PV1-51 set to H.	"Cancel Pending xxx" ADT event. ZBE segment is not used.
Update	Event A08, or the original ADT event being updated (e.g. A02). ZBE-1 holds original movement number, ZBE-2 the (updated) movement time.	Event A08, or the original ADT event being updated (e.g. A02). ZBE-1 holds original movement number, ZBE-2 the (updated) movement time. PV1-51 set to H.	Not used.

Notes:

• The value of ZBE-4 can be deduced from the ADT event code *if* update messages always use event A08. In that case, all ADT "Cancel xxx" events map to DELETE, the A08 event to "UPDATE" and all other events to "INSERT". In our opinion update messages should always use event A08. Reuse of the original event code causes problems for those systems that don't support movement-IDs.
• ZBE-2 should be declared 'for backward compatibility only', EVN-6 (Event Occurence Time/Date) should be used instead. When ZBE-2 is valued, it should have the same value as used in field EVN-6.
• The recommendation for the use of PV1-51 is specific for Germany, it conflicts with the intention of the standard.

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.

3.3. IHE - Patient Administration Management (PAM) Profile

The Patient Administration Management (PAM) profile, part of the IHE ITI technical Framework, was published in June 2005. It contains a description of the workflow related to ADT messages. This profile defines a Movement to be "an event describing a change of the situation of the patient in the context of the encounter. This concept encompasses changes such as transfer of patient location, change of patient class, new attending doctor, new consulting doctor, new encounter starting, encounter closing, etc.".

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

• A new message with trigger Z99 (and the structure of ADT_A01) is sent to communicate an update of a Movement, which can be the current Movement or a historic one. This enables updates of such events at any later time point after they were initially reported.
• The addition of segment ZBE after the PV1/PV2 segment group in all ADT messages. The Profile describes the use of a ZBE Segment with a structure derived from the German ZBE Segment.

Seq	Table	r/o/c	Rep#	Description	Data type
1		R	Y	Movement-ID Movement-ID	EI
2		R		Start Movement Date/Time Movement start time	TS
3		O		End Movement Date/Time Movement end time	TS
4		R		Movement Action Code Update mode	ID
5		R		Historical Movement Indicator Yes/No code	ID
6		C		Original trigger Event Code Used if new trigger is A08	ID
7		O		Responsible Ward	CWE

ZBE-1 Movement-ID (EI)
Definition: Contains one or more identifiers of the movement. This is a repeating field. If a system refers to a movement-ID assigned by another system, then the movement-ID of that system has to be contained in the message. The Movement Identifier list is created with the action INSERT, and then recalled with further actions such as UPDATE or CANCEL.

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)
Definition: The date/time the movement occurred, i.e. the effective date time of the event that used action INSERT with this Movement.

ZBE-3 End Movement Date/Time (TS)

ZBE-4 Movement Action Code (ID)
Definition: The way in which this movement related transaction should be dealt with by the receiving application (INSERT - With any trigger event that inserts a movement, UPDATE - With trigger event Z99, CANCEL - With any �cancel� trigger event).

ZBE-5 Historical Movement Indicator (ID)
Definition: Contains �Y� when the message is related to a Historic Movement, contains �N� when the message is related to the current (last or next) movement.

ZBE-6 Original trigger Event Code (ID)
Definition: This field shall be populated when ZBE-4 contains action UPDATE or CANCEL. In this case, this field is populated with the trigger event that inserted (action INSERT) the movement being currently updated or canceled.

ZBE-7 Responsible Ward (CE)
This field may be further constrained in national extensions of this profile. It will, for example, be associated with usage �RE� in the French extension of the IHE Profile.

3.3.1. Analysis

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

	Current (Actual)	Historical	Planned (Future)
Create	ADT event, not A08. ZBE-1 holds movement number, ZBE-2 holds movement time; ZBE-4 set to "UPDATE".	Event Z99. ZBE-1 holds movement number, ZBE-2 holds movement time, ZBE-4 set to "UPDATE". ZBE-5 set to Y.	"Pending xxx" ADT event. ZBE segment is not used.
Cancel	ADT "Cancel xxx" event, not A08. ZBE-1 holds original movement number; ZBE-4 set to "CANCEL".	Event Z99. ZBE-1 holds original movement number, ZBE-4 set to "CANCEL". ZBE-5 set to Y.	"Cancel Pending xxx" ADT event. ZBE segment is not used.
Update	Event Z99. ZBE-1 holds original movement number, ZBE-2 the (updated) movement time. ZBE-4 set to "UPDATE".	Event Z99. ZBE-1 holds original movement number, ZBE-2 the (updated) movement time. ZBE-4 set to "UPDATE", ZBE-5 set to Y.	Not used.

Notes:

• ZBE-2 should be declared 'for backward compatibility only', EVN-6 (Event Occurred Date/Time) should be used instead. When ZBE-2 is valued, it should have the same value as used in field EVN-6.

4. Query for historical events

HL7 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 3

When 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. Analysis

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

	Current (Actual)	Historical	Planned (Future)
Create	Set end-time of mini-encounter that has the "active" status to "now"; change its status to "completed". Create a new mini-encounter in EVN mood; set its start-time to "now"; set its status to "active".	Create a new mini-encounter in EVN mood; set its effective time to be the historical time-range of validity; set its status to "completed".	Create a new mini-encounter in APT mood; set its effective time to be the expected time-range of validity; set its status to "active".
Cancel	Set status of the mini-encounter to "nullified".	Set status of the mini-encounter to "nullified".	Set status of the mini-encounter to "nullified".
Update	Update mini-encounter Act.	Update mini-encounter Act.	Update mini-encounter Act.

6. Acknowledgements

We 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 bv

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