Stream: Covid-19 Response
Topic: Location extensions for Beds, Helipads, & Trauma Centers
Abbie Watson (Apr 13 2020 at 06:15):
Hi,
So I've been digging into the ArcGIS HIFLD Hospital data file, and interestingly it provides a nation wide inventory of 7581 hospitals, including bed count, trauma center availability, and helipad availability. Here's a sample record if anybody wants to take a look:
{
type: 'Feature',
properties: {
OBJECTID: 1001,
ID: '0007892363',
NAME: 'COLORADO RIVER MEDICAL CENTER',
ADDRESS: '1401 BAILEY AVENUE',
CITY: 'NEEDLES',
STATE: 'CA',
ZIP: '92363',
ZIP4: 'NOT AVAILABLE',
TELEPHONE: 'NOT AVAILABLE',
TYPE: 'GENERAL ACUTE CARE',
STATUS: 'OPEN',
POPULATION: 25,
COUNTY: 'SAN BERNARDINO',
COUNTYFIPS: '06071',
COUNTRY: 'USA',
LATITUDE: 34.8330659210001,
LONGITUDE: -114.617493964,
NAICS_CODE: '622110',
NAICS_DESC: 'GENERAL MEDICAL AND SURGICAL HOSPITALS',
SOURCE: 'http://www.oshpd.ca.gov/HID/Facility-Listing.html',
SOURCEDATE: '2018-08-08T00:00:00.000Z',
VAL_METHOD: 'IMAGERY/OTHER',
VAL_DATE: '2014-02-10T00:00:00.000Z',
WEBSITE: 'http://www.cityofneedles.com/Hospitals.asp',
STATE_ID: 'NOT AVAILABLE',
ALT_NAME: 'NOT AVAILABLE',
ST_FIPS: '06',
OWNER: 'GOVERNMENT - LOCAL',
TTL_STAFF: -999,
BEDS: 25,
TRAUMA: 'NOT AVAILABLE',
HELIPAD: 'Y'
},
geometry: {
type: 'Point',
coordinates: [ -114.61749396399995, 34.83306592100008 ]
}
}
Anyhow, I'm thinking it makes sense to create a Location extension to track some of these extra parameters.
Keith Boone (Apr 13 2020 at 09:00):
I had used an extension somewhere to store the lat/long to support "near" search in FHIR. The ID: field is something we can put into the identifier of the reporting organization. Since the other data is publicly accessible knowledge, if the consumer wants it, they could simply join against the ARCGIS data set.
John Moehrke (Apr 13 2020 at 13:18):
There is Long/Lat in the Location resource -- Location.position
You added extension on the Measure.. I think the Location resource should be leveraged for this, not duplicated in extensions in Measure
Josh Mandel (Apr 13 2020 at 13:20):
Several of these should also also be slottable into existing identifier and telecommunication elements. It would be good to figure out what's left over.
Abbie Watson (Apr 13 2020 at 14:44):
Note of clarification: I'm thinking less of a location extension on other elements (that has been covered previously), and more along the lines of what Josh is saying, and making sure that identifier and telecom extension is available to add to Location.
Yeah, it's the beds, trauma unit, and helipad fields that are the leftovers that I'm noodling over. There are the Location.physicalType field and the Location.type array that can maybe be used to track trauma/helipad availability. physicalType seems more appropriate, but it's not available as an array. We'd need have separate Locations and link together via Location.partOf, which is its own bit of set theory fun.
But the two fields from this geojson file that would probably be most impactful to have on Location via an extension would be POPULATION and BEDS. In effect, the ArcGIS HIFLD Hospital data file is arguing (on behalf of the GIS community) that there is a clear use case for a capacity planning and population census extension for Location.
And if we go and make a an extension with two valueQuantitites for beds and population, should we also include ventilators, masks, etc?
Abbie Watson (Apr 13 2020 at 14:52):
Also, to further clarify - when the Location resources wind up in the GIS systems, they tend to get squashed/mapped into large GeoJson files, or translated into super in-memory optimized LatLng or Marker pointers. Due to the nature of how GIS systems load up large data sets of tiny points and do their rendering, it's often not possible to do data joins after the fact. It wont work with the map rendering lifecycle. The data that is going to be on the map is preferably squashed onto the Location object as it enters the GIS system, hence the use case for a Location extention for things like capacity planning. Within the GIS application, that extension will be getting mapped to color and styling variables in the presentation layer, and it's difficult to pull in other data after-the-fact.
Keith Boone (Apr 13 2020 at 22:12):
John Moehrke said:
There is Long/Lat in the Location resource -- Location.position
You added extension on the Measure.. I think the Location resource should be leveraged for this, not duplicated in extensions in Measure
John, I added that a while back. It kind of depends on where Location fits, because MeasureReport can have either "Location" or "Organization" as the reporter. Location can get you to Organization, so using that might work, but then we get into a "Chained + near" search in a FHIR Server. I know I can probably make one or the other work in at least one off-the-shelf server, but combining both could be challenging. I'll look at this when I get to rebuilding examples tonight for FEMA reports from real (state level) data.
Gino Canessa (Apr 14 2020 at 16:13):
I'm struggling a bit here because it feels like we are defining a second FHIR structure for the same data we have in SANER (e.g., if we are adding all the quantities we care about to location, why are we using Measure and MeasureReport?). Further (as Abigail points out), the data needs to be converted from FHIR into something like GeoJson anyway.
I guess my question is: if there's already a required translation step, can it use the SANER format as input?
- this could be the return of an operation - a Bundle with the Org, Location, and Reports of interest
- in addition to a FHIR Bundle, servers could support GeoJson (
application/geo+json) returns directly
Even if a FHIR server didn't want to implement the operation, a proxy could be stood up in front of anything that's SANER compliant quite easily.
Abbie Watson (Apr 14 2020 at 17:10):
So, I'd suggest that the extension for Location be thought of in terms of supporting presentation layer only. Google Maps isn't the place to have provenance, auditing, measure reporting, etc. We just need to know how to color markers and which icons to use. Yet, with that being said, if we're going to put that presentation data anywhere, the Location resource makes the most sense because it primarily handles Lat/Lng already. This isn't suggesting to muck with any of the upstream decisions or processes that have been hashed out. We just need a rider extension on the resource that some of the downstream systems will be exchanging.
Otherwise, yes on the proxy servers. application/geo+json would be ideal, but I'm not holding my breath waiting for the major vendors to implement anytime soon. T
A Bundle of Org, Location, Reports would also be perfectly fine. Our server acting as a proxy could totally handle that. But once it's in our system, we will be flattening it into something that can be stored in a single table with a 2dsphere geospatial index on Mongo. That's how we get performant scalability, is to preoptimize the queries and do the joins at the front end when the server receives the data. The received Orgs, Reports, and Locations will be sitting around in helper collections.
The obvious resource for doing all that is a modified Location (with internal extensions), and we just run the geospatial index on the Lat/Lng point. But if we're serving those indexed Location records up to mapping clients or other GIS systems, then we have a responsibility to document our changes according to the FHIR spec.
Gino Canessa (Apr 14 2020 at 19:27):
My concern is around trying to push specific presentation logic into generic resources/servers/specs - particularly when it duplicates data from other areas. I don't think it's possible to capture all the requirements (especially over time), and my experience is that chasing it is always painful.
To use the mapping example, what about when I need to start reporting Ethnicity, distance to care location, etc.? There would be quite a few extensions on Location, and you only care about a couple of them.
If the existing formats aren't suitable for exchange downstream, that is something that should be discussed/addressed. The more formats we have, the more likely we are to introduce errors.
Abbie Watson (Apr 14 2020 at 19:59):
It's an extension. We're not discussing putting the that presentation data into the Location schema itself. It's what extensions were built for. And we're going to have an SQL/NoSQL disagreement around normalizing data and deduplicating. So let's just agree to disagree on that point. If the CDC updates their reporting requirements, and it goes through SANER, and we need to update Covid19 related maps accordingly, we'll update the extension. This doesn't need to be difficult.
Gino Canessa (Apr 14 2020 at 20:50):
Apologies if I come across as being difficult. I am just hoping to avoid multiple "standard" representations of the same data in FHIR.
Keith Boone (Apr 14 2020 at 21:06):
I'd ask that folks write up the user stories around location as Issues, so that we can get more clarity on the requirements. I'll write up the user story on the extension I used and that can help explain why I used it. It's already partly in these stories https://github.com/AudaciousInquiry/fhir-saner/issues/23 and https://github.com/AudaciousInquiry/fhir-saner/issues/24
Last updated: Apr 12 2022 at 19:14 UTC
