Situational Awareness for Novel Epidemic Response, published by HL7 International / Public Health. This guide is not an authorized publication; it is the continuous build for version 1.0.1 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/fhir-saner/ and changes regularly. See the Directory of published versions

Use Cases

The following use cases were used to identify the requirements addressed by this guide:

• Collecting Hospital and Ventilator Measures
• Accessing Measure Reports
• Distributing Measure Definitions
• Automating Measure Computation
• Reporting Supplemental Data

These are described in more detail in the sections that follow.

Collecting Hospital and Ventilator Measures

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 received 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

  • Measure Source

  • Measure Consumer

• Transactions

  • Query Measure

  • Produce Measure

Collecting Hospital and Ventilator Measures Process Flow

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:

1. Patient Impact
2. Hospitalized Patients w/ COVID-19
3. Hospitalized and Ventilated Patients w/ COVID-19
4. Patients with Hospital Onset of COVID-19
5. Patients in ED/Overflow w/ COVID-19
6. Ventilated Patients in ED/Overflow w/ COVID-19
7. Patient Deaths due to COVID-19
8. Hospital Bed/ Intensive Care Unit (ICU)/ Ventilator Capacity
9. Total number of available (inpatient and outpatient) beds
10. Total Acute staffed beds
11. Total Occupied Beds
12. Total ICU Beds
13. Total Occupied ICU Beds
14. Total Ventilators
15. Total Ventilators in Use

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.

1. ICU/Central Monitoring System collects data

   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.

2. The system collects information about ventilators outside the ICU for which the associated patient was admitted for suspected or confirmed COVID-19. It can makes the determination of suspected/confirmed COVID-19 from the DG1 segment of the ADT message it recieved regarding the patient.
3. The system counts the number of ICU beds that it has been configured to recognize and which are operational
4. The system counts the number of ICU beds that are transmitting telemetry (patient monitoring) information.
5. The system counts the number of ventilators that it has been configured to recognize and which are operational

6. The system counts the number of ventilators that are transmitting telemetry data to it in the ICU.

7. ICU/Central Monitoring System Reports on multiple data elements (measure populations)

   Multiple collected values are aggregated into a report which is then transmitted to the Measure Collector.

8. Bed Management System Reports on multiple data elements (measure populations)

   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.

9. The Bed Management System examines master file data to count the total number of beds in the hospital, as well as those beds specifically identified as being for acute (inpatient) care. The Bed Management solution can be a component of the EHR, or as occurs in some hospital settings, a third party solution that integrates with the EHR (usually through ADT and master file messages).

10. 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.”

11. EHR System reports on multiple data elements (measure populations)

    The Hospital’s EHR collects data for multiple data elements.

12. The EHR collects data on hospitalized patients w/ COVID-19.
13. The EHR collects data on hospitalized patients diagnosed with COVID-19 14 days after admission.

14. The EHR collects data on patient deaths due to COVID-19.

15. The ED System reports on patients in the ED and/or overflow area.
16. Measure Collector aggregates reports for transmission to a Public Health Agency

    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.

17. Transmit Aggregated MeasureReport Data

    In a “push” model, the Measure Collector sends the aggregated MeasureReport to a MeasureConsumer (e.g., a Public Health endpoint used for measure transmission).

18. A Public Health Agency queries the hospitals Measure Collector for the most recent reports.

    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).

19. Transmit Aggregated MeasureReport Data

    The Measure Collector sends the aggregated MeasureReports to the requesting Public Health Agency.

Accessing Measure Reports

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

  • Measure Consumer

  • Measure Intermediary

• Transactions

  • Communicate Results

Accessing Measure Reports Process Flow

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.

1. Measure Intermediary aggregates data from one or Measure Sources

   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.

2. User Initiates Search

   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.

3. Get Aggregated Results

   The reporting system requests aggregated results from the analytics system

4. Aggregated Results

   The analytics system returns the aggregated results

5. Display 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.

6. User refines Focus or Form of Display

   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).

7. Get Aggregated Results

   The reporting system requests aggregated results from the analytics system

8. Aggregated Results

   The analytics system returns the aggregated results

9. Display Refined Results

   The Measure Repository modifies the users focus and reporting format

Distributing Measure Definitions

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

  • Measure Definition Source

  • Measure Definition Consumer

• Transactions

  • Query Measure Definition

Distributing Measure Definitions Process Flow

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.

1. Query for New or Updated Measures

   An organization required to report queries for for updated from one or public health or emergency response agencies to identify reporting requirements.

2. Return matching measure specifications

   The agency sends the new or updated definitions to the requesting reporting organization.

Automating Measure Computation

A reporting organization (e.g., a hospital) automatically computes and reports measure data.

This use case is supported by the following

• Actors

  • Measure Source

  • Measure Consumer

  • Measure Definition Consumer

  • Measure Computer

  • Data Source

• Transactions

  • Compute Measure

Automating Measure Computation Process Flow

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.

1. Query for New or Updated Measures

   The reporting organization checks for new measures see Distributing Measure Definitions above.

2. Compute Measure

   The hospital information system collects data and computes the measures, returning a completed report.

3. Gather Data

   The hospital information system queries the local EHR or FHIR Server for applicable FHIR resources used in measure computation.

4. Returns Matching FHIR Resources

   The local EHR or FHIR Server returns the requested data and included resources.

5. Send Measures to a Measure Consumer

   The reporting organization sends the computer measure to the public health agency.

Reporting Supplemental Data

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

  • Measure Source

  • Measure Consumer

  • Measure Computer

  • Data Source

• Transactions

  • Compute Measure

Reporting Supplemental Data Process Flow

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.

1. Compute Measure

   The hospital information system collects data and computes the measures, returing a completed report.

2. Gather Measure Data

   The hospital information system queries the local EHR or FHIR Server for applicable FHIR resources used in measure computation.

3. Returns Matching FHIR Resources

   The local EHR or FHIR Server returns the requested data and included resources.

4. Gather Supplemental Data

   The hospital information system queries the local EHR or FHIR Server for supplemental FHIR resources reported with the measure.

5. Returns Supplemental FHIR Resources

   The local EHR or FHIR Server returns the supplemental data and included resources.