Interoperable Digital Identity and Patient Matching
1.0.0 - STU 1.0.0
Interoperable Digital Identity and Patient Matching
1.0.0 - STU 1.0.0
This page is part of the Interoperable Digital Identity and Patient Matching (v1.0.0: STU1) based on FHIR R4. This is the current published version. For a full list of available versions, see the Directory of published versions 
| Official URL: http://hl7.org/fhir/us/identity-matching/ImplementationGuide/hl7.fhir.us.identity-matching | Version: 1.0.0 | |||
| Active as of 2023-03-09 | 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.
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.
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.
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:
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
IG © 2021+ HL7 International - Patient Administration WG. Package hl7.fhir.us.identity-matching#1.0.0 based on FHIR 4.0.1. Generated 2023-06-02
Links: Table of Contents |
QA Report
| Version History |
|
Propose a change