Verified Health Link
0.0.2-current - ci-build International flag

Verified 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

Appendix A: Comparision of health links

Category HL7 SMART Health Links IHE Verified Health Links (VHL) References
1. Transmission Method In Spec:
Defined as a URL that points to internet‐accessible storage (e.g., a FHIR server).
Examples in Practice:
The URL may be shared via a QR code.
Embedding the entire IPS in a QR code is a feature of the SMART Health Cards framework—not part of the core SHLink spec.		 In Spec:
The VHL specification defines a URL that references a document stored in an IHE-compliant repository (e.g., XDS, MHD).
QR codes are used to convey that URL or document reference.		 HL7: SMART App Launch VHL: IHE VHL Volume 1
2. Verifying URL Safety In Spec:
The specification does not mandate a specific method for verifying URL safety.
Examples in Practice:
Implementations typically rely on standard HTTPS/TLS for domain authentication.
Some systems may check an issuer (iss) claim and use JWKS (as seen in SMART Health Cards), but that is not defined in the core SHLink spec.		 In Spec:
URL safety is ensured via the pre-established trust network where digital signatures are verified against exchanged PKI material.
The specification defines mechanisms to retrieve and verify PKI material via a Trust Anchor.		 HL7: SMART App Launch (no mandated URL verification method) VHL: IHE VHL Volume 1 – Security Considerations
3. Issuance of Sender Credentials In Spec:
There is no formal requirement for credential issuance in SHLink.
Optional Implementation:
Systems may choose to sign payloads using JWS with public keys published via a JWKS endpoint (as seen in SMART Health Cards).		 In Spec:
The VHL framework requires that the sender use PKI credentials issued by a trusted authority as part of a pre-defined trust network.
While the spec refers to exchanging and verifying PKI material via a Trust Anchor, in practice this is typically implemented using X.509 certificates, even though the document does not always state “X.509” explicitly.		 HL7 (Optional): SMART Health Cards Overview VHL: IHE VHL Volume 1 – Actors & Transactions
4. Receiver Credentials for Access In Spec:
No specific receiver credentials are mandated, possession of the URL grants access.
Optional:
Implementations may add a passcode/PIN for additional security.
CA:SHL guidance defines passcode as mandatory.		 In Spec:
The receiver must be an authorized participant in the trust network and be verified using their PKI credentials (typically implemented as X.509 certificates).
Access is controlled by repository permissions within the trust framework.
Additional security measures (e.g., passcodes) are available as options.		 HL7: SMART App Launch VHL: IHE VHL Volume 1 – Actors & Transactions
5. Document Integrity Verification In Spec:
The SHLink specification does not mandate a specific mechanism for document integrity verification.
Optional Implementation:
Some systems may use JWS signatures and dynamically fetch public keys via a JWKS endpoint (as seen in SMART Health Cards) to verify integrity; however, this is not required by SHLink.		 In Spec:
The VHL specification mandates that document integrity is verified using digital signatures based on exchanged PKI material.
The signature is validated by checking the certificate chain against a recognized Trust Anchor, ensuring the document has not been modified since signing.		 HL7 (Optional): RFC7515 & RFC7517 VHL: IHE VHL Volume 1 – Document Signature
6. Unauthorized Access Prevention In Spec:
Access is granted solely by possession of the URL.
Optional:
Additional measures (e.g., encryption or a passcode) may be implemented by the application, but these are not defined by the core SHLink spec.
CA:SHL guidance defines passcode, encryption, and short-lived URL as mandatory.		 In Spec:
The VHL specification requires that access to the document is controlled via repository permissions enforced within the trust network.
Only authorized participants (as verified by the trust framework) can retrieve the document.		 HL7: SMART Health Cards Overview (for optional enhancements) VHL: IHE VHL Volume 1 – Security Considerations
7. Predefined Relationship Requirements In Spec:
There is no requirement for a pre-established trust relationship between sender and receiver in SHLink.
Trust is established dynamically using standard web security (e.g., HTTPS).		 In Spec:
The VHL framework requires that both sender and receiver be part of a pre-established trust network.
Their identities must be verified against a common Trust Anchor, ensuring mutual trust across jurisdictions.		 HL7: SMART App Launch VHL: IHE VHL Volume 1 – Actors & Transactions
8. Consent Recording In Spec:
The SHLink specification does not include mechanisms for formal consent recording.
Optional:
Implementations may integrate consent recording using external systems or components from related standards (e.g., SMART Health Cards or FHIR-based consent modules).
Considering adding explicit consent to CA:SHL in future		 In Spec (Option):
The VHL specification provides an optional Record Consent Option (e.g., via integration with IHE Privacy Consent on FHIR (PCF)).
This option enables capturing and referencing patient consent as part of the VHL transaction.		 HL7: SMART Health Cards Overview (does not mandate consent recording) VHL: IHE VHL Volume 1 – Section XX.2.2 Record Consent Option
9. Audit Logging In Spec:• Audit logging is not mandated by the SHLink specification.Optional:• Systems may choose to implement logging externally at the receiver’s side if desired.
Considering adding explicit audit requirement to CA:SHL in future		 In Spec (Option):
The VHL specification includes an optional Audit Event Option(typically implemented using IHE ATNA profiles) to log document access and transaction events.
This supports security audits and regulatory compliance.		 HL7: SMART App Launch (no audit requirement) VHL: IHE VHL Volume 1 – Section XX.2.3 Audit Event Option
10. Criteria for Choosing the Standard In Spec:
SHLink is designed for simpler, ad hoc, patient-initiated sharing scenarios without formal trust networks.
It is intended for use cases where minimal infrastructure is desired.
Consideration:
Suitable when regulatory requirements for trust and auditing are less stringent.		 In Spec:
VHL is intended for use in regulated, cross-jurisdictional environments where explicit trust, and optional consent recording and audit logging, are important.
Best used when participants are part of a pre-established trust network with formal PKI (typically implemented using X.509 certificates).		 HL7: SMART Health Cards Overview(provides context for simple sharing) VHL: IHE VHL Volume 1 – Use Cases

Editors Note: The table is thanks to:

https://tabletomarkdown.com/convert-spreadsheet-to-markdown/ from the source 

https://docs.google.com/spreadsheets/d/1aAT2zLDzhk4pcSy9DGXf4b2vS0dDefBkg6Z4TCJB6f0/edit?gid=0#gid=0 bl