Real Time Location Systems

Submitted by: Amit Popat (Epic) Revision date: 2007-02-21 Submitted date: 2007-02-20

Proposal Requirements

• Patients
  • Capture location updates and movement within a facility
• Providers
  • Real-time location of providers is needed for emergencies and efficiency
• Assets
  • Devices are expensive, and organizations would like to not lose them

Real-Time Location Systems (RTLS) capture, process and store location specific data. This proposal defines interface messages that might be sent to and from other types of systems that might consume this data.

Storyboards

• Patient – Tag Association (at Emergency Check In)
  • Adam Everyman arrives to Good Health Hospital Emergency Room via car. Mr. Everyman has broken his left hand. Christopher Clerk, the emergency room clerk registers and checks in Mr. Everyman and assigns him a unique RTLS tracking device with a tag ID E1124. A message is sent from the EMR system to the real time location system associating Mr. Everyman with the tag E1124.

• Patient Location Update
  • Mr. Everyman is then taken to room 12A where he waits for the physician on duty, Dr. Eric Emergency. A message is sent from the real time location system to the EMR with the updated location.

• Patient – Provider Association
  • Dr. Eric Emergency walks into Mr. Everyman’s room and checks Mr. Everyman’s hand. A message is sent from the real time location system associating Dr. Emergency with Mr. Everyman. Dr. Emergency suspects that Mr. Everyman’s hand is broken. He calls for the x-ray technician, Ms. Tina Technician.

• Patient – Provider – Device Association

Ms. Technician brings along the portable x-ray machine with her to Mr. Everyman’s room and performs the x-ray on his hand. A message is sent from the real time location system to the EMR associating Ms Technician, Mr. Everyman and the x-ray machine X-21 together.

Use Case Model

Activity Diagrams

• The activity shown above is used when one system is registering the location device (tag) with a particular role (e.g. Patient). This message could be generated by the RTLS or the registration system.

---

• The activity shown above is used to update the location of a particular tag (and thus the role associated with the tag - e.g. the patient). This message would be sent from the RTLS to the consuming system.

• The business rules surrounding when a tag is considered to be in a particular location is to be determined by the RTLS. This needs to happen so as to not have intermediate locations generate messages, but only the final location during the tag movement. These requirements are not captured by the activity diagram, as they include things like the tag having being in the same location for a particular set amount of time, and so forth.

---

• Tha activity show above is used when associating multiple tags (and thus roles associated to these tags) together by virtue of their proximity determined by spatial location by the RTLS. This message is sent from the RTLS to the consuming system.

• The budiness rules regarding the definition of proximity are to be determined by the RTLS and the consuming vendor system analysts. As this definition relies on the technology being used, the activity diagram does not capture these requirements.

Sequence Diagram

State Diagram

Message Data Requirements

<Coming Soon>

R-MIMs

• The following R-MIM is for the tag registration message, associating the Tag to the (Patient)Role. This shown as the first message in the Sequence Diagram.

---

• The following R-MIM is for the location update message, updating the Tag location (and thus the patient location). This is shown as the second message in the Sequence Diagram.

---

• The following R-MIM is for the location association message, associating two (or more) tags (and thus the associated roles) to each other by virtue of the location. This is shown as the third and fourth messages in the Sequence Diagram.

---

Here are the RTLS R-MIM Visios