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

Validation and Pre-Qualification

Page standards status: Informative

All submission data must pass pre-qualification prior to submission to the National Healthcare Safety Network (NHSN), regardless of the mechanism/tools used for evaluation and submission. Pre-qualification involves categorizing FHIR (Fast Healthcare Interoperability Resources) validation issues (errors, warnings and informational) for a given submission dataset to NHSN. Categories are defined to match one or multiple types of validation issues. One key component of every category is the required “acceptability” flag (field). Every category must be defined according to NHSN as either acceptable or unacceptable.

Examples of Acceptable Validation Issues

Missing Valid Code from an Extensible Value Set

A warning validation message such as “None of the codings provided are in the value set, and a coding should come from this value set unless it has no suitable code” may be produced when a code outside of a value set with an extensible binding strength is used to represent a concept.

For example, the ACH Monthly Event Condition profile binds Condition.category to the Condition Category Codes Value Set with an extensible binding strength. With an extensible binding, a code from the specified Value Set should be used when an appropriate code exists. However, a code outside of the Value Set may be used when the Value Set does not contain a suitable code for the concept being represented. When the FHIR Validator encounters a code that is not included in the bound Value Set, it may generate a warning indicating that a code from the Value Set should be used unless no suitable code is available.

Missing Valid Code from a Preferred Value Set

An informational validation message such as “None of the codings are in the value set, and a coding is recommended to come from this value set” may be produced when a code outside of a value set with a preferred binding strength is used.

For example, the ACH Monthly Event Medication Request profile binds MedicationRequest.dosageInstruction.​timing.code to the TimingAbbreviation Value Set with a preferred binding strength. A preferred binding indicates that codes from the specified Value Set are recommended but are not required. Therefore, when a code outside of this Value Set is used, FHIR validation may produce an informational message indicating that use of a code from the specified Value Set is recommended.

Example of an Unacceptable Validation Issue

Missing Required Element

The validation error message, “minimum required = 1, but only found 0 (from ‘profile’)”, results when an element that is required by a profile is missing from a resource. A minimum cardinality of 1 indicates that at least one instance of the element must be present for the resource to confirm to the profile. For example, the ACH Monthly Event Encounter profile requires Encounter.location.period to be present for each Encounter.location element. When Encounter.location.period is absent, the validation message "minimum required = 1, but only found 0” results.

NHSN has determined that resources missing required elements, as in the Encounter.location.period example, are unacceptable issues and therefore would result in a failed submission of this dataset to NHSN.

Note: If one or more unacceptable categories exist within a potential data submission set, the entire dataset will not be submitted.

Standardized Terminology Validation

For code systems and value sets referenced by this Implementation Guide, NHSN permits the use of codes that were active at any time during the current calendar year or the three preceding calendar years. A code remains acceptable under this policy even if a subsequent release of the source terminology changes the code's status to inactive, retired, deprecated, remapped, or another status indicating that it is no longer active.

This policy recognizes that terminology systems evolve over time and that data submitted to NHSN may represent events documented using terminology versions that were current when the data were originally recorded. Accordingly, validation against the most recent version of a code system alone must not cause an otherwise valid code to be rejected when the code meets the NHSN acceptance period described above.

The National Library of Medicine's Value Set Authority Center (VSAC), which serves as the source for many value sets referenced in this Implementation Guide, similarly accounts for terminology changes over time. Previously published value sets may contain codes whose status subsequently changes, including codes that become inactive or retired or that are remapped as the underlying code systems evolve. VSAC provides information about retired or legacy codes and code remapping to support interpretation of such terminology changes.

Note: While codes outside of a value set or code system binding with a strength of example, preferred, or extensible are all considered to be acceptable validation issues as they are technically allowable, any code outside of the terminology binding will be unusable by NHSN. Therefore, it is the facility’s responsibility to ensure that all data required for NHSN reporting and metric calculation is mapped to the appropriate standardized terminology and/or Value Set.

When Pre-qualification Happens During Submission to NHSN

Validation and subsequent pre-qualification occur after data evaluation and before final submission to NHSN. Implementers acting as data submitters to NHSN perform and attest to pre-qualification for each dataset submitted to NHSN. An implementer system representing a new data source targeting NHSN submission in conformance with this guide should expect extensive and iterative pre-qualification-driven testing to identify acceptable and unacceptable data quality issues. To ensure a successful NHSN submission, it is crucial to address the unacceptable issues with the guidance provided for resolution. These issues may be addressed and resolved through various potential mechanisms, such as technical (i.e., configuration) updates at the data source (EHR), modifications to clinical workflows, data querying, and/or data normalization.

Figure 1 (above) represents the process flow for pre-qualification. This process includes:

1. Data retrieval: Primary dQM data is retrieved from the EHR Data Source through a secure FHIR API. This uses the Patients of Interest List and the dQM definitions in which the facility is enrolled.
2. Initial evaluation: The data goes through an initial evaluation, which includes normalization and determination of what data is reportable.
3. Filtering: Data determined to be reportable continues through the process. Data that is not reportable is discarded and does not move forward.
4. Augmentation: Reportable data is augmented with related supplemental data retrieved from the same EHR Data Source API.
5. Validation and bundling: The submission dataset is validated and packaged into a MeasureReport bundle.
6. Pre-qualification: The dataset undergoes pre-qualification, which identifies potential issues (errors, warnings, informational). Each issue is categorized.
7. Acceptability check: A key component of each category is acceptability, used to determine whether an issue is acceptable for submission to the NHSN Application.
8. Submission outcome:
   • If no issues exist, or only “acceptable” issues are found, the submission is successful and sent to the NHSN Application.
   • If one or more unacceptable issues exist, the dataset is not sent forward. Instead, it undergoes a review and remediation process

Pre-qualification categorization is technology agnostic; the frameworks and programming languages used to implement above do not matter. This allows the evaluation and submission of data to NHSN through multiple systems and pathways, provided pre-qualification results are acceptable. Similarly, the technology used to implement pre-qualification categorization to determine and assert only acceptable issues exist within a given submission dataset is not mandated.