Situational Awareness for Novel Epidemic Response
1.0.0 - STU Release
Situational Awareness for Novel Epidemic Response
1.0.0 - STU Release
This page is part of the Situational Awareness for Novel Epidemic Response (v1.0.0: STU 1) based on FHIR R4. This is the current published version in its permanent home (it will always be available at this URL). For a full list of available versions, see the Directory of published versions 
The following use cases were used to identify the requirements addressed by this guide:
These are described in more detail in the sections that follow.
This use case addresses the collection and exchange of data from several information systems in a Facility to a centralized reporting system that communicates to Public Health. The ICU/Central Monitoring System collects data for multiple data elements by examining messages recieved and data in its database, and then reports these to a Measure Collector within the hospital.
This use case is supported by the following
Actors
Transactions
Measure report data can come from multiple systems within a facility. For example, the CDC/NHSN Patient Impact and Hospital Capacity Module asks for the following data elements:
These data elements are often not available through a single system. For example, an ICU/Central Monitoring System might have knowledge of 1.2,5 and 2.4-7 above, while the Bed Management System could report on 2.1-3, the Hospital’s EHR is aware of 1.1, 1.3 and 1.6, and the Emergency Department system can provide an update on 1-4.
In order to automate capture of this information, a central reporting system (e.g., a FHIR Server) can be made available to accept partial reports for data. This data can then be aggregated from reports made by the various information systems, and forwarded to a public endpoint for reporting.
Figure 2.3.1.1-1: Collecting Hospital and Ventilator Measures Process Flow
The ICU/Central Monitoring System is triggered (by request or schedule) to generate a report on ICU beds and equipment, including ventilated patients in ED/Overflow w/ COVID-19, Total ICU Beds, Occupied ICU Beds, Total Ventilators, Ventilators in Use.
The system counts the number of ventilators that are transmitting telemetry data to it in the ICU.
Multiple collected values are aggregated into a report which is then transmitted to the Measure Collector.
The Hospitals Bed Management System collects data for multiple data elements by examining messages recieved and data in its database, and then reports these to a Measure Collector within the hospital.
The bed management system counts the occupied beds (based on current state of each bed) as tracked through state changes communicated through ADT messages. The Bed Management solution might be used to support housekeeping, or to support an electronic bedboard that might used by a hospital “Bed Czar.”
The Hospital’s EHR collects data for multiple data elements.
The EHR collects data on patient deaths due to COVID-19.
Either periodically on some schedule configured for the hospital, or upon recieving a full set of data, the Measure Collector gathers a set of results from different systems that have communicated them, putting together a complete MeasureReport for later reporting to the Public Health Agency.
In a “push” model, the Measure Collector sends the aggregated MeasureReport to a MeasureConsumer (e.g., a Public Health endpoint used for measure transmission).
As an alternative to push, the Public Health Agency can also “pull” data by querying the Hospitals “Measure Collector” endpoint (in fact, a FHIR Server with some additional features supporting aggregation).
The Measure Collector sends the aggregated MeasureReports to the requesting Public Health Agency.
A public health user queries a reporting system to report on a measure for a region.
This use case is supported by the following
Actors
Transactions
In this use case, we see the classic “dashboard” panel, where a public health user selects a region, and one or more measures (or functions of measures) to report on, and the data is presented to them in an easy to view format.
Figure 2.3.1.2-1: Accessing Measure Reports Process Flow
The Measure Intermediary, acting as a Measure Consumer gathers and aggregates data (possibly computing a function with other associated data) from one or more Measure Sources, and makes them available through a Measure Source interface it provides.
The specific ordering in which gathering and aggregation is performed is not further specified by this implementation guide. It is shown as occuring before the user initiates the query here, but could also occur after. However, for many cases, geospatial systems can likely do a better job if the aggregation is done ahead of time. The application of a function to the data can enable a measure such as # of cases to be combined with other data such as population for the area to report # of cases per 10K population, or similar functions to better present data in a way that allows it to be reported using comparable scales.
The Public Health User navigates to a web page where collected data is reported.
The user selects a geographic region and an issue of concern (e.g., beds, ventilators, PPE). The Measure Consumer collects the appropriate reports and displays the results.
The reporting system requests aggregated results from the analytics system
The analytics system returns the aggregated results
The Measure Consumer displays an overview of aggregated regional results to the user, and additional links which enable navigation to finer grained or alternative displays.
Data can be displayed as aggregated or fine-grained status information based on the current focus of the public health user. It may be shown as a map, a table, or a graph.
The Public Health User selects a new form of display (e.g., Map, table or graph) or refines their focus (e.g., wider or smaller region).
The reporting system requests aggregated results from the analytics system
The analytics system returns the aggregated results
The Measure Repository modifies the users focus and reporting format
A public health or emergency response agency distributes updated Measure definitions, a hospital or intermediary retrieves these definitions for reporting.
This use case is supported by the following
Actors
Transactions
Measures created for tracking a public health emergency may be revised periodically to support changing needs. This use case supports the need to distribute updated measure definitions to organizations who report on these measures.
Figure 2.3.1.3-1: Distributing Measure Definitions Process Flow
An organization required to report queries for for updated from one or public health or emergency response agencies to identify reporting requirements.
The agency sends the new or updated definitions to the requesting reporting organization.
A reporting organization (e.g., a hospital) automatically computes and reports measure data.
This use case is supported by the following
Actors
Transactions
Automating measure reporting reduces the burden on users for manual data collection. When a measure has been automated, it can be computed using FHIR APIs from supporting information systems provided by the organization.
Figure 2.3.1.4-1: Automating Measure Computation Process Flow
The reporting organization checks for new measures see Distributing Measure Definitions above.
The hospital information system collects data and computes the measures, returing a completed report.
The hospital information system queries the local EHR or FHIR Server for applicable FHIR resources used in measure computation.
The local EHR or FHIR Server returns the requested data and included resources.
The reporting organization sends the computer measure to the public health agency.
A reporting organization (e.g., a hospital) collects and reports supplemental data with a measure report.
This use case is supported by the following
Actors
Transactions
Supplemental data enables additional data analysis to be performed. The MeasureReport itself provides the capacity to detect a signal, e.g., increased strain on institutional resources, but does not by itself enable deeper analysis with regard to level or impact of this strain. Exchange of additional data elements allow deeper analysis, as might be used to support risk adjustment, or cause or impact analysis.
Consider the case where patient comorbidities (e.g., Cardiovascular Disease, Smoking Status) are known to impact patient risk and associated complications, but where detailed analysis of these risk effects is unknown. Communication of supplemental data that include presence or absence of cardiovascuar disease, or the patient smoking status, and presence of absence of complications allows the recieving public health agencies to further analyze this data retrospectively.
In the initial stages, this analysis can be used to assess strain, by comparing the impact of comorbidities on complications over time in facilities with otherwise similar measures of utilization. In later stages, this data can be used to further assess and refine strain created by disease burden based on associated complications.
Figure 2.3.1.5-1: Reporting Supplemental Data Process Flow
The hospital information system collects data and computes the measures, returing a completed report.
The hospital information system queries the local EHR or FHIR Server for applicable FHIR resources used in measure computation.
The local EHR or FHIR Server returns the requested data and included resources.
The hospital information system queries the local EHR or FHIR Server for supplemental FHIR resources reported with the measure.
The local EHR or FHIR Server returns the supplemental data and included resources.
IG © 2020+ HL7 International Public Health Workgroup. Package hl7.fhir.uv.saner#1.0.0 based on FHIR 4.0.1. Generated 2021-09-07
Links: Table of Contents |
QA Report
| Version History |
Search |
|
Propose a change