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
Contents:
This page provides a list of the FHIR artifacts defined as part of this implementation guide.
The following artifacts define the types of individuals and/or systems that will interact as part of the use cases covered by this implementation guide.
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. |
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. |
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. |
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. |
The following artifacts describe the specific requirements to be met by systems compliant with the implementation guide.
Accept mTLS |
The VHL Sharer, when acting as a server in a Verified Health Link (VHL) transaction, SHALL accept a mutually authenticated TLS (mTLS) connection initiated by a VHL Receiver. During the TLS handshake, the Sharer SHALL:
Successful completion of the mTLS handshake is a prerequisite for all VHL operations involving sensitive data exchange. This requirement refines the bilateral obligations described in Create Trusted Channel. |
Audit Event - Accessed Health Data |
Purpose: Description:
|
Audit Event - Received Health Data |
Purpose: Description:
|
Create Trusted Channel |
The VHL Sharer and VHL Receiver SHALL jointly establish a mutually authenticated TLS (mTLS) connection prior to executing any Verified Health Link (VHL) transactions involving the exchange of sensitive data. This requirement entails:
Establishing this trusted channel ensures confidentiality, integrity, and bilateral authentication of all subsequent communications, and fulfills the trust obligations defined in the Establish Trust requirement. |
Distribute PKI Material |
Upon receipt of public key material from a VHL Sharer or VHL Receiver, the Trust Anchor SHALL validate, organize, sign, and expose the PKI material as part of a trusted, canonical trust list. This signed trust list enables all participants in the VHL trust network to verify digital signatures and establish secure connections in accordance with the governance policies of the Trust Anchor. |
Establish Trust |
Before participating in any Verified Health Link (VHL) transactions, the VHL Sharer and VHL Receiver SHALL establish a trust relationship based on shared acceptance of a designated Trust Anchor. Trust is established by referencing and accepting public key material published and distributed in accordance with this specification (e.g., via Distribute PKI Material and Receive PKI Material transactions). All participants MUST validate digital signatures using keys that are anchored in the agreed trust framework. |
Generate a VHL Authorization Mechanism Based on Query Parameters |
The VHL Sharer SHALL generate a Verified Health Link (VHL) to be issued to a VHL Holder. The Sharer SHALL conduct all necessary tasks to prepare the content referenced by the VHL. These tasks MAY be further defined by applicable content profiles or implementation guides, and MAY include:
Once content preparation is complete, the Sharer SHALL construct the VHL payload and sign it to produce a cryptographically verifiable authorization mechanism. Optional behaviors:
|
Initiate mTLS |
The VHL Receiver, when acting as a client in a Verified Health Link (VHL) transaction, SHALL initiate a mutually authenticated TLS (mTLS) connection to the VHL Sharer. This initiation includes:
Successful completion of the mTLS handshake is a prerequisite for all subsequent transactions involving sensitive data exchange, including the retrieval of VHLs or associated health documents. |
Provide PKI material |
Upon receiving a Retrieve PKI Material request, the Trust Anchor SHALL validate the request and respond with appropriate public key material. This MAY include:
The Trust Anchor SHALL only respond with validated and trustworthy material in accordance with the governance policies of the VHL trust framework. |
Provide VHL |
The VHL Sharer SHALL generate a Verified Health Link (VHL) to be issued to a VHL Holder. This includes preparing or retrieving the referenced health content, constructing the VHL payload, and digitally signing it to ensure authenticity and integrity. The Sharer SHALL perform all necessary steps to assemble the content for sharing. These steps MAY include:
The Sharer SHALL construct the VHL payload in accordance with the applicable VHL content profile, and SHALL cryptographically sign the VHL to make it verifiable. Optional behaviors:
Depending on the use case, the VHL MAY be rendered or transmitted using formats such as QR code, Verifiable Credentials, Bluetooth, or NFC. Supported mechanisms are defined in Volume 3. |
Receive PKI material |
A VHL Sharer or VHL Receiver, after receiving PKI material from a Trust Anchor, SHALL validate and process the trust information for subsequent cryptographic operations. Participants SHOULD:
|
Receive VHL authorization mechanism |
The VHL Receiver SHALL be capable of receiving a Verified Health Link (VHL) from a VHL Holder through a supported transport mechanism (e.g., QR code scan, direct URL, or digital message). Upon receipt, the Receiver SHALL:
Receipt of the VHL may occur through direct user interaction (e.g., scanning a QR code) or automated channels, depending on the implementation context. |
Record Access to Health Data |
The VHL Sharer MAY record audit events when health data is accessed through a Verified Health Link (VHL). These events support accountability, traceability, and compliance with applicable security and privacy regulations. Audit records MAY include the following metadata:
Audit events SHALL be represented using the FHIR |
Record Consent |
The VHL Sharer SHALL record the consent granted by a VHL Holder to authorize the sharing of their health data via a Verified Health Link (VHL). This consent confirms that the Holder agrees to the creation of a VHL and its use by authorized VHL Receivers to access specific health documents. In this requirement, the VHL Sharer acts as a Consent Recorder, as defined in the Privacy Consent on FHIR (PCF) profile. Specifically, the Sharer SHALL initiate the Access Consent - ITI-108 transaction to formally capture the Holder's consent. The resulting
The ITI-108 transaction SHOULD be invoked as part of the actions triggered by a Generate VHL request, particularly when legal, jurisdictional, or organizational policy requires explicit, recorded consent prior to enabling document sharing. This requirement enables lawful, transparent sharing of personal health information across organizations and trust domains. |
Request PKI material |
A VHL Sharer or VHL Receiver, as a participant in the trust network, SHALL be capable of requesting public key infrastructure (PKI) material from a designated Trust Anchor. The retrieved material MAY include:
Participants SHOULD cache the received trust list to reduce network and server load. Preconditions:
|
Request VHL Document |
The VHL Receiver SHALL initiate a request to retrieve a single health document from a VHL Sharer, using a previously received and validated Verified Health Link (VHL). This transaction SHALL be conducted over a mutually authenticated TLS (mTLS) channel. Both the Receiver and Sharer SHALL validate each other's participation in the trust network using PKI material published by the Trust Anchor. Optional behaviors:
|
Request VHL Documents |
The VHL Receiver SHALL initiate a request to retrieve a set of health documents from a VHL Sharer, using a previously received and validated Verified Health Link (VHL). This transaction SHALL be conducted over a mutually authenticated TLS (mTLS) channel. Both the Receiver and Sharer SHALL validate each other's participation in the trust network using PKI material published by the Trust Anchor. Optional behaviors:
|
Request that a VHL authorization mechanism be issued |
A VHL Holder initiates a request to a VHL Sharer to generate a Verified Health Link (VHL) that references one or more health documents. The resulting VHL allows the Holder to subsequently share access to those documents with a VHL Receiver. The Holder MAY include optional parameters to constrain or protect the issued VHL-such as defining an expiration period, scoping which documents are included, or requiring a passcode for retrieval. These parameters guide the Sharer's issuance of the VHL and influence the conditions under which the associated documents may be accessed. Preconditions:
|
Submit PKI Material |
When a VHL Sharer or VHL Receiver generates a new public-private key pair for use within the VHL trust network, they SHALL submit the corresponding public key material to the Trust Anchor for validation and inclusion in the trust list. The submission MAY include metadata to support categorization of key usage (e.g., digital signatures, encryption, mTLS) and business or operational context. |
Verify Document Signature |
The VHL Receiver, upon receiving a digitally signed health document from a VHL Sharer, MAY verify the document's digital signature using previously retrieved PKI material. This verification process confirms the authenticity, integrity, and provenance of the document independently of the Verified Health Link (VHL) itself. The public key used for this verification MAY:
Implementers SHOULD consult cross-profile guidance regarding interoperability with the IHE Document Digital Signature (DSG) profile, particularly in cases where additional attestation, long-term non-repudiation, or multi-party signatures are involved. |
The following artifacts define the specific capabilities that different types of systems are expected to have in order to comply with this implementation guide. Systems conforming to this implementation guide are expected to declare conformance to one or more of the following capability statements.
Trust Anchor |
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. |
These define groups of interrelated examples that demonstrate one or more of the workflows supported by this implementation guide.
UseCaseEVC |