Cultural Influence on HL7

I recently started writing articles from my HL7 integration experience on US based projects. But a comment from Rene Spronk on one of my articles (HL7 Identifiers (Person, Patient, Account, Visit) made me think about extensions in HL7 by nation/region. I researched a bit on this and found interesting results of cultural influence on HL7 standard.

---

I found most of information around this in IHE profiles, would request readers to provide me more sources if they can.
Following is the few interesting facts that I would like to share & request you to correct/add to this.

UK

PID.18 Patient Account Number is not supported (ignored) in UK

Itally

PID.18 Patient Account Number is required field in Itally

France

PID.18 is optional field, may be used to group one or more visits under same Episode of Care.
It is illegal to transmit PID.10 (Race) & PID.22 (Ethnic Group) in an HL7 message. It would be interesting to know if HIS/EMR stores these fields at all.
A major difference between the management of responsibilities between the USA and France is that the responsibility for a patient is often managed at the level of a functional unit rather than at the level of an attending doctor. For this purpose the Z Segment ZFU has been created.
For IHE-F, the ZFU segment is required for messages A01, A02, A04, A05, A06, A07, and A08

Germany

Field PID.18 "Patient Account Number" is used to consolidate information relative to several visits and is generally not used in Germany.
Field PV1.19 "Visit Number" is required and shall be used to transmit the patient admission identifier ("Fallnummer").
The ZBE segment is an HL7 extension defined by the German Chapter of HL7. It introduces a field called "Movement ID" which allows, upon the reception of a change message (ADT^A08), to exactly determine the original message (ADT^A01, ADT^A02) to which the change is related.
The use of this Z-segment is optional, but allowed and recommended in IHE-D for all ADT messages.

Comments:

I appreciate honest (positive/negative) feedback.

Source

Comment

Email

Rene Spronk on 26th Feb 2013 although the topic is more one of localisation, in terms of language, of the way healthcare is financed, of the insurance scheme that a country uses, legislation and cultural differences PID-10 and 22 (race, ethnicity) is illegal in all of Europe - the intent of those fields is to capture race for administrative/statistical purposes, and one isn't allowed to do that. If you need race for medical reasons (for certain deceases that may be of importance) then race is an observation (OBX) just like length, weigth, and other relevant clinical findings. PID-17 (religion) - mandatory in Saudi Arabia, probably never captured in Northern Europe. The ZBE segment, although originally German (see http://www.ringholm.com/docs/00810_en.htm ), has been adopted by IHE profiles and is also used in France.

PID Segment - Patient Identifiers

HL7 PID segment has three fields for Patient Identifiers, PID.2 - Patient ID (External ID), PID.3 - Patient Identifier List (Internal ID), PID.4 - Alternate Patient ID.
HL7 recommended use of these fields have changed in different revisions. How a healthcare system recognize & use these different fields is totally a system dependent. For any HL7 interface development, it is advisable to consult source system administrator during analysis.

---

In this article, I will discuss these three fields & their applications

PID.2 Patient ID (External ID)

This field generally identifies a patient across facilities. When we have a multi facility setup or we receive messages from external systems, this field is stores patient id from that system.
These days many organizations are in process of implementing EMPI(Enterprise Master Patient Index) and they use PID.2 to store EMPI which can identify a patient across facilities/hospitals.
This field has been deprecated & term "External Id" associated with this field has been removed from HL7 v2.3.1 onwards and it is recommended to use PID.3 for all kind of patient identifiers.
This field still remains for backward compatibility and older systems still use this.

PID.3 Patient Identifier List

This filed contains list of identifiers which are used to identify a patient within or across healthcare facility. Multiple repetitions are used to store different identifiers.
Most common use ot PID.3 in healthcare systems is to store MRN (Medical Record Number) of a patient. But repetitions allow us to store multiple identifiers like MRN, Billing Number, SSN etc. HL7 Table 0203 - Identifier Type lists all possible identifier types.
The repetitions: assigning authority, assigning facility, and identifier type code attributes of PID.3 allow for distinctive identifier representation.

Components:  <ID (ST)> ^ <check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ <assigning authority (HD)> ^ <identifier type code (IS)> ^ <assigning facility (HD)>
Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>

A Sample PID.3 field

PID|1||12345^^^ADT1^MR^MCM~123456789^^^ADT1^SS^MCM~1-123-123^^^ADT1^PI^MCM||JONES^WILLIAM^A^III||19610615|M||C|1200 N ELM STREET^^GREENSBORO^NC^27401 1020|GL|(919)379 1212|(919)271 3434||S||PATID12345001^2^M10^ADT1^AN^A|123456789

Following is the detail of different repetitions used in highlighted PID.3 in above PID segment & table lists meaning of different Identifier Type Codes  

12345^^^ADT1^MR^MCM~
123456789^^^ADT1^SS^MCM~
1-123-123^^^ADT1^PI^MCM

 

Identifier Type Code	Meaning	Field Value	Assigning Authority	Assigning Facility
MR	MRN	12345	ADT1	MCM
SS	SSN	123456789	ADT1	MCM
PI	Patient Internal Identifier	1-123-123	ADT1	MCM

 

PID.4 Alternate Patient ID

This field has been depricated from HL7 v2.3.1 onwards and it is recommended to use PID.3 for all kind of patient identifiers.
It was used to store Patient ID when we have more than one identifier for patient.
Note: I have never seen HL7 feed which sends PID.4 in my projects.

 

HL7 Identifiers (Person, Patient, Account, Visit)

Healthcare systems uses different ways to identify a person or patient within the system. Most common way is to use a Medical Record Number(MRN). Patient gets a unique MRN when he/she visits a hospital for first time. If a patient visits two facilities in a hospital network he will get unique MRN for each facility. With every MRN there would be one or more accounts associated. Account number would identify a single course of treatment or episode of care. With every Account there would be one or more Visits associated. Visit Number identify a single visit or encounter during episode of care.

---

Now a days, many hospital networks have build a mechanism to identify a person/patient accross facilities. These are advanced systems which implement Enterprise Marser Patient Index functionality (EMPI). One patient will have single EMPI assigned for a hospital across facilities.

Identifier Hierarchy

HL7 has provided following level of identifiers to facilitate patient/visit identification. These are very helpful in Merge/Move scenarios.
Level 4 Person PID.2 - External Id -  EMPI
Level 3 Patient PID.3 - Internal Id - MRN
Level 2 Account PID.18 - Account Number
Level 1 Visit PV1.19 - Visit Number
Following figure illustrates this hierarchy in graphical way

As we go up in hierarchy, we get more aggregare data and as we go down in hierarchy, we get more atomic data.
Every person in a hospital will be identified by a EMPI. A person would be registered as patient at different facilities within hospital and will get a new MRN at that facility.
Every patient would be assigned a unique account number for a perticular care episode. Every care episode will have one or more encounters identified by Visit Number.
Following figure shows relationship between identifiers

There will be parent-child relationship between these identifiers where each parent will have one or more child with following exceptions:

• Visit level will not have any child
• Person level will not have any parent

Note:

Every visit must map to single account, but an Account can have one or more visits associated with it.
Every Account must map to single Patient, but a Patient can have one or more Accoutns associated with it.
Every Patient must map to single Person, but a Person can have one or more Patients associated with it.
Every hospital system will have its own policies for assigning these identifiers, but for a good HL7 interface, a system should provide following at minimmum:

• Either a PID.2 or PID.3 to identify a unique patient within system
• Either a PID.18 or PV1.19 to identify a unique visit within system

If PID.2 is not implemented at hospital, an HL7 Integration Analyst could still implement an EMPI using custom patient matching within ADT interface

Comments:

I appreciate honest (positive/negative) feedback.

Source	Comment
	Rene Spronk on 21st Feb 2013 Id Hierarchy - be careful, rather US-centric description.e.g. PID-18 is not used elsewhere.. http://wiki.hl7.org/index.php?title=Requirements_for_an_Universal_Encounter_model PID-18 used in some countries, PV1-19 regarded as mandatory in others, notably Germany. PID-2 only in old systems..

ADT A11 - Cancel Admit/Visit Notification

In hospitals, there might be a need to cancel an admission for admitted patients (Admitted patients are one for whom we have received and A01). This happens when hospital/doctor decides not to admit a patient. This can also happen when a patient is admitted by mistake and records need to be corrected.

---

We can also cancel visit notification of non-admitted patients (Outpatients) for whom we have received an A04 message earlier.

HL7 has provided this trigger event (ADT A11 Cancel Admit/Visit Notification) to
Cancel A01 for admitted patients
Cancel A04 for non admitted patients

This trigger event (A11 Cancel Admit/Visit Notification) signals receiving system to cancel admission or close visit. But implementation depends on receiving system. One can

• Mark the patient/visit as inactive
• Remove the patient/visit from database (Not preferred)

I will provide basic details of implementing A11 into your system, but please contact source system administrator before implementing your interface.

There could be many fields in HL7 message or in your system which can identify visit status (This depends on your EMR configuration or system which mangaes your Admission/Discharge/Transfer).
Common fields are PatientClass, PatientType, AccountStatus, AssignedPatientLocation etc. and all of these values would be very meaningful for Healthcare Systems.

Let me start with a scenario where we need to cancel a visit notification (I will let users think about cancel admission based on this)
Suppose we have received a visit notification for Patient A using A04 message & we have received following values in PV1 segment
PatientClass (PV1.2) - O (Important & Requred field)
AccountStatus (PV1.41) - REG
So, when our system receives this registration message it will create a new patient visit and data in database will look like this

(I have only mentioned fields which are required to describe A11)

PV1.2	PV1.41
PatientClass	AccountStatus
O	REG

Now, let's assume that we have received an A11 message for same patient with following values in PV1 segment
PatientClass (PV1.2) - P (Important & Requred field)
AccountStatus (PV1.41) - CAN

So when we process this message, system will change the values in database as following

PV1.2	PV1.41
PatientClass	AccountStatus
P	CAN

You can see, now, the system will identify same patient as an Pre-Admit patient and AccountStatus is changed to CAN. (Different systems could use different codes & fields to identify cancelled/inactive visit)
Depending on these fields, application which displays the data to end users can filter the patients with active visits.

Important

Please get clarification from your source system administrator on following:
How will you process messages recieved after A11 with same account & visit details?
Usually when we cancel a visit, we assume that episide of care is over & new visit has to be created using A04/A01 for this patient.

Note:

ADT messages always contain current information except MRG segments
Process all the fieds in PID & PV1 & other segments in message as normal A08 upate message unless specified by source system.
It is recommended not to send any updated fields except required ones in A11. A08 should be used to update any other fields.

ADT A13 - Cancel Discharge/End Visit

A13 is used to trigger cancellation of previous discharge message. This could happen if it is decided that patient need more care after discharging or discharge message was trigger by mistake.
In HL7, ADT A13 event is used to trigger cancellation of dischange for an admitted patient. This can alos cancel end visit notification fro non-admitted patients.

---

Let's understand the scenario:
Patient A was admitted to a hospital and assigned some physical location
When we receive an A03 HL7 message, we record patients discharge date & allocated physical location becomes available for other patients.
When we receive an A13 HL7 message, we cancel the discharge.

There could be many fields in HL7 message or in your system which can identify patient's discharge (This depends on your EMR configuration or system which mangaes your Admission/Discharge/Transfer).
Common fields are PatientClass(PV1.2), AssignedPatientLocation(PV1.3), AccountStatus, DischargeDate etc. and all of these values would be very meaningful for Healthcare Systems.

In real world, a hospital system would receive many messages for a patient before A13, but to understand A03 scenario we will discuss two important one - A01 (Admission) and A03 (Discharge)
I will include only those fields in example which are required to describe the A13 cancel discharge message.

Suppose, we have received an A01 hl7 message for a patient with following details
PatientClass (PV1.2) - E (Important & Requred field)
AssignedLocation (PV1.3) - PointOfCare - IR, Room - 101, Bed - A
AccountStatus (PV1.41) - REG
AdmissionDate (PV1.44) - 1/1/2012

after processing this A01 message, we have following details in our system:

PV1.2	AssignedPatientLocation PV1.3			PV1.41	PV1.44	PV1.45
PatientClass	PointOfCare	Room	Bed	AccountStatus	AdmissionDate	DischargeDate
I	IR	101	A	REG	1/1/2012

Now suppose, patients has received care & need to be discharged from facility.
Now, we have received a discharge request by A03 hl7 message with following details
PatientClass (PV1.2) - E (Important & Requred field)
AssignedLocation (PV1.3) - PointOfCare - IR, Room - 101, Bed - A
AccountStatus (PV1.41) - DIS
AdmissionDate (PV1.44) - 1/1/2012
DischargeDate (PV1.45) - 1/5/2012

after processing this we have following details in our system:

PV1.2	AssignedPatientLocation PV1.3			PV1.41	PV1.44	PV1.45
PatientClass	PointOfCare	Room	Bed	AccountStatus	AdmissionDate	DischargeDate
I	IR	101	A	DIS	1/1/2012	1/5/2012

Now, suppose it was decided to cancel the discharge & contiue with this episode of care and we have recieved an A13 message with following details:
PatientClass (PV1.2) - E (Important & Requred field)
AssignedLocation (PV1.3) - PointOfCare - IR, Room - 101, Bed - A
AccountStatus (PV1.41) - REG
AdmissionDate (PV1.44) - 1/1/2012
DischargeDate (PV1.45) - ""

after processing this message, we will have following details in our system:

PV1.2	AssignedPatientLocation PV1.3			PV1.41	PV1.44	PV1.45
PatientClass	PointOfCare	Room	Bed	AccountStatus	AdmissionDate	DischargeDate
I	IR	101	A	REG	1/1/2012

You can see that after processing A13, patient is registered again in facility & will continue receiving care.

Important:

Patiet's location hould be in PV1.3 & this could be different than what it was before discharge.
A13 will be important for billing system to notify that patient's billing period is still valid

Note:

ADT messages always contain current information except MRG segments
Process all the fieds in PID & PV1 & other segments in message as normal A08 upate message unless specified by source system.
It is recommended not to send any updated fields except required ones in A13. A08 should be used to update any other fields.

 

ADT A03 Discharge Patient / End Visit

Patien's will get discharged from hospitals after recieving care. This signals end of patient's stay in healthcare facility.
In HL7, ADT A03 event is used to trigger dischange for an admitted patient. This can alos end visit fro non-admitted patients.

---

Let's understand the scenario:

Patient A was admitted to a hospital and assigned some physical location

When we receive an A03 message, we record patient's discharge date & allocated physical location becomes available for other patients.
There could be many fields in HL7 message or in your system which can identify patient's discharge (This depends on your EMR configuration or system which mangaes your Admission/Discharge/Transfer).

Common fields are PatientClass(PV1.2), AssignedPatientLocation(PV1.3), AccountStatus, DischargeDate etc. and all of these values would be very meaningful for Healthcare Systems.

In real world, a hospital system would receive many messages for a patient before A03, but to understand A03 scenario we will discuss only important one - A01 (Admission)

I will include only those fields in example which are required to describe the A03 discharge message.
Suppose, we have received an A01 message for a patient with following details
PatientClass (PV1.2) - E (Important & Requred field)
AssignedLocation (PV1.3) - PointOfCare - IR, Room - 101, Bed - A
AccountStatus (PV1.41) - REG
AdmissionDate (PV1.44) - 1/1/2012

after processing this A01 message, we have following details in our system:

PV1.2	AssignedPatientLocation PV1.3			PV1.41	PV1.44	PV1.45
PatientClass	PointOfCare	Room	Bed	AccountStatus	AdmissionDate	DischargeDate
I	IR	101	A	REG	1/1/2012

Now suppose, patients has received care & need to be discharged from facility.
Now, we have received a discharge request by A03 message with following details
PatientClass (PV1.2) - E (Important & Requred field)
AssignedLocation (PV1.3) - PointOfCare - IR, Room - 101, Bed - A
AccountStatus (PV1.41) - DIS
AdmissionDate (PV1.44) - 1/1/2012
DischargeDate (PV1.45) - 1/5/2012

after processing this we have following details in our system:

PV1.2	AssignedPatientLocation PV1.3			PV1.41	PV1.44	PV1.45
PatientClass	PointOfCare	Room	Bed	AccountStatus	AdmissionDate	DischargeDate
I	IR	101	A	DIS	1/1/2012	1/5/2012

You can see the magic of A03, the patient's physical loation has been restored to his prior location.

Important:

Patiet's location before discharge should be in PV1.3
A03 will be important for billing system to notify that patient's billing period has ended
If patient expired during hospital stay, it should be indicated in PID.29 & PID.30 fields of A03 message

Note:

ADT messages always contain current information except MRG segments
Process all the fieds in PID & PV1 & other segments in message as normal A08 upate message unless specified by source system.
It is recommended not to send any updated fields except required ones in A03. A08 should be used to update any other fields.

ADT A12 - Cancel Transfer

In hospitals, there might be a need to cancel patient transfer (physical location). This happens when an HL7 A02 (transfer patient) message was triggered by mistake by system or there was a wrong decision made to transfer patient.

---

Let's understand the scenario:

Patient A was allocated a physical location (Room 101 Bed A)
We received an A02 to transfer patient to (Room 102 Bed B)
We received an A12 HL7 message to cancel transfer, this will again change patient's current location to (Room 101 Bed A) & prior location will be (Room 102 Bed B)
This trigger event (A12 Cancel Transfer) signals receiving system to switch patients current & prior location. But implementation depends on receiving system.

I will provide basic details of implementing A12 into your system, but please contact source system administrator before implementing your interface.

There could be many fields in HL7 message or in your system which can identify patient's location (This depends on your EMR configuration or system which mangaes your Admission/Discharge/Transfer).

Common fields are PatientClass(PV1.2), AssignedPatientLocation(PV1.3), PriorPatientLocation(PV1.6) etc. and all of these values would be very meaningful for Healthcare Systems.

Let me start with a scenario (I am not including processing of A02 in this article, we will post another article for that):

In real world, a hospital system would receive many messages for a patient before A12, but to understand A12 scenario we will discuss two important ones - A01 (Admission) & A02 (Transfer)
I will include only those fields in example which are required to describe the A12 cancel transfer message.

Suppose, we have received an A01 message for a patient with following details
PatientClass (PV1.2) - I (Important & Requred field)
AssignedLocation (PV1.3) - PointOfCare - IR, Room - 101, Bed - A
AccountStatus (PV1.41) - ADM
after processing this A01 message, we have following details in our system:

PV1.2	AssignedPatientLocation PV1.3			PriorPatientLocation PV1.6			PV1.41	PV2.4
PatientClass	PointOfCare	Room	Bed	PointOfCare	Room	Bed	AccountStatus	TransferReason
I	IR	101	A				ADM

Now, we have received a transfer request by A02 message with following details

PatientClass (PV1.2) - I (Important & Requred field)
AssignedLocation (PV1.3) - PointOfCare - IR, Room - 201, Bed - B
PriorLocation (PV1.6) - PointOfCare - IR, Room - 101, Bed - A
AccountStatus (PV1.41) - ADM
TransferReason (PV2.4) - Reason For Transfer
after processing this we have following details in our system:

PV1.2	AssignedPatientLocation PV1.3			PriorPatientLocation PV1.6			PV1.41	PV2.4
PatientClass	PointOfCare	Room	Bed	PointOfCare	Room	Bed	AccountStatus	TransferReason
I	IR	201	B	IR	101	A	ADM	reason for transfer

Now, suppose we have received an A12 (Cancel Transfer) message with following details, this should trigger the cancellation of previous A02 and when we process this message patient's physical location will be restored to what it was before processing A02
PatientClass (PV1.2) - I (Important & Requred field)
AssignedLocation (PV1.3) - PointOfCare - IR, Room - 101, Bed - A
PriorLocation (PV1.6) - PointOfCare - IR, Room - 201, Bed - B
AccountStatus (PV1.41) - ADM
TransferReason (PV2.4) - Reason For Cancelling the Transfer

So, after processing A12, we will have following details in our system

PV1.2	AssignedPatientLocation PV1.3			PriorPatientLocation PV1.6			PV1.41	PV2.4
PatientClass	PointOfCare	Room	Bed	PointOfCare	Room	Bed	AccountStatus	TransferReason
I	IR	101	A	IR	201	B	ADM	Reason for cancelling transfer

You can see the magic of A12, the patient's physical loation has been restored to his prior location.

Note:

ADT messages always contain current information except MRG segments
Process all the fieds in PID & PV1 & other segments in message as normal A08 upate message unless specified by source system.
It is recommended not to send any updated fields except required ones in A12. A08 should be used to update any other fields.

ADT A02 - Transfer Patient

In hospitals, there might be a need to change patient's physical location (transfer a patient). This HL7 event is useful in notifying other hospital systems that patient has changed the location and required services need to be redirected.

---

ADT A02 should not be used when patient is going to a temporary location like O/R, XRAY etc.
Let's understand the scenario:
Patient A was allocated a physical location (Room 101 Bed A)
We received an A02 to transfer patient to (Room 102 Bed B)
I will provide basic details of implementing A12 into your system, but please contact source system administrator before implementing your interface.
There could be many fields in HL7 message or in your system which can identify patient's location (This depends on your EMR configuration or system which mangaes your Admission/Discharge/Transfer).
Common fields are PatientClass(PV1.2), AssignedPatientLocation(PV1.3), PriorPatientLocation(PV1.6) etc. and all of these values would be very meaningful for Healthcare Systems.
In real world, a hospital system could receive many HL7 messages for a patient before A02, but to understand A02 scenario we will discuss only important one - A01 (Admission)
I will include only those fields in example which are required to describe the A02 transfer message.
Suppose, we have received an A01 message for a patient with following details
PatientClass (PV1.2) - I (Important & Requred field)
AssignedLocation (PV1.3) - PointOfCare - IR, Room - 101, Bed - A
AccountStatus (PV1.41) - ADM
after processing this A01 message, we have following details in our system:

PV1.2	AssignedPatientLocation PV1.3			PriorPatientLocation PV1.6			PV1.41	PV2.4
PatientClass	PointOfCare	Room	Bed	PointOfCare	Room	Bed	AccountStatus	TransferReason
I	IR	101	A				ADM

Now, we have received a transfer request by A02 message with following details
PatientClass (PV1.2) - I (Important & Requred field)
AssignedLocation (PV1.3) - PointOfCare - IR, Room - 201, Bed - B
PriorLocation (PV1.6) - PointOfCare - IR, Room - 101, Bed - A
AccountStatus (PV1.41) - ADM
TransferReason (PV2.4) - Reason For Transfer
after processing this we have following details in our system:

PV1.2	AssignedPatientLocation PV1.3			PriorPatientLocation PV1.6			PV1.41	PV2.4
PatientClass	PointOfCare	Room	Bed	PointOfCare	Room	Bed	AccountStatus	TransferReason
I	IR	201	B	IR	101	A	ADM	Reason For Transfer

You can see the magic of A02, the patient's physical loation has been restored to his prior location.

Note:

ADT messages always contain current information except MRG segments
Process all the fieds in PID & PV1 & other segments in message as normal A08 upate message unless specified by source system.
It is recommended not to send any updated fields except required ones in A02. A08 should be used to update any other fields.