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

Patient Identification

The first step in a FHIR-based query exchange is identifying the individual in the queried FHIR server. A high-confidence match between the Client and Server is essential to ensure accurate data retrieval for the correct patient. The outcome of this step is that both systems share the logical ID of the FHIR resource (Patient.id), which is crucial for constructing public health agency queries. This document does not specify the patient data to use for matching or the required confidence level before retrieving clinical data; implementers must define these based on workflow and local policies.

In some cases, a new match may not be necessary. For example, the event triggering the query could include a Medical Record Number or the FHIR Patient.id in an electronic Case Report (eCR). Additionally, if previous events for the same individual resulted in a high-confidence match, the FHIR client should retain the FHIR Patient.id for future queries. Public Health Agencies may choose to retain additional patient identifiers retrieved during a successful match to improve the confidence of matching to that patient even as demographics change over time. These identifiers may include Medical Record Number, Driver's License, and/or identity tokens issued by an Identity Provider.

Establishing a patient match is typically integral to FHIR query exchanges, especially since the FHIR Patient.id is not commonly included in non-FHIR data submissions. The FHIR standard offers several patient matching methods, including Patient Search and the $match operation. While out-of-band methods may work, they are not recommended due to their reliance on manual processes.

For a thorough understanding of patient matching, readers should refer to the FHIR search framework and the Patient FHIR resource. The US Core Patient profile also provides guidance on search parameters. Note that FHIR servers are not required to support all Patient search parameters, so implementers should identify specific requirements from HIT vendors or healthcare organizations. Some FHIR servers may use the CapabilityStatement resource to describe the search parameters that they support.

The $match operation allows users to input patient details and receive a bundle of potential matches with search scores. Support for this operation varies among FHIR servers, so implementers should understand their partners' capabilities before selecting a matching approach.

Implementers must consider all possible outcomes of patient matching. Ideally, the process yields a single high-confidence match, but other outcomes may include multiple matches or no matches at all. Implementers should prepare for workflows when a single high-confidence match is not achieved, including re-querying with additional information or invoking human review. Validation of returned results may also be necessary to meet local patient matching requirements before requesting clinical data, keeping in mind that human intervention can impact data acquisition timeliness.