CDC National Healthcare Safety Network (NHSN) Digital Quality Measures (dQM) Content Package IG
2.0.0-cibuild - Release 2 ci-build United States of America flag

CDC National Healthcare Safety Network (NHSN) Digital Quality Measures (dQM) Content Package IG - Local Development build (v2.0.0-cibuild) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Specification

Page standards status: Informative

This section of the implementation guide (IG) defines the specific conformance requirements for systems wishing to conform to this NHSN dQM Reporting IG. The bulk of it focuses on evaluating facility data against measure criteria and submitting those data to NHSN, though it also provides guidance on privacy, security, and other implementation requirements.

Pre-reading

Before reading this formal specification, implementers should first familiarize themselves with the Use Cases page that describes the measure and reporting use cases this IG covers.

Conventions

This IG uses specific terminology to flag statements that have relevance for the evaluation of conformance with the guide:

  • SHALL indicates requirements that must be met to be conformant with the specification.

  • SHOULD indicates behaviors that are strongly recommended (and which may result in interoperability issues or sub-optimal behavior if not adhered to), but which do not, for this version of the specification, affect the determination of specification conformance.

  • MAY describes optional behaviors that are free to consider but are not a recommendation for or against adoption.

Inheritance of Requirements From Base Specifications

This Implementation Guide (IG) profiles resources derived from US Core, QI Core and the HL7 NHSN dQM Implementation Guides and therefore inherits all applicable conformance requirements defined in those guides. In accordance with FHIR profiling rules, inherited constraints:

  • Cannot be relaxed
  • May only be further constrained

Specifically:

  • A minimum cardinality of 1 in a parent profile SHALL NOT be reduced.
  • Elements marked Must Support (MS) in a parent profile SHALL remain Must Support.
  • Required and Extensible terminology bindings and other structural constraints SHALL be preserved or further constrained.

As a result, certain elements may be required or marked Must Support due to base IG conformance requirements, independent of whether NHSN reporting explicitly relies on those elements for measure calculation or submission validation.

NHSN-Specific Must Support Notation: (NHSN-MS)

To clearly communicate which data elements are relevant for NHSN digital quality measure (dQM) reporting, separate from inherited conformance obligations, this IG introduces an NHSN-specific notation: (NHSN-MS).

This designation is used solely to identify elements that NHSN considers necessary for reporting, validation, or measure processing, regardless of inherited cardinality or Must Support status.

This notation does not alter FHIR conformance semantics. Instead, it clarifies NHSN reporting expectations layered on top of inherited conformance requirements.

Elements that are relevant for NHSN reporting are identified by a MS flag in the Flags column and prefixing the element’s short description with the (NHSN-MS) notation. These elements will have a mouse hover message indicating "This element is Must Support for NHSN reporting."

Hover Image: This element is Must Support for NHSN reporting.

Elements that are marked as Must Support and have no (NHSN-MS) notation, will have a mouse hover message indicating "Must Support in a base specification. NOT needed for NHSN reporting."

Hover Image: Must Support in a base specification. NOT needed for NHSN reporting.

Interpretation of Rules for (NHSN-MS)

The effect of (NHSN-MS) depends on the element’s minimum cardinality:

  • (NHSN-MS) + min = 1 The element is required. Absence of such an element in a submission will result in a pre-qualification issue, as described in the Validation and Pre-Qualification guidance.

  • (NHSN-MS) + min = 0 The element is considered Must Support for NHSN reporting and SHALL follow the Must Support guidance defined in this IG. It is expected when applicable.

  • No (NHSN-MS) designation If the element has a minimum cardinality of 0, its absence is acceptable for NHSN reporting and will not result in a pre-qualification issue.

Summary of Rules for NHSN Must Support

Condition NHSN Expectation
[1..x] + (NHSN-MS) Pre-qualification issue if missing
[0..x] + (NHSN-MS) Expected when applicable; subject to Must Support processing rules
[1..x] + No (NHSN-MS) Absence is acceptable
[0..x] + No (NHSN-MS) Absence is acceptable

Must Support

The following rules regarding Must Support elements apply to all Profiles in this guide. The Must Support definitions are not inherited from other IGs, even for profiles in this guide that are derived from another guide.

Sender

  • If the data element is available in the Fast Healthcare Interoperability Resources (FHIR) application programming interface (API) or electronic health record (EHR), the data element SHALL be provided (either through submission or response to a query) for measure calculation or risk adjustment.
  • If the sender does not capture/store the data, the data are not available, or sharing of the data is not authorized, the system SHOULD NOT send the element if the element is not marked as mandatory (lower cardinality of 0).

Receiver

  • The receiver SHALL be capable of processing resource instances containing must-support data elements without generating an error or causing the application to fail.
  • The receiver SHALL be able to process resource instances containing must-support data elements asserting missing information (data absent reason extension).

Note: The profiles in this IG inherit from the US Core, which has some requirements that are more stringent than what is necessary for measure reporting (e.g. Practitioner references). This means that some inherited US Core required elements may not be used by NHSN and, if missing, may still pass NHSN ingestion validation.

Profiles

This specification makes significant use of FHIR profiles to define the data requirements for measure-specific submissions.

The complete set of profiles defined in this IG can be found by following the links on the Artifacts page.

Reporting Scenarios

The following reporting scenarios use the Actors defined in the Actors and Use Cases page.

The general reporting workflows are detailed in the Reporting Scenarios section of the HL7 NHSN dQM Reporting Implementation Guide.

When NHSNLink acquires data from Facility Environment, both the NHSNLink and the NHSN application reside within an NHSN-controlled environment. NHSNLink first retrieves the latest FHIR measures and related resources from the measure source and extracts the data requirements for each measure. NHSNLink queries the data source for data; evaluates the data against a measure; prepares bundles containing MeasureReport and supporting resources; and then performs pre-qualification (see Validation and Pre-qualification tab). Additionally, it conducts measure-specific FHIR validation checks, before making the data available to NHSN back-end systems. In this scenario, the data source SHALL have a FHIR API that, at a minimum, provides read access to all resources required by the measure(s).

Figure 1: How NHSNLink Works
Figure 1: Flowchart showing the process NHSNLink uses collect and provide data to NHSN as described in the body of the text in this page.

Figure 1 (above) illustrates the flow of data within and between the systems. NHSN is within the CDC Secure Environment. Under NHSN there are two systems: NHSN Application and NHSN Link. This process includes:

  1. Enrollment and readiness: In the NHSN Application, the facility enrolls in the digital measure reporting plan (DMRP). The facility selects FHIR dQMs, which are then communicated to the Facility Configuration in NHSNLink. This step confirms the facility’s readiness to report digital quality measures and that it has signed the NHSN data-use agreements required for secure data sharing.
  2. Data acquisition and normalization: NHSNLink determines the Patients of Interest based on the digital quality measures (dQM), and based on this list, securely acquires the data from the reporting facility’s clinical data sources,and normalizes the data as required by the respective dQM(s). NHSNLink then evaluates and filters the data as defined by each dQM and bundles the data into a MeasureReport.
  3. Validation and pre-qualification: NHSNLink applies validation tests on the data and runs it through a pre-qualification process to determine if it is acceptable to submit to NHSN.
  4. Submission: NHSNLink submits the MeasureReport bundles meeting the dQM requirements to the NHSN Data Analytics Pipeline and the data is applied to the analysis datasets.
  5. Ingestion and reporting: The NHSN Application ingests and analyzes the MeasureReport bundles and makes reports available to facilities via secure NHSN user interface.

* dQM = digital quality measure; FHIR = Fast Healthcare Interoperability Resources.