Stream: implementers
Topic: reporting of a Patient's tracked location
Simone Heckmann (Sep 21 2016 at 21:00):
How would a Device tracking a Patient's Location (e.g. a wearable device detecting emergency situations) report the Location?
The question is derived from a comment on David's Blog: https://fhirblog.com/2016/09/20/fhir-and-version-2-the-location/:
My question is could, should and how would location info be posted for info collected by a Consumer/Patient Mobile Health Device?
Case 1: Patient fallen, can’t get up [...]
Simone Heckmann (Sep 21 2016 at 21:04):
I'm considering the actual event to be recorded as an Observation with a Location reported by a Device, thus Observation.device.location...?
Jason Walonoski (Sep 22 2016 at 12:03):
In Synthea (synthetic patient generator), we're using an extension... right now on Patient, but it could be on any resource...
Jason Walonoski (Sep 22 2016 at 12:03):
{ "url": "http://standardhealthrecord.org/fhir/extensions/wkt-geospatialpoint", "valueString": "POINT (-71.10671654481652, 41.85438652696115)" }
Jason Walonoski (Sep 22 2016 at 12:04):
The format is the WKT ( Well Known Text) standard. So the first number (-71) is longitude, and the second (41) is latitude.
Simone Heckmann (Sep 22 2016 at 13:23):
I think for the above use case, a point in space only has meaning if it is associated with a point in time. What is your usecase for capturing a Patient's location without a timestamp? Are your synthetic Patients not moving around? :)
Simone Heckmann (Sep 22 2016 at 13:30):
I admit I had never heard of WKT before, so I looked it up: https://en.wikipedia.org/wiki/Well-known_text
According to that, shouldn't the notation of the coordinates be whitespace separated rather than colon separated?
Jason Walonoski (Sep 23 2016 at 10:56):
The use case is to geolocate their address... but yes, if they were moving around and we were tracking them ala "big brother" then we'd have timestamps. And yes, you are correct, the comma is invalid.
Brian Postlethwaite (Sep 23 2016 at 19:33):
There is an extension on address that you can now use as defined here:
http://hl7.org/fhir/2016Sep/extension-geolocation.html
and a sample resource with it filled in here:
http://sqlonfhir-ci.azurewebsites.net/fhir/Patient/10004992
Brian Postlethwaite (Sep 23 2016 at 19:33):
You can convert this into your WKT format on the client side, and others who don't use that format don't have to parse it out.
Brian Postlethwaite (Sep 23 2016 at 19:34):
Really handy if you're using the addresses for routing home visits ;)
Jason Walonoski (Sep 26 2016 at 13:18):
Latitude is spelled incorrectly on that extension. Submitted gforge ticket: 12185
Brian Postlethwaite (Sep 27 2016 at 12:11):
Thanks, will fix
Simone Heckmann (Sep 28 2016 at 13:12):
I agree, that this extension is useful for (static) adresses but not for moving objects! I believe that there will be plenty of IoT use cases to trace Patients, Devices, or Practitioners around, requiring to pinpoint their Location at a specific time or their "Last known location". I'm still not sure how to handle that. I rather wouldn't extend the tracked Resources because in case of high precision tracking there'd be way too many updates on the Resources.
I'd rather have one seperate Resource referencing the tracked person/item and reporting their last known location.
The Location Resource however is not a good fit for this as it has neither a reference to the tracked person/item, nor a timestamp (altough: it has lastUpdated...!)
So... would an extension on Location named "tracking" with Reference to any potentially trackable Resource (Patient, RelatedPerson, Practitioner, Device... what else...?) be helpful?
Or do we need a new Resource altogether...?
Do we need additional information about the method/precision/frequency of the tracking...?
John Moehrke (Sep 28 2016 at 14:04):
Why do you think that would be 'way too many updates'? This seems exactly what would be done.
Simone Heckmann (Sep 28 2016 at 14:10):
IDK feels weird to update an otherwise relatively static resource like Patient or Device every other second just to update the location, especially with all the potential for write conflict... I mean: any client who tries to update the Patient address would subsequently hit a write conflict because the tracker updated the Resource at least twice during the time you need to type a street name.
John Moehrke (Sep 28 2016 at 14:19):
I see my confusion. For your usecase, I thought that Patient had a location element, and you would be updating the Location resource which does have GPS coordinates. Might be a good CP to write up. I am not clear how 'current patient location' is intended to be handled. In the Location resource they hint about "Patient's Home", but don't even show that (I think that use-case is not in scope anymore).
Simone Heckmann (Sep 28 2016 at 16:19):
Actually, this isn't really my usecase, it just popped up when a reader commented on my blog about V2 location mapping
https://fhirblog.com/2016/09/20/fhir-and-version-2-the-location/
I wonder if there's anyone here who actually has this use case and can give us more input, rather than me just making up stuff :D
Lloyd McKenzie (Sep 29 2016 at 22:54):
In general, patient locations are only tracked when they're admitted, so the patient's location is handled using Encounter, not Patient
Simone Heckmann (Sep 29 2016 at 23:50):
I reckon, the information that the patient's encounter is assigned to a Bed/Ward and the Information that the Patient is currently halfway between his Bed and the Radiology Department are two different kinds of "Location".
Also, I believe that Patient tracking is more relevant in homecare scenarios, where wearable devices are used to detect seizures or collapses and report the incident. In these cases, there is no Encounter context.
Brian Postlethwaite (Sep 30 2016 at 04:43):
This is potentially quite different in residential aged care. Where the resident actually has a Bond on the room itself, or independant living unit.
Last updated: Apr 12 2022 at 19:14 UTC
