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

## ToDo Home

Official URL: https://profiles.ihe.net/ITI/VHL/ImplementationGuide/ihe.iti.vhl | Version: 0.0.2-current
Draft as of 2026-02-09 | Computable Name: IHE_ITI_VHL

The Verifiable Health Link (VHL) profile defines protocols and patterns that allow the sharing of health documents in a auditable and verfiable manner within and across jurisdictional boundaries. The VHL profile describes mechanisms, the VHLs, that an individual, the VHL Holder, uses to provide authorize access to their health records from an issuer, the VHL Sharer, to a third party, the VHL Receiver. The means by which the VHL is held by the VHL Holder or shared by the VHL Holder to the VHL Receiver are beyond the scope of this profile.

Significant Changes, Open and Closed Issues

### Organization of This Guide

This guide is organized into the following sections:

1. Volume 1:
   1. Introduction
   2. Actors, Transactions, and Content
   3. Actor Options
   4. Actor Required Groupings
   5. Overview
   6. Security Considerations
   7. Cross Profile Considerations
   8. TODO: point to the Volume 1 Appendix if there is one
2. Volume 2: Transaction Detail
   1. Submit PKI Material with DID [ITI-YY1]
   2. Retrieve Trust List with DID [ITI-YY2]
   3. Generate VHL [ITI-YY3]
   4. Provide VHL [ITI-YY4]
   5. Retrieve Manifest [ITI-YY5]
   6. TODO: point to the Volume 2 Appendix if there is one
3. Volume 3: Metadata and Content
   1. Content Profiles
4. Volume 4: National Extensions
   1. TODO: point at the National Extensions if there are any
5. Other
   1. Test Plan
   2. Changes to Other IHE Specifications
   3. Download and Analysis

See also the Table of Contents and the index of Artifacts defined as part of this implementation guide.

### Conformance Expectations

IHE uses the normative words: Shall, Should, and May according to standards conventions.

#### Must Support

The use of `mustSupport` in StructureDefinition profiles equivalent to the IHE use of R2 as defined in Appendix Z.

mustSupport of true - only has a meaning on items that are minimal cardinality of zero (0), and applies only to the source actor populating the data. The source actor shall populate the elements marked with MustSupport, if the concept is supported by the actor, a value exists, and security and consent rules permit. The consuming actors should handle these elements being populated or being absent/empty. Note that sometimes mustSupport will appear on elements with a minimal cardinality greater than zero (0), this is due to inheritance from a less constrained profile.