Query & Response for Public Health, published by HL7 International / Public Health. This guide is not an authorized publication; it is the continuous build for version 1.0.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/us-helios-QR/ and changes regularly. See the Directory of published versions
| Page standards status: Informative |
Data governance for public health FHIR Query and Response is essential to ensure responsible management, access, and exchange of protected health information. It establishes clear policies and procedures for data quality, security, privacy, and interoperability across participating entities. In the context of FHIR-based public health reporting, data governance defines who can query or respond to clinical data requests, the conditions for doing so, and the standards for data validation. A key element of this governance is the use of Data Use Agreements (DUAs) or Participation Agreements, such as New York’s SCPA, which outline the specific terms under which data may be shared between providers and Public Health Agencies, including permitted uses and security protocols. These agreements ensure compliance with regulations such as HIPAA, clarify roles and responsibilities among partners, and foster trust by safeguarding patient privacy while enabling accurate, timely, and actionable data sharing to enhance public health surveillance and response efforts.
TEFCA encourages, but does not require, providers to respond to queries. Healthcare providers need information about the requestor to determine whether to respond to a public health agency query. In some jurisdictions, providers may have legal obligations to respond to certain public health authorities while being prohibited from responding to others. Existing regulations, workflows, and data-sharing agreements should guide public health authorities in selecting which provider organizations to query for data.
FHIR facilitates both “business-to-business” trust between provider organizations and public health authorities (PHAs) and access for individual users through SMART on FHIR. When authorizing a FHIR client, provider organizations implement policies that dictate the conditions for approving requests. For example, a provider may choose to respond to requests from organizations within their state while declining those from organizations outside their state.
Jurisdictions derive the authority to collect data relevant to their public health functions through local and state regulation and law. Public health access is also supported through Data Use Agreements (DUAs) and other documents which further describe permitted data uses and obligations. However, the specific mechanisms for data access are not always clearly defined and potential data sources may not recognize a requirement to respond to FHIR-based queries if they can meet reporting requirements through other mechanisms. Jurisdictions should thoroughly understand the scope of their local authority to collect data via FHIR as not all jurisdictions may come to the same conclusion. Those jurisdictions with the authority to utilize FHIR-based queries should work with data sources to establish a clear understanding of the scope and nature of the queries to be performed and determine appropriate data sharing or DUAs to facilitate data exchange. The lack of clear authority to use FHIR will adversely affect the ability to automate data collection and reduce data reporting burden
A description of the existing federal certification requirements and the types of data likely to be available via FHIR API query may be found on the Support page.
Guidance on using TEFCA to facilitate queries and TEFCA Exchange Purposes are outlined in the Public Health standard operating procedure (SOP).
The Trusted Exchange Framework provides the infrastructure for patient discovery, FHIR Push, and FHIR Query capabilities. It encourages responding nodes to return, at a minimum, USCDI data classes and data elements maintained and requested by the Initiating Node, in accordance with Applicable Law.
The Common Agreement authorizes six types of Exchange Purposes (XPs), including Public Health, allowing TEFCA participants to securely share and request information from PHAs. However, due to the complexities and variations in laws regarding public health exchange purposes, the Common Agreement states that PHAs are not required to respond to any queries from requesters, although they are encouraged to do so as appropriate under Applicable Law.
TEFCA defines an automated mechanism for Client Registration, but until the FHIR at Scale Taskforce (FAST) SSRAA Implementation Guide is widely adopted, PHAs will need to manually register their clients at responding organizations or work with intermediaries who provide FHIR connectivity.
Automated data retrieval that supports a Public Health workflow, requires either:
In addition to the audit and logging requirements defined in the HIPAA Security Rule and TEFCA Common Agreement, PHAs should consider implementing the Privacy and Security requirements defined by the ASTP’s Certified EHR Technology. Generally, this means retaining a tamper-resistant log of all transactions made to retrieve data and to access data and assigning appropriate role-based security to Case Investigators to minimize and detect misuse. In absence of an industry-wide solution for scalable security to back-end APIs, PHAs may be subject to additional constraints on the scope or volume of data they are permitted to access. The Helios and Security HL7 workgroups are collaborating to extend the concepts of consent and certifications to include authorizations granted by a jurisdiction or pursuant to a document, such as an initial case report.
The current state of Public Health data exchange relies on three different models of authorization:
Backend system trust: A PHA may establish FHIR connectivity with the State HIE that receives data from member healthcare organizations. A data use agreement, signed by the PHA, HIE, and its members allows the PHA to retrieve data without requiring individual user authentication. This approach simplifies connectivity as compared to connecting to each member organization directly.
Patient-authorized data exchange (Individual Access Use Case):Patients can initiate data sharing by authenticating themselves with a state portal and querying for their data. This is useful for preparing International Patient Summaries and consolidating immunization records but is less useful for case investigation.
Case Investigator log in to an intermediary, such as an HIE, or directly into an EHR (including SMART on FHIR): Case Investigators may be granted individual logins to access EHRs, web portals hosted by HIEs, or other online data repositories, however this approach is heavily manual and can be time consuming.