This page is part of the Situational Awareness for Novel Epidemic Response (v0.1.0: STU 1 Ballot 1) based on FHIR R4. The current version which supercedes this version is 1.0.0. 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.
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 Hospital’s EHR collects data for multiple data elements.
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 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 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.