§1:This operation is an alternative of the $match operation, constrained to meet the additional requirements found in this IG. One of the IDI Patient profiles outline in this guide (IDI-Patient, IDI-Patient-L0, IDI-Patient-L1, IDI-Patient-L2) SHALL be used as the input for the match request. An IDI-Match-Bundle will be returned to the requesting entity. This Bundle will contain the full URLs of the sourced information, an Organization resource, and any matched Patient resources.

A Patient resource that includes an Identifier with a value that is a Legal Entity Identifier (LEI), and may carry the verified LEI (vLEI). This profile is used to represent a patient who has a legal entity identifier, which is typically used for individuals who are associated with legal entities in financial transactions. The profile includes an extension for the verified LEI (vLEI) to indicate that the LEI has been verified and is valid.

A Person resource that includes an Identifier with a value that is a Legal Entity Identifier (LEI), and may carry the verified LEI (vLEI). This profile is used to represent a person who has a legal entity identifier, which is typically used for individuals who are associated with legal entities in financial transactions. The profile includes an extension for the verified LEI (vLEI) to indicate that the LEI has been verified and is valid.

A Practitioner resource that includes an Identifier with a value that is a Legal Entity Identifier (LEI), and may carry the verified LEI (vLEI). This profile is used to represent a practitioner who has a legal entity identifier, which is typically used for individuals who are associated with legal entities in financial transactions. The profile includes an extension for the verified LEI (vLEI) to indicate that the LEI has been verified and is valid.

A PractitionerRole resource that includes an Identifier with a value that is a Legal Entity Identifier (LEI), and may carry the verified LEI (vLEI). This profile is used to represent a practitioner role that has a legal entity identifier, which is typically used for roles that are associated with legal entities in financial transactions. The profile includes an extension for the verified LEI (vLEI) to indicate that the LEI has been verified and is valid.

A RelatedPerson resource that includes an Identifier with a value that is a Legal Entity Identifier (LEI), and may carry the verified LEI (vLEI). This profile is used to represent a related person who has a legal entity identifier, which is typically used for individuals who are associated with legal entities in financial transactions. The profile includes an extension for the verified LEI (vLEI) to indicate that the LEI has been verified and is valid.

An Organization resource that includes an Identifier with a value that is a Legal Entity Identifier (LEI), and may carry the verified LEI (vLEI). This profile is used to represent an organization that has a legal entity identifier, which is typically used for organizations that are involved in financial transactions. The profile includes an extension for the verified LEI (vLEI) to indicate that the LEI has been verified and is valid.

US Core 6.1.0 Organization constrained for FAST Identity STU3: adds the LEI as the organizational 'golden record' identifier and a verifiable LEI (vLEI) reference. US Core NPI/CLIA identifier slices and open slicing are preserved.

US Core 6.1.0 Patient constrained for FAST Identity STU3: adds jurisdiction-scoped Golden Record Identifier(s) and CSP-issued identifier(s) with assurance metadata. Slicing is open, so US Core / local identifiers (MRN, member ID) remain valid.

US Realm adapter: applies the Golden Record Identifier slice within a US Core Patient. Inherits US Core / USCDI must-supports in addition to the Golden Identifier slice.

Patient carrying a Golden Record Identifier, derived from base FHIR Patient so it is usable by any assigner — EHRs, payers, HIEs, and Credential Service Providers (CSPs) — and portable across realms. Must-support flags express the Golden Record identity boundary (brief §3): core identity attributes are Must Support; contextual data (employment, organizational role, coverage, clinical/USCDI demographics) is intentionally not required by this profile and lives in other resources.

Bundle requirements for responders to an $IDI-match request. Responders SHALL include only absolute URL FHIR server addresses, and SHALL NOT include URIs for UUIDs or OIDs, in the fullURL returned. This additional constraint on a response to $IDI-match is intended to help recipients understand the source of the response, particularly when a patient match is invoked as part of record location–such that the URL would be needed for additional health data requests performed subsequent to matching. Additionally, the .identifier.assigner element within the returned Bundle SHOULD include an Organization resource that contains at least one appropriate contact point.

The Parameters profile used to define the inputs of the $IDI-match operation using an IDI-Patient profile for submission.

The Parameters profile used to define the outputs of the $IDI-match operation.

An Identifier with a value that is a Legal Entity Identifier (LEI), and may carry the verified LEI (vLEI)

Assurance metadata for a CSP-issued person identity, aligned to NIST SP 800-63-3.

The governing jurisdiction (nation and, optionally, state/region) that issues and maintains a Golden Record Identifier. Enables multiple jurisdiction-scoped GRIs for one person.

A verifiable LEI (vLEI) credential attesting the organization's LEI. Carries the content-addressed credential identifier (SAID) and a resolvable source (OOBI / .well-known) for discovery. Verification is cryptographic against the GLEIF chain of trust, not the hosting domain.

An extension to hold the verified LEI (vLEI) indicating that the LEI has been verified and is valid. Note that the vLEI is not further decomposed into the Attachment elements, as pulling these values outside of the vLEI leaves them unprotected. Thus any access to the vLEI elements should go through the proper vLEI validation process and use the values in the then validated vLEI.

Permitted NIST 800-63-3 Authenticator Assurance Levels.

Permitted NIST 800-63-3 Identity Assurance Levels.

Type code(s) that mark a Patient.identifier as a Golden Record Identifier.

Lifecycle status of a verifiable LEI (vLEI) credential.

NIST SP 800-63-3 assurance levels used to qualify a CSP-issued identity.

Identifier type codes distinguishing Golden Record and CSP-issued person identifiers within FAST Identity.

Code system for the type of golden identifier used in the .identifier element of the Patient resource.

Lifecycle status of a verifiable LEI (vLEI) credential.

This is an example of a Patient resource that includes an Identifier with a value that is a Legal Entity Identifier (LEI). The Identifier uses the LEI profile to specify that the value is a valid LEI, and includes the system URI for the LEI. The example also includes an extension for the verified LEI (vLEI) to indicate that the LEI has been verified and is valid.

This is an example of a Person resource that includes an Identifier with a value that is a Legal Entity Identifier (LEI). The Identifier uses the LEI profile to specify that the value is a valid LEI, and includes the system URI for the LEI. The example also includes an extension for the verified LEI (vLEI) to indicate that the LEI has been verified and is valid.

This is an example of a Practitioner resource that includes an Identifier with a value that is a Legal Entity Identifier (LEI). The Identifier uses the LEI profile to specify that the value is a valid LEI, and includes the system URI for the LEI. The example also includes an extension for the verified LEI (vLEI) to indicate that the LEI has been verified and is valid.

This is an example of a PractitionerRole resource that includes an Identifier with a value that is a Legal Entity Identifier (LEI). The Identifier uses the LEI profile to specify that the value is a valid LEI, and includes the system URI for the LEI. The example also includes an extension for the verified LEI (vLEI) to indicate that the LEI has been verified and is valid.

This is an example of a RelatedPerson resource that includes an Identifier with a value that is a Legal Entity Identifier (LEI). The Identifier uses the LEI profile to specify that the value is a valid LEI, and includes the system URI for the LEI. The example also includes an extension for the verified LEI (vLEI) to indicate that the LEI has been verified and is valid.

This is an example of an Organization resource that includes an Identifier with a value that is a Legal Entity Identifier (LEI). The Identifier uses the LEI profile to specify that the value is a valid LEI, and includes the system URI for the LEI. The example also includes an extension for the verified LEI (vLEI) to indicate that the LEI has been verified and is valid.

Jordan Alexander Rivera — dual US/UK citizen. Two jurisdiction-scoped Golden Record Identifiers plus two CSP identities (CLEAR, ID.me) with NIST 800-63-3 assurance metadata.

Example Health System — NPI plus LEI (golden record) and a vLEI credential referenced by OOBI/.well-known with its content-addressed SAID.

Jane Marie Doe — a Golden Record Identifier asserted by a Credential Service Provider on a base FHIR Patient. Universal-ready: no USCDI demographics required (design brief 2.3, 2.3,

Jane Doe — one person carrying Golden Record Identifiers from two different CSPs, distinguished by system and assigner (multi-CSP scenario, design brief §4 Q6).

A Credential Service Provider asserts a Golden Record Identifier on a base FHIR Patient. Demonstrates the universal-ready authoritative profile (brief 2.3): the assigner is not a US Core producer, yet the record is fully conformant because only core identity attributes are required. No USCDI demographics are present, by design (brief 2.3): the assigner is not a US Core producer, yet the record is fully conformant because only core identity attributes are required. No USCDI demographics are present, by design (brief

An EHR persists the Golden Record Identifier inside a US Core Patient. Beyond the shared Golden Identifier slice it satisfies US Core / USCDI must-supports (race, ethnicity, birth sex, name, telecom, gender, birthDate, address). Contrast with Examples A and B: those USCDI demographics are contextual to identity resolution and are only present here because US Core requires them — the reason the authoritative profile stays on base Patient (brief 2.3, 2.3,

Illustrates action item #7: the same person carrying Golden Identifiers from two different CSPs, distinguished by system/assigner (brief §4 Q6).

Patient with one Golden Record Identifier issued by a CSP.

One person, two Golden Record Identifiers from different CSPs (multi-CSP scenario, brief §4 Q6). The identifiers share the #golden type but differ in system and assigner, which is how a matcher tells the issuing authorities apart.

Jane Doe — the same Golden Record Identifier persisted inside a US Core Patient by an EHR. Carries USCDI must-supports (race, ethnicity, birth sex) alongside the shared Golden Identifier slice (design brief §2.3 realm adapter).