Verifiable Health Link
0.0.2-current - ci-build
Verifiable Health Link
0.0.2-current - ci-build
Verifiable Health Link, published by IHE IT Infrastructure Technical Committee. This guide is not an authorized publication; it is the continuous build for version 0.0.2-current built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/IHE/ITI.VHL/ and changes regularly. See the Directory of published versions
As individuals move within or across jurisdictional boundaries, they may wish to provide access to clinical or other health-related documents to a defined set of trusted parties who are authorized to access their records. This access may be granted for a single document or for a set of related documents.
The Verifiable Health Link (VHL) profile defines a set of protocols and patterns that enable health documents to be shared in a verifiable and auditable manner—both within and across jurisdictions. Central to this profile is the concept of the VHL, a signed artifact that an individual (the VHL Holder) can use to authorize access to their health records from an issuer (the VHL Sharer) to a third party (the VHL Receiver). The mechanisms by which the VHL is held by the Holder or transmitted to the VHL Receiver are out of scope for this profile.
VHL leverages Public Key Infrastructure (PKI) to establish trust among actors and to verify the authenticity and integrity of exchanged artifacts.
Within the VHL trust model, both the VHL Receiver and the VHL Sharer are participants in a shared trust network. This network enables:
The authority to participate in the trust network is governed by each actor's jurisdiction, which determines eligibility and onboarding criteria. Verification of this authorization is achieved through PKI, specifically through the validation of credentials issued or endorsed by a Trust Anchor (Trust Anchor).
Jurisdictions may also impose specific regulatory requirements on the privacy and security of health data exchange. These may include mandatory consent verification, audit logging, or other compliance controls that impact how VHL-based exchanges are implemented.
As members of a trust network, both the VHL Receiver and the VHL Sharer are expected to submit and retrieve PKI material—typically as signed Trust Lists—from the Trust Anchor. The precise onboarding and credential issuance processes used to establish trust with the Trust Anchor are implementation-specific and beyond the scope of this profile.
Note on SMART Health Links (SHL):
VHLs and SMART® Health Links (SHLs) are conceptually related but rely on fundamentally different trust assumptions. In the VHL model, a pre-established trust relationship exists between the VHL Sharer and the VHL Receiver, verified via PKI material exchanged through Trust Lists. In contrast, SHL assumes no prior trust between the SHL Receiver and SHL Sharer. Instead, trust is conveyed at the time the SHL is presented, often using embedded JWS signatures and keys controlled by the SHL Sharer. See Appendix A for a more detailed comparison.
This section defines the actors, transactions, and/or content modules in this profile. Further information about actor and transaction definitions can be found in the IHE Technical Frameworks General Introduction Appendix A: Actors and Appendix B: Transactions.
As a pre-condition to transactions ITI-YY4 and ITI-YY5, the VHL Receiver and VHL Sharer must have established trust relationships enabling mutual authentication and VHL signature verification.
This trust MAY be established through:
This is illustrated in Figure X.X.X.X-1.
Figure X.X.X.X-1: Trust Network PKI Exchange
The process of a VHL Holder requesting a VHL for a set of health documents from a VHL Sharer and subsequently sharing them to a VHL Receiver is illustrated in Figure X.X.X.X-2.
Figure X.X.X.X-2: VHL Generation, Provision, and Document Retrieval Flow
Table XX.1-1: VHL Profile - Actors and Transactions
| Actors | Transactions | Initiator or Responder | Optionality | Reference |
|---|---|---|---|---|
| Trust Anchor | Submit PKI Material with DID | Responder | R | ITI TF-2: 3.YY1 |
| Retrieve Trust List with DID | Responder | R | ITI TF-2: 3.YY2 | |
| VHL Holder | Generate VHL | Initiator | R | ITI TF-2: 3.YY3 |
| Provide VHL | Initiator | R | ITI TF-2: 3.YY4 | |
| VHL Receiver | Submit PKI Material with DID | Initiator | O | ITI TF-2: 3.YY1 |
| Retrieve Trust List with DID | Initiator | O | ITI TF-2: 3.YY2 | |
| Provide VHL | Responder | R | ITI TF-2: 3.YY4 | |
| Retrieve Manifest | Initiator | R | ITI TF-2: 3.YY5 | |
| VHL Sharer | Submit PKI Material with DID | Initiator | O | ITI TF-2: 3.YY1 |
| Retrieve Trust List with DID | Initiator | O | ITI TF-2: 3.YY2 | |
| Generate VHL | Responder | R | ITI TF-2: 3.YY3 | |
| Retrieve Manifest | Responder | R | ITI TF-2: 3.YY5 |
The actors in this profile are described in more detail in the sections below.
An authorized organization in the trust framework that manages and distributes PKI material—such as public key certificates and revocation lists—to participants in the network. It ensures that this material is trustworthy and available, enabling VHL Sharers and VHL Receivers to verify digital signatures and authenticate the origin of shared data.
This actor fulfills the following requirements:
This actor fulfills the following capabilities:
CapabilityStatement for Trust Anchor Actor in the IHE IT Infrastructure Technical Framework Supplement IHE VHL. An authorized organization in the trust framework that manages and distributes PKI material—such as public key certificates and revocation lists—to participants in the network. It ensures that this material is trustworthy and available, enabling VHL Sharers and VHL Receivers to verify digital signatures and authenticate the origin of shared data.
An individual—typically the patient or their delegate—who possesses a Verified Health Link (VHL), a signed data artifact that enables a VHL Receiver to verify its authenticity and access one or more health documents made available by a VHL Sharer.
This actor fulfills the following requirements:
A system or organization that receives a Verified Health Link (VHL) from a VHL Holder and uses it to retrieve health documents from a VHL Sharer, after verifying the authenticity and integrity of the VHL.
This actor fulfills the following requirements:
The VHL Sharer generates a VHL, provides the VHL to a VHL Holder, and responds to requests from a VHL Sharer to utilize the VHL.
This actor fulfills the following requirements:
The transactions in this profile are summarized in the sections below.
This transaction is used by a VHL Receiver or VHL Sharer to submit PKI material to a Trust Anchor using Decentralized Identifiers (DIDs). The submitted material is formatted as DID Documents containing public keys and associated metadata for validation and inclusion in the Trust List.
Transaction Optionality:
This transaction is:
Alternative Implementations:
Actors that do not implement this transaction MUST establish trust relationships through jurisdiction-specific mechanisms that are out of scope for this profile.
For more details see the detailed transaction description
This transaction is captured as the following requirements:
This transaction is used by a VHL Receiver or VHL Sharer to retrieve a Trust List from a Trust Anchor containing DID Documents with PKI material. The retrieved DID Documents include public keys and metadata necessary for verifying digital signatures and establishing trust relationships. Received key material should be distinguished by the participating jurisdiction, use case context, and key usage.
Transaction Optionality:
This transaction is:
When to Implement:
VHL Sharer and VHL Receiver actors SHALL implement this transaction when:
Alternative Implementations:
Actors that do not implement this transaction MUST retrieve trust material through jurisdiction-specific mechanisms that are out of scope for this profile. Such implementations:
For more details see the detailed transaction description
This transaction is captured as the following requirements:
This transaction is used by a VHL Holder to request that a VHL Sharer generate a QR code containing a VHL. The QR code is encoded as an HCERT/CWT structure.
A VHL Sharer MAY:
For more details see the detailed transaction description
This transaction is captured as the following requirements:
This transaction is initiated by a VHL Holder to transmit a VHL to a VHL Receiver by displaying or providing a QR code for scanning.
QR Code Transmission:
The VHL Holder presents the VHL by:
The VHL Receiver scans the QR code using a camera-equipped device and processes the HCERT-encoded VHL through a 9-step decoding process:
For more details see the detailed transaction description
This transaction is captured as the following requirements:
This transaction is initiated by a VHL Receiver to retrieve a document manifest from a VHL Sharer using a previously validated VHL as authorization. The transaction uses standard FHIR search on the List resource, following the same pattern as MHD ITI-66 Find Document Lists.
Response:
The VHL Sharer returns a FHIR Bundle of type "searchset" containing:
_include parameter used)If the VHL Sharer supports the Include DocumentReference Option, it processes the _include=List:item parameter and returns both List and DocumentReference resources in a single response, reducing network round trips.
If the VHL Sharer does NOT support this option, it ignores the _include parameter and returns only the List resource. The VHL Receiver then retrieves individual DocumentReference resources using separate read requests.
Capability Statements:
Client and server requirements are defined in:
For more details see the detailed transaction description
This transaction is captured as the following requirements:
Options that may be selected for each actor in this implementation guide are listed in Table XX.2-1 below. Dependencies between options when applicable are specified in notes.
Table XX.2-1: Actor Options
| Actor | Option Name |
|---|---|
| VHL Receiver | Sign Manifest Request |
| ^ | Include DocumentReference |
| ^ | Verify Document Signature |
| ^ | OAuth with SSRAA |
| VHL Sharer | Include DocumentReference |
| ^ | Sign Manifest Request |
| ^ | OAuth with SSRAA |
The Sign Manifest Request Option enables the VHL Receiver to digitally sign manifest requests sent to the VHL Sharer and enables the VHL Sharer to verify digital signatures on manifest requests from the VHL Receiver.
This option provides:
Complementary Option: This option is designed to work with the Sign Manifest Request Option (VHL Sharer). If a VHL Receiver signs requests, the VHL Sharer should support signature verification.
See ITI-YY5 Section 2:3.YY5.4.1.2 for detailed signature format.
The Include DocumentReference Option enables the VHL Sharer to process the _include=List:item parameter in manifest requests and return DocumentReference resources along with the List resource in a single response.
Benefits:
Implementation Note: When generating VHLs in ITI-YY3, VHL Sharers supporting this option SHOULD include _include=List:item in the manifest URL. VHL Sharers not supporting this option SHOULD NOT include the _include parameter in the manifest URL.
See ITI-YY5 Section 2:3.YY5.4.1.3 for detailed behavior.
In this option the VHL Receiver, after receipt of a digitally signed document from a VHL Sharer, shall verify the digital signature using previously retrieved PKI material. This key material may or may not be distributed under the same trust network under which the VHL was distributed. This key material may or may not be the same key material that was used to verify the VHL.
See cross-profile considerations for a discussion of the relationship of this option to the IHE Document Signature profile.
This option is captured in the following business requirement:
The OAuth with SSRAA Option enables the VHL Receiver and VHL Sharer to use OAuth 2.0 access tokens for authentication during the ITI-YY5 Retrieve Manifest transaction, as an alternative to HTTP Message Signatures. This option provides interoperability with systems implementing the HL7 Security for Scalable Registration, Authentication, and Authorization IG (SSRAA).
Complementary Option: Both the VHL Receiver and VHL Sharer must support this option for OAuth-based authentication to be used. If only one actor supports this option, HTTP Message Signatures or other authentication mechanisms defined in ITI-YY5 SHALL be used instead.
See ITI-YY5 Section 2:3.YY5.4.1.4 for detailed OAuth flow and examples.
The following actor groupings are required for secure operations within the VHL trust network:
Table XX.3-1: VHL Profile - Required Actor Groupings
| VHL Actor | Grouping Condition | Actor(s) to be grouped with | Reference |
|---|---|---|---|
| VHL Receiver | Required for ITI-YY5 | ITI ATNA / Secure Node or Secure Application | ITI TF-1: 9.1 |
| VHL Sharer | Required for ITI-YY5 | ITI ATNA / Secure Node or Secure Application | ITI TF-1: 9.1 |
| Trust Anchor | – | None | – |
| VHL Holder | – | None | – |
Note: The VHL Receiver and VHL Sharer SHALL be grouped with ATNA Secure Node or Secure Application to support the secure channel requirements of the ITI-YY5 Retrieve Manifest transaction.
This section shows how the transactions/content modules of the profile are combined to address the use cases.
A Verifiable Health Link (VHL) is a mechanism that enables individuals to share access to health documents in a secure, auditable, and configurable manner. Sharing options may include limited-time access, PIN-protected retrieval, or ongoing access to a longitudinal dataset that may evolve over time. VHLs can be rendered as QR codes or downloaded to a user’s device, supporting patient-mediated data sharing and enhancing interoperability across healthcare systems.
The World Health Organization (WHO) operates the Global Digital Health Certification Network (GDHCN), a trust network for public-sector health jurisdictions. The GDHCN provides the infrastructure for the bilateral verification and utilization of Verifiable Digital Health Certificates across participating jurisdictions.
The GDHCN uses the notion of a Trust Domain which is defined by a set of:
How Trust is Established:
Trust in the GDHCN is established through a Public Key Infrastructure (PKI). Each participating jurisdiction submits its PKI material — including Signing Certificate Authority (SCA) certificates and Document Signer Certificates (DSCs) — to the WHO Trust Anchor through a formal onboarding process. The Trust Anchor publishes this key material in trust lists that other participants can retrieve and use to verify the digital signatures on health certificates.
DID-Based Trust List Distribution:
The GDHCN distributes trust lists using Decentralized Identifiers (DIDs). Each participating jurisdiction's key material is represented as a DID Document containing verification methods with the jurisdiction's public keys. These DID Documents are published as endpoints by the Trust Anchor, analogous to how the IHE mCSD Profile distributes service endpoints for Organizations. This enables participants to discover and retrieve the PKI material needed for signature verification through a standardized, cacheable, and federated mechanism.
Trust Network Gateway:
The GDHCN Trust Network Gateway (TNG) provides a federated architecture that enables multiple trust anchors and cross-gateway trust propagation. The TNG supports both an API gateway method and DID-based resolution for trust list distribution, ensuring interoperability across diverse jurisdictional implementations.
The PKI operated by the WHO supports a variety of trust domains, two of which — the Hajj Pilgrimage and the Pan-American Highway for Health — are described below.
Figure X.X.X.X-TN: WHO GDHCN Trust Network
This use case has the following business requirements:
During the Hajj pilgrimage, the Kingdom of Saudi Arabia (KSA) hosts approximately two million pilgrims from across the globe as part of a mass gathering event. Temporary hospitals and clinics, comprising over a thousand beds, are established to provide care to the pilgrims over the four-week period of Hajj.
Starting with Hajj 1445 AH (2024 CE), pilgrims from Oman, Malaysia, and Indonesia were able to share their health records utilizing the International Patient Summary (IPS) with verification of health documents provided through the WHO Global Digital Health Certification Network (GDHCN) infrastructure.
Key Features:
Some of the challenges faced during the pilot implementation, though not necessarily to be taken up in this profile, include:
This use case has the following business requirement:
In the region of the Americas, "countries identified several priorities for cross-border digital
health, including optimizing available human resources through international telehealth, validating digital certificates, ensuring continuity of care, and regional resilience to face health emergencies by sharing data for public health. During the IDB-PAHO co-led event, RELACSIS 4.0.1 a plan was launched to strengthen regional digital health services and resilience, through regional data exchange and policy harmonization. Sixteen countries successfully exchanged digital vaccine certificates (COVID-19, Polio, Measles, and Yellow Fever) and critical clinical information (diagnosis, allergy, and prescription information) using international standards during the 2nd Regional LACPASS Connectathon.2 Regional bodies and network such as the Council of Ministers of Health of Central America and the Dominican Republic (COMISCA), The Caribbean Public Health Agency (CARPHA), and the LAC Digital Health Network (RACSEL) have all identified cross-border data sharing as a priority."
footnote
The Pan American Health Organization (PAHO) and the InterAmerican Development Bank (IADB) are supporting the development of policies and digital infrastructrue to support this need. One particular priority is to improve the continuity of care for internal migrants within the region, by ensuring individuals have access to and can share their vaccination records and the International Patient Summary.
The Pan-American Highway for Health (PH4H) "aims to provide patients with better healthcare services, regardless of their location. It will also enhance healthcare for those who move temporarily for work or study, as well as for migrants, by enabling them to share their health history, thus improving their employability and access to education. "
footnote
While there currently there is no single legal framework that broadly enables data sharing across the region, there are sub-regional networks (e.g. COMISCA, CARPHA) that have policies that can be leveraged in the short term while necessary data sharing agreements are developed. Thus, individuals in this region will need to be able to move through overlapping trust networks.
This use case has the following business requirement:
The European Vaccination Card (EVC) is a citizen-held card to foster informed decision-making on vaccination, and improve continuity of care across the EU.
The EVC will allow "Member States to bilaterally verify the authenticity of digital records through an interoperable trust architecture. While similar to the EU Digital COVID Certificate in being a portable vaccination record, the EVC serves a different purpose. Unlike the certificate, which often fulfilled legal or health mandates, the EVC is specifically designed to empower individuals by granting them control over their vaccination information. This empowerment is crucial for ensuring continuity of care for those crossing borders or transitioning between healthcare systems."
The EVC will operate in the context of the European Health Data Spaces that requires detailed information on access the health data to be recorded.
Figure X.X.X.X-8: European Health Data Spaces
For more information see Regulation (EU) 2025/327 of the European Parliament and of the Council of 11 February 2025 on the European Health Data Space and amending Directive 2011/24/EU and Regulation (EU) 2024/2847. Specifically:
A critical privacy requirement for the EVC is unlinkability: Article 5a(16) of Regulation (EU) No 910/2014 as amended Article 5a(16): The technical framework of the European Digital Identity Wallet shall:
(a) not allow providers of electronic attestations of attributes or any other party, after the issuance of the attestation of attributes, to obtain data that allows transactions or user behaviour to be tracked, linked or correlated, or knowledge of transactions or user behaviour to be otherwise obtained, unless explicitly authorised by the user;
(b) enable privacy preserving techniques which ensure unlinkability, where the attestation of attributes does not require the identification of the user.
This use case has the following business requirement:
The Trusted Exchange Framework and Common Agreement (TEFCA) is a United States initiative established by the Office of the National Coordinator for Health IT (ONC) and operated by the Sequoia Project as the Recognized Coordinating Entity (RCE). TEFCA provides a single on-ramp for nationwide health information exchange by establishing a common set of principles, terms, and conditions that enable nationwide interoperability.
Under TEFCA, Qualified Health Information Networks (QHINs) serve as the primary exchange intermediaries, facilitating data sharing among Health Information Networks (HINs), healthcare providers, payers, and public health agencies. Each QHIN must meet rigorous security, privacy, and technical requirements to participate in the TEFCA ecosystem.
Relevance to VHL:
TEFCA's trust model aligns with the VHL profile's trust network architecture. In the context of VHL:
OAuth with SSRAA Option:
Organizations already using OAuth with UDAP (via the HL7 SSRAA IG) can leverage VHL for health record sharing without additional authentication infrastructure. TEFCA participants, for example, can use their existing TEFCA-issued X.509 certificates and UDAP Dynamic Client Registration to authenticate VHL exchanges, enabling seamless interoperability within established national-scale health information networks.
This use case has the following business requirements:
VHL is a building block that is meant to be used together with added security measures, otherwise it is not suitable for exchange in environments where security and provenance cannot be reliably established by other means.
Key security considerations include:
This section is informative, not normative. It is intended to put this profile in context with other profiles. Any required groupings should have already been described above.
The VHL Receiver and VHL Sharer SHALL be grouped with ATNA Secure Node or Secure Application actors to support the secure channel requirements of ITI-YY5. This grouping ensures:
When the VHL Sharer implements the Record Consent option, it acts as a Consent Recorder and initiates Access Consent [ITI-108] transactions to record consent declarations by the VHL Holder.
ITI-YY5 (Retrieve Manifest) follows patterns similar to MHD transactions:
The Trust Anchor may store DID (Decentralized Identifier) as endpoints for Jurisdictions. The mCSD Profile supports querying for Endpoint(s) for Organizations.
The Verify Document Signature option enables VHL Receiver to verify digital signatures on retrieved documents. This may use:
The key material used for document signature verification may or may not be the same as the key material used to verify the VHL itself, and may or may not be distributed under the same trust network.
IG © 2024+ IHE IT Infrastructure Technical Committee. Package ihe.iti.vhl#0.0.2-current based on FHIR 4.0.1. Generated 2026-03-13
Links: Table of Contents |
QA Report
| New Issue | Issues
Version History |
|
Propose a change