This page is part of the Interoperable Digital Identity and Patient Matching (v1.0.0-ballot: STU 1 Ballot 1) based on FHIR R4. . For a full list of available versions, see the Directory of published versions

Digital Identity

Overview

Digital Identity is the unique representation of a subject engaged in an online transaction. A digital identity SHALL always be unique in the context of a digital service that is compliant with this IG, but does not necessarily need to uniquely identify the subject in all contexts. Specifically, such a digital service SHALL NOT require that the subject’s real-life identity is evident from the credential identifier on its own.

In an effort to address matching errors by prioritizing the use of Digital Identifiers, this section of the IG defines what are likely to be new Digital Identifiers suitable for use in person matching where high confidence in the Digital Identity associated with such an Identifier is needed. Though there can be usability benefits in having just one such credential, an individual’s choice to utilize multiple such Digital Identifiers each from a different service, also referred to an Identity provider or Assigner, would also be consistent with the requirements of this IG. This section of the IG also describes Enterprise Identifiers which are the next best option when a Digital Identifier is unavailable or has not yet been established. In this context “Enterprise Identifiers” are identifiers issued by assigners who have not implemented the stricter requirements necessary for Digital Identifiers. For example, a clinic that leverages insurance member IDs for identifiers and therefore requires additional demographics to be provided during a match request to the insurance company because the identifier is not 1:1 with a unique identity.

Note: digital identities involved in healthcare transactions may correspond to Patients, Providers, Payers, and other healthcare actors.

Requirements for Digital Identifiers

• Identifier SHALL be capable of a validation process. Acceptable validation methods include 1) the user authenticates themselves at a level of authentication assurance commensurate with that of the credential itself and the credential is confirmed to originate from a trusted Identity Provider – authentication assurance SHALL be AAL2 or greater for any identity assurance level greater than IAL1; 2) relying party queries the Identity Provider’s system to confirm demographics associated with the individual in a privacy preserving way, for example by presenting a cryptographic hash of first, last, date of birth and home street address including zip or city and state along with the Identifier; or 3) authenticated individual authorizes sharing of demographics with the relying party. Acceptable verification methods include: 1) Identifier matches an Identifier previously associated to the medical record; 2) the Individual Profile Photo associated with an OpenID Connect Credential bound to the Identifier is consistent with this Implementation Guide and NIST 800-63-3 requirements on the use of biometrics and is a visual match to the individual or to a government-issued photo ID previously associated with the individual during a documented Identity Proofing event and saved in their record.

• A documented Identity Proofing process, performed by the Identity Provider directly and not through a Trusted Agent, at a minimum SHALL establish that a unique individual is represented by each Identifier and includes a declaration of identity assertion by the individual (such that it is fraudulent to claim a false identity). This requires the Identity Provider to follow a process that is IAL1.5 or higher according to this guidance. As future guidance may require an indication of individual attribute verification status, for example, a flag indicating whether an address was verified, and the verification date, Identity Providers SHOULD capture sufficient detail in their Identity Proofing records that their systems can differentiate between verified and unverified identity attributes.

• Identifier SHALL be unique for all time within the assigner’s system.

• Each Digital Identifier SHALL correspond 1:1 with a unique person on the Identity Provider’s (assigner’s) system: more than one Identifier cannot be generated within the assigner’s system for the same individual, as that would lead to mismatches on individual identity and potential patient safety issues.

• Identifier SHALL NOT ever be reassigned to a different individual except in the case of name changes.

• The associated individual onboarding process SHALL require the individual to assert that any attributes they provide correspond to their own identity. Legal names SHALL be used and the use of work addresses or phone numbers or other attributes not belonging to the individual SHOULD be discouraged.

• The email address and mobile number provided SHALL be under the individual’s exclusive control if used to secure the Identifier or an associated credential.

• Identifier SHOULD be ‘FHIR-ready’. The Identifier can be associated with an OpenID Connect credential that is capable of OAuth 2.0 authentication via UDAP Tiered OAuth; assigners which manage patient health records SHALL recognize such Identifiers when associated with a patient in their system as a Patient.identifier resource element and respond to queries that use this Identifier as a search parameter or in a match request. For example, the Identifier SHOULD appear in OpenID Connect identity claims made to trusted healthcare relying parties and is different from the OpenID Connect subject identifier, for example:

{
   ...
   "iss":"https://generalhospital.example.com/as",
   "sub":"328473298643",
   "identifier":"123e4567-e89b-12d3-a456-426614174000a",
   "amr":"http://udap.org/code/auth/aal2",
   "acr":"http://udap.org/code/id/ial2",
   "name": "Jane Doe",
   "given_name": "Jane",
   "family_name": "Doe",
   "birthdate": "1979-01-01",
   "address": {
     "street_address": "1234 Hollywood Blvd.",
     "locality": "Los Angeles",
     "region": "CA",
     "postal_code": "90210",
     "country": "US"},
    "email": "janedoe@example.com",
   "picture":"https://generalhospital.example.com/fhir/Patient?identifier=https://generalhospital.example.com/issuer1|123e4567-e89b-12d3-a456-426614174000a"
}

Alternatively, the assigner and identifier may be included as FHIR system and value data within a fhirUser identity claim as per 2015 Edition Cures Update requirements.

• The combination of Identifier plus Assigner cannot be reassigned for an individual; therefore the Identifier SHALL be protected like a Social Security Number and SHALL NOT be shared other than for patient matching purposes in a healthcare setting. The Identifier itself SHALL NOT be used as an OpenID Connect identifier and SHALL NOT be programmatically derived or otherwise possible to deduce from the OpenID Connect identifier since the OpenID Connect identifier may need to be re-issued from time to time, and individuals may want to use their OpenID Connect credential to authenticate themselves in other settings in which they do not wish to share personally identifiable information. Identity Providers SHALL NOT enable an individual to authorize sharing of the Identifier with an endpoint that is not a trusted healthcare organziation. For Identifiers assigned at any identity assurance level greater than IAL1, Identity Providers which establish a mechanism for proof of control of the credential SHALL associate with the Identifier an authenticator meeting NIST AAL2 or higher authentication assurance and that can be reset, in lieu of or supplemental to the OpenID Connect 1.0 workflow.

• The Identifier and any associated credentials SHALL be managed in alignment with NIST 800-63-3 Digital Identity Guidelines except as specified otherwise in this IG.

Digital Identifier Workflow Example

Patient completes an IAL 1.6 or greater identity verification process with a healthcare organization at registration and/or check-in, and the resultant Digital Identifier is then associated with the patient’s record in that organization’s EHR. The process includes collection and verification of (at a minimum, verification of control) a personal mobile number and email address belonging to the patient. The Identity Provider binds the Digital Identifier to an OpenID Connect credential with AAL2 authentication assurance. The patient subsequently authenticates to their insurance company’s system using this credential, after which the insurance company uses the Digital Identifier in a match request to the healthcare organization. Because this strong identity assurance credential has been used to authenticate the individual to both systems, and the patient authorizes sharing of PII from the Identity Provider to the healthcare organization for identity resolution, the healthcare organization can confidently share the correct patient data with the requesting party. If needed, the health system can contact the account holder out of band for additional information or can request real-time identity verification.

Requirements for Enterprise Identifiers

Locally-established business identifiers used in cross-organizational matching SHALL correspond to unique identities in the real world. In other words, business identifiers used in cross-organizational matching SHALL NOT be reassigned to a different person in the future, nor did they correspond to a different person at any time in the past. NOTE that these are examples of what we have in place today that can be used for matching and may not meet all the requirements required of a Digital Identifier as defined in this Implementation Guide.

Requirements:

Unique for the individual person (i.e. not the same identifier for entire family) within organizational boundaries of the exchange partner

“assigner” plus “identifier”/ (number) is not reusable for a different person

Can be stored as an identifier along with its assigner in FHIR Patient resource and therefore used in $match operations or other transactions

Identifiers with date issued, expiration date, or other validity period will contain this metadata when available.

Assigners SHOULD avoid the letters I and O in identifiers, as they are difficult to differentiate from 1 and 0.   

Enterprise Identifier Workflow Example

Patient provides their identifier(s) to a healthcare organization at registration and/or check-in, and the identifier(s) is/are then associated with the patient’s record. As an alternative to such an in-person binding to the record, patient rosters could be shared that describe how to associate each patient medical record number and insurance identifier pairing, for example, to manage identities at scale.

Miscellaneous Established Identifiers

Absent a Digital Identifier or Enterprise Identifier as described above, other good identifiers are particularly helpful in best practice person matching, for example:

• Social Security Numbers/Last 4

• Driver’s License Numbers

• Military ID Numbers

• Passport Numbers

• Individual National Provider Identifier

Miscellaneous Identifier Workflow Example

As these Miscellaneous Identifiers are increasingly collected, they are useful on their own or along with Enterprise Identifiers in improving probabilistic Patient Matching as described elsewhere in this Implementation Guide.