Stream: implementers
Topic: Saving multiple Location positions
Tristan Wilson (Aug 01 2018 at 17:13):
Hey everyone! Have a quick question regarding HealthcareService locations and coverageAreas in FHIR.
HealthcareService.location.reference > Location.position saves latitude, longitude, and altitude as decimal values.
HealthcareService.coverageArea.reference > Location.position only allows for one position to be stored; In a case where we are storing multiple positions (i.e Municipal boundaries) and have many positions needing to be stored in a specific order, what would be the proper way to store a coverage area in this case?
@Tim Berezny
Tim Berezny (Aug 01 2018 at 19:12):
Is creating an extension the only way put in a service's coverage area as a shapefile (like, .kml, which is a series of points that make up a shape such as a municipal boundary?)
Elliot Silver (Aug 01 2018 at 19:21):
At the moment, yes, however look at GF#13391, and https://chat.fhir.org/#narrow/stream/4-implementers/subject/Input.20on.20representing.20geoshape.20data.20in.20FHIR. Please provide feedback on GForge tracker item if you have an opinion.
Brian Postlethwaite (Aug 01 2018 at 22:14):
This is one that I'm hoping we get into R4 as a standard extension, so yes, please put your thoughts in that tracker! Time is getting short for our change.
The format of the boundary definition is the only thing to be decided right now.
Brian Postlethwaite (Aug 01 2018 at 22:15):
(and yes, some guidance notes in the Location resource highlighting the extension, and how it relates to the address/position properties)
Tim Berezny (Aug 02 2018 at 18:49):
The GeoJSON looks good to me. Would love to have this included in R4...
Elliot Silver (Aug 02 2018 at 20:16):
@Tim Berezny If a resource is retrieved in XML, do you feel GeoJSON for the location is still appropriate?
Tim Berezny (Aug 04 2018 at 12:51):
@Elliot Silver Well that's an interesting conundrum... Is there such as a shapefile format that has a parallel in both XML and JSON?
We have very advanced use of shapefiles as it relates to HealthcareServices. We only use JSON, so I don't have much insight into XML specifically. However, I can say that in the converse scenario if the format chosen was KML (which is XML) and that KML was returned in my JSON-oriented world, I would be fine with getting a KML file with no complaints.
In other words ... yes.
John Moehrke (Aug 04 2018 at 14:55):
I think the point here is to leverage external and commonly used standards. If the Geo standards are focused on JSON, then yes it is appropriate that JSON alone is used even when moving it around XML FHIR... SImilar is done in the Signature datatype, as we are leveraging external signature standards for the signature evidence. Note that the Signature datatype does expose in FHIR encoding some signature elements that are considered important to FHIR world. Note also that Signature datatype leverages mime-type to distance us from picking an external standard, and supports multiple... I am bias, as I own the Signature Datatype.
Lloyd McKenzie (Aug 04 2018 at 15:17):
The fun bit is whether it's sent as XML or JSON, it'll be base64 encoded in both transports.
Tim Berezny (Aug 04 2018 at 16:25):
I think a main criteria would be that’s it’s easily renderable in web mapping programs like google maps without conversions. It looks like geoJSON meets this criteria.
If it’s being sent as a base64 anyway, whether it’s JSON or XML becomes pretty much irrelevant. It’s the kind of data you’ll be running my through some kind of library anyway.
Brian Postlethwaite (Aug 07 2018 at 03:32):
It'll be string encoded json (or XML), not base64endocded..
I've had a wonder through a bit of info online, and most things support both these formats, and there are converters for both available to get into and out of each other, and other platforms.
So all things being equal, I suggest we go with GeoJSON as noted in the tracker item.
Last chance before this is done for R4! (plan to include in last PA R4 block vote)
Brian Postlethwaite (Aug 07 2018 at 03:34):
@Tim Berezny , @Elliot Silver , @Carl Leitner , @John Moehrke, @Tristan Wilson
Brian Postlethwaite (Aug 07 2018 at 03:39):
Note that I've drafted the resolution into the tracker item, so you can see exactly what it is that we are proposing, so you can compare with any internal definitions you may have defined.
@Abigail Watson , @Cooper Thompson
Elliot Silver (Aug 07 2018 at 03:42):
What are “both these formats”?
I think that for clarity, if we have an always JSON string, it should be base64 encoded (potentially as a full Attachment). Saying it is an always-JSON string in a regular convertible resource is going to lead to errors.
Hmmm, the Atrachment parallel brings up an interesting issue: how large will these strings be? Do we want the ability to reference an external GeoJSON string?
Brian Postlethwaite (Aug 07 2018 at 03:47):
Sorry, the 2 main formats under consideration/suggestion were KML (google/XML) and GeoJson
Brian Postlethwaite (Aug 07 2018 at 03:48):
I'll encode up some boundaries and check the sizes (it also depends on the level of accuracy/detail that is included in the shape)
Brian Postlethwaite (Aug 07 2018 at 04:00):
https://data.boston.gov/dataset/city-council-districts
The total of boston's location data (not sure on its granularity)
KML(XML) 205KB
GeoJson 202KB
Base64 encoded GeoJson 1.1MB
Brian Postlethwaite (Aug 07 2018 at 04:01):
This is the 9 districts of Boston, so maybe divide the size by that as you'd likely only have 1 district per FHIR location resource, but I guess this gives you some idea as to the size.
And also a feel as to the cost of the encoding
Brian Postlethwaite (Aug 07 2018 at 04:02):
(and we'd need to chose which charset to encode/decode with UTF-8?
Grahame Grieve (Aug 07 2018 at 04:26):
always UTF-8 unless there's a really coherent reason
Abbie Watson (Aug 07 2018 at 04:26):
+1 for GeoJson. Clear favorite.
Won't bash KML, since it's tried and true. Just not supported in browsers. Good option for XML based systems.
Base64 approach is... misguided, in my opinion. Would vote against.
Happy to provide code samples, application samples, FHIR based geomapping examples, etc.
Abbie Watson (Aug 07 2018 at 04:38):
To bring in GeoJson officially, we need to think about the supporting geospatial primatives. Good news is they're already defined, similar to FHIR Datatypes. But if we want FeatureCollection, we'll need Feature, which generally relies on MultiPolygon, Polygon, Line, and Point.
Brian Postlethwaite (Aug 07 2018 at 04:55):
Would definitely love to see those example resources @Abigail Watson !
With your permission would like to include one/some updated to the formal name etc.
Brian Postlethwaite (Aug 07 2018 at 04:56):
If they aren't already publicly available, could you put them on one of the public servers, mine if you like
http://sqlonfhir-stu3.azurewebsites.net/fhir/Location
Abbie Watson (Aug 07 2018 at 05:09):
Mmmm.... not sure it's quite possible to upload the geojson to a /fhir/Location path. Here's a .geojson file of 2014 Health Service Areas for the U.S.
Be forewarned, it's 22MB... pretty typical for geojson maps, and certainly not the largest file we work with. (The geomapping files are similar in size to DICOM images.)
You can load this file up into Google Maps. One can extract FHIR Organizations from this file; or do vice-versa and write FHIR Organizations into the properties field and and FHIR Locations into the geometry field.
Brian Postlethwaite (Aug 07 2018 at 05:16):
I thought you already had some fhir location resources already up and going from your screenshots pasted into the tracker ;)
Abbie Watson (Aug 07 2018 at 05:16):
Oh, I have those too.
Abbie Watson (Aug 07 2018 at 05:17):
Um, are Chicago area hospitals okay? That's the dataset we usually use.
Brian Postlethwaite (Aug 07 2018 at 05:18):
Yup, as long as we aren't violating any copyright issues.
Brian Postlethwaite (Aug 07 2018 at 05:18):
Or privacy issues :P
Abbie Watson (Aug 07 2018 at 05:19):
Locations of hospitals are usually in the public domain, so we'll probably be okay.
Brian Postlethwaite (Aug 07 2018 at 05:20):
Ok, send the links on through and I'll check em over.
Abbie Watson (Aug 07 2018 at 05:22):
Just put it on tomorrow's inbox. Let's check in tomorrow afternoon.
Brian Postlethwaite (Aug 07 2018 at 05:24):
Changes to the spec are getting closing soon, and we need to land this for voting before it can go into R4 which is closing soonish, would prefer not to miss the boat on this one if we can.
But thanks so much for your contributions here!
Brian Postlethwaite (Aug 07 2018 at 14:05):
I've pre-applied a version of the standard extension that we're discussing on the call today at 3pm eastern
http://build.fhir.org/extension-location-boundary-geojson.html
Tim Berezny (Aug 07 2018 at 14:34):
GeoJSON vs. KML, i'll go with the flow.
The question by @Elliot Silver is worth poking at a bit: "Hmmm, the Atrachment parallel brings up an interesting issue: how large will these strings be? Do we want the ability to reference an external GeoJSON string".
In particular... being able to EXTERNALLY reference a GeoJSON string could be very quite helpful. So long as that's possible, the various sizes of potential GeoJSON strings becomes much less constraining.
Definitely don't want to "miss the boat" as @Brian Postlethwaite says on this one.
Brian Postlethwaite (Aug 07 2018 at 14:37):
I don't know what resource type the external definition is.
Interested to get some real examples of the GeoJSON to check the sizing.
An area of boston as defined above looks like it was around 20kb. Remember that this is the boundary of the specific resource, not of a group of areas.
Tim Berezny (Aug 07 2018 at 14:57):
I think what i mean is, you could allow the GeoJSON to be inline in the resource, and also allow it to be listed as a URL to go grab it anywhere on the internet. (similar to how we have "data" and "url" in the attachment datatype).
The size of shapefiles can vary wildly, especially when there are tight contours to shorelines. Our largest in 30k vertices. It's in PostGIS so the size won't be exactly the same but the structure is not too different from GeoJSON, and it clocks in at 2.5MB. That's the extreme end of the spectrum probably.
Elliot Silver (Aug 07 2018 at 16:31):
@Tim Berezny , @Brian Postlethwaite , yes, the data/url capability was what I was referring to. At 20K, I'd say that's about where it makes sense to have references to the data rather than inline it. We don't want to have every reader of the location resource have to read/skip that content regardless of whether they are interested in the mapping info or not.
Abbie Watson (Aug 07 2018 at 18:15):
In particular... being able to EXTERNALLY reference a GeoJSON string could be very quite helpful. So long as that's possible, the various sizes of potential GeoJSON strings becomes much less constraining.
Yes, this is how GeoJSON is designed to be used. No need for a Base64 encoded attachment. We use it with great success. Can sometimes be a bit slow to load; but it's been very reliable.
Abbie Watson (Aug 07 2018 at 18:17):
The size of shapefiles can vary wildly, especially when there are tight contours to shorelines. Our largest in 30k vertices. It's in PostGIS so the size won't be exactly the same but the structure is not too different from GeoJSON, and it clocks in at 2.5MB. That's the extreme end of the spectrum probably.
Haven't gotten around to drawing nation wide maps yet, eh? :) We have lots of 20MB+ files; and some of them get up to be 100MB files. Same general size as DICOM, roughly speaking. But no problems as long as the internet connection is reasonably fast. My $0.02 is this is very dependent upon one's development environment... monitors, available RAM, and network speed. The more screen real-estate and RAM you have, the more comfort you'll be pushing around large geodata files.
Abbie Watson (Aug 07 2018 at 18:19):
@Brian Postlethwaite Some Chicago Area Hospitals coded up as Locations. Pretty typical. We use these with pathfinding and paratransit ambulance routing applications. We haven't been using the PUT functionality all that much, so currently working on that functionality. In the meantime, here's a (virtual) hand delivered Bundle.
ChicagoAreaHospitals.Locations.fhir
Abbie Watson (Aug 07 2018 at 18:22):
That's our internal representation. We extend the resources by adding a location field for a GeoJSON Point primitive, so we can use Mongo's 2-sphere geospatial index. It duplicates the lat/lng data, which would be nice to have resolved. But that would involve harmonizing the FHIR and GeoJSON specifications on the Point data primitive.
Abbie Watson (Aug 07 2018 at 18:47):
Heh. Tried to send over the Bundle via Postman, and your server really didn't like it. Unknown Bundle, missing Narrative.div, unknown Location.location field, empty Location.address[0], and System.Xml.XmlTextReaderImpl errors. Mostly all to be expected.
Brian Postlethwaite (Aug 07 2018 at 19:03):
Did you want to join the call which is just starting now to discuss?
Elliot Silver (Aug 07 2018 at 19:04):
A PA call?
Brian Postlethwaite (Aug 07 2018 at 19:05):
yes
https://global.gotomeeting.com/join/311685429
1-770-657-9270 Participant Code: 986210
for non-US participants: https://www.intercallonline.com/listNumbersByCode.action?confCode=4603612751
Brian Postlethwaite (Aug 07 2018 at 19:16):
So change my extension to be extension.valueAttachment with the same thing?
Elliot Silver (Aug 07 2018 at 19:17):
I think that would be simplest.
Elliot Silver (Aug 07 2018 at 19:18):
FYI: application/vnd.geo+json is registered.
Correction -- looks like they've upgraded: application/geo+json
Abbie Watson (Aug 07 2018 at 19:33):
Joined on call.
Brian Postlethwaite (Aug 07 2018 at 20:05):
Thanks all for your contributions on this one, the committee has approved the standard extension (attachment) for this functionality.
This results in it being contained (base64 encoded in the data) or external (through the URL property)
Abbie Watson (Aug 07 2018 at 20:07):
Was that a balloting call? PA? What does PA stand for again? I feel like I just participated in something official, and I don't know what! :D
Elliot Silver (Aug 07 2018 at 20:08):
Yup, Patient Admin.
Lloyd McKenzie (Aug 07 2018 at 20:49):
HL7 is highly addicted to acronyms (starting with our own name :>) A cheat-sheet to the work group abbreviations can be found at the bottom of the FHIR WGM agendas (e.g http://wiki.hl7.org/index.php?title=FHIR_Agenda_201805_WGM). Much of the reconciliation of tracker items is handled on conference calls like that one. Far more gets handled at conference calls than face-to-face at WGMs (though we typically have fewer people on calls than at face-to-face sessions)
Brian Postlethwaite (Aug 07 2018 at 21:01):
For your viewing pleasure, the new standard extension (only took how long for us to get there?)
http://build.fhir.org/extension-location-boundary-geojson.html
Brian Postlethwaite (Aug 08 2018 at 02:02):
On a related note, I'm updating the definition of the Location near search parameter (GF#14216) and wanted to give a preview of the new format for comment. (this is a "special" type search parameter and isn't able to use generic search processing logic)
GET [base]/Location?near=-83.694810|42.256500|11.20|km,active=true
near = {latitude}|{longitude}|{distance}[|{unit}) If distance is missing, then default is kms.
The new format is done as a single parameter, and therefore can work with multiples, and also through chaining.
This also got me thinking about our new standard extension, should we also have a new search parameter for that to cover the point in area space - tracker and thoughts for the future on this one
Brian Postlethwaite (Aug 08 2018 at 02:04):
@Elliot Silver , @Abigail Watson , @Cooper Thompson , @Carl Leitner Thoughts on this?
Brian Postlethwaite (Aug 08 2018 at 02:05):
p.s. the near-distance search parameter will also dissappear as is no longer required, its merged into this single parameter
Elliot Silver (Aug 08 2018 at 02:08):
If units is missing, then it defaults to km?
Elliot Silver (Aug 08 2018 at 02:09):
Distance is max distance from point?
Elliot Silver (Aug 08 2018 at 02:29):
Hmm, so we now have two definitions of the place of something - the lat/long, and the boundary. What does it mean when both are populated? Is one the front door, and the other the area it is responsible for?
When you search, are you looking for the nearest front door, or who is responsible for a particular place? You may be dealing with the case where the neighbouring jurisdiction office is closer than your jurisdiction’s office.
There may be multiple locations that all cover the same point. What does that mean for nearest?
(Aside - is “nearest” expected to be straight-line, travel distance, travel time, ...?)
Brian Postlethwaite (Aug 08 2018 at 02:30):
y (within distance) - server could have its own decision as what nearest means
Brian Postlethwaite (Aug 08 2018 at 02:31):
Multiple locations at same point, then they'll get returned in the search results. As you'd expect.
Brian Postlethwaite (Aug 08 2018 at 02:37):
There is no expectation that the near relates to the boundary, I expect people will use near to locate a place, where they will use the boundary to perform a different search on that extension, maybe:
GET [base]/HealthcareService?coverageArea.contains=-83.694810|42.256500
This would check that the provided point is in the coverage area of the Healthcare Service
Brian Postlethwaite (Aug 08 2018 at 02:38):
In the search results you may get a distance from the location to the point you specified, which would help you locate the appropriate location
Elliot Silver (Aug 08 2018 at 03:15):
Ok, so you are asking if we need a search specifically on the new extension? nearestBoundary (or insideBoundry) search?
I’m mixed on that. On the face of it, it might be useful, but it also seems like a smart server could use it in calculating the response to near.
What does strike me as useful, is the ability to specify modes or hints in the near search: straight-line, driving distance, walking time, jurisdiction not point,...
Do we need to be able to search against another boundary or just a point? Another boundary opens up several cans of worms.
I filed the original issue on behalf of IHE and @Luke Duncan, and don’t deal with GIS issues myself. Although I find the topic interesting, I’ll step back and let other with experience answer further.
Abbie Watson (Aug 08 2018 at 03:30):
near and contain roughly map onto the geospatial database operators, and are pretty good parameters to support, in the same way that GET/PUT/POST/DELETE roughly map onto CRUD. They're a pragmatic choice.
The issue of 'near' in terms of travel time, distance, gas mileage costs, or other metrics are compound functions built on top of those geospatial primitives. Scalars vs vectors. So, if we have near and contain, we have the necessary information to do the geometry, and can build up most of the other details from them.
All things considered, we get a lot of mileage from them, it's a bit more than I expected to see in the API, and they provide enough functionality to keep a lot of people busy for awhile.
I keep stressing the following point, and need to reiterate it again: Before building out more search parameters, I think FHIR needs to have official support for geospatial primitives (Point, Line, Polygon, MultiPolygon). near and contain are freebies that geospatial databases often optimize for and expose as special operators because they're so commonly used. But more advanced functionality like paths, pathfinding, region intersections, etc need those primitives.
Brian Postlethwaite (Aug 08 2018 at 03:33):
And I think those really should stay outside of the FHIR space and let the geospatial things do their bit.
(I think that is agreeing with you Abigail?)
Brian Postlethwaite (Aug 08 2018 at 03:34):
I think contains and near are actually quite different things.
In some contexts the contains is the eligibility, if you're over the street, you don't get service.
Abbie Watson (Aug 08 2018 at 03:35):
Well, we can let the geospatial folks define and manage the geospatial primitives. We can also forklift/piggyback on their work, and simply say that any GeoJSON primitive is also a FHIR datatype. But that probably needs to be explicit.
Brian Postlethwaite (Aug 08 2018 at 03:36):
Except that then doesn't help with the XML world. And extensions wouldn't apply to it.
Brian Postlethwaite (Aug 08 2018 at 03:36):
So not feeling very fhir-y
Abbie Watson (Aug 08 2018 at 03:36):
And therein is the rub.
Brian Postlethwaite (Aug 08 2018 at 03:37):
I kinda like where we got things to, enough to permit the overlap to occur, now we just need to see how we can make them work together before we get too excited :grinning:
Brian Postlethwaite (Aug 08 2018 at 03:38):
(Not proposing we put the contains operation in R4, but maybe consider at connectathons if people are keen enough)
Tim Berezny (Aug 08 2018 at 13:17):
I 1000% support a contains search parameter (searching for an address within a coverage area). In our application we focus on home and commuity care services, and contains is acutely relevant for finding homecare services. i.e., for home care services, it's irrelevant what a HealthcareService's office address distance from home is (near function), need to know where it deliver's home care to (contains function).
contains search is to coverageArea as near search is to point
Tim Berezny (Aug 08 2018 at 13:19):
In other words, it's GREAT that there is now a (proposed) method for storing shapefiles, but that really is only half of the equation. Most of the benefit from having a shape comes from being able to do a search (contains) within that shape.
Tim Berezny (Aug 08 2018 at 13:22):
I haven't done any work with extensions yet ... so this is probably my extension newbiness speaking, but should i expect to see something at the link referenced in the extension (which is blank now)? http://hl7.org/fhir/StructureDefinition/location-boundary-geojson
Brian Postlethwaite (Aug 08 2018 at 20:55):
Once the R4 is officially published that URL should resolve, however the details of the extension are here
http://build.fhir.org/extension-location-boundary-geojson.html
Brian Postlethwaite (Aug 08 2018 at 21:04):
And yes, we can probably talk about the search operation at the connectathon, and get some agreement on that, and try it out
John Moehrke (Aug 08 2018 at 21:42):
Sequoia (CareQuality and eHEX) have a Provider Directory with geolocation information in it. @Eric Heflin see this javascript page driven off of their FHIR API https://sequoiaproject.org/carequality/active-sites-search/
Brian Postlethwaite (Aug 08 2018 at 21:47):
I suspect that one is just using the positions, rather than boundaries (which is the new part)
But thanks for the link too!
Brian Postlethwaite (Aug 08 2018 at 21:51):
I also assume that in that implementation the distance is in miles?
Brian Postlethwaite (Aug 08 2018 at 21:52):
(Must test that my server handles the Mi/Km conversion correctly, have tested Km/m but not the other)
Brian Postlethwaite (Aug 19 2018 at 03:26):
And those looking for an example of the new format!
http://build.fhir.org/ig/HL7/VhDir/Location-wash-dc-metro.xml.html
Last updated: Apr 12 2022 at 19:14 UTC
