Health Care Surveys Reporting
2.0.0 - STU 2 United States of America flag

Health Care Surveys Reporting, published by HL7 International / Public Health. This guide is not an authorized publication; it is the continuous build for version 2.0.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/fhir-health-care-surveys-reporting-ig/ and changes regularly. See the Directory of published versions

Specification

Page standards status: Informative

This section defines the specific requirements for systems wishing to conform to actors specified in this Health Care Surveys Content Implementation Guide (IG). The specification focuses on using the eCR Now FHIR App-Health Care Surveys to report the health care survey data to National Center for Health Statistics (NCHS) data stores.

Pre-reading

Before reading this formal specification, implementers should first be familiar with the Background page which provides the business context and general process flow.

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 where there is no recommendation for or against adoption.

Claiming Conformance

Actors and Systems asserting conformance to this IG must implement the requirements outlined in the corresponding capability statements. The following definition of Must Support is to be used in the implementation of the requirements.

Must Support Definition

  • Systems SHALL be capable of populating data elements as specified by the profiles and data elements are returned using the specified APIs in the capability statement. §HCS-1
  • Systems SHALL be capable of processing resource instances containing the Must Support data elements without generating an error or causing the application to fail. §HCS-2
  • Systems SHOULD be capable of displaying the Must Support data elements for human use or storing them for other purposes. §HCS-3
  • In situations where information on a particular data element is not present and the reason for absence is unknown, Systems SHALL NOT include the data elements in the resource instance returned from executing the API requests. §HCS-4
  • When accessing Health Care Surveys Content IG data, Systems SHALL interpret missing data elements within resource instances returned from API requests as data not present. §HCS-5
  • When data is not available for any of the mandatory elements specified in the IG, a data absent reason extension SHOULD be added to satisfy the requirement along with an appropriate value from the data-absent-reason value set. §HCS-6

Profiles and Other IGs Used by the Specification

This specification makes significant use of FHIR profiles, search parameter definitions, and terminology artifacts to describe the content to be shared as part of Health Care Surveys Content IG workflows. The IG is based on FHIR R4 and profiles are listed for each interaction.

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

US Core Usage

This IG leverages the US Core set of profiles defined by HL7 for sharing non-veterinary electronic medical record (EMR) individual health data in the U.S. Where US Core profiles exist, this IG either leverages them directly or uses them as a base for any additional constraints needed to support the research use cases. If no constraints are needed, this IG does not define any profiles.

SMART App Launch IG Usage

This IG leverages the SMART App Launch IG defined by HL7 Infrastructure WG for enabling authentication and authorization between various actors involved in the workflows. This IG leverages Substitutable Medical Applications, Reusable Technologies (SMART) on FHIR Backend Services Authorization requirements.

Implementation Requirements

SMART on FHIR Backend Services Requirements

This section outlines how the SMART on FHIR Backend Services Authorization will be used by the Health Care Surveys Content IG.

  • The system actors namely Data Source, eCR Now FHIR App-Health Care Surveys and the NCHS Data Store are required to use the SMART on FHIR Backend Services Authorization mechanisms as outlined below for the following interactions:

    • eCR Now FHIR App-Health Care Surveys accessing data from the Data Source
    • eCR Now FHIR App-Health Care Surveys posting data to the NCHS Data Store acting as a Data Receiver with FHIR capabilities

  • System actors acting as servers (e.g., electronic health record (EHR) and NCHS Data Store) SHALL advertise conformance to SMART on FHIR Backend Services by hosting Well-Known Uniform Resource Identifiers (URIs) as defined in the SMART App Launch IG Backend Services specification. §HCS-7

  • System actors acting as servers SHALL include token_endpoint, scopes_supported, token_endpoint_auth_methods_supported and token_endpoint_auth_signing_alg_values_supported as defined in the SMART App Launch IG Backend Services specification. §HCS-8

  • When System actors act as clients (e.g., eCR Now FHIR App-Health Care Surveys), they SHALL share their JSON Web Key Set (JWKS) with the server System actors (e.g., EHR and NCHS Data Store) using Uniform Resource Locators (URLs) as defined in the SMART App Launch IG Backend Services specification. §HCS-9

  • System actors acting as clients SHALL obtain the access token as defined in the SMART App Launch IG Backend Services specification. §HCS-10

  • For the Health Care Survey use cases, Data Sources SHALL support the system/*.read scopes. §HCS-11

  • The NCHS Data Store SHALL support the system/.read and system/.write scopes. §HCS-12

  • The health care organization's existing processes along with the Data Source's authorization server SHALL verify any organizational policy requirements (for example, registration of the eCR Now FHIR App-Health Care Surveys, authorizing requested scopes, testing and verification of eCR Now FHIR App-Health Care Surveys implementation in sandbox environment prior to production) before allowing the eCR Now FHIR App-Health Care Surveys to access the data to be included in the health care survey report. §HCS-13

Knowledge Artifact and Knowledge Artifact Repository Requirements

  • The NCHS Data Store SHALL create a Knowledge Artifact §HCS-14

  • The NCHS Data Store SHALL publish the Group Resource containing the list of all the Practitioners participating in the health care survey. This can be published in the NCHS Data Store FHIR Server or a separate Knowledge Artifact Repository. §HCS-15

  • The NCHS Data Store SHALL republish the Group Resource when the list of all the Practitioners participating in the health care survey changes. §HCS-16

  • The NCHS Data Store SHALL create the Knowledge Artifact following the constraints. §HCS-17

  • The NCHS Data Store SHALL implement the Knowledge Artifact Repository requirements. §HCS-18

Data Source Requirements

Authorization Requirements
Subscription Requirements

  • The Data Source SHALL support the creation of Subscriptions. §HCS-21

  • The Data Source SHALL support rest-hook Subscription channel to notify the eCR Now FHIR App-Health Care Surveys. §HCS-22

  • The Data Source SHALL support Notification Bundles with full resource payload as outlined in the Backport Subscriptions IG. §HCS-23

  • For the Health Care Surveys Content IG, the Data Source SHALL include the Encounter resource which was closed as part of the Notification Bundle. §HCS-24

  • The Data Source SHALL support operations and APIs for Subscription, Notification Bundle, Subscription status resources as outlined in the Data Source Capability Statement. §HCS-25

Data API Requirements

eCR Now FHIR App-Health Care Surveys Requirements

Authorization Requirements
Subscription Requirements

  • The eCR Now FHIR App-Health Care Surveys SHALL create Subscriptions. §HCS-28

  • The eCR Now FHIR App-Health Care Surveys SHALL support rest-hook Subscription channel to receive notifications from the Data Source. §HCS-29

Subscription Notification API
  • The eCR Now FHIR App-Health Care Surveys SHALL support a POST API <BSA Base URL>/receive-notification with a payload of the Subscription Notification Bundle to receive the notifications from the Data Source. §HCS-30
Knowledge Artifact Processing Requirements

  • The eCR Now FHIR App-Health Care Surveys SHALL allow the health care organization to activate/deactivate a specific Knowledge Artifact. Activation indicates applying the Knowledge Artifact and deactivation indicates not applying the Knowledge Artifact for events occurring within the health care organization. §HCS-31

  • The eCR Now FHIR App-Health Care Surveys SHALL process the Health Care Surveys Knowledge Artifact and create Subscription resources in the Data Source for each trigger event. §HCS-32

  • For the health care surveys, the eCR Now FHIR App-Health Care Surveys SHALL create the Subscription. §HCS-33

  • Upon deactivation of a Knowledge Artifact, The eCR Now FHIR App-Health Care Surveys SHALL delete the Subscriptions previously created by the eCR Now FHIR App-Health Care Surveys for the Knowledge Artifact (e.g., delete the Subscription created for encounter-end trigger event). §HCS-34

  • The eCR Now FHIR App-Health Care Surveys SHALL implement FhirPath expression processing to process the Health Care Surveys Knowledge Artifact actions. §HCS-35

  • The eCR Now FHIR App-Health Care Surveys SHALL use the default queries outlined by the Health Care Surveys Knowledge Artifact unless overridden by the health care organization. §HCS-36

  • The eCR Now FHIR App-Health Care Surveys SHALL ensure no duplicate reports are submitted for the same patient and encounter occurring within a health care organization. §HCS-37

Data API Requirements
Report Generation Requirements

  • The eCR Now FHIR App-Health Care Surveys SHALL create a health care survey report following the constraints identified in Health Care Survey Content Bundle. §HCS-39

  • The eCR Now FHIR App-Health Care Surveys SHALL package the health care survey report following the constraints identified in Health Care Survey Reporting Bundle. §HCS-40

  • The eCR Now FHIR App-Health Care Surveys SHALL submit the message containing the health care survey report to the endpoint identified in the Health Care Surveys Knowledge Artifact unless overridden by the health care organization. §HCS-41

Use of Non-FHIR Based Approaches to Submit the Health Care Surveys Report
  • The eCR Now FHIR App-Health Care Surveys MAY use other transport methods such as Direct Transport to submit the Health Care Survey Report created when appropriate. §HCS-42
Message Receiving and Processing Requirements

  • The NCHS Data Store SHALL implement the $process-message operation on the ROOT URL of the FHIR Server to receive reports from the Backend Service App using the POST operation. §HCS-43

  • Upon receipt of the message, the NCHS Data Store SHALL validate the message before accepting the message. §HCS-44

  • When there are validation failures, the NCHS Data Store SHALL return a Operation Outcome response with the details of the validations as part of the POST response. §HCS-45

  • The NCHS Data Store SHALL implement the PHA requirements. §HCS-46

Conformance Statements in this Guide

IdExpectationConditional?Rule
 SHALL
 SHOULD
 SHALL NOT
 MAY		 Yes
 No
 Any
§HCS-1SHALL Systems SHALL be capable of populating data elements as specified by the profiles and data elements are returned using the specified APIs in the capability statement.
§HCS-2SHALL Systems SHALL be capable of processing resource instances containing the Must Support data elements without generating an error or causing the application to fail.
§HCS-3SHOULD Systems SHOULD be capable of displaying the Must Support data elements for human use or storing them for other purposes.
§HCS-4SHALL NOT In situations where information on a particular data element is not present and the reason for absence is unknown, Systems SHALL NOT include the data elements in the resource instance returned from executing the API requests.
§HCS-5SHALL When accessing Health Care Surveys Content IG data, Systems SHALL interpret missing data elements within resource instances returned from API requests as data not present.
§HCS-6SHOULD When data is not available for any of the mandatory elements specified in the IG, a data absent reason extension SHOULD be added to satisfy the requirement along with an appropriate value from the data-absent-reason value set.
§HCS-7SHALL System actors acting as servers (e.g., electronic health record (EHR) and NCHS Data Store) SHALL advertise conformance to SMART on FHIR Backend Services by hosting Well-Known Uniform Resource Identifiers (URIs) as defined in the SMART App Launch IG Backend Services specification.
§HCS-8SHALL System actors acting as servers SHALL include token_endpoint, scopes_supported, token_endpoint_auth_methods_supported and token_endpoint_auth_signing_alg_values_supported as defined in the SMART App Launch IG Backend Services specification.
§HCS-9SHALL When System actors act as clients (e.g., eCR Now FHIR App-Health Care Surveys), they SHALL share their JSON Web Key Set (JWKS) with the server System actors (e.g., EHR and NCHS Data Store) using Uniform Resource Locators (URLs) as defined in the SMART App Launch IG Backend Services specification.
§HCS-10SHALL System actors acting as clients SHALL obtain the access token as defined in the SMART App Launch IG Backend Services specification.
§HCS-11SHALL For the Health Care Survey use cases, Data Sources SHALL support the system/*.read scopes.
§HCS-12SHALL The NCHS Data Store SHALL support the system/.read and system/.write scopes.
§HCS-13SHALL The health care organization's existing processes along with the Data Source's authorization server SHALL verify any organizational policy requirements (for example, registration of the eCR Now FHIR App-Health Care Surveys, authorizing requested scopes, testing and verification of eCR Now FHIR App-Health Care Surveys implementation in sandbox environment prior to production) before allowing the eCR Now FHIR App-Health Care Surveys to access the data to be included in the health care survey report.
§HCS-14SHALL The NCHS Data Store SHALL create a Knowledge Artifact
§HCS-15SHALL The NCHS Data Store SHALL publish the Group Resource containing the list of all the Practitioners participating in the health care survey. This can be published in the NCHS Data Store FHIR Server or a separate Knowledge Artifact Repository.
§HCS-16SHALL The NCHS Data Store SHALL republish the Group Resource when the list of all the Practitioners participating in the health care survey changes.
§HCS-17SHALL The NCHS Data Store SHALL create the Knowledge Artifact following the constraints.
§HCS-18SHALL The NCHS Data Store SHALL implement the Knowledge Artifact Repository requirements.
§HCS-19SHALL The Data Source (e.g., EHR, clinical data repository) SHALL support the requirements as outlined in the Data Source Capability Statement.
§HCS-20SHALL The Data Source SHALL support the SMART on FHIR Backend Services Authorization outlined above as a Server.
§HCS-21SHALL The Data Source SHALL support the creation of Subscriptions.
§HCS-22SHALL The Data Source SHALL support rest-hook Subscription channel to notify the eCR Now FHIR App-Health Care Surveys.
§HCS-23SHALL The Data Source SHALL support Notification Bundles with full resource payload as outlined in the Backport Subscriptions IG.
§HCS-24SHALL For the Health Care Surveys Content IG, the Data Source SHALL include the Encounter resource which was closed as part of the Notification Bundle.
§HCS-25SHALL The Data Source SHALL support operations and APIs for Subscription, Notification Bundle, Subscription status resources as outlined in the Data Source Capability Statement.
§HCS-26SHALL The Data Source SHALL support the US Core Server APIs and MedicationAdministration APIs as outlined in the EHR Capability Statement for the eCR Now FHIR App-Health Care Surveys to access patient data.
§HCS-27SHALL The eCR Now FHIR App-Health Care Surveys SHALL support the SMART on FHIR Backend Services Authorization outlined above as a client.
§HCS-28SHALL The eCR Now FHIR App-Health Care Surveys SHALL create Subscriptions.
§HCS-29SHALL The eCR Now FHIR App-Health Care Surveys SHALL support rest-hook Subscription channel to receive notifications from the Data Source.
§HCS-30SHALL The eCR Now FHIR App-Health Care Surveys SHALL support a POST API <BSA Base URL>/receive-notification with a payload of the Subscription Notification Bundle to receive the notifications from the Data Source.
§HCS-31SHALL The eCR Now FHIR App-Health Care Surveys SHALL allow the health care organization to activate/deactivate a specific Knowledge Artifact. Activation indicates applying the Knowledge Artifact and deactivation indicates not applying the Knowledge Artifact for events occurring within the health care organization.
§HCS-32SHALL The eCR Now FHIR App-Health Care Surveys SHALL process the Health Care Surveys Knowledge Artifact and create Subscription resources in the Data Source for each trigger event.
§HCS-33SHALL For the health care surveys, the eCR Now FHIR App-Health Care Surveys SHALL create the Subscription.
§HCS-34SHALL Upon deactivation of a Knowledge Artifact, The eCR Now FHIR App-Health Care Surveys SHALL delete the Subscriptions previously created by the eCR Now FHIR App-Health Care Surveys for the Knowledge Artifact (e.g., delete the Subscription created for encounter-end trigger event).
§HCS-35SHALL The eCR Now FHIR App-Health Care Surveys SHALL implement FhirPath expression processing to process the Health Care Surveys Knowledge Artifact actions.
§HCS-36SHALL The eCR Now FHIR App-Health Care Surveys SHALL use the default queries outlined by the Health Care Surveys Knowledge Artifact unless overridden by the health care organization.
§HCS-37SHALL The eCR Now FHIR App-Health Care Surveys SHALL ensure no duplicate reports are submitted for the same patient and encounter occurring within a health care organization.
§HCS-38SHALL The eCR Now FHIR App-Health Care Surveys acting as a client SHALL use the US Core Server APIs and MedicationAdministration APIs as outlined in the Data Source Capability Statement to access patient data from the Data Source.
§HCS-39SHALL The eCR Now FHIR App-Health Care Surveys SHALL create a health care survey report following the constraints identified in Health Care Survey Content Bundle.
§HCS-40SHALL The eCR Now FHIR App-Health Care Surveys SHALL package the health care survey report following the constraints identified in Health Care Survey Reporting Bundle.
§HCS-41SHALL The eCR Now FHIR App-Health Care Surveys SHALL submit the message containing the health care survey report to the endpoint identified in the Health Care Surveys Knowledge Artifact unless overridden by the health care organization.
§HCS-42MAY The eCR Now FHIR App-Health Care Surveys MAY use other transport methods such as Direct Transport to submit the Health Care Survey Report created when appropriate.
§HCS-43SHALL The NCHS Data Store SHALL implement the $process-message operation on the ROOT URL of the FHIR Server to receive reports from the Backend Service App using the POST operation.
§HCS-44SHALL Upon receipt of the message, the NCHS Data Store SHALL validate the message before accepting the message.
§HCS-45SHALL When there are validation failures, the NCHS Data Store SHALL return a Operation Outcome response with the details of the validations as part of the POST response.
§HCS-46SHALL The NCHS Data Store SHALL implement the PHA requirements.