Interoperable Digital Identity and Patient Matching
2.0.0-draft - STU 2.0.0-draft United States of America flag

Interoperable Digital Identity and Patient Matching, published by HL7 International - Patient Administration WG. This guide is not an authorized publication; it is the continuous build for version 2.0.0-draft built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of and changes regularly. See the Directory of published versions


Official URL: Version: 2.0.0-draft
Active as of 2023-10-17 Computable Name: DigitalIdentity

This Identity-focused FHIR implementation guide (IG) has been established upon the recommendations of ONC’s FHIR at Scale Task Force (FAST) Identity Team and has been adapted from solution documents previously published by the team. The IG’s primary objective is to provide guidance on identity verification and patient matching as used in workflows pertinent to FHIR exchange and to facilitate cross-organizational and cross-network interoperability.

The IG may provide a foundation for future digital identity management requirements.


About This Guide

This IG describes how to extend the FHIR patient $match operation for use in cross-organizational workflows and serves as a set of best practices for matching in similar FHIR transactions not specifically invoking $match, as well as in other transaction types.

The requirements described in this guide are intended to align with the proposed solutions, including the security model, of the ONC FHIR at Scale Task Force’s Identity Team.

This guide is divided into several pages which are listed in the menu bar.

  • Home: The home page provides the introduction and background for this project and general requirements that apply to all workflows described in this guide.
  • Industry Initiatives: This page includes a compilation of industry-wide digital identity and patient matching projects.
  • Guidance on Identity Assurance: This page describes best practices for patient identity verification in the most common workflows necessary to support healthcare-related transactions.
  • Patient Matching: This page describes the appropriate usage of the patient $match operation for cross-organizational exchange.
  • Digital Identity: This page provides best practices for individual identity management in a healthcare context.
  • Conformance: This page provides explicit guidelines for an implementer to be considered conformant with this IG.
  • FHIR Artifacts: This page provides additional conformance artifacts for FHIR resources.


Executive Summary

This IG provides guidance to enhance current workflows that support patient matching and digital identity and envisions a path for both providing more specific guidance and incorporating emerging identity concepts over time. This specification contributes to a long-term goal of establishing Digital Identity by providing guidance on identity assurance best practices for attribute and evidence verification. The guide extends the patient $match operation for cross-organizational use by highlighting best practices in using matching attributes and their verification prior to responding to a patient match request or interpreting match results.

This guide will address the two concepts of patient matching and Digital Identity with care to differentiate between the two distinct disciplines and the workflows usually unique to one concept or the other:

Identity. Digital health identity refers to the technology and processes that support personal identity as it pertains to electronic health information. Digital health identity includes identifiers as well as components such as matching, identity vetting (also referred to as proofing or verification), identity authentication, authorization and access control, and other technologies and processes.

Patient Matching. Patient matching and record linkage help address interoperability by determining whether records—both those held within a single facility and those in different healthcare organizations—correctly refer to a specific individual. Matching methods use demographic information, such as name and date of birth.

Research has shown that matching is improved when higher-quality demographics are provided in the match request; verifying the identity of an individual at a specific identity assurance level (IAL1, IAL2, etc.), and that any match input data is consistent with the identity verification event, helps measure the quality of data included in a match request. For this reason, this IG will provide both guidance on how to improve identity assurance and how to leverage identity assurance in matching.

When the identity of the person who is authenticated in a transaction is known with high confidence, this information can be used in an access decision, e.g., Patient-Directed Exchange. This allows implementers to rely on user authentication in this workflow instead of probabilistic matching, which becomes increasingly convenient as federated identity services proliferate. This also reduces the number of credentials an individual needs to maintain.

As a secondary effect, digital credentials with high confidence identity assurance and a globally unique identifier associated with the individual, even in Business to Business matching (where the patient is not authenticated as being present in the transaction), emulate the perfect matching described in the paragraph above. Attempting to match on such a unique identifier is a preferred best practice over matching with a combination of demographics.

When identity proofing has been completed for an individual, the process of verifying that demographic attributes are consistent with a unique individual in the real world makes the attributes more meaningful in match requests and improves match quality when probabilistic matching must be used.


Use Cases and Roles

This IG provides identity management and person matching guidance to support the use cases listed below, with a focus on FHIR transactions. However, the guidance also applies to any transaction type. Roles such as Identity Provider, patient, authorized representative, application, data holder, and intermediary are highlighted within the use case descriptions.

Patient-Mediated B2C: Patient or their authorized representative authorizes access to their data by a third party when the data are under the patient’s management and not the data creator’s (e.g., a consumer app enables the patient to manage their own data).

Patient-Directed B2C: Patient or their authorized representative authorizes a third-party application to access patient’s data as in the SMART App Launch workflow (or equivalent) using their credentials at the data holder organization or other trusted credentials from a third-party Identity Provider (for example, as in Unified Data Access Profiles (UDAP) Tiered OAuth for User Authentication to authenticate the user.

Examples of this use case include:

  1. A patient using an app of their choice along with FHIR APIs required by ONC or CMS
  2. TEFCA Individual Access or other Patient Request via federated identity with UDAP Tiered OAuth, as outlined in the TEFCA FHIR Roadmap.

App-Mediated B2B with Patient User: This type of individual access lets a patient or their authorized representative use a patient-facing app, not necessarily operated by a covered entity or business associate, to exercise their HIPAA Right of Access. The user’s identity is verified in accordance with this guide, and the app appropriately restricts the information made available to the user, though the requirements on how data are restricted are beyond this guide’s scope. This use case which relies on UDAP Business-to-Business security model in FHIR transactions may be limited to a match with or without endpoint lookup (record location) or may also include a health data request. In other words, the user is attempting to access patient id(s) corresponding to one or more endpoints and/or the patient’s health data at those endpoints without using a credential they obtained from the data creator or intermediary data holder. Note that this use case can be implemented for record location at one or more endpoints and a different use case employed for access to health data. Ultimately this is a B2C transaction.

Along with additional stipulations, one example of the above use case is TEFCA Individual Access Services.

B2B Treatment Payment Operations (TPO): This business-to-business workflow involves a covered entity with an exchange purpose of treatment, healthcare payment, or healthcare operations.

B2B Coverage Determination: This business-to-business workflow involves a non-covered entity with an exchange purpose of eligibility determination.

B2B Patient Request: This business-to-business workflow involves an entity with an exchange purpose of patient requested (when patient may not have access to data).

Examples of B2B exchange relevant to this IG include record location and other patient matching use cases for queries and messaging enabled for trusted organizations by community or point to point access. Relevant B2B exchanges also include TEFCA Facilitated FHIR, TEFCA Brokered FHIR, TEFCA Broadcast Query, TEFCA Targeted Query, TEFCA Message Delivery, TEFCA Population-Level Data Exchange, and associated patient discovery and matching services.

(1) Patient Identity Integrity White Paper HIMSS, December 2009
(2) Approaches and Challenges to Electronically Matching Patients’ Records across Providers GAO, January 2019
(3) The Sequoia Project
(4) Defining and Evaluating Patient-Empowered Approaches to Improving Record Matching RAND, 2018



Primary Authors: Julie Maas EMR Direct
  Carmen Smiley ONC
  Jeff Brown Lantana Consulting Group
Contributors: Paul Vaughan Optum
  Vijey Kris Sridharan United Healthcare
  Jim St. Clair Linux Foundation
  Catherine Schulten Walmart
  Ryan Howells Leavitt Partners
  Rita Torkzadeh Independent Consultant

This IG was made possible by the thoughtful contributions and feedback of the following additional people and organizations:

The members of the ONC FHIR at Scale Taskforce (FAST) Identity Team

The members of the HL7 Patient Administration Work Group