Abigail's profile

Yes! If you use a utility like Postman, you should be able to GET and POST data on the /baseR4/MeasureReport route. So, for instance:

GET https://saner.symptomatic.io/baseR4/metadata
GET https://saner.symptomatic.io/baseR4/MeasureReport
POST https://saner.symptomatic.io/baseR4/MeasureReport

You can get the Postman utility here:
https://www.postman.com/

Attaching a screenshot as an example. Would be exciting to have somebody else confirm that they can fetch or post data.

Symptomatic has worked on FHIR enabled chatbots to collect patient data before. It's not entirely clear that FHIR Questionnaire and QuestionnaireResponse are designed to be able to handle conversational/chat style flow logic. We were able to get some basic decision tree working, and even had a rudimentary multi-person chat bot up and running. But then runway ran out. If you're looking for solutions in this space, please feel free to reach out.

Happily, some of us are working with rapid-prototyping tools, and were able to do some experimenting over the weekend.

I took our MeasureReport generator page, which is usually a 2 panel layout, and converted it into a 4 panel layout. Pulled in the IN.gov coronavirus website as a sample page to iFrame and scrape.

Now then, here is where things get a little wonky. The April CDC NHSN reporting requirements had measures like ICU bed count, ventilators, etc which are already summarized data, and nicely modeled by the FHIR MeasureReport resource.

The Cares Act Section 18115, on the other hand, drills down into the specifics of lab orders, such that we're being provided OBR, OBX, and PID segments to map to. These data elements would be more appropriately mapped to the Patient and Observation resources.

I loaded up a sample HHS Cares Act Measure, and MeasureReport, and my initial assessment is that we can try to shoehorn the CARES 18115 reporting requirements into the MeasureReport population codes, but it's really not what the MeasureReport is intended for.

Rather, we need to use the population codes to say 'Field Tests' with a count of 60; 'At Home Tests' with a count of 528, 'Positivity Rate' is equal to 15%, and so forth. Meanwhile, the population array in the MeasureReport is the perfect place to place a list of the scraped patients and lab results. Or, rather, MeasureReport becomes the ideal reporting bucket that v2.x messages get accumulated into.

So far, so good. While I normally don't recommend screen scraping because it *is* brittle, for the task at hand, I think it has the potential to be a relevant technology.

The question I have is around 'which website is to be scraped'? I grabbed the Indiana coronavirus webpage, which has aggregated stats, but it really doesn't have the laboratory data, since that's PHI.

So, my questions are along the lines of: a) can we get a better sample website to scrape, and b) would this scrapper need to operate behind a VPN or firewall (quite possibly), and c) do we have a list of non-FHIR enabled EHRs that we anticipate being used, and how many of them have web interfaces?

So far, I'm thinking screen-scraper is a workable kludge that might fill in the gaps for a lot of lesser supported EHR and LIS systems that have web interfaces but might not have v2 interfaces set up. Which might be very common situation for at-home testing vendors, who have a basic patient portal, but haven't ever had to actually address interoperability.

But does CLIA have geographic coverage? Are there CLIA service areas?

Because the virus doesn't care about laboratory certifications or state boundaries or zipcodes.

For what it's worth, we could certainly accept v2 feeds, feed them into FHIR, and then into the maps. We have a Technical Assistance Partner on standby, who has expressed interest and willingness to help bridge those technologies, who has experience contracting with the CDC and APHL.

By comparison, the HL7 SANER relay network (and Symptomatic) are able to report directly from the EHRs, meaning we can have a more municipal county or HSA level reporting.

So, for quality control purposes, we can show each individual HSA checking in its data. Below is an interstate example we put together, where we were importing Indiana state level data, with City of Chicago municipal data. We were going to load in IL, WI, and MI data, but none of the states had APIs we could use; so nothing could be relied on and automated.

Nonetheless, even with just two states reporting in, it's evident how these maps can provide an important quality control tool for knowing which specific counties and HSAs are reporting in, and which are not. That helps with compliance, when everybody can see who is reporting and who is not.

Now then, we can run these check-in maps on intermediary/hubs in the SANER network. Meaning we can run them out of large metropolitan areas (Chicagoland, LA, Bay Area, NYC Metro, etc); or at the state level (one map for each state), at the multi-state regional (Great Lakes Region, the South, New England, etc), etc.

More generally, these maps give us visibility into whats happening within the HL7 SANER network. Which, as of September, connects with the CDC NHSN, and therefore can theoretically feed into the HHS efforts.

But to get to that kind of reporting requires a whole other type of quality control reporting infrastructure. A challenge that Symptomatic has been working with MITRE and HL7 to develop.

And to illustrate that, lets review some of the quality control that's currently happening with HHS, with regard to how percentage of reporting hospitals is calculated and visualized.

Again, we see the state level map is grossly conflating urban and rural counties, pooling hospitals together to create arbitrary state percentages, etc. No complaint or disrespect intended to the hardworking analysts and epidemiologists who put this together. It's simply an artifact of our federal government, and how data is collected (which is funded by taxes).

So, generally speaking, higher fidelity maps are useful for improved quality control, data visualization, and policy making. And the concern that has driven the development of this work, is that quality control and policy making are only as granular as the buckets that we put the data in.

So, on the outbound reporting side, take a look at the numbers that are currently being reported by HHS. And then compare to the HSA level map that we provided above.

By having more granular buckets of data, and reporting at the HSA level, policy makers could specify that this city here needs to lockdown again, but the entire state doesn't need to go into lockdown.

The existence of FHIR servers at every Medicare hospital in the US makes it possible for HHS and the CDC to even consider this kind of more granular reporting.

We’re actually proposing a third possibility for collecting data: instead of zipcodes or census tracts, the SANER approach proposes and allows for reporting via health service area (HSA).

HSAs are tied to Medicare hospitals, and therefore should all have FHIR compliant EHRs at this point, and thus a standard API. So, we know that we can get geographic coverage of the entire US with this API, regardless of state or county level partisanship.

Philosophically, it’s a cartographic shift from mapping the population numbers based on taxation and inputs into the government, and instead mapping based on service delivery and outputs.

Of course, there is the problem of ancillary locations (like schools) which don’t have EHRs at all. Which is where the intermediary/hub nodes come into play, and report grouping and roll up.

Importantly, the concept of Provenance is supported, and SANER has been architected with support for saying ‘these numbers came in via a zipcode based system, and these other numbers came from an EHR query’. So, if they need to be sorted or split or regrouped later on, they can be.

Otherwise, you’re very much starting to envision the possibilities that better geomapping tools could provides. Pandemics are inherently based on population density, and therefore geospatial in nature. Better maps can lead to better public health policies.

Well, preferably a pilot sponsor with some budget. This stuff is expensive to host and develop!

But financial matters aside, a school would be a fine place to do a pilot. If we’re using a screen scraper, then I doubt any adjustments to the registration system would need to be made.

We wouldn’t be able to use the data-mining utility, of course. That is an EHR utility. But if the school had some sort of nursing EHR, then it would be a matter of whether it’s been upgraded to include FHIR Interoperability functionality.

Well, I’m saying that the 2 page mode has functionality and design in place that we could build the scraper mapping / training components rather easily, and then leverage the rest of the infrastructure.

Screen scrapers are useful and fun technologies, but my experience is that they’re brittle and rarely ‘one time’ configurations. Each time the website it’s pointing to changes or is reconfigured, boom... scraper breaks.

But they do have a super important and useful role in automating systems when API interfaces aren’t available. The design challenge is having a simple and easy to use training interface for the scraper, that lets one choose the elements of the page, and then puts it all into a report.

Do you have an example of a school report that might need to be scraped? Somewhere that doesn’t have an EHR?