Draft Implementation Guide Outline

Executive Summary

This Implementation Guide enhances current workflows that support patient matching and Digital Identity, while envisioning the path for incorporating emerging identity concepts over time. In addition to extending the patient $match operation for cross-organizational use by highlighting best practices in the use of matching attributes and their verification prior to making or answering a patient match request and for returning and interpreting match results, this specification will also offer guidance on identity assurance as it relates to attribute and evidence verification and to establishing Digital Identity. Implementation guidance for interoperable Digital Identity is another, longer-term objective for this project. 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 that are 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 not just identifiers, but also components such as matching, identity vetting, proofing, and verification, identity authentication, authorization and access control, as well as 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. In this context, the term “patient matching” refers to the process that identifies and matches records that represent the same individual within the same enterprise, while record linkage refers to the matching that occurs when data is exchanged between enterprises. 

2 Use Cases and Roles

Build from items the Use Cases team originally tagged as applicable to us (a few are linked in action items from this meeting) + Core Capabilities flagged for Identity

Possible Candidates from 7/19/21 Tiger Team Meeting:

• HIE 
• VCI (what is "VCI")
• Good Health Pass Collaborative Blueprint (Final to be published July 21)
• Payer to Payer Data Exchange - B2B vs. B2C; patient-mediated vs. not patient-mediated
• Maternal-child health research - how do we verify the child so we know who a vaccine was given to?
• Pediatrics or Geriatrics - may be too many policy implications re: delegated access to tackle right now

TEFCA-specific (per draft 2; will need updating): Recording & communicating a Meaningful Choice; Authorizing an Individual Access Request

Patient Mediated. Patient authorizes access to their data by a third party when it is under patient's management and not the data creator (e.g. an intermediary allows patient to manage their own data).

Patient Directed. Patient authorizes access to their data to a third party through an app as in SMART app launch workflow using the patient's credentials for authenticating themselves at the data holder organization which is the data creator.

3 Compilation of industry-wide digital identity and patient matching projects

Bring in summary items from June Meeting discussion and add to list with guidance as to applicability of each

(Note: Decentralized Identity is mentioned in the June meeting notes but not included in the list of representative examples) 

Patient ID Now Coalition Framework for a National Strategy on Patient Identity

• The Framework identified nine areas for definition of a national patient identity strategy 

4 Guidance on Identity Assurance

Supplemental information going beyond NIST 800-63-3a for its practical application in healthcare settings–for example, articulate example procedures to achieve IAL2 and other proofing levels in typical healthcare workflows 

Potential references:

IAL1.2 and IAL1.4

IAL1.8 (TBD); see: Patient IAL2 as in TEFCA and Kantara "IAL2 Light" proposal to NIST (1 STRONG or 3 FAIR)  

Worksheet comparing various levels

Risk Analysis or similar discussion Identifying the Identity Level of Assurance that is appropriate for various use cases, for example a patient's access to their own data or to make a consent, covered entity access to health data for Treatment/Payment/Operations, verification of demographic attributes to flag as verified and with Patient resource or Encounter context. 

Include process for verifying a photo for use in matching, e.g., as in 800-63 where photo taken during proofing event is confirmed as matching with photo on identity evidence for IAL2 remote unsupervised etc. 

Identity verification use case leveraging the parent's identity verification in order to shore up identity of the child.

5 TBD 

Discovering Identifiers corresponding to interoperable Digital Identities and the verification status of other identity attributes that comply with this IG (meta security tags, for example, and other existing FHIR and PKI items)

6 Matching Specification

Best practice patient matching, extending patient $match for cross-organizational use

Summary of recommendations from solution document, at least 2 workflows–Individual Access + TPO (others? probably want to separate out into various workflows, for readability):

When transmitting identity information about individuals to authorized parties--such as from an OpenID UserInfo endpoint or in another user information request, within a UDAP assertion object, or as part of a patient match or patient search request--each included identity attribute either must have been verified at the identity level of assurance asserted by the match requestor or must be consistent with other information so verified. If a level of assurance is not explicitly asserted, at a minimum, 1) the combination of identity attributes submitted is consistent with and sufficient to identify a unique identity (for example, first, last, DOB and home street address OR first, last, and a compliant Identifier) and corresponds to a human person whose identity has been verified at a level greater than IAL1 in accordance with the practices of NIST 800-63-3a using Fair or stronger evidence and/or credit bureau records (or equivalent); as a best practice, identity verification occurred at a minimum of IAL2 or LoA-3 for the individual and for an implementer's overall operations and 2) for Individual Access (or if PHI or PII will be returned, as a result of or subsequent to the match request, other than to a Covered Entity in a TPO workflow), a minimum of IAL1.8 or LoA-2 In Person end user identity verification is required and in that case, all identity attributes submitted for matching are verified to be consistent with the minimum IAL1.8 or LoA-2 In Person identity verification (and related attribute consistency requirement) before including those attributes in a match request.

When receiving identity information about individuals in a patient match or patient search request, then each match against identity attributes included by the requesting party must be performed against the subset of responder's patient records which includes only uniquely identified individuals (the records have been de-duplicated and data scrubbed such that attributes used in matching have been verified as consistent with the associated unique identity and all fields used for matching meet data validation requirements, e.g. street address validated as per USPS). Additionally, for Individual Access requests or equivalent workflows, the match must be performed using the subset of patient records for which the patient’s identity has been verified by responder at IAL1.8 or greater and patient attributes reflect or are consistent with that level of verification.

For sharing of immunization records only, patient matching may be performed using identity attributes verified at IAL1.2 or higher by requesting party and responder.

Need to insert best practice identity elements returned in different use cases

Benchmarking?

7 Exception Handling

8 International relevance

9 Relevance to other standards, e.g. IHE

10 Artifacts Summary

11 Examples