Interoperable Digital Identity and Patient Matching
3.0.0-current - STU 3
Interoperable Digital Identity and Patient Matching
3.0.0-current - STU 3
Interoperable Digital Identity and Patient Matching, published by HL7 International / Patient Administration. This guide is not an authorized publication; it is the continuous build for version 3.0.0-current built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/fhir-identity-matching-ig/ and changes regularly. See the Directory of published versions
| Page standards status: Informative |
This guidance defines how the FAST Identity Matching IG profiles the use of the LEI and the vLEI for verifiable organizational identity.
In scope.
Organization resource as the carrier of organizational identity.Practitioner / PractitionerRole profiling for OOR/ECR is referenced but defined in companion FAST Identity guidance.)Out of scope.
For use within this IG:
https://www.gleif.org/lei (see §B.5.1)..well-known paths.The single most important profiling principle in this section is the distinction between an identifier and a credential:
Organization.identifier.Organization.identifier; it is conveyed via a credential reference and verified out of band of the FHIR resource itself.A FHIR resource never embeds a vLEI credential inline. Instead, the resource:
identifier, andThis separation matters because FHIR resources are mutable, propagated, and frequently re-served — the verifiable claim must be re-checkable from a stable cryptographic source, not from the FHIR copy.
The following matrix maps common FAST scenarios to the minimum identity assurance needed for the organizational layer. The matrix is non-normative for STU3 but is intended to harden into SHALL/SHOULD language as adoption matures.
| # | Scenario | Trust requirement | LEI sufficient? | vLEI required? | Rationale |
|---|---|---|---|---|---|
| 1 | Listing an organization in a directory (NDH, payer directory, network roster) | Identification only | Yes | No | The directory is the source of truth; the LEI cross-references the entity globally. |
| 2 | Cross-walking organizational records between networks (e.g., NDH ↔ TEFCA participant list) | Identification only | Yes | No | Reconciliation does not require real-time proof; the LEI is an unambiguous join key. |
| 3 | Regulatory or analytics reporting that names an organization | Identification only | Yes | No | The relying party validates by registry lookup, not by credential. |
| 4 | A FHIR Organization resource published as reference data |
Identification only | Yes | Optional (recommended) | Adding a vLEI reference future-proofs the resource for downstream verifiers. |
| 5 | Issuing or rotating an OAuth client credential bound to an organization | Authentication of legal entity | No | Yes | The authorization server must prove which legal entity controls the client; LEI alone is unauthenticated. |
| 6 | Asserting an organization in a UDAP dynamic client registration | Authentication of legal entity | No | Yes | UDAP today binds to X.509 + DNS; the vLEI binds to the legal entity behind the cert. See §B.7. |
| 7 | Cross-network FHIR data exchange where TLS and the responding server's cert do not establish who the requester legally is | Authentication of legal entity | No | Yes | Endpoint trust ≠ entity trust. The vLEI closes the gap. |
| 8 | Submitting prior authorization, regulatory filings, claims attachments, or payment instructions on behalf of an organization | Authentication + delegation | No | Yes (Legal Entity + OOR/ECR) | High-trust transactions require both organizational authentication and proof that the human (or system) is authorized to act on the entity's behalf. |
| 9 | Delegating a specific authority to a vendor, an admin staff member, a system, or a downstream organization, or AI agent | Authentication + delegation | No | Yes (ECR) | ECR is the explicit mechanism for engagement-context delegation; LEI cannot express delegation. |
| 10 | Logging / auditing an action attributed to an organization in a way that survives later dispute | Cryptographic accountability | No | Yes | Only a cryptographically signed credential supports non-repudiation. |
| 11 | Population health, benchmarking, or de-identified analytics that name participating organizations | Identification only | Yes | No | No transactional trust required. |
| 12 | Initial onboarding of an organization to a network where credentials will later be issued | Identification (then authentication on issuance) | Yes (initial); vLEI on activation | Required by go-live | The organization can be referenced by LEI during paperwork; the vLEI is required before the entity is allowed to authenticate. |
Use the LEI alone when you only need to identify the organization. Use the vLEI when the organization, or a person, or agent, acting on its behalf, is acting — making, signing, asserting, or authorizing something — and the relying party needs cryptographic proof.
A useful test question: "If this assertion turned out to be wrong, would I want a cryptographic record of who actually made it?" If yes, vLEI is required.
Organization.identifierThe LEI is conveyed as an entry in Organization.identifier with the following semantics:
system = https://www.gleif.org/lei (canonical GLEIF URI for the LEI)value = the 20-character LEI string (uppercase per ISO 17442)use = officialtype.coding = an IDTYPE code (the FAST Identity work group will publish a CodeSystem or extend an existing one; in the interim, a Coding with display = "Legal Entity Identifier" is acceptable for narrative IGs)Cardinality guidance. This IG SHOULD treat the LEI as the preferred organizational identifier where one is available, while continuing to permit NPI, Tax ID, and OID identifiers in the same Organization.identifier array. Slicing on system allows multiple identifiers to coexist without ambiguity.
A FHIR resource cannot carry a verifiable credential by value. It can, however, signal:
The FAST Identity work group SHOULD define a single extension on Organization.identifier (slice: LEI) for this purpose. A working name is org-vlei-anchor. The extension should carry, at minimum:
aid — the KERI Autonomic Identifier of the Legal Entity vLEI credential subject,qvi — the LEI of the Qualified vLEI Issuer that issued the credential,oobi — one or more OOBI (Out-Of-Band Introduction) URLs through which a relying party can resolve KERI verification material for the AID.Verifiers MUST resolve the credential out of band via the KERI infrastructure. The FHIR resource is a pointer, not a substitute for the credential.
For healthcare exchange, the OOBI URL SHOULD resolve to an endpoint that the organization itself controls — typically a path under the organization's primary domain. The recommended pattern is to publish the OOBI under a stable, well-known path:
https://{organization-domain}/.well-known/vlei/oobi
A .well-known path (per RFC 8615) is appropriate because it is a standardized, predictable location for service metadata that any relying party can find without prior coordination.
Hosting the OOBI on infrastructure the organization controls delivers three benefits at once:
CapabilityStatement endpoints, well-known/smart-configuration, UDAP metadata, supported networks, technical and trust contacts, and so on. The OOBI URL becomes a hub for "everything a relying party needs to engage in exchange with this organization."Organization resources, directory listings, and downstream consumers do not need to be re-issued.Implementers SHOULD ensure that:
.well-known namespace is used to host other exchange metadata, those resources are clearly distinguished from the OOBI itself (e.g., different path segments under /.well-known/vlei/).What is a witness? In KERI, a witness is an independent service designated by the controller of an AID to observe that AID's Key Event Log (KEL) and counter-sign each event it sees, producing a key event receipt. Witnesses serve two purposes. First, they provide independent attestation that the controller's published KEL is the same history the witness observed — this is KERI's defence against duplicity, where a malicious controller could otherwise present different key histories to different verifiers. Second, they provide availability, since a verifier can fetch verification material from a witness even when the controller's own endpoint is unreachable. An organization typically designates a small set of witnesses (often 3–7) and specifies a witness threshold (for example, "any 2 of 3" or "any 5 of 7") that verifiers require before accepting a key event as confirmed. Witnesses are usually operated by independent parties — sometimes the QVI, sometimes dedicated witness operators — precisely so that no single party controls the historical record. For OOBI purposes, a witness endpoint is therefore both a redundant route to verification material and an independent attestation of the same key state.
An organization MAY publish more than one OOBI URL — for example, one on its own domain and one or more provided by witness operators — for resilience and for independent attestation. The oobi extension cardinality is therefore 1..*. Verifiers SHOULD be prepared to try alternate OOBIs if one is unreachable, and MUST require that all reachable OOBIs resolve to materially consistent KERI state for the same AID. Where the relying party's policy specifies a witness threshold, the verifier MUST confirm that threshold has been met before accepting a credential.
The following FSH is illustrative only — it shows the shape of the slicing and extension; final names, URIs, and binding strength are deferred to the FAST Identity work group.
// Identifier slice for the LEI on FHIR Organization
Profile: FASTOrganization
Parent: Organization
Id: fast-organization
Title: "FAST Organization"
Description: "Organization profile supporting LEI identification and optional vLEI verifiability."
* identifier ^slicing.discriminator.type = #value
* identifier ^slicing.discriminator.path = "system"
* identifier ^slicing.rules = #open
* identifier contains lei 0..1 MS and npi 0..1 MS and taxId 0..1
* identifier[lei].system = "https://www.gleif.org/lei" (exactly)
* identifier[lei].value 1..1 MS
* identifier[lei].use = #official
* identifier[lei].extension contains
OrgVleiAnchor named vleiAnchor 0..1 MS
Extension: OrgVleiAnchor
Id: org-vlei-anchor
Title: "Organization vLEI Anchor"
Description: "Pointer to the Legal Entity vLEI credential that verifies the LEI carried on this identifier slice. Verification is performed out of band via KERI. For healthcare exchange, at least one OOBI URL SHOULD resolve to an endpoint controlled by the organization itself, typically under /.well-known/vlei/oobi on the organization's primary domain."
* extension contains
aid 1..1 MS and
qvi 0..1 MS and
oobi 1..* MS
* extension[aid].value[x] only string
* extension[aid].value[x] ^short = "KERI Autonomic Identifier (AID) of the Legal Entity vLEI subject"
* extension[qvi].value[x] only Identifier
* extension[qvi].value[x] ^short = "LEI of the Qualified vLEI Issuer that issued the credential"
* extension[oobi].value[x] only url
* extension[oobi].value[x] ^short = "OOBI URL for KERI verification (organization-controlled .well-known endpoint preferred for healthcare)"
// Example
Instance: AcmeHealthOrganization
InstanceOf: FASTOrganization
Title: "Acme Health System"
Usage: #example
* name = "Acme Health System"
* identifier[lei].system = "https://www.gleif.org/lei"
* identifier[lei].value = "549300ABCD1234567890"
* identifier[lei].use = #official
* identifier[lei].extension[vleiAnchor].extension[aid].valueString = "EAbCdEfGhIjKlMnOpQrStUvWxYz0123456789AbCd"
* identifier[lei].extension[vleiAnchor].extension[qvi].valueIdentifier.system = "https://www.gleif.org/lei"
* identifier[lei].extension[vleiAnchor].extension[qvi].valueIdentifier.value = "9876543210ZYXWVUTSRQ"
// Primary OOBI: organization-controlled .well-known endpoint
* identifier[lei].extension[vleiAnchor].extension[oobi][0].valueUrl = "https://acmehealth.example.org/.well-known/vlei/oobi"
// Secondary OOBI (optional): witness operator endpoint, for resilience
* identifier[lei].extension[vleiAnchor].extension[oobi][+].valueUrl = "https://oobi.example-witness.org/oobi/EAbCd.../witness/BWit..."
The example LEI value shown above is illustrative; production LEIs are governed by GLEIF and conform to ISO 17442.
A central insight from the 9 April 2026 co-leads discussion is that delegation in healthcare is not primarily a patient → caregiver story; it is overwhelmingly an organization → individual / vendor / system story. This section profiles how an organization with a Legal Entity vLEI confers authority on an IAL2-assured individual, and how that delegation is conveyed to FHIR consumers.
The full delegation trust stack runs from the GLEIF root of trust to a specific transaction:
The IAL2 layer is independent of the vLEI: IAL2 establishes who the human is; the OOR/ECR establishes which organization that human is acting for, and in what capacity. Both are required for high-trust transactions; neither is a substitute for the other.
| Aspect | OOR (Official Organizational Role) | ECR (Engagement Context Role) |
|---|---|---|
| Role taxonomy | ISO 5009 (general-business roles: CEO, CFO, etc.) | Defined by the issuing organization for a specific context |
| Stability | Long-lived; tied to public corporate roles | Often time-bounded or scoped to a transaction class |
| Healthcare fit | Limited (few healthcare-specific roles in ISO 5009) | High — encodes "authorized for prior auth," "authorized for regulatory filing," "data exchange representative" |
| When to require | Board attestations, public regulatory filings, signed corporate disclosures | Day-to-day transactional authority across FHIR APIs, TEFCA exchange, payer-provider workflows |
For most FAST FHIR use cases, the ECR is the operative credential. OORs are useful for high-formality attestations.
The OOR/ECR credential binds the individual subject identifier (e.g., a KERI AID controlled by the individual, or another resolvable identifier) to the organization. The IAL2 identity proofing process — and the chosen identity provider — sit underneath this binding. This IG does not prescribe a specific IdP. It does require that:
FHIR profiling of the OOR/ECR-to-PractitionerRole mapping is companion guidance to this document and is referenced from the Practitioner and PractitionerRole profiles.
This guidance is intended to be layered on top of, not in conflict with, UDAP and the FAST Security IG. The vLEI does not displace UDAP's PKI-based client identity; it complements it by adding a legal entity layer beneath the existing endpoint / client layer.
UDAP today identifies an OAuth client by binding it to an X.509 certificate whose subject identifies the client and whose issuer is a trusted CA. The certificate establishes:
It does not by itself establish that the legal entity behind the client is who it claims to be globally. In a multi-network world (TEFCA, CMS Aligned Networks, payer-provider, vendor ecosystems), CA-rooted trust fragments along network boundaries.
A Legal Entity vLEI Credential, presented alongside or referenced from the X.509-based UDAP credential, anchors the client to a globally recognized legal entity under a single root of trust (GLEIF) that crosses network boundaries.
Two integration patterns are anticipated for FAST Security:
org-vlei-anchor extension on the corresponding Organization resource, or via a JWT claim) to confirm the legal entity. This is the lower-disruption path and is the expected near-term posture.A practical motivation for layering the vLEI under UDAP is that vLEI-based legal-entity identity is durable across trust boundaries and PKI lifecycle events in a way that X.509-based identity is not. (The educational framing of this point appears in §A.4.1; the security-engineering implications are summarized below.)
| Event | Effect on X.509 / UDAP identity | Effect on vLEI legal-entity identity |
|---|---|---|
| Joining a new network with a different CA trust list | Re-issue or re-cross-certify; re-register UDAP client | None — the vLEI is recognized by every ecosystem rooted in GLEIF |
| Certificate routine rotation (1–2 yr cycle) | Every artifact bound to the old cert subject/thumbprint must be updated | None — AID is stable; the KEL records the rotation, no downstream re-issuance |
| Key compromise / emergency rotation | Cert revoked; new cert issued; downstream systems must trust the new cert | KERI rotation event recorded in the KEL; AID and vLEI remain valid |
| CA distrust / root program change | All certs under that CA must be replaced; trust paths break until reissued | Verification path runs through GLEIF/KERI, not X.509 — unaffected |
| Organization changes its TLS provider | New cert from a different CA; counterparty trust must be re-established | None — vLEI is independent of the TLS provider |
| Organization changes its OAuth client implementation | New client_id, new software statement, new dynamic registration |
Same vLEI references the same legal entity; only the client-auth layer is rebuilt |
Operationally, this means the vLEI gives healthcare organizations an identity layer that outlives the certs and CAs underneath it. UDAP keeps doing what UDAP does well at the channel and client-auth layers; the vLEI provides continuity at the legal-entity layer. For long-lived FHIR exchange relationships — which is most of healthcare — that continuity is a substantial reduction in operational and audit burden.
When a relying party processes an OAuth/UDAP request:
| Layer | Question answered | Mechanism |
|---|---|---|
| TLS | Is the channel authentic and confidential? | Server X.509 cert |
| OAuth client auth | Which registered client is this? | UDAP / X.509 client cert / private_key_jwt |
| Legal entity | Which legal entity is behind this client? | Legal Entity vLEI |
| Acting individual | Which proofed person is making this request, and on whose behalf? | OOR / ECR + IAL2/AAL2 assertion |
| Authorization | What is this combination allowed to do? | Scopes, purpose-of-use, network policy |
Profiling each layer is the responsibility of the IG that owns it. The legal entity and acting individual layers are owned by FAST Identity (this IG); the client auth layer is owned by FAST Security; the TLS layer is owned by deployment guidance.
This section walks through five relationship patterns — the four flagged in the 9 April 2026 co-leads call (action item 10.A) plus an emerging Organization ↔ AI Agent pattern that healthcare implementations are encountering with increasing frequency — and shows how the LEI/vLEI profiling guidance applies to each. Every walkthrough follows the same template — Scenario, Parties, Identity needs, Credentials, FHIR conveyance, Decision (LEI / vLEI), Notes — so that implementers can compare patterns side-by-side.
A summary at the end (§B.8.6) consolidates the credential picture across all five.
Scenario. A licensed clinician practices at one or more healthcare organizations. A relying party — another provider, a payer, a network — needs to be confident both that the organization is who it claims to be and that this clinician is genuinely associated with it in a specific role.
Parties.
Identity needs.
Credentials required.
FHIR conveyance.
Organization profile (FAST) carrying the LEI in identifier[lei] and an org-vlei-anchor extension pointing to the Legal Entity vLEI.Practitioner profile carrying the provider's identifiers (NPI, etc.) and a reference (via FAST Identity companion guidance) to the OOR/ECR credential anchor.PractitionerRole linking Practitioner to Organization, with role/specialty coded as today, plus a verifiable-credential pointer that lets a relying party check the ECR.Decision. vLEI required for the organization in any transactional context (matrix rows 5–10). LEI alone is sufficient when only listing the organization in a directory or static reference data (rows 1–4).
Notes. This use case is the closest analogue to the existing FHIR Practitioner ↔ PractitionerRole ↔ Organization pattern. The vLEI does not invent new constructs; it adds verifiability to the join. A directory consumer that previously trusted the directory itself can now independently verify the organization and the provider-to-organization binding.
Scenario. A payer (health plan) engages a third-party vendor — for example, a clearinghouse, a prior authorization automation vendor, an analytics or quality-measurement vendor, or a UM partner — to act on the payer's behalf for a defined scope of work. The vendor's systems issue or receive FHIR transactions that must be attributable to the payer.
Parties.
Identity needs.
Credentials required.
FHIR conveyance.
Organization resources, each carrying its own LEI and vLEI anchor.Provenance.agent.onBehalfOf) referencing the payer Organization.Provenance is the natural FHIR carrier for "this assertion was made by X on behalf of Y" and SHOULD be used for transactions where attribution must survive later dispute (matrix row 10).Decision. vLEI required for both parties. The defining feature of this use case is delegation across legal-entity boundaries; the LEI alone cannot represent that delegation.
Notes. This is structurally an organization-to-organization delegation. The ECR pattern still applies — ECRs can be issued to a system or to a person at the delegated organization. The relying party's verification logic must walk both chains: the vendor's own vLEI (to know who the vendor is) and the ECR (to know what the payer authorized them to do).
Scenario. A healthcare organization outsources part of its IT stack — for example, EHR hosting, FHIR API publication, identity provider operation, or specific data services — to a technology vendor. The IT vendor operates the infrastructure, but the data steward and legal entity responsible is the healthcare organization. Relying parties making API calls need to know whose data they are actually receiving.
Parties.
Identity needs.
Credentials required.
FHIR conveyance.
Organization.identifier with the healthcare organization's LEI and the org-vlei-anchor extension, not the IT vendor's.managingOrganization pattern in FHIR (e.g., Patient.managingOrganization, Practitioner.qualification.issuer) continues to refer to the healthcare organization.Provenance.agent may carry both the IT vendor (as the operating agent) and the healthcare organization (as the legal-entity principal) when transactional attribution is required.Decision. vLEI required for both parties. The whole point of this use case is that endpoint trust (TLS / X.509) does not by itself answer "whose data is this?" — the vLEI does.
Notes. This is the use case where the failure mode of "endpoint trust ≠ entity trust" (§B.7.1) is most visible. Today, relying parties often infer the legal entity from the cert subject or the OAuth client name. With the vLEI, that inference becomes a verifiable claim. This pattern also generalizes to subcontracting chains (IT Vendor → Subcontractor) by issuing nested ECRs, though such chains should be kept short for auditability.
Scenario. An administrative staff member — a non-clinician — performs actions on behalf of an organization. Examples: a credentialing coordinator updates provider directory entries; a billing administrator submits claims attachments; a compliance officer signs a regulatory filing; a directory admin manages endpoint metadata.
Parties.
Identity needs.
Credentials required.
FHIR conveyance.
Practitioner (they are not delivering care). Options:
RelatedPerson is awkward; it is patient-anchored.Person resource linked into a workflow context is one possibility.Provenance.agent.who SHOULD reference whatever resource represents the delegate, with Provenance.agent.onBehalfOf referencing the Organization and a credential pointer to the ECR.Decision. vLEI required. Administrative actions on behalf of an organization are exactly the kind of "the relying party will want a cryptographic record of who actually made this assertion" use case the matrix is designed to flag.
Notes. This use case exposes a real FHIR gap: the platform's role-binding constructs are clinician-centric, but a large fraction of organizational accountability lives with non-clinical staff. The vLEI ECR mechanism does not solve that gap on its own, but it gives FAST Identity a clean mechanism for conveying authority outside the Practitioner graph, which can then be linked to whichever FHIR construct best represents the delegate.
Scenario. An AI agent — a software system that takes autonomous or semi-autonomous actions — operates on behalf of an organization. Examples include AI scribes that draft clinical documentation, prior-authorization automation agents that submit and respond to PA requests, claims-processing agents that prepare or adjudicate transactions, patient-communication agents, and orchestration agents that chain together multiple FHIR API calls to complete a workflow. The agent is not a human and cannot be IAL2-proofed, but every action it takes must be attributable to a specific agent identity and bound to the authorizing organization's accountability.
Parties.
Identity needs.
Credentials required.
FHIR conveyance.
Practitioner (it is not delivering care). Candidate FHIR carriers:
Device is the closest existing fit for a software agent acting in healthcare workflows; Device.identifier can carry the agent's AID and Device.owner can reference the Organization.Provenance.agent SHOULD record: agent.who referencing the agent's resource representation; agent.type (or an extension) distinguishing software / AI agents from human actors; agent.onBehalfOf referencing the Organization; and a pointer to the agent's ECR credential anchor.Provenance.agent MAY include both the AI agent and the responsible human, each with their own credential pointers — recording that the action was prepared by the agent and authorized by the human.Decision. vLEI required. The whole purpose of this use case is to make AI-agent actions attributable, scoped, and revocable. None of those properties is achievable with the LEI alone; all of them depend on a verifiable credential.
Notes. This use case is structurally similar to Org ↔ IT Vendor delegation (a non-human system actor authorized via ECR) but with three healthcare-specific tightening factors: (1) ECR scopes for AI agents SHOULD be narrower and more frequently revisited than for IT vendors, because agent capabilities and risk profiles evolve as models change; (2) provenance is mandatory, not optional — every regulated agent action SHOULD be recorded with full credential attribution, both for accountability and to enable later dispute resolution; and (3) agent ECRs SHOULD encode any oversight or human-co-sign requirements as part of the credential's scope, so that those requirements travel with the credential and are enforceable by any relying party. Agent-to-agent delegation chains MAY be expressed via nested ECRs (analogous to subcontracting in §B.8.3), but SHOULD be kept short for auditability.
| Aspect | Provider ↔ Organization | Payer ↔ Vendor | Org ↔ IT Vendor | Org ↔ Delegate | Org ↔ AI Agent |
|---|---|---|---|---|---|
| Number of legal entities | 1 (org) + 1 individual | 2 (payer, vendor) | 2 (org, IT vendor) | 1 (org) + 1 individual | 1 (org) + 1 software agent |
| Org-level credential | Legal Entity vLEI (org) | Legal Entity vLEI (both) | Legal Entity vLEI (both) | Legal Entity vLEI (org) | Legal Entity vLEI (org) |
| Person/system credential | ECR (clinical role) | ECR (transactional auth) | ECR (operational scope) | ECR (administrative scope) | ECR (scoped agent authority) + optional agent attestations |
| OOR plausible? | No (not in ISO 5009) | Rarely (e.g., signing officer) | Rarely | For a few signing roles | No (agent is not a natural person) |
| IAL2 individual involved? | Yes | Yes (often) | Sometimes (system actor possible) | Yes | Not for the agent itself; human IAL2 required for co-sign on regulated actions |
| Primary FHIR carrier | Practitioner + PractitionerRole |
Organization (×2) + Provenance |
Organization (×2) + Provenance |
Non-clinical agent + Provenance |
Device or non-clinical agent profile + Provenance |
| LEI sufficient anywhere? | Directory listings only | Directory listings only | Directory listings only | Directory listings only | Directory listings only |
| vLEI required for action? | Yes | Yes | Yes | Yes | Yes |
| Defining trust gap closed | Provider-to-org binding | Cross-entity delegation | Endpoint trust ≠ entity trust | Non-clinical accountability | Attribution and scoping of autonomous AI actions |
The pattern across all five is the same: LEI is enough for static reference; vLEI is required as soon as anyone — or anything — acts.
The following items are flagged for resolution before the LEI/vLEI guidance leaves draft status. They map back to action items 10.A–10.D from the 9 April 2026 co-leads call.
IDTYPE code. The canonical Organization.identifier.system URI for LEI is widely cited as https://www.gleif.org/lei; this should be confirmed against current GLEIF guidance and registered as appropriate.org-vlei-anchor extension shape (§B.5.2) is a working sketch and will be finalized in coordination with FAST Security.Person, Device, or a custom resource pattern) for non-clinical actors that do not fit Practitioner — both human administrative delegates and software / AI agents acting on behalf of an organization.Provenance to carry vLEI credential anchors for cross-entity delegation, IT-vendor scenarios, and AI-agent actions (including the multi-agent record needed when a regulated action requires human co-sign on top of an AI-prepared transaction).
IG © 2021+ HL7 International / Patient Administration.
Package hl7.fhir.us.identity-matching#3.0.0-current based on FHIR 4.0.1.
Generated
2026-08-20
Links: Table of Contents |
QA Report
| Version History |
|
Propose a change