Purpose

The creation of this project closely followed the ANSI withdrawal of the HL7v3 specification in 2022, which was the only available standard for the implementation of a Real Time Location System (RTLS) at the time. Since RTLS and patient location tracking continues to be a growing space, this introduced the need for a more current standard, such as FHIR, that is able to continue supporting all previously existing workflows, as well as support the addition of new functionality to the standard.

Current Project

For this version of the RTLS FHIR Implementation Guide, the primary focus is to implement an event-driven communication model as the method for sending tag location updates from a RTLS to a subscribing system, such as an electronic health record (EHR) system. This means that initially, the specification primarily defines the Tag Centric Workflow. It also includes the use of tags to drive auxiliary functions, such as a Staff Duress signal. See the Specification page for more technical details.

Tag Centric Workflow

The Tag Centric Workflow is a scenario where the event listener or non-RTLS system is the source of truth for all information about tag associations. The only roles of the RTLS is this case are to notify the event listener when a tag has a new/updated location, which tag the update is for, and what the new/updated location is. The following storyboard illustrates this workflow:

1. A patient arrives at the hospital and is assigned a tag. The tag's unique ID is entered into the EHR system, and the "association" is recorded in the EHR system.
2. Since the tag is now associated with a patient, the hospital wants to receive updates on the tag's location so that they know where the patient is throughout their stay. The EHR system communicates this desire to the RTLS by sending a Enroll Tag message containing the tag's unique ID.
3. The RTLS receives the Enroll Tag message with the tag's unique ID, and knows which tag to "enroll," or start sending updates for.
4. The patient is escorted to their room, bringing along their tag with them. The RTLS notes the tag's new location and notifies the EHR system with a Tag Location Update message containing the tag's unique ID and the updated location.
5. The EHR system receives the Tag Location Update message with the tag's unique ID, and recognizes it as the tag associated with the patient. The EHR system records the location sent from the RTLS as the patient's most recent location.
6. The patient finished their treatment and was discharged, returning their assigned tag in the process. This "disassociation" is recorded in the EHR system.
7. Since the tag is no longer associated with a patient, the hospital no longer wants to receive updates on the tag's location. The EHR system communicates this to the RTLS by sending a Unenroll Tag message containing the tag's unique ID.
8. The RTLS receives the Unenroll Tag and knows which tag to "unenroll," or stop sending updates for.

Terminology

• Enrolled - The state of a unique tag when the event listener wants to receive updates related to that specific tag.
• Association - The linkage between a tag and its subject. Literally, an association indicates that a tag is attached to or physically in the same location as the subject.
• Unenrolled - The state of a unique tag when the event listener does not want to receive updates related to that specific tag.
• RTLS - The acronym for Real Time Location System, which is a server/software that captures, processes, and stores information about the location of tags.
• Subject - The system that is "subscribed" to, or wants to receive updates from the RTLS about information pertaining to the location/status of tags.
• Tag - A physical tracking device that is assignable to patients, providers, staff, or other assets in the healthcare facility context. This may also interchangeably be referred to as a "beacon" or "tracking tag."

Auxiliary Function Workflow

The Auxiliary Function Workflow is where an auxiliary function supported by the tag is performed (e.g. a button on the tag is pressed) and notifies the event listener in order to facilitate a particular action. Currently the only supported function is a Staff Duress signal. The following storyboard illustrates this Staff Duress workflow:

1. A nurse fears for their safety, and presses a panic button on their tag.
2. The RTLS notes the tag's location and notifies the EHR System with an Auxiliary Function message containing the type of staff-duress, the location, and the device identifier.
3. The EHR receives the Auxiliary Function message, and recognizes it is a staff duress signal. The EHR system notifies a nearby security team that the staff member is under duress.
4. The EHR communicates back to RTLS that the auxiliary function was successful and provides the notification id that was created for this staff duress event, which will be unique from any other staff duress events received by the EHR.
5. The RTLS receives the notification id, which it can then poll to check for updates.
6. The RTLS notifies the EHR that it wants to read the notification based on that id.
7. The EHR receives the Communication Read, and recognizes it is for the staff duress notification. Since no one has acknowledged the notification yet, it sends back the communication resource with a status of in-progress.
8. The RTLS receives the communication resource, sees that it is still in-progress, then polls that resource again a few seconds later.
9. Sometime later, while the RTLS continues to poll the notification resource, a user acknowledges the notification through a workflow in the EHR.
10. The EHR receives the next Communication Read. Since someone has acknowledged the notification, it sends back the communication resource with a status of completed.
11. The RTLS receives the communication resource, sees that it is completed, then stops polling that resource.

Auxiliary Functions

• Staff Duress - If a user requires assistance pertaining to a security incident or threat, this function sends a distress signal that will notify nearby security members.