|
Type
|
Reference
|
Content
|
|
web
|
www.ihe.net
|
contact
: https://www.ihe.net/ihe_domains/it_infrastructure/
, iti@ihe.net
, IHE IT Infrastructure Technical Committee: iti@ihe.net
|
|
web
|
euvabeco.eu
|
The European Vaccination Card (EVC)
is a citizen-held card to foster informed decision-making on vaccination, and improve continuity of care across the EU.
|
|
web
|
eur-lex.europa.eu
|
ANNEX II - Essential requirements for the harmonised software components of EHR systems and for products for which interoperability with EHR systems has been claimed
|
|
web
|
eur-lex.europa.eu
|
Article 9 - Right to obtain information on accessing data
|
|
web
|
eur-lex.europa.eu
|
A critical privacy requirement for the EVC is unlinkability: Article 5a(16) of Regulation (EU) No 910/2014 as amended
Article 5a(16):
The technical framework of the European Digital Identity Wallet shall:
|
|
web
|
smart.who.int
|
The World Health Organization (WHO) operates the Global Digital Health Certification Network (GDHCN)
, 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.
|
|
web
|
profiles.ihe.net
|
The GDHCN distributes trust lists using Decentralized Identifiers (DIDs)
. 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
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.
|
|
web
|
ewsdata.rightsindevelopment.org
|
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
|
|
web
|
ewsdata.rightsindevelopment.org
|
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
|
|
web
|
profiles.ihe.net
|
Initiate Authenticate Node ITI-19
transaction to establish a secure connection and validate participation in the trust network using PKI material published by the trust anchor.
|
|
web
|
profiles.ihe.net
|
|
|
web
|
profiles.ihe.net
|
|
|
web
|
github.com
|
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
|
|
web
|
www.ihe.net
|
IG © 2024+ IHE IT Infrastructure Technical Committee
. Package ihe.iti.vhl#0.0.2-current based on FHIR 4.0.1
. Generated 2026-05-15
Links: Table of Contents |
QA Report
| New Issue | Issues
Version History |
 |
Propose a change
|
|
web
|
github.com
|
Links: Table of Contents
|
QA Report
| New Issue
| Issues
Version History
|
|
Propose a change
|
|
web
|
github.com
|
Links: Table of Contents
|
QA Report
| New Issue
| Issues
Version History
|
|
Propose a change
|
|
web
|
profiles.ihe.net
|
Links: Table of Contents
|
QA Report
| New Issue
| Issues
Version History
|
|
Propose a change
|
|
web
|
www.ihe.net
|
Links: Table of Contents
|
QA Report
| New Issue
| Issues
Version History
|
|
Propose a change
|
|
web
|
profiles.ihe.net
|
IHE mCSD
: Mobile Care Services Discovery
|
|
web
|
smart.who.int
|
The VHL payload conforms to the SMART Health Links payload format
and carries the manifest URL, a symmetric decryption key, and optional metadata (expiration, flags, label, purpose-of-use bindings). By default the VHL is returned as a QR code encoded as an HCERT/CWT structure per the WHO SMART Trust HCERT specification
. When the VHL Sharer
supports the VC Enveloped VHL Carrier Option
, the caller MAY instead request the VHL as a signed W3C Verifiable Credential ( application/vc+ld+json
).
|
|
web
|
smart.who.int
|
The default carrier when format
is omitted or set to qrcode
. The VHL payload is embedded in an HCERT
structure at claim key 5 per the WHO SMART Trust HCERT specification
, signed as a CWT, and rendered as a QR code with the HC1:
prefix. The VHL Receiver verifies the CWT signature against the trust list. See 2:3.YY3.4.1.3 Expected Actions
for the full VHL Payload Construction and HCERT/CWT encoding steps, including a worked example.
|
|
web
|
smart.who.int
|
The default carrier when format
is omitted or set to qrcode
. The VHL payload is embedded in an HCERT
structure at claim key 5 per the WHO SMART Trust HCERT specification
, signed as a CWT, and rendered as a QR code with the HC1:
prefix. The VHL Receiver verifies the CWT signature against the trust list. See 2:3.YY3.4.1.3 Expected Actions
for the full VHL Payload Construction and HCERT/CWT encoding steps, including a worked example.
|
|
web
|
smart.who.int
|
Based on the requested format
, the VHL Sharer
generates the VHL as either a QR code (HCERT/CWT-encoded per the WHO SMART Trust HCERT specification
, with the VHL payload embedded at claim key 5) or a Verifiable Credential (JSON-LD per the W3C VC Data Model v2
, with the VHL payload under credentialSubject
). Both carriers share the same VHL payload construction.
|
|
web
|
profiles.ihe.net
|
Generate a 32-byte (256-bit) random encryption key, base64url-encode it (resulting in 43 characters) - this is the 'key' parameter. The VHL Receiver
uses this key to decrypt document binaries retrieved via ITI-68
; see ITI-YY5 Document Encryption
.
|
|
web
|
profiles.ihe.net
|
Note: The manifest URL is a FHIR search on List
using the search parameters that the Document Responder in IHE MHD ITI-66 Find Document Lists
is required to support — specifically _id
, code
, status
, and the patient identifier expressed as a chained search on the patient
reference parameter ( patient.identifier=system|value
). _include=List:item
is added only when the VHL Sharer
supports the Include DocumentReference Option.
|
|
web
|
smart.who.int
|
After constructing the VHL payload (steps 1–4 above), the VHL Sharer
SHALL encode it within an HCERT
structure per the WHO SMART Trust specification with the VHL payload at HCERT claim 5, then generate the QR code per the HCERT Specification
.
|
|
web
|
smart.who.int
|
After constructing the VHL payload (steps 1–4 above), the VHL Sharer
SHALL encode it within an HCERT
structure per the WHO SMART Trust specification with the VHL payload at HCERT claim 5, then generate the QR code per the HCERT Specification
.
|
|
web
|
profiles.ihe.net
|
Purpose of Use Handling (if provided)
— The VHL Sharer
SHALL validate each purposeOfUse
value against PurposeOfUse
(extensible binding) and persist the value(s) against the folder ID for downstream enforcement at ITI-YY5
. When grouped with an IHE PCF Consent Creator
or Consent Recipient
, the persisted value(s) SHALL populate Consent.provision.purpose
. purposeOfUse
value(s) SHALL NOT be embedded in the QR code, VC, or VHL payload — they are share metadata held by the VHL Sharer
, not content consumed by the VHL Receiver
.
|
|
web
|
profiles.ihe.net
|
See ITI TF-2: Appendix Z.6
for more details on response format handling.
|
|
web
|
smart.who.int
|
WHO SMART Trust HCERT Specification
: HCERT Structure
|
|
web
|
profiles.ihe.net
|
key
: base64url-encoded decryption key, 43 characters (required). The VHL Receiver
caches this key for the VHL session and uses it as the symmetric key for JWE dir
/ A256GCM
decryption of document binaries retrieved via ITI-68
; see ITI-YY5 Document Encryption
.
|
|
web
|
profiles.ihe.net
|
ITI TF-2: Mobile Health Document Sharing (MHD)
: ITI-66 Find Document Lists
|
|
web
|
profiles.ihe.net
|
ITI TF-2: Mobile Health Document Sharing (MHD)
: ITI-68 Retrieve Document
- used to retrieve the binary content referenced from DocumentReference.content.attachment.url
|
|
web
|
profiles.ihe.net
|
ITI Internet User Authorization (IUA)
: IUA Profile
|
|
web
|
profiles.ihe.net
|
This transaction MAY be conducted over a secure channel, as defined in the Audit Trail and Node Authentication (ATNA)
Profile.
|
|
web
|
profiles.ihe.net
|
Because the VHL manifest URL constructed at ITI-YY3
is a FHIR search on List
using the search parameters required by the Document Responder in IHE MHD ITI-66 Find Document Lists
, the Retrieve Manifest response is — at the FHIR level — an MHD ITI-66 response message
: a FHIR searchset
Bundle. The shape of the Bundle depends on whether the VHL Sharer
supports the Include DocumentReference Option
AND the VHL Receiver
included _include=List:item
in the request:
|
|
web
|
profiles.ihe.net
|
Because the VHL manifest URL constructed at ITI-YY3
is a FHIR search on List
using the search parameters required by the Document Responder in IHE MHD ITI-66 Find Document Lists
, the Retrieve Manifest response is — at the FHIR level — an MHD ITI-66 response message
: a FHIR searchset
Bundle. The shape of the Bundle depends on whether the VHL Sharer
supports the Include DocumentReference Option
AND the VHL Receiver
included _include=List:item
in the request:
|
|
web
|
profiles.ihe.net
|
The Bundle conforms to the standard MHD ITI-66 response. For Bundle structure, element semantics, and a worked example, see ITI-66 Message Semantics
. The VHL Receiver
SHALL resolve each List.entry[].item.reference
via a separate FHIR read on the VHL Sharer
before retrieving binaries.
|
|
web
|
profiles.ihe.net
|
Retrieve Document [ITI-68]
|
|
web
|
profiles.ihe.net
|
This requirement is satisfied by implementing secure channel establishment as defined in the Audit Trail and Node Authentication (ATNA)
Profile, specifically through the Authenticate Node [ITI-19] transaction.
|
|
web
|
profiles.ihe.net
|
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.
|
|
web
|
profiles.ihe.net
|
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.
|
|
web
|
profiles.ihe.net
|
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.
|
|
web
|
www.ihe.net
|
Contact:
( https://www.ihe.net/ihe_domain...
, iti@ihe.net
, IHE IT Infrastructure Technical Committee: iti@ihe.net
)
|
|
web
|
profiles.ihe.net
|
IHE uses the normative words: Shall, Should, and May according to standards conventions
.
|
|
web
|
profiles.ihe.net
|
The use of mustSupport
in StructureDefinition profiles equivalent to the IHE use of R2
as defined in Appendix Z
.
|
|
web
|
profiles.ihe.net
|
Editor, add the following new or modified actors to the IHE Technical Frameworks General Introduction Appendix A
:
|
|
web
|
profiles.ihe.net
|
Editor, add the following new or modified transactions to the IHE Technical Frameworks General Introduction Appendix B
:
|
|
web
|
profiles.ihe.net
|
Editor, add the following new or modified terms to the IHE Technical Frameworks General Introduction Appendix D
:
|
|
web
|
smarthealth.cards
|
HL7: SMART Health Cards Overview
VHL: VHL Volume 1 – Actors
|
|
web
|
smarthealth.cards
|
HL7: SMART Health Cards Overview
VHL: VHL Volume 1 – Security
|
|
web
|
smarthealth.cards
|
HL7: SMART Health Cards
VHL: VHL Volume 1 – Cross-Profile (PCF)
|
|
web
|
smarthealth.cards
|
HL7: SMART Health Cards
VHL: VHL Volume 1 – Use Cases
|
|
web
|
profiles.ihe.net
|
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
and Appendix B: Transactions
.
|
|
web
|
profiles.ihe.net
|
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
and Appendix B: Transactions
.
|
|
web
|
profiles.ihe.net
|
ITI MHD / Document Responder ( ITI-68
)
|
|
web
|
profiles.ihe.net
|
ITI MHD / Document Consumer ( ITI-68
)
|
|
web
|
profiles.ihe.net
|
Note: The VHL Sharer
SHALL be grouped with an MHD Document Responder so that the binary referenced from DocumentReference.content.attachment.url
can be retrieved via ITI-68 Retrieve Document
. The VHL Receiver
SHALL be grouped with an MHD Document Consumer to perform that retrieval. Document binaries are encrypted as JWE per RFC 7516/7518 using the key
from the VHL payload decoded by the VHL Receiver
in ITI-YY4; specific JWE algorithms are selected per Cryptographic Algorithm Selection
.
|
|
web
|
profiles.ihe.net
|
The IHE Privacy Consent on FHIR (PCF)
profile is the recommended companion for capturing, storing, and enforcing patient consent alongside VHL. When the VHL Sharer
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
.
|
|
web
|
profiles.ihe.net
|
ITI-YY5 (Retrieve Manifest) reuses the FHIR search machinery of MHD ITI-66 Find Document Lists
: the VHL manifest URL constructed at ITI-YY3 is a FHIR List
search using the parameters the Document Responder is required to support per ITI-66, and the ITI-YY5 response is an ITI-66 searchset
Bundle. Binary retrieval is delegated to MHD ITI-68 Retrieve Document
per the required grouping in §XX.3 Required Actor Groupings
.
|
|
web
|
profiles.ihe.net
|
ITI-YY5 (Retrieve Manifest) reuses the FHIR search machinery of MHD ITI-66 Find Document Lists
: the VHL manifest URL constructed at ITI-YY3 is a FHIR List
search using the parameters the Document Responder is required to support per ITI-66, and the ITI-YY5 response is an ITI-66 searchset
Bundle. Binary retrieval is delegated to MHD ITI-68 Retrieve Document
per the required grouping in §XX.3 Required Actor Groupings
.
|
