Stream: implementers
Topic: Patient location tracking
René Spronk (Dec 03 2018 at 14:15):
How does one support real-time location tracking for Patients ? One can track locations for encounters, but that's not really useful here as that would be the 'prereserved bed', not 100s of locations where the patient is know to be if they wander the corridors.
Cooper Thompson (Dec 05 2018 at 19:54):
We'd been considering using Device for RTLS. The Device would basically represent the RFID tag that is given to the patient. We haven't really gotten into the details, and right now we'd need an extension on Device to represent the physical coordinates. I'm interested in where this discussion goes.
Eric Haas (Dec 05 2018 at 19:58):
If the coordinates are reported by the device that would be a pair of observations
Eric Haas (Dec 05 2018 at 19:59):
Extension on device would be static Why not reference a location
John Silva (Dec 05 2018 at 22:06):
Wasn't there some discussion about using geo-location data format/standards ? Was there thought of having a FHIR GeoLocation data type?
Eric Haas (Dec 05 2018 at 22:22):
there is an extension:
http://build.fhir.org/extension-geolocation.html
on Address
Craig McClendon (Dec 05 2018 at 22:23):
Location already allows for capturing lat/long coordinates as attributes of the Location. But if those were rolled up into a datatype then Observation.value[x] could capture them. It would also better lend to other uses as a datatype (calculations, geo-fencing, various other GIS-related operations, etc.)
Eric Haas (Dec 05 2018 at 22:26):
could use Obs as it is with a lat and lon components with value int.
René Spronk (Dec 06 2018 at 08:39):
This may not just be about lat/long, which would be the raw data, but it may have a translation for humans, i.e. the patients location is "hallway 2 in building 7", or "17, main street". That could be a Location resource, or mapped from the long/lat using some translation logic.
It would be an Observation (done by the Device), not just a Device resource. We'd have to extend Observation with a valueReference (or: valueLocation) to reference a Location resource (which holds both the geolocation as well as human-interpretable descriptions of the geolocation, and an optional address).
Lloyd McKenzie (Dec 11 2018 at 02:26):
@Brian Postlethwaite ?
Brian Postlethwaite (Dec 11 2018 at 04:46):
Not something that I've had to try out, and the level of detail that is here feels more like an operation rather than a property or extension on a resource.
However the result of the operation could be a location resource, maybe.
Also interested in if there are more than just where is this patient, but rather where are all the patients...
Brian Postlethwaite (Dec 11 2018 at 04:48):
And device does sound pretty right to me, the automated tracking of the patient would have to come from some form of device, which does have a location reference on it. So that could be either contained with the current values, or if it as a known registered location, reference that instance.
René Spronk (Dec 11 2018 at 09:54):
In general this is about real time asset tracking. An operation sounds like a proper way of doing this if one has the use case "where's X now?" - but sometime you may wish to track where something has been in the past, much like a fitness tracker. Like a valueSampledData in an Observation.
John Silva (Dec 11 2018 at 10:43):
Yes but you do not need a 'device' to provide geo-coordinates; e.g. a set of lat/long for locations within a hospital (hard-wired or in a DB). Not sure if this has already been discussed before but you could imagine use cases where each Location (or Organization) has it's own geo-location (rectangular or otherwise); this is why it might be nice to have a reusable DataType.
Thomas Tveit Rosenlund (Feb 28 2019 at 09:30):
We have actually implementet Location tracking of patients (as a part of assisted living services) using the Location resource. The use case description includes the need for more accurate location data (velocity, accuracy etc.) as well as the need to send Location measurements from the device only when the device is outside a predefined geofence. I tink we got an implementation of this profile running somwhere in Trondheim, but I have not gotten around to getting any actual information about how it did work out for them.
The profile should be remade as well because I added the altiture to an extension for some reason, I think it was the vendor that preferred information about the metric used as part of the element name, not so smart in hindsight however. I guess we could use the Observation for this, but it seemed that the Location resource was a better fit and should cover this use case "A Location is valid without an address in cases where it could be purely described by a geo-coded location in remote areas, or when recorded by a device."
Eric Haas (Jun 05 2019 at 21:17):
what are folks doing with this?
- Observation + extension valueLocation?
- Observation + components?
- Other?
Last updated: Apr 12 2022 at 19:14 UTC
