Overview

This implementation guide defines the use of FHIR R4 resources to exchange information that describes the location of patients, providers, staff, equipment, or other permanent assets within a hospital or other healthcare facility. This data is typically exchanged between a healthcare system (e.g. EHR software) and a Real Time Location System (RTLS) that captures, processes, and stores information about the location of tags.

These tracking tags are associated with an assigned subject (i.e. patients, providers, assets) and their location data is recorded as the associated subject moves throughout a healthcare facility. This location data has many applications in the healthcare context, such as workflow automation, staff/asset tracking, and patient monitoring.

Current Scope

The current scope of this implementation guide defines the communication model for sending location data for a tag from a RTLS server to another subscribed system, such as the Electronic Health Record (EHR) software, henceforth referred to as the subscriber. This specification addresses the tracking of patients, providers, staff, equipment, or other permanent assets. Other subjects/resources that may exist in the healthcare setting such as supplies and pharmaceuticals are not in scope for this implementation guide, but may be tracked by some systems.

This initial implementation operates under the assumption that the RTLS server does not require information about the subject associated with a tag, known as the Tag Centric Workflow. In effect, this means that the RTLS system does not receive or store data about the patients, providers, staff, or assets associated with tags. Also, this means that the subscriber only receives location data for a specific tag, and must handle the association (and disassociation) of a tag to its subject exclusively.

The following relevant data exchange workflows are included as part of the initial scope:

• Enroll Tag - Indicates to the RTLS that the subscriber is requesting to receive updates for a specific tag (i.e. the tag is associated with a subject that the subscriber wants to track).
• Unenroll Tag - Indicates to the RTLS that the subscriber no longer wants to receive updates for a specific tag (i.e. the tracking is no longer associated with a subject that the subscriber wants to track).
• Tag Location Update - Notifies the subscriber that an enrolled tag has a new/updated location, as determined by the RTLS.

Planned Scope

Future versions of this implementation will support other relevant workflows for communication between a RTLS and another subscribed system (the subscriber).

This includes an additional communication model for a scenario where the RTLS requires information about the subjects associated with tags (i.e. data regarding the associations of tags is stored in the RTLS server). This need arises when the association and disassociation of a tag to its subject is handled on the RTLS side, for any number of tags. The following additional data exchange workflows are relevant for this scenario:

• Associate Tag - Indicates that a specific tag is newly associated with a subject and is now enrolled. This communication can originate from either the RTLS or the subscriber.
• Disassociate Tag - Indicates that a specific tag is no longer associated with a subject and is no longer enrolled. This communication can originate from either the RTLS or the subscriber.

Guidelines for implementing other data exchange workflows are planned to be added in the future to support additional functionality that some Real Time Location Systems may offer, such as the following:

• Tag Co-location Notification - Indicates that two or more enrolled tags, each associated with a unique subject, are in the same location and are determined to be "co-located," as defined by the RTLS. Consider, for example, two tags where one is associated to a patient and the other to a provider. The two tags are in the same location for more than 30 seconds while the provider is examining the patient. If 30 seconds is the length of time at which the RTLS considers two subjects to be "co-located," the subscriber would be notified of the co-location event.
• Tag Auxiliary Function - Notifies the subscriber that an auxiliary function supported by an enrolled tag was performed (e.g. a button located on the tag was pressed by the subject).
• Tag Status Update - Notifies the subscriber that an enrolled tag has an update in status (e.g. the tag has low remaining battery life).
• Tag Availability Update - Indicates to the subscriber whether a currently unenrolled tag is or isn't available to be associated with a subject (e.g. a tag is lost/missing, non-functional, or newly added to circulation)

Implementation Guide Structure

This implementation guide is organized into the following main sections which provide background and technical details for exchanging location information using a framework of tags which are associated to patients, providers, staff, equipment, or other permanent assets:

Background	Introduces key workflows/concepts and defines terminology that are relevant for this implementation.
Specification	Describes the communication model and technical expectations for this implementation.
Artifact Index	Provides a list of the FHIR artifacts and resource profiles defined as part of this implementation guide.

Dependencies

IG	Package	FHIR	Comment
Real Time Location Services Implementation Guide	hl7.fhir.uv.rtls#1.0.0-ballot	R4
HL7 Terminology (THO)	hl7.terminology.r4#5.5.0	R4	Automatically added as a dependency - all IGs depend on HL7 Terminology
FHIR Extensions Pack	hl7.fhir.uv.extensions.r4#5.1.0	R4	Automatically added as a dependency - all IGs depend on the HL7 Extension Pack

Package hl7.fhir.uv.extensions.r4#5.1.0 This IG defines the global extensions - the ones defined for everyone. These extensions are always in scope wherever FHIR is being used (built Sat, Apr 27, 2024 18:39+1000+10:00)

Global Profiles

There are no Global profiles defined

IP Statements

No use of external IP