Respiratory Virus Hospitalization Surveillance Network (RESP-NET) Content Implementation Guide, published by HL7 International / Public Health. This guide is not an authorized publication; it is the continuous build for version 1.0.0-ballot built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/fhir-resp-net-ig/ and changes regularly. See the Directory of published versions
This section defines the specific requirements for systems wishing to conform to actors specified in this Respiratory Virus Hospitalization Surveillance Network (RESP-NET) Content Implementation Guide (IG). The specification focuses on using the Health Data Exchange App (HDEA), Making Electronic Data More available for Research and Public Health’s (MedMorph) backend services app, to report the data to RESP-NET sites.
Before reading this formal specification, implementers should first be familiar with the Use Cases page which provides the business context and general process flow.
This IG uses specific terminology to flag statements that have relevance for the evaluation of conformance with the guide:
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.
This specification makes significant use of FHIR profiles, search parameter definitions, and terminology artifacts to describe the content to be shared as part of RESP-NET 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.
This IG leverages the MedMorph Reference Architecture (RA) IG defined by HL7 Public Health Workgroup (WG) as the reference architecture for automation and implementing the RESP-NET use cases.
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.
This IG leverages the Subscriptions Backport IG defined by HL7 Infrastructure WG for automating reporting workflows using subscriptions.
This IG leverages the US Public Health Profiles Library IG defined by the Public Health WG as a collection of reusable architecture and content profiles representing common public health concepts and patterns. The USPHPL IG is intended to be a complement to US Core used to ease implementation burden of healthcare organizations, electronic health record companies, public health agencies, and others involved in the US public health endeavor.
This IG leverages the electronic Case Reporting (eCR) IG defined by the Public Health WG specifies the appropriate FHIR resources and transactions needed for the eCR process. FHIR offers opportunities to further enable automated triggering and reporting of cases from EHRs, to ease implementation and integration, to support the acquisition of public health investigation supplemental data, and to connect public health information (e.g., guidelines) with clinical workflows.
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.
This section outlines how the SMART on FHIR Backend Services Authorization will be used by the RESP-NET Content IG.
The system actors namely Data Source, HDEA and the Data Receiver are required to use the SMART on FHIR Backend Services Authorization mechanisms as outlined below for the following interactions:
System actors acting as servers (e.g., Data Source and Data Receiver) 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.
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.
When System actors act as clients (e.g., HDEA), they SHALL share their JSON Web Key Set (JWKS) with the server System actors (e.g., Data Source and Data Receiver) using Uniform Resource Locators (URLs) as defined in the SMART App Launch IG Backend Services specification.
System actors acting as clients SHALL obtain the access token as defined in the SMART App Launch IG Backend Services specification.
For the RESP-NET use cases, Data Sources SHALL support the system/*.read scopes.
The Data Receiver SHALL support the system/.read and system/.write scopes.
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 HDEA, authorizing requested scopes, testing and verification of HDEA implementation in sandbox environment prior to production) before allowing the HDEA to access the data to be included in the RESP-NET report.
The Data Receiver SHALL create a Knowledge Artifact following the constraints identified by the MedMorph Provisioning requirements.
The Data Receiver SHALL create the Knowledge Artifact following the constraints identified in the RESP-NET-PlanDefinition.
The Data Receiver SHALL implement the Knowledge Artifact Repository requirements as outlined in the MedMorph RA Knowledge Artifact Repository Requirements.
The Data Source SHALL support the creation of Subscriptions for the encounter-end Subscription Topic
The Data Source SHALL support rest-hook
Subscription channel to notify the HDEA.
The Data Source SHALL support Notification Bundles with full resource payload
as outlined in the Backport Subscriptions IG.
For the RESP-NET Content IG, the Data Source SHALL include the Encounter resource which was closed as part of the Notification Bundle.
The Data Source SHALL support operations and APIs for Subscription, Notification Bundle, Subscription status resources as outlined in the Data Source Capability Statement.
The HDEA SHALL create Subscriptions for the encounter-end Subscription Topic.
The HDEA SHALL support rest-hook
Subscription channel to receive notifications from the Data Source.
The HDEA 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.
The HDEA SHALL process the RESP-NET Knowledge Artifact and create Subscription resources in the Data Source for each trigger event.
For RESP-NET, the HDEA SHALL create the Subscription for the encounter-end Subscription Topic trigger event.
Upon deactivation of a Knowledge Artifact, The HDEA SHALL delete the Subscriptions previously created by the HDEA for the Knowledge Artifact (e.g., delete the Subscription created for encounter-end trigger event).
The HDEA SHALL implement FhirPath expression processing to process the RESP-NET Knowledge Artifact actions.
The HDEA SHALL use the default queries outlined by the RESP-NET Knowledge Artifact unless overridden by the health care organization.
The HDEA SHALL ensure no duplicate reports are submitted for the same patient and encounter occurring within a health care organization.
The HDEA SHALL create a RESP-NET report following the constraints identified in RESP-NET Content Bundle.
The HDEA SHALL package the RESP-NET report following the constraints identified in RESP-NET Reporting Bundle.
The HDEA SHALL submit the message containing the RESP-NET report to the endpoint identified in the RESP-NET Knowledge Artifact unless overridden by the health care organization.
The Data Receiver 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.
Upon receipt of the message, the Data Receiver SHALL validate the message before accepting the message.
When there are validation failures, the Data Receiver SHALL return a Operation Outcome response with the details of the validations as part of the POST response.
The Data Receiver SHALL implement the PHA requirements as outlined in the MedMorph Data Receiver requirements.