# 1:XX Verifiable Health Links (VHL) - Volume 1 - Verifiable Health Link v0.0.2-current

* [**Table of Contents**](toc.md)
* **1:XX Verifiable Health Links (VHL) - Volume 1**

## 1:XX Verifiable Health Links (VHL) - Volume 1

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](ActorDefinition-VHLSharer.md)) to a third party (the [VHL Receiver](ActorDefinition-VHLReceiver.md)). The mechanisms by which the VHL is held by the Holder or transmitted to the [VHL Receiver](ActorDefinition-VHLReceiver.md) 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](ActorDefinition-VHLReceiver.md) and the [VHL Sharer](ActorDefinition-VHLSharer.md) are participants in a shared **[trust network](other.md#ihe-technical-frameworks-general-introduction-appendix-d-glossary)**. This network enables:

* Verification of the origin of a health document,
* Validation of any access mechanism (i.e., the VHL itself),
* Authentication of requests that seek to utilize these mechanisms.

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](ActorDefinition-TrustAnchor.md)).

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](ActorDefinition-VHLReceiver.md) and the [VHL Sharer](ActorDefinition-VHLSharer.md) are expected to submit and retrieve PKI material—typically as signed **Trust Lists**—from the [Trust Anchor](ActorDefinition-TrustAnchor.md). The precise onboarding and credential issuance processes used to establish trust with the [Trust Anchor](ActorDefinition-TrustAnchor.md) 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](ActorDefinition-VHLSharer.md) and the [VHL Receiver](ActorDefinition-VHLReceiver.md), 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](vhl_vs_shl.md) for a more detailed comparison.

## 1:X.1 Actors, Transactions, and Content Modules

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](https://profiles.ihe.net/GeneralIntro/ch-A.html) and [Appendix B: Transactions](https://profiles.ihe.net/GeneralIntro/ch-B.html).

*  Actors 
* [Trust Anchor](ActorDefinition-TrustAnchor.md)
* [VHL Holder](ActorDefinition-VHLHolder.md)
* [VHL Receiver](ActorDefinition-VHLReceiver.md)
* [VHL Sharer](ActorDefinition-VHLSharer.md)
 
*  Transactions 
*  [Submit PKI Material with DID](ITI-YY1.md)
*  [Retrieve Trust List with DID](ITI-YY2.md)
*  [Generate VHL](ITI-YY3.md) 
*  [Provide VHL](ITI-YY4.md)
*  [Retrieve Manifest](ITI-YY5.md)
 

As a pre-condition to transactions ITI-YY4 and ITI-YY5, the [VHL Receiver](ActorDefinition-VHLReceiver.md) and [VHL Sharer](ActorDefinition-VHLSharer.md) must have established trust relationships enabling mutual authentication and VHL signature verification.

This trust MAY be established through:

* Implementation of the optional Submit PKI Material with DID [ITI-YY1] and Retrieve Trust List with DID [ITI-YY2] transactions, OR
* Alternative jurisdiction-specific PKI exchange mechanisms (out of scope for this profile)

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](ActorDefinition-VHLSharer.md) and subsequently sharing them to a [VHL Receiver](ActorDefinition-VHLReceiver.md) 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

| | | | | |
| :--- | :--- | :--- | :--- | :--- |
| [Trust Anchor](ActorDefinition-TrustAnchor.md) | [Submit PKI Material with DID](ITI-YY1.md) | Responder | R | ITI TF-2: 3.YY1 |
|   | [Retrieve Trust List with DID](ITI-YY2.md) | Responder | R | ITI TF-2: 3.YY2 |
| [VHL Holder](ActorDefinition-VHLHolder.md) | [Generate VHL](ITI-YY3.md) | Initiator | R | ITI TF-2: 3.YY3 |
|   | [Provide VHL](ITI-YY4.md) | Initiator | R | ITI TF-2: 3.YY4 |
| [VHL Receiver](ActorDefinition-VHLReceiver.md) | [Submit PKI Material with DID](ITI-YY1.md) | Initiator | O | ITI TF-2: 3.YY1 |
|   | [Retrieve Trust List with DID](ITI-YY2.md) | Initiator | O | ITI TF-2: 3.YY2 |
|   | [Provide VHL](ITI-YY4.md) | Responder | R | ITI TF-2: 3.YY4 |
|   | [Retrieve Manifest](ITI-YY5.md) | Initiator | R | ITI TF-2: 3.YY5 |
| [VHL Sharer](ActorDefinition-VHLSharer.md) | [Submit PKI Material with DID](ITI-YY1.md) | Initiator | O | ITI TF-2: 3.YY1 |
|   | [Retrieve Trust List with DID](ITI-YY2.md) | Initiator | O | ITI TF-2: 3.YY2 |
|   | [Generate VHL](ITI-YY3.md) | Responder | R | ITI TF-2: 3.YY3 |
|   | [Retrieve Manifest](ITI-YY5.md) | Responder | R | ITI TF-2: 3.YY5 |

### XX.1.1 Actors

The actors in this profile are described in more detail in the sections below.

#### XX.1.1.X Trust Anchor

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:

*  **[Retrieve Trust List Response](Requirements-RespondtoRetrieveTrustListRequest.md)** 
*  **[Respond to Submit PKI Material Request](Requirements-RespondtoSubmitPKIMaterialRequest.md)** 

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.

#### XX.1.1.X VHL Holder

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:

*  **[Request that a VHL authorization mechanism be issued](Requirements-InitiateVHLGenerationRequest.md)** 
*  **[Provide VHL](Requirements-ProvideVHL.md)** 

#### XX.1.1.X VHL Receiver

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:

*  **[Audit Event - Received Health Data](Requirements-AuditEventReceived.md)** 
*  **[Create Secure Channel](Requirements-CreateSecureChannel.md)** 
*  **[Establish Trust](Requirements-EstablishTrust.md)** 
*  **[Initiate Retrieve Trust List Request](Requirements-InitiateRetrieveTrustListRequest.md)** 
*  **[Initiate Submit PKI Material Request](Requirements-InitiateSubmitPKIMaterialRequest.md)** 
*  **[Receive Trust List](Requirements-ReceiveTrustList.md)** 
*  **[Request VHL Document](Requirements-RequestVHLDocument.md)** 
*  **[Request VHL Documents](Requirements-RequestVHLDocuments.md)** 
*  **[Receive VHL authorization mechanism](Requirements-RespondtoProvideVHL.md)** 
*  **[Verify Document Signature](Requirements-VerifyDocumentSignature.md)** 

#### XX.1.1.X VHL Sharer

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:

*  **[Audit Event - Accessed Health Data](Requirements-AuditEventAccess.md)** 
*  **[Create Secure Channel](Requirements-CreateSecureChannel.md)** 
*  **[Establish Trust](Requirements-EstablishTrust.md)** 
*  **[Initiate Retrieve Trust List Request](Requirements-InitiateRetrieveTrustListRequest.md)** 
*  **[Initiate Submit PKI Material Request](Requirements-InitiateSubmitPKIMaterialRequest.md)** 
*  **[Receive Trust List](Requirements-ReceiveTrustList.md)** 
*  **[Record Access to Health Data](Requirements-RecordAccessToHealthData.md)** 
*  **[Record Consent](Requirements-RecordConsent.md)** 
*  **[Generate a VHL Authorization Mechanism Based on Query Parameters](Requirements-RespondtoGenerateVHLRequest.md)** 

### XX.1.2 Transaction Descriptions

The transactions in this profile are summarized in the sections below.

#### XX.1.2.1 Submit PKI Material with DID [ITI-YY1]

This transaction is used by a [VHL Receiver](ActorDefinition-VHLReceiver.md) or [VHL Sharer](ActorDefinition-VHLSharer.md) to submit PKI material to a [Trust Anchor](ActorDefinition-TrustAnchor.md) 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:

* **REQUIRED (R)** for Trust Anchor actors
* **OPTIONAL (O)** for VHL Sharer and VHL Receiver actors

**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](ITI-YY1.md)

This transaction is captured as the following requirements:

* [Initiate Submit PKI Material Request](Requirements-InitiateSubmitPKIMaterialRequest.md)
* [Respond to Submit PKI Material Request](Requirements-RespondtoSubmitPKIMaterialRequest.md)

#### XX.1.2.2 Retrieve Trust List with DID [ITI-YY2]

This transaction is used by a [VHL Receiver](ActorDefinition-VHLReceiver.md) or [VHL Sharer](ActorDefinition-VHLSharer.md) to retrieve a Trust List from a [Trust Anchor](ActorDefinition-TrustAnchor.md) 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:

* **REQUIRED (R)** for Trust Anchor actors
* **OPTIONAL (O)** for VHL Sharer and VHL Receiver actors

**When to Implement:**

VHL Sharer and VHL Receiver actors SHALL implement this transaction when:

* They do not have pre-established mechanisms to retrieve PKI material from the [Trust Anchor](ActorDefinition-TrustAnchor.md), OR
* They wish to demonstrate interoperability at IHE Connectathons

**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:

* Cannot participate in IHE Connectathon testing for trust material retrieval
* Must document their trust material retrieval mechanisms in their IHE Integration Statement
* Are responsible for obtaining current PKI material for VHL signature verification

For more details see the detailed [transaction description](ITI-YY2.md)

This transaction is captured as the following requirements:

* [Initiate Retrieve Trust List Request](Requirements-InitiateRetrieveTrustListRequest.md)
* [Respond to Retrieve Trust List Request](Requirements-RespondtoRetrieveTrustListRequest.md)

#### XX.1.2.3 Generate VHL [ITI-YY3]

This transaction is used by a [VHL Holder](ActorDefinition-VHLHolder.md) to request that a [VHL Sharer](ActorDefinition-VHLSharer.md) generate a QR code containing a VHL. The QR code is encoded as an HCERT/CWT structure.

A [VHL Sharer](ActorDefinition-VHLSharer.md) MAY:

* Record consent of the individual
* Create audit trail of VHL creation
* Set passcode protection (P flag) with secure hash storage
* Set expiration time for time-limited access
* Set long-term flag (L) for ongoing access

For more details see the detailed [transaction description](ITI-YY3.md)

This transaction is captured as the following requirements:

* [Initiate VHL Generation Request](Requirements-InitiateVHLGenerationRequest.md)
* [Respond to VHL Generation Request](Requirements-RespondtoGenerateVHLRequest.md)

#### XX.1.2.4 Provide VHL [ITI-YY4]

This transaction is initiated by a [VHL Holder](ActorDefinition-VHLHolder.md) to transmit a VHL to a [VHL Receiver](ActorDefinition-VHLReceiver.md) by displaying or providing a QR code for scanning.

**QR Code Transmission:**

The [VHL Holder](ActorDefinition-VHLHolder.md) presents the VHL by:

* Displaying the QR code on their device screen for the [VHL Receiver](ActorDefinition-VHLReceiver.md) to scan, OR
* Providing a printed QR code generated during ITI-YY3

The [VHL Receiver](ActorDefinition-VHLReceiver.md) 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](ITI-YY4.md)

This transaction is captured as the following requirements:

* [Provide VHL](Requirements-ProvideVHL.md)
* [Respond to Provide VHL](Requirements-RespondtoProvideVHL.md)

#### XX.1.2.5 Retrieve Manifest [ITI-YY5]

This transaction is initiated by a [VHL Receiver](ActorDefinition-VHLReceiver.md) to retrieve a document manifest from a [VHL Sharer](ActorDefinition-VHLSharer.md) 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](ActorDefinition-VHLSharer.md) returns a FHIR Bundle of type "searchset" containing:

* **List resource** with search.mode="match" - references available documents
* **DocumentReference resources** with search.mode="include" (if Include DocumentReference Option supported and `_include` parameter used)

If the [VHL Sharer](ActorDefinition-VHLSharer.md) 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](ActorDefinition-VHLSharer.md) does NOT support this option, it ignores the `_include` parameter and returns only the List resource. The [VHL Receiver](ActorDefinition-VHLReceiver.md) then retrieves individual DocumentReference resources using separate read requests.

**Capability Statements:**

Client and server requirements are defined in:

* [VHL Receiver Client Capability Statement](CapabilityStatement-VHLReceiverCapabilityStatement.md)
* [VHL Sharer Server Capability Statement](CapabilityStatement-VHLSharerCapabilityStatement.md)

For more details see the detailed [transaction description](ITI-YY5.md)

This transaction is captured as the following requirements:

* [Request VHL Documents](Requirements-RequestVHLDocuments.md)

## XX.2 Actor Options

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

| | |
| :--- | :--- |
| [VHL Receiver](ActorDefinition-VHLReceiver.md) | Sign Manifest Request |
| ^ | Include DocumentReference |
| ^ | Verify Document Signature |
| ^ | OAuth with SSRAA |
| [VHL Sharer](ActorDefinition-VHLSharer.md) | Include DocumentReference |
| ^ | Sign Manifest Request |
| ^ | OAuth with SSRAA |

### XX.2.1 Sign Manifest Request Option (VHL Receiver)

The Sign Manifest Request Option enables the [VHL Receiver](ActorDefinition-VHLReceiver.md) to digitally sign manifest requests sent to the [VHL Sharer](ActorDefinition-VHLSharer.md) and enables the [VHL Sharer](ActorDefinition-VHLSharer.md) to verify digital signatures on manifest requests from the [VHL Receiver](ActorDefinition-VHLReceiver.md).

This option provides:

* Mutual authentication between VHL Receiver and VHL Sharer
* Non-repudiation of manifest requests
* Protection against request forgery
* Enhanced audit trail

**Complementary Option:** This option is designed to work with the Sign Manifest Request Option (VHL Sharer). If a [VHL Receiver](ActorDefinition-VHLReceiver.md) signs requests, the [VHL Sharer](ActorDefinition-VHLSharer.md) should support signature verification.

See ITI-YY5 Section 2:3.YY5.4.1.2 for detailed signature format.

### XX.2.2 Include DocumentReference Option (VHL Sharer)

The Include DocumentReference Option enables the [VHL Sharer](ActorDefinition-VHLSharer.md) to process the `_include=List:item` parameter in manifest requests and return DocumentReference resources along with the List resource in a single response.

**Benefits:**

* Reduces network round trips for VHL Receiver
* Improves performance for document discovery
* Simplifies workflow for retrieving document metadata

**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.

### XX.2.3 Verify Document Signature Option (VHL Receiver)

In this option the [VHL Receiver](ActorDefinition-VHLReceiver.md), after receipt of a digitally signed document from a [VHL Sharer](ActorDefinition-VHLSharer.md), 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:

* [Verify Document Signature](Requirements-VerifyDocumentSignature.md)

### XX.2.4 OAuth with SSRAA Option

The OAuth with SSRAA Option enables the [VHL Receiver](ActorDefinition-VHLReceiver.md) and [VHL Sharer](ActorDefinition-VHLSharer.md) 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](http://hl7.org/fhir/us/udap-security/) (SSRAA).

**Complementary Option:** Both the [VHL Receiver](ActorDefinition-VHLReceiver.md) and [VHL Sharer](ActorDefinition-VHLSharer.md) 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.

## XX.3 Required Actor Groupings

The following actor groupings are required for secure operations within the VHL trust network:

Table XX.3-1: VHL Profile - Required Actor Groupings

| | | | |
| :--- | :--- | :--- | :--- |
| [VHL Receiver](ActorDefinition-VHLReceiver.md) | Required for ITI-YY5 | ITI ATNA / Secure Node or Secure Application | ITI TF-1: 9.1 |
| [VHL Sharer](ActorDefinition-VHLSharer.md) | Required for ITI-YY5 | ITI ATNA / Secure Node or Secure Application | ITI TF-1: 9.1 |
| [Trust Anchor](ActorDefinition-TrustAnchor.md) | – | None | – |
| [VHL Holder](ActorDefinition-VHLHolder.md) | – | None | – |

Note: The [VHL Receiver](ActorDefinition-VHLReceiver.md) and [VHL Sharer](ActorDefinition-VHLSharer.md) SHALL be grouped with ATNA Secure Node or Secure Application to support the secure channel requirements of the ITI-YY5 Retrieve Manifest transaction.

## XX.4 Overview

This section shows how the transactions/content modules of the profile are combined to address the use cases.

### XX.4.1 Concepts

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.

#### XX.4.2 Use Cases

#### XX.4.2.1 Use Case #1: WHO Global Digital Health Certification Network

The World Health Organization (WHO) operates the [Global Digital Health Certification Network (GDHCN)](https://smart.who.int/trust), 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:

* use cases and business processes related to the utilization of Verifiable Digital Health Certificates
* open, interoperable technical specifications that define the applicable Trusted Services and verifiable digital health certificates for the use case
* policy and regulatory standards describing expected behavior of participants for the use case

**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)](https://www.w3.org/TR/did-core/). 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](https://profiles.ihe.net/ITI/mCSD/) 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:

* [Establish Trust](Requirements-EstablishTrust.md)
* [Initiate Submit PKI Material Request](Requirements-InitiateSubmitPKIMaterialRequest.md)
* [Initiate Retrieve Trust List Request](Requirements-InitiateRetrieveTrustListRequest.md)

##### XX.4.2.1.1 Hajj Pilgrimage Use Case Description

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:

* Trust established through WHO GDHCN trust network
* Multi-country interoperability (Oman, Malaysia, Indonesia to KSA)
* IPS-based continuity of care
* Consent captured and enforced through IPS Advanced Directives
* PIN protection for additional security on printed cards
* Support for both physical and digital VHL provisioning

Some of the challenges faced during the pilot implementation, though not necessarily to be taken up in this profile, include:

* while not the main point of security, leveraging the PIN is a weakness, need to enable better options for future consideration (e.g. biometrics, other authorization methods)
* in planning for expansion to umrah and general tourism, there will not in general be a health check which presents some process challenges such as not having a encounter point to record consent prior to a visit
* how to scale and automate some of the health checks (e.g. are vaccinations sufficient) using verifiable health documents (e.g. the IPS).

This use case has the following business requirement:

* [Establish Trust](Requirements-EstablishTrust.md)
* [Create Trusted Channel](Requirements-CreateTrustedChannel.md)

##### XX.4.2.1.2 Pan-American Highway for Health Use Case Description

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](https://ewsdata.rightsindevelopment.org/files/documents/46/IADB-RG-T4546_BBZnmFh.pdf)

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](https://ewsdata.rightsindevelopment.org/files/documents/46/IADB-RG-T4546_BBZnmFh.pdf)

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:

* [Establish Trust](Requirements-EstablishTrust.md)

#### XX.4.2.2 Use Case #2: EU Vaccination Card

The [European Vaccination Card (EVC)](https://euvabeco.eu/news/european-vaccination-card-evc-a-citizen-held-card-to-foster-informed-decision-making-on-vaccination-and-improve-continuity-of-care-across-the-eu/) 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:

* [ANNEX II - Essential requirements for the harmonised software components of EHR systems and for products for which interoperability with EHR systems has been claimed](https://eur-lex.europa.eu/eli/reg/2025/327/oj#anx_II)
* [Article 9 - Right to obtain information on accessing data](https://eur-lex.europa.eu/eli/reg/2025/327/oj#art_9)

A critical privacy requirement for the EVC is unlinkability: Article 5a(16) of [Regulation (EU) No 910/2014 as amended](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A02014R0910-20241018) **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:

* [Record Access To Health Data](Requirements-RecordAccessToHealthData.md)

#### XX.4.2.3 Use Case #3: US Trusted Exchange Framework and Common Agreement (TEFCA)

The [Trusted Exchange Framework and Common Agreement (TEFCA)](https://www.healthit.gov/topic/interoperability/policy/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:

* QHINs and their participants can act as VHL Sharers and VHL Receivers within the TEFCA trust framework
* TEFCA's credential and certificate management infrastructure can serve as a trust anchor for VHL exchanges
* The individual (patient) retains control over sharing their health records via VHL, consistent with TEFCA's patient access principles

**OAuth with SSRAA Option:**

Organizations already using OAuth with UDAP (via the [HL7 SSRAA IG](http://hl7.org/fhir/us/udap-security/)) 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:

* [Establish Trust](Requirements-EstablishTrust.md)
* [Create Secure Channel](Requirements-CreateSecureChannel.md)
* [Request VHL Documents](Requirements-RequestVHLDocuments.md)

## XX.5 Security Considerations

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:

### XX.5.1 Trust Network Security

* All participants ([VHL Receiver](ActorDefinition-VHLReceiver.md), [VHL Sharer](ActorDefinition-VHLSharer.md)) must establish trust via the [Trust Anchor](ActorDefinition-TrustAnchor.md) using ITI-YY1 (Submit PKI Material) and ITI-YY2 (Retrieve Trust List) transactions.
* PKI material must be validated before use in signature verification or secure channel establishment.
* Certificates and keys should be regularly updated and revocation status checked.

### XX.5.2 Secure Channel Requirements

* ITI-YY5 (Retrieve Manifest) SHALL be conducted over a secure channel as defined by ATNA Authenticate Node [ITI-19].
* Both [VHL Receiver](ActorDefinition-VHLReceiver.md) and [VHL Sharer](ActorDefinition-VHLSharer.md) SHALL present credentials validated against the [Trust Anchor](ActorDefinition-TrustAnchor.md).
* Mutual authentication is required for all document retrieval operations.

### XX.5.3 VHL Integrity and Authorization

* VHL signatures must be verified before trusting VHL content.
* VHL expiration timestamps should be enforced.
* Passcodes (if used) should be communicated out-of-band and validated server-side.
* VHL Sharers should implement rate limiting and account lockout for failed passcode attempts.

### XX.5.4 Audit Requirements

* The European Health Data Space (EHDS) requires detailed audit information on data access.
* Provisions 8f) and 12a) outline requirements for auditability of data access.
* VHL Sharers and VHL Receivers should record audit events documenting: 
* VHL generation requests
* VHL provision events
* Document retrieval attempts
* Authentication/authorization failures
 

### XX.5.5 Privacy Considerations

* VHL payloads do not contain PHI - only references to documents.
* Actual health data is transmitted over secure channels (ITI-YY5).
* Consent may be recorded during VHL generation (Record Consent option).
* VHL Holders retain the right to revoke access where supported.

## XX.6 Cross-Profile Considerations

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.

### XX.6.1 ATNA - Audit Trail and Node Authentication

The [VHL Receiver](ActorDefinition-VHLReceiver.md) and [VHL Sharer](ActorDefinition-VHLSharer.md) SHALL be grouped with ATNA Secure Node or Secure Application actors to support the secure channel requirements of ITI-YY5. This grouping ensures:

* Mutual authentication via X.509 certificates or other ATNA-supported mechanisms
* Secure channel establishment per ATNA Authenticate Node [ITI-19]
* Audit logging capabilities for security events

### XX.6.2 PCF - Privacy Consent on FHIR

When the [VHL Sharer](ActorDefinition-VHLSharer.md) 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](ActorDefinition-VHLHolder.md).

### XX.6.3 MHD - Mobile Health Document Sharing

ITI-YY5 (Retrieve Manifest) follows patterns similar to MHD transactions:

* Returns FHIR Bundle (searchset) with DocumentReference resources, similar to MHD ITI-67
* Document retrieval patterns could be extended to align with MHD ITI-68

### XX.6.4 mCSD - Mobile Care Services Discovery

The [Trust Anchor](ActorDefinition-TrustAnchor.md) may store DID (Decentralized Identifier) as endpoints for Jurisdictions. The mCSD Profile supports querying for Endpoint(s) for Organizations.

### XX.6.5 DSG/DSGj - Document Digital Signature

The Verify Document Signature option enables [VHL Receiver](ActorDefinition-VHLReceiver.md) to verify digital signatures on retrieved documents. This may use:

* DSG (Document Digital Signature) profile for XML-based documents
* DSGj (JSON Document Signature) profile for JSON-based documents

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.

