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:

• Present a valid X.509 server certificate that is anchored to a recognized Trust Anchor
• Validate the client certificate presented by the Receiver against the same trust framework
• Establish a secure channel over which all subsequent VHL-related transactions are conducted

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.

Purpose:
Ensure that the VHL Sharer records audit events when health documents are accessed or retrieved using a Verified Health Link (VHL).

Description:
The VHL Sharer MAY record audit events for critical events involving document access. These MAY include:

• A request from a VHL Holder to generate a VHL
• A request from a VHL Receiver to retrieve one or more health documents using a valid VHL
• Any access to protected health content triggered by the use of a VHL

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:

• The VHL Receiver initiating the mTLS handshake as the client and presenting a valid X.509 certificate
• The VHL Sharer responding as the server, presenting its own certificate and validating the client's certificate against a trusted Certificate Authority or Trust Anchor

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.

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.

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:

• Generation of new documents;
• Querying for existing documents associated with the VHL Holder; or
• Creation of digital signatures on one or more documents.

Once content preparation is complete, the Sharer SHALL construct the VHL payload and sign it to produce a cryptographically verifiable authorization mechanism.

Optional behaviors:

• The Sharer MAY record consent in accordance with the Record Consent requirement.
• The Sharer MAY log an audit event describing the VHL issuance, in accordance with the Audit Event – Accessed Health Data requirement.

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:

• Querying for existing health documents (e.g., IPS, CDA, FHIR Bundles)
• Generating new content in real time
• Applying digital signatures to selected documents or bundles

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:

• The Sharer MAY record consent in accordance with the Record Consent requirement.
• The Sharer MAY log an audit event describing the creation of the VHL, as defined in the Audit Event – Accessed Health Data requirement.

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.

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:

• Cache the received trust list or certificate material to reduce network and server load
• Validate digital signatures or trust paths before use in VHL validation or mTLS sessions
• Monitor certificate expiration or revocation status where applicable

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:

• Timestamp of the access event
• Identity of the accessing actor (e.g., person or system)
• Type and identifier of the accessed resource (e.g., DocumentReference)
• Purpose of access, where available (e.g., treatment, consent verification)
• Outcome of the event (e.g., success, failure)

Audit events SHALL be represented using the FHIR AuditEvent resource, and SHOULD conform to applicable IHE profiles such as ATNA where appropriate. Implementers MAY define additional audit logging behavior to meet jurisdictional or organizational policies.

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 Consent resource SHALL document:

• The data subject (VHL Holder)
• The purpose of use
• The authorized data recipients (i.e., permitted VHL Receivers)
• The scope of data (e.g., specific documents or resource types)
• The duration or validity period of the consent

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.

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:

• Public key certificates and associated trust lists
• Certificate revocation data (e.g., CRLs, OCSP responses)
• Metadata used to:
  • Validate digital signatures on VHLs and related resources
  • Establish mutually authenticated TLS (mTLS) connections
  • Decrypt content protected via asymmetric encryption

Participants SHOULD cache the received trust list to reduce network and server load.

Preconditions:

• The requesting participant knows in advance the endpoint from which to retrieve PKI material, as published or distributed by the Trust Anchor.

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.