Stream: Covid-19 Response
Topic: multiple measure reports for a single location/date?
Sean McIlvenna (May 13 2020 at 19:47):
Is it possible to have multiple MeasureReports for a single location and date?
Rick Geimer (May 13 2020 at 20:43):
Possible yes (there is nothing stopping me from posting multiple MeasureReport resources for the same date/location to HAPI for instance), but the real question is if this is a valid use case for production data, or is it expected that if a report is re-run for a given date/location that you would version an existing MeasureReport. @Keith Boone ?
Sean McIlvenna (May 13 2020 at 21:19):
@Michael Donnelly
Michael Donnelly (May 13 2020 at 22:24):
There are a few different reasons you'd see multiple MeasureReports for the same subject + measure + date:
- Each has a partial subset of the available data. E.g. the bed management system knows about beds and the EHR knows about admitted patients.
- The measure is over a period of time shorter than a day.
- The Measure Source made a mistake the first time. The new MeasureReport should replace the old one.
Michael Donnelly (May 13 2020 at 22:25):
In case 2, I'd expect that the periods in the MeasureReports would not overlap.
Michael Donnelly (May 13 2020 at 22:26):
In case 3, I'd expect the reporters in the MeasureReports would be different.
Michael Donnelly (May 13 2020 at 22:28):
In case 1, I'd expect that they wouldn't have an overlap in the populations they include.
Keith Boone (May 13 2020 at 23:56):
A couple of thoughts there: Different systems have access to different data. The ICU Central Monitoring station knows almost as soon as a ventilator is turned on that it is in use, and which bed (and thus which patient) is using it. That system has enough information to establish the principal diagnosis for the patient, race, gender and ethnicity, and gender at birth of a patient. Whereas the EHR in a busy ICU won't know about the three stat intubations until possibly after shift end, when verbal stat orders are finally entered into the EHR, and marked as having been completed. But that same system cannot report about the status of other beds within the facility. The EHR can report on the status of patients within beds who have been admitted, but some hospitals use a separate system to monitor and track what's going on in the Emergency department. And the EHR may know about occupied beds, but the bed and workforce management systems together might be needed to determine of unoccupied beds, how many are actually available for use, and which of these can be staffed. So, there's no single system which has complete knowledge of everything that is going on in the facility. Thus, we can see that there would be cases where there would be multiple "partial reports", which another component would then piece together to create a complete report on the state of the facility in order to gather the data that CDC requests.
So, I could see cases, and we've also allowed for cases where there might exist multiple "incomplete" reports, which might then be aggregated to produce a complete report for NHSN. If I were building a smart agency (or perhaps even a SMART on FHIR agency) to report to the CDC, I'd probably look for a) a singular completed report, or b) the set of incomplete reports which would make up a completed report. What goes into b) might vary from hospital to hospital, and even within a facility might vary over time as newer information systems are deployed, and so might need some configuration. The protocol that I've proposed is that a system can report "complete" data, or "in process" data, indicating that it's a partial report, and that other reports would need to be examined to make up a complete report, and that a subsidiary system (or a component in the repository), might periodically aggregate the parts into the whole.
Keith Boone (May 14 2020 at 00:00):
FOr the "error correct case" that Michael brings up, we haven't yet addressed that workflow, but I think that if a system is able to "create a report", then it must be able to "update the report", in order for it to be able to make corrections. The process to determine whether an update or create is needed can be established through a protocol that means that the original creator doesn't even have to recall what it sent, it just needs to see if the data it's trying to report was already reported by itself earlier, and if so, issue an update rather than a create.
Michael Donnelly (May 14 2020 at 01:31):
That is technically correct but might be too optimistic an assumption about the sophistication of submitters.
Michael Donnelly (May 14 2020 at 01:35):
If a Measure Source does a create and then another create, there are several possibilities:
- Both are correct and should be added together.
- The second one is a correction, but the Measure Source didn't know how to do an update.
- Something went wrong, and it submitted the same thing twice by accident.
I suspect that #1 is the least likely and least common of these, and if we assume #1 was the intention every time we see that behavior, we'll get errors far more often than desired behavior.
I don't know if there's someone-or-other's law for this, but in general interaction models that are idempotent are less fragile than those that are not.
Michael Donnelly (May 14 2020 at 01:36):
Given that intentionally adding up two sets of data is a less common and more sophisticated case, I think we should shunt the complication in that direction and let the more common cases - and the ones that are easier to screw up - have the simplicity.
Last updated: Apr 12 2022 at 19:14 UTC
