Stream: Covid-19 Response
Topic: Geomapping
Abbie Watson (Mar 30 2020 at 15:45):
This weekend, for the Datavant Pandemic Response Hackathon, I put together together a COVID19 on FHIR Geomapping tool. I'm registering it with the EHR App stores, and have a full schedule of calls this week with ONC, State of Illinois, Allscripts, a Paratransit Dispatch service, and others.
Covid19Geomapping-SyntheaHeatmap.png
Project website:
https://github.com/symptomatic/covid19-on-fhir
Demo website:
https://covid19-on-fhir.meteorapp.com/
Hackathon Entry:
https://devpost.com/software/covid19-on-fhir
Big thank you to @Jason Walonoski and @James Agnew.
Keith Boone (Mar 30 2020 at 15:49):
Awesome, how can we integrate this with a Measaure Source from The SANER Project so that it could map w/ data from there?
Abbie Watson (Mar 30 2020 at 15:57):
Yes, I have Measure and MeasureReporting UI components available, and I've been planning to get them in ASAP. I also made sure when implementing the heatmap to use the weighted version, so we can add bed count to markers and heatmap. There's going to be some fine tuning to get the map right, but totally doable.
Jason Walonoski (Mar 30 2020 at 15:58):
FWIW, I plan to add ventilator use and other supply consumption to the Synthea COVID model.
Jason Walonoski (Mar 30 2020 at 15:58):
Ventilator is already in there, but as a Procedure and not a Device.
Abbie Watson (Mar 30 2020 at 16:04):
That would be an excellent addition. We have Device UI components as well. But I may need to make a second page for the ICU bed tracking components.
Abbie Watson (Mar 30 2020 at 16:05):
Also, regarding the hackathon entry. If you want an easy way to lend some help, go to the Devpost website, and like and VOTE for the project. ONC and others are evaluating submissions for the next two days.
https://devpost.com/software/covid19-on-fhir
@Dave deBronkart Signal boost?
Abbie Watson (Mar 30 2020 at 18:36):
Initial registration with the EHRs completed. Now onto SMART on FHIR testing with their sandboxes. I'm skeptical that they will have any COVID19 data, but I'm not entirely sure we need it. We've already validated and done some amount of load testing with HAPI and the Synthea data.
Abbie Watson (Apr 01 2020 at 01:08):
@Keith Boone - I added in the Measure, MeasureReport, Device, and Organization components today. We have the necessary pieces in place to generate an ICU bed capacity map.
Screen-Shot-2020-03-31-at-8.01.04-PM.png
Abbie Watson (Apr 01 2020 at 01:10):
Right now the utility is configured as an app that fetches data. So if SANER can expose the Measure, MeasureReport, and Organization endpoints, we should have enough to generate maps.
Abbie Watson (May 12 2020 at 00:43):
Uploading the latest version of the geomapping software this evening. Got the Health Service Area (HSA) and Health Referral Region (HRR) shapefiles loaded up, and we use the ISSP organization file to cross reference between CMS number and HSA code. Sweet! (That's a sharp looking map, if I do say so myself. Still swapping out reimbursement data for synthetic Covid19 data, but I think it's going to pull together nicely.)
Screen-Shot-2020-05-11-at-7.32.59-PM.png
John Moehrke (May 12 2020 at 00:49):
Abigail, are you using the geolocation extension coordinates in the extension or the geo codes in the Location.position? I find it strange to have these extensions in Measure when Location already has position.
Abbie Watson (May 12 2020 at 01:07):
Not using the geolocation extension. Going the other direction. For these maps, I'm generally using capacity-planning extensions on the Location object. So the workflow goes:
A. Hub receives MeasureReport (push or fetch)
B. Hub maybe also receives Organizations, Devices, Locations; or does lookups as needed.
C. Hub maps MeasureReport.group.measureScore to Location.extension.extensionA and stored in a 2dsphere index.
D. 2dsphere index service serves up Location objects to clients and anybody who asks for it.
E. Clients map Location.extension.extensionA to geoJson feature file and renders. (Might have the server do this)
The extensions on the Location object are intended to be lightweight and lossy. They won't pass validation when the Location object is passed to external systems, which is by design. Feature, not a flaw. They're like extension riders for the mapping software, but as soon as they hit a validator, they get cleaved off and abandoned leaving the underlying Location object intact. The mapping presentation layer can be ephemeral; it doesn't need to be authoritative.
Abbie Watson (May 12 2020 at 01:08):
Here is an example of what I have in mind. (I brought this up a few weeks ago).
Abbie Watson (May 12 2020 at 01:09):
I just need to publish a StructureDefinition so we have a valid URL to put in the extension.
Abbie Watson (May 12 2020 at 04:54):
Okay, I've drafted two possible StructureDefinitions that I'm proposing, and could use some feedback on. Understanding that the authoritative version of the score will be kept in the MeasureReport resource, when passing around lightweight extensions, should we try to differentiate and be semantically different? Or should we try to preserve the original context?
Option A - Be precise in intended function and use (i.e. LocationBedCapacity)
https://github.com/symptomatic/covid19-saner/blob/master/data/specifications/Extension-LocationBedCapacity-StructureDefinition.json
Option B - Preserve original context and variable name. (i.e. numTotBeds)
https://github.com/symptomatic/covid19-saner/blob/master/data/specifications/Extension-numTotBeds-StructureDefinition.json
Abbie Watson (May 12 2020 at 04:56):
(deleted)
John Moehrke (May 12 2020 at 13:39):
I am not a fan of these extensions either. We are in early data modeling of the FHIR specification. Sometimes extensions are needed to move faster than the FHIR specification can manage. but we should not be putting data into a Resource that is not proper in that resource. This is why I didn't like the GeoLocation in the Measure, and this is why I would not like a bed capacity in the Location resource. That said, I agree with doing this in the short term and turning that into proper FHIR change requests and modeling in the medium term.
Abbie Watson (May 12 2020 at 17:26):
I'm not exactly proposing that these extensions themselves get formalized or encouraged.
Rather, I think it's important that implementors document the customizations or changes that we make using the tools and processes that we all have agreed upon. And then also design in such a way that the protocols gracefully degrade services and/or jettison payloads if another system doesn't support those customizations. When used correctly, extensions allow both systems to use the same underlying Resource, while one of them uses it in a more robust way. (Honestly, from an implementation perspective, I find it a graceful approach.) That's interoperability at its best.
For what its worth, I'm probably going to do the exact same thing as I create the Organization Leaderboard. Bed capacity doesn't belong on the Organization resource either, but if I'm using the Organization resource to create a Leaderboard and make a customization to it, I think it's good practice to document the customizations accordingly.
In both cases, I think there's an underlying need for FHIR change requests related to capacity and inventory management. Hopefully, these extensions will be documented evidence for creating those change requests.
John Moehrke (May 12 2020 at 17:44):
yup. do what we need to now... figure out 'better' next week
Abbie Watson (May 14 2020 at 22:41):
Quick updates on geomapping:
Here's a map of CMS hospitals, with the IPPS file (Provider Directory). I was thinking of adding the capacity and MeasureScores directly to the map.
Symptomatic-Covid19-HospitalCapacity-Evansville-Sm.png
Abbie Watson (May 14 2020 at 22:43):
Another map of Patient/Location, for GPS enabled Contact Tracing.
Symptomatic-HomeAddresses-Heatmap2-Sm.png
Abbie Watson (May 14 2020 at 22:49):
And lastly, this one uses a provider directory and a heatmap and measure scores. I like the direction this is going, but there's something missing. Maybe the orange header/footer are a bit much. Maybe it needs a You Are Here icon. Or hospital icons. Something. I'm still noodling on it's design.
Symptomatic-CovidGeomapping-Chicago-Hospitals2-Sm.png
Terrie Reed (May 14 2020 at 23:09):
At some point UDI-DI (model/version of device) would add value to ventilator use. IEEE 11073 group has included UDI in networked device information. Supply chain is beginning to use UDI in inventory systems. If devices by model (UDI-DI) were planned for as you iterate on this model, then in future pandemics hospitals could not only identify gross numbers but types of devices depending on patient need, clinician training etc. It would also allow for monitoring of device effectiveness with certain patient populations
Abbie Watson (May 30 2020 at 06:58):
All right, here is the municipal heatmap using test data pulled from the Epic servers.
Symptomatic-SANER-Chicago-EpicData-SunnyGradient.jpg
Abbie Watson (May 30 2020 at 06:59):
And the same map in a Frozen/Halo color theme.
Symptomatic-SANER-Chicago-EpicData-FrozenGradient.jpg
Abbie Watson (May 30 2020 at 17:19):
Here's the Dartmouth HSA shapefile (choropleth) without any data mapped onto it.
Symptomatic-SANER-Choropleth-EasternZone.jpg
Abbie Watson (May 30 2020 at 17:35):
(deleted)
Abbie Watson (May 30 2020 at 17:44):
Here is some of the raw MeasureReport scores (numBeds) being mapped (without the HSA choropleth shapefile layer). Next step for the choropleths to is roll up the numbers using $contains or a similar operator.
Symptomatic-SANER-Chicago-EpicData.jpg
Abbie Watson (May 30 2020 at 19:17):
Ah, I've managed to begin colorizing the choropleth based on the data from the sandbox servers.
Symptomatic-SANER-Choropleth-ChicagoMilwaukeeMadison-ChiTownReporting-50Percent.jpg
Last updated: Apr 12 2022 at 19:14 UTC
