In hospitals, there might be a need to swap beds between two patiens. HL7 has provided this trigger event (A17 Bed Swap) to perform this task.
This is a special kind of message which contains two different Patient ID & Visit segments for both patients.
In this article I will discuss how to implement this message & will request readers to add to this or correct me.
HL7 has provided this message type to swap beds and there is a common way to treat this message. But before implementing any interface for this please contact your client or administrator of source system which is sending this message.
Before I start how I have handled A17 (Bed Swap) messages in my implementations, let me describe some sematics of A17 (Bed Swap) messages:
Suppose, two patients A & B had a bed exchange and we have received A17 trigger to reflect this in our system.
These messages contain two PID segments containing patient identifiers & demographics
first one will be of Patient A and second one will be of Patient B. These segments are important to indentify two patients who swap or exchange beds.
Same way we will have two PV1 segments containing visit information.
First PV1 will contain Patiet A's visit details and second PV1 will contain Patient B's visit details. These segments are important to identify both patient's current & prior locations.
We can also have optional PV2s for both patients. I don't want to include PV2 in scope of this article, but it can surely provide some valuable comments/reasons for bed transfers.
Now, lets discuss implementation:
Suppose we have two patients A & B registered in our system as inpatient.
Note: If you find A17 where any of the PV1s says outpatient or preadmit, please clarify it with the administrator of source system which is sending the feed.
Here is a sample PV1 data of both of this patients in our database
AssignedPatientLocation | PriorPatientLocation | ||||||
Patient | PatientClass | PointOfCare | Room | Bed | PointOfCare | Room | Bed |
Patient A | I | PTC | 353 | 1 | |||
Patient B | I | PTC | 354 | 2 |
Now, we have received A17 message to swap beds of A & B
After processing this A17, database values will changes as following:
AssignedPatientLocation | PriorPatientLocation | ||||||
Patient | PatientClass | PointOfCare | Room | Bed | PointOfCare | Room | Bed |
Patient A | I | PTC | 354 | 2 | PTC | 353 | 1 |
Patient B | I | PTC | 353 | 1 | PTC | 354 | 2 |
Can you see the magic of A17? Please see the AssignedPatientLocation & PriorPatientLocation columns and match them with previous data.
Before A17, Patient A's location was Room 353 Bed 1 and Patient B's location was Room 354 Bed 2
Now After A17, Patient A's location is Room 354 Bed 2 (Patient B's prior location) and Patient B's location is Room 353 Bed 1 (Patient A's prior Location)
Important
Please get clarification from your source system administrator on following:
A17 message with PID Segment count != 2 (these should be skipped with an error)
A17 message with PV1 Segment count != 2 (these should be skipped with an error)
A17 message with both PID's having same patient ID (these should be skipped with an error)
What to do if we receive an A17 message for a patient which is not registered in our system? (skip the message or register the patient and continue)
Note:
ADT messages always contain current information
Process all the fieds in PID & PV1 & other segments in message as normal A08 upate message unless specified by source system.
Patient's Current Physical Location will be in PV1.3 & prior location will be in PV1.6
Let me quickly discuss why do we need A17 when we have A02 (transfer) message.
With A02, bed swap will become a three step process.
This is very similar to swap algorithm that we learn while learning basics of computer programming:
To swap values between variables A & B
have temporary variable T
T = A
A = B
B = T
Now, I will let readers to think how can we swap beds with A02 message and why we have A17?