Verified Health Link
0.0.2-current - ci-build
Verified Health Link
0.0.2-current - ci-build
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
As an individual moves within or across jurisdictional boundaries, they may wish to provide access to clinical anor other health related documents to a set of trusted parties who are authorized to access that individual's health documents. The individual may wish to grant access to a single health document or a set of related health documents.
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.
The VHL leverages Public Key Infrastructure (PKI) as a means to verify trust amongst the actors and the veracity of artifacts.
In the VHL profile, the VHL Receiver and VHL Sharer participate in a trust network which enables the verification of the origin of the health document, any access mechanisms to these health documents, and the origin of requests to utilze these access mechanisms. The authorization for the participation of a VHL Receiver or VHL Sharer with the trust network is maintained by their respective jurisidictions. The verification of that authorization is acheived using the PKI.
The respective jurisidictions of the VHL Receiver and VHL Sharer may have regulatory framework in regards to the privacy and security of access to patient data that may include the needs for verfication of consent and maintaining audit trails for access to an person's health data.
qAs participants within a trust network, the VHL Receiver and VHL Sharer both share and receive PKI material as Trustlists, with the Trust Anchor of the trust network. The means by which the VHL Receiver and VHL Sharer establish trust with the Trust Anchor is beyond the scope of this profile.
Note that VHLs and a SMART(R) Health Links (SHLs) are related concepts with different assumptions on the trust network. In the VHL context a trust relationship is pre-established between the VHL Receiver and the VHL Sharer through PKI material distributed as Trustlists distribution mechanism. In the SHL context, there is no pre-existing trust relationship between the a SHL Receiver and SHL Sharer and the PKI material is distributed by the SHL Sharer at the time that the SHL Holder provides the SHL to the SHL Receiver. See Appendix A for a more detailed comparison.
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.
As a pre-condition to transactions ITI-YY3, ITI-YY4 and ITI-YY5, the VHL Receiver and VHL Sharer must exchange the appropriate PKI in order to verify their trust relationship at the time of the utlization of the VHL. As the identities of the VHL Receiver and VHL Sharer are not directly know to each other in advance of a request to utilize a VHL, the VHL Receiver and VHL Sharer publish and retrieve key material from a third party, the Trust Anchor. This is illustrated in Figure X.X.X.X-1
Figure X.X.X.X-2: Use Case Issue and Utilize VHL for a (set of) Health Document(s) Process Flow
The process of a VHL Holder requesting a VHL to a set of health documents from a VHL Sharer and subsequently sharing them to a VHL Receiver is illusrated in Figure X.X.X.X-2.
The interaction between a VHL Holder requesting a VHL to a single health document from a VHL Sharer and subsequently sharing them to a VHL Receiver is illusrated in Figure X.X.X.X-2.
Figure X.X.X.X-2: Use Case Issue and Utilize VHL for a (set of) Health Document(s) Process Flow
Table XX.1-1: Profile Acronym Profile - Actors and Transactions
| Actors | Transactions | Initiator or Responder | Optionality | Reference |
|---|---|---|---|---|
| Trust Anchor | Publish PKI Material | Responder | R | ITI TF-2: YY1 |
| Retreive PKI Material | Responder | R | ITI TF-2: YY2 | |
| VHL Holder | Generate VHL | Initiator | R | ITI TF-2: YY3 |
| Provide VHL | Initiator | R | ITI TF-2: YY6 | |
| VHL Receiver | Publish PKI Material | Initiator | R | ITI TF-2: YY1 |
| Retreive PKI Material | Initiator | R | ITI TF-2: YY2 | |
| Provide VHL | Responder | R | ITI TF-2: YY6 | |
| Request Documents | Initiator | R | ITI TF-2: YY4 | |
| Request Document | Initiator | R | ITI TF-2: YY5 | |
| VHL Sharer | Publish PKI Material | Initiator | R | ITI TF-2: YY1 |
| Retreive PKI Material | Initiator | R | ITI TF-2: YY2 | |
| Generate VHL | Responder | R | ITI TF-2: YY3 | |
| Request Documents | Responder | R | ITI TF-2: YY4 | |
| Request Documents | Responder | R | ITI TF-2: YY5 |
The actors in this profile are described in more detail in the sections below.
The Trust Anchor receives, aggregates and distributes PKI material to the participants within a trust network, specifically the VHL Reciver and VHL Sharer.
This actor fulfills the following requirements:
This actor fufills the following capabilities:
CapabilityStatement for Trust Anchor Actor in the IHE IT Infrastructure Technical Framework Supplement IHE VHL. The Trust Anchor receives, aggregates and distributes PKI material to the participants within a trust network, specifically the VHL Reciver and VHL Sharer.
The VHL Holder is an individual that is holding an authorization mechanism, a VHL, which allows a VHL Receiver to access a (set of) health document(s) held by a VHL Sharer.
This actor fulfills the following requirements:
The VHL Receiver receives a VHL from a VHL Holder which it utilizes to request access to health documents from a VHL Sharer.
This actor fulfills the following requirements:
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.
This actor fulfills the following requirements:
The transactions in this profile are summarized in the sections below.
This transactions is used by a VHL Receiver or VHL Sharer to publish PKI material to a Trust Anchor.
For more details see the detailed transaction description
This transaction is captured as the following requirement:
This transactions is used by a VHL Receiver or VHL Sharer to retrieve PKI material previously published to a Trust Anchor. Retrieved key material should be able to be distinguised by the participating jurisdiction, use case context, and key usage.
For more details see the detailed transaction description
This transaction is captured as the following requirement:
This transactions is used by a VHL Holder to request that a VHL Sharer generate a VHL. A VHL Sharer may optionally record the consent of the individual to share their information under the Record Consent option. A VHL Sharer may optionally create an audit trail of the creation of the VHL under the Audit Event option. The individual shall trust that VHL Sharer has been authorized by its jurisidiction to authorize and provide access to health documents.
For more details see the detailed transaction description
This transaction is captured as the following requirement:
This transactions is initiated by a VHL Receiver to request a set of health documents from a VHL Sharer. This transaction should be conducted in such a manner that the VHL Receiver and VHL Sharer can validate one another's participation in the same trust network. The VHL Sharer shall optionally be able to record an audit event for the access of the folder by the VHL Receiver upon the transaction request under the Audit Event option.
For more details see the detailed transaction description
This transaction is captured as the following requirement:
This transactions is initiated by a VHL Receiver to request a single health document from a VHL Sharer. This transaction should be conducted in such a manner that the VHL Receiver and VHL Sharer can validate one another's participation in the same trust network. The VHL Receiver shall optionally be able to validate that the veracity of the health document received through this transaction under the Verify Document Signature option. The VHL Sharer shall optionally be able to record an audit event for the access of the folder by the VHL Receiver upon the transaction request under the Audit Event option.
For more details see the detailed transaction description
This transaction is captured as the following requirement:
This transacation is initiated by a VHL Holder to transmit a VHL to the VHL Receiver. Depending on the use case and context, the payload comprising the VHL may be rendered/serialized and transmitted through various mechanisms, for example as a QR-code, Verifiable Credentials, bluetooth or near-field communication protocols. These mechanisms are described in Volume 3
For more details see the detailed transaction description
This transaction is captured as the following requirement:
Options that may be selected for each actor in this implementation guide, are listed in Table 3.2-1 below. Dependencies between options when applicable are specified in notes.
Table XX.2-1: Actor Options
| Actor | Option Name |
|---|---|
| VHL Receiver | Verify Document Signature |
| VHL Sharer | Record Consent |
| Audit Event |
In this option the VHL Receiver, after receipt of a digitally signed document from a VHL Sharer, shall verify the digtial signature using previosuly retrieved PKI material. This key material may or may not be distributed under the same trust network under which the VHL was distributed. This key material may or may not be the same key material that was used to verify the VHL.
See cross-profile considerations for a discussion of the relationship of this option to the IHE Document Signature profile.
This option is captured in the following business requirement:
In this option the VHL Sharer acts a Consent Recorder from the Privacy Consent on FHIR (PCF) profile. In this option, the VHL Sharer SHALL initiate a [Access Consent : ITI-108)(https://profiles.ihe.net/ITI/PCF/ITI-108.html) transaction as part of the Expected Actions after receipt of a Generate VHL request. The Access Consent transaction is used to record the consent declarations by the VHL Holder for the sharing of the (set of) health document(s) by the VHL Sharer to any authorized VHL Receiver within the trust network for a specified use case.
This option is captured in the following business requirement:
In this option the VHL Sharer records an audit event for critical events in the access of health documents including:
This option is captured in the following business requirement:
Describe any requirements for actors in this profile to be grouped with other actors.
This section specifies all REQUIRED Actor Groupings (although "required" sometimes allows for a selection of one of several). To SUGGEST other profile groupings or helpful references for other profiles to consider, use Section XX.6 Cross Profile Considerations. Use Section X.5 for security profile recommendations.
An actor from this profile (Column 1) shall implement all of the required transactions and/or content modules in this profile in addition to all of the requirements for the grouped actor (Column 2) (Column 3 in alternative 2).
If this is a content profile, and actors from this profile are grouped with actors from a workflow or transport profile, the Reference column references any specifications for mapping data from the content module into data elements from the workflow or transport transactions.
In some cases, required groupings are defined as at least one of an enumerated set of possible actors; this is designated by merging column one into a single cell spanning multiple potential grouped actors. Notes are used to highlight this situation.
Section XX.5 describes some optional groupings that may be of interest for security considerations and Section XX.6 describes some optional groupings in other related profiles.
Two alternatives for Table XX.3-1 are presented below.
alternative 1 Table XX.3-1: Profile Name - Required Actor Groupings
All actors from this profile should be listed in Column 1, even if none of the actors has a required groupings. If no required grouping exists, "None" should be indicated in Column 2. If an actor in a content profile is required to be grouped with an actor in a transport or workflow profile, it will be listed with at least one required grouping. Do not use "XD*" as an actor name.
In some cases, required groupings are defined as at least one of an enumerated set of possible actors; to designate this, create a row for each potential actor grouping and merge column one to form a single cell containing the profile actor which should be grouped with at least one of the actors in the spanned rows. In addition, a note should be included to explain the enumerated set. See example below showing Document Consumer needing to be grouped with at least one of XDS.b Document Consumer, XDR Document Recipient or XDM Portable Media Importer
The author should pay special consideration to security profiles in this grouping section. Consideration should be given to Consistent Time (CT) Client, ATNA Secure Node or Secure Application, as well as other profiles. For the sake of clarity and completeness, even if this table begins to become long, a line should be added for each actor for each of the required grouping for security. Also see the ITI document titled 'Cookbook: Preparing the IHE Profile Security Section' at http://ihe.net/Technical_Frameworks/#IT for a list of suggested IT and security groupings.
Table XX.3-1: Actor Groupings
| this Profile Acronym Actor | Actor(s) to be grouped with | Reference | Content Bindings Reference |
|---|---|---|---|
| Actor A | external Domain Acronym or blank profile acronym/Actor e.g., ITI CT / Time Client |
TF Reference; typically from Vol 1 e.g., ITI-TF-1: 7.1 |
-- |
| Actor B | None | -- | -- |
Actor C In this example, Actor C shall be grouped with all three actors listed in column 2 |
external Domain Acronym or blank profile acronym/Actor |
-- | See Note 1 |
| external Domain Acronym or blank profile acronym/Actor | -- | See Note 1 | |
external Domain Acronym or blank profile acronym/Actor |
-- | See Note 1 | |
Actor D (See note 1) In this example, the note is used to indicate that the Actor D shall be grouped with one or more of the two actors of the two actors in column 2. |
external Domain Acronym or blank profile acronym/Actor |
-- | See Note 1 |
external Domain Acronym or blank profile acronym/Actor |
-- | See Note 1 | |
Actor E In rare cases, the actor to be grouped with must implement an option. An example is in column 2.) |
external Domain Acronym or blank profile acronym Actor e.g., ITI RFD Form Filler with the Archive Form Option |
TF Reference to the Option definition; typically from Vol 1 (e.g., ITI TF-1: 17.3.11) |
|
| e.g., Content Consumer (See Note 1) | ITI XDS.b / Document Consumer | ITI TF-1: 10.1 | PCC TF-2:4.1 (See Note 2) |
| ITI XDR / Document Recipient | ITI TF-1: 15.1 | PCC TF-2:4.1 (See Note 2) | |
| ITI XDM / Portable Media Importer | ITI TF-1: 16.1 | PCC TF-2:4.1 (See Note 2) | |
| e.g., Content Consumer | ITI CT / Time Client | ITI TF-1: 7.1 | -- |
Note 1: This is a short note. It may be used to describe situations where an actor from this profile may be grouped with one of several other profiles/actors.
Note 2: A note could also be used to explain why the grouping is required, if that is still not clear from the text above.
alternative 2 Table XX.3-1: this Profile Acronym Profile
All actors from this profile should be listed in Column 1. If no required grouping exists, "None" should be indicated in Column 3.
Guidance on using the "Grouping Condition" column:
Table XX.3-1: Actor Groupings
| this Profile Acronym Actor | Grouping Condition | Actor(s) to be grouped with | Reference |
| Actor A | -- | None | -- |
| Actor B | Required | external Domain Acronym or blank profile acronym/Actor e.g., ITI CT / Time Client |
TF Reference; typically from Vol 1 (e.g., ITI TF-1: 7.1) |
| Actor C | With the Option name in this profile Option | external Domain Acronym or blank profile acronym/Actor | Where the Option is defined in this profile Section XX.3 z |
Actor D if an actor has both required and conditional groupings, list the Required grouping first |
Required | external Domain Acronym or blank profile acronym/Actor | TF Reference; typically from Vol 1 |
| If the Option name in this profile Option is supported. | external Domain Acronym or blank profile acronym/Actor | TF Reference; typically from Vol 1 | |
| If the other Option name in this profile Option is supported. | external Domain Acronym or blank profile acronym/Actor | TF Reference; typically from Vol 1 | |
Actor E (In rare cases, the actor to be grouped with must implement an option, an example is in column 3) |
Required | external Domain Acronym or blank profile acronym/Actor with the option name e.g. ITI RFD Form Filler with the Archive Form Option |
TF Reference to the Option definition; typically from Vol 1 (eg ITI TF-1:17.3.11) |
This section shows how the transactions/content modules of the profile are combined to address the use cases.
Use cases are informative, not normative, and "SHALL" language is not allowed in use cases.
A Verifiable Health Link is a mechanism which enables the sharing of health documents with additional sharing options that may include: limited-time access, long-term sharing of data that can evolve over time, and protecting access with a PIN. These shareable links can often be downloaded onto devices and converted into a QR code format, facilitating patient-mediated data sharing and interoperability within the healthcare ecosystem.
A patient, via a patient-facing application, requests access to a shareable copy of their health summary.
Ms. SJ, a 37-year-old non-smoker and non-drinker, recently experienced a high-risk pregnancy involving early hospitalization and pre-term delivery due to pre-eclampsia and gestational diabetes. She is currently taking metformin and an anti-hypertensive. Ms. SJ, recently moved within her province, and she found a new primary care clinic that is taking on new patients.
Ms. SJ signs up for a patient-facing provincial application to access her personal health information and creates a shareable patient summary, which will be useful for her upcoming appointment. On the application, she is presented with privacy and security measures, such as a consent notice, passcode, and QR code timeout. After providing her consent and completing the security instructions for her shareable patient summary, the application assembles her patient summary using available data and creates a VHL and QR code, which is displayed on Ms. SJ’s mobile phone, and she is happy to see that she has the option to print a copy. Ms. SJ is ready for her appointment.
Pre-conditions:
Main Flow:
Post-conditions:
A QR code, with a VHL, is created and displayed to the patient for accessing and sharing their patient summary.
The patient provides access to their encrypted patient summary via the QR code on their mobile device or by sharing a secure VHL, (e.g., via email) at the point of care (e.g., walk-in clinic, emergency department). The healthcare provider scans the QR code or accesses the VHL shared by the patient, addressing any security prompts, such as entering a passcode if required, and then may proceed to view/utilize and consume the patient summary.
Pre-conditions:
Main Flow:
Post-conditions:
HCP has access to Patient Summary.
Figure X.X.X.X-3: Use Case Issue and Utilize VHL for a Single Health Document Process Flow
Figure X.X.X.X-2: Use Case Issue and Utilize VHL for a (set of) Health Document(s) Process Flow
This use case has the following business requirement:
Pre-conditions:
Main Flow:
Post-conditions:
Figure X.X.X.X-1: Use Case Issue and Utilize VHL Process Flow
Pre-conditions:
Main Flow:
Post-conditions:
The World Health Organization (WHO) operates a trust network, the Global Digital Health Certification Network (GDHCN), for use by public sector health jurisidictions. The WHO GDHCN uses the notion of a Trust Domain which is defined by a set of:
The PKI operated by the WHO supports a variety of trust domains, two of which are described below.
During the Hajj pilgrimage the Kingdom of Saudi Arabia (KSA) hosts approximately two milliion pilgrims from across the globe as part of a mass gathering event. Temporary hospitals and clinics, comprising over a thousand beds, are established to provide care to the pilgrims over the ?four? week period of Hajj.
Starting with Hajj XXXX, in 2024, pilgrims from Oman, Malaysia and Indonesia were able to share their health records utilizing the International Patient Summary (IPS) with verification of health documents provided through the GDHCN infrastructure.
Pilgrims begin their journey in their home country where they receive a health check and are educated on the use of QR codes (a version of Verifiable Health Links) and provide the consent to share their health records. This consent may be provided verbally or recorded digitally. When recorded, there are two notions of consent recorded:
The verifiable health link is provided by their home jurisidiction during their health check as a QR code.
Depending on the digital infrastructure pilgrim's origin country, jurisidictional policies and digital capabilities (e.g. access to smart phones) of the pilgrim's origin country, the verifable health link may be:
During a care encounter in KSA, the pilgrim provides their verifiable health link as a QR code to their care provider. Once a VHL is shared by a pilgrim during a care enounter in KSA:
Some of the challenges faced during the pilot implementation, though not necessarily to be taken up in this profile, include:
Figure X.X.X.X-1: Pilgrim's Journey Hajj Health Card
This use case has the following business requirement:
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
The Pan American Health Organization (PAHO) and the InterAmerican Development Bank (IADB) are supporting the development of policues and digital infrastructrue to support this need. One particular priority is to improve the continuity of care for internal migrants within the region, by ensuring individuals have access to and can share their vaccination records and the International Patient Summary.
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
While there currently there is no single legal framework that broadly enables data sharing across the region, there are sub-regional networks (e.g. COMISCA, CARPHA) that have policies that can be leveraged in the short term while neccesary data sharing agreements are developed. Thus, individuals in this region will need to be able to move through overlapping trust networks.
Figure X.X.X.X-1: Pan-American Highway for Digital Health Goals
This use case has the following business requirement:
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.
The EVC will allow "Member States to bilaterally verify the authenticity of digital records through an interoperable trust architecture. While similar to the EU Digital COVID Certificate in being a portable vaccination record, the EVC serves a different purpose. Unlike the certificate, which often fulfilled legal or health mandates, the EVC is specifically designed to empower individuals by granting them control over their vaccination information. This empowerment is crucial for ensuring continuity of care for those crossing borders or transitioning between healthcare systems."
The EVC will operate in the context of the European Health Data Spaces that requires detailed information on access the health data to be recorded.
Figure X.X.X.X-1:European Health Data Spaces
For more infomration see Regulation (EU) 2025/327 of the European Parliament and of the Council of 11 February 2025 on the European Health Data Space and amending Directive 2011/24/EU and Regulation (EU) 2024/2847. Specifically:
This use case has the following business requirement:
Not sure if we want to include "Verifiable" health link as an option and Smart Health Link as another option. If so, we should recap SHL use case here. (No pre-coordination of trust)
See ITI TF-2x: Appendix Z.8 "Mobile Security Considerations"
The following is instructions to the editor and this text is not to be included in a publication.
The material initially from [RFC 3552 "Security Considerations Guidelines" July 2003](https://tools.ietf.org/html/rfc3552).
This section should address downstream design considerations, specifically for: Privacy, Security, and Safety. These might need to be individual header sections if they are significant or need to be referenced.
The editor needs to understand Security and Privacy fundamentals.
General [Security and Privacy guidance](http://hl7.org/fhir/R4/secpriv-module.html) is provided in the FHIR Specification.
The FHIR core specification should be leveraged where possible to inform the reader of your specification.
IHE FHIR based profiles should reference the [ITI Appendix Z](https://profiles.ihe.net/ITI/TF/Volume2/ch-Z.html) section 8 Mobile Security and Privacy Considerations base when appropriate.
IHE Document Content profiles can reference the security and privacy provided by the Document Sharing infrastructure as directly grouped or possibly to be grouped.
While it is not a requirement that any given specification or system be
immune to all forms of attack, it is still necessary for authors of specifications to
consider as many forms as possible. Part of the purpose of the
Security and Privacy Considerations section is to explain what attacks have been
considered and what countermeasures can be applied to defend against them.
There should be a clear description of the kinds of threats on the
described specification. This should be approached as an
effort to perform "due diligence" in describing all known or
foreseeable risks and threats to potential implementers and users.
Authors MUST describe:
* which attacks have been considered and addressed in the specification
* which attacks have been considered but not addressed in the specification
* what could be done in system design, system deployment, or user training
At least the following forms of attack MUST be considered:
eavesdropping, replay, message insertion, deletion, modification, and
man-in-the-middle. Potential denial of service attacks MUST be
identified as well. If the specification incorporates cryptographic
protection mechanisms, it should be clearly indicated which portions
of the data are protected and what the protections are (i.e.,
integrity only, confidentiality, and/or endpoint authentication,
etc.). Some indication should also be given to what sorts of attacks
the cryptographic protection is susceptible. Data which should be
held secret (keying material, random seeds, etc.) should be clearly
labeled.
If the specification involves authentication, particularly user-host
authentication, the security of the authentication method MUST be
clearly specified. That is, authors MUST document the assumptions
that the security of this authentication method is predicated upon.
The threat environment addressed by the Security and Privacy Considerations
section MUST at a minimum include deployment across the global
Internet across multiple administrative boundaries without assuming
that firewalls are in place, even if only to provide justification
for why such consideration is out of scope for the protocol. It is
not acceptable to only discuss threats applicable to LANs and ignore
the broader threat environment. In
some cases, there might be an Applicability Statement discouraging
use of a technology or protocol in a particular environment.
Nonetheless, the security issues of broader deployment should be
discussed in the document.
There should be a clear description of the residual risk to the user
or operator of that specification after threat mitigation has been
deployed. Such risks might arise from compromise in a related
specification (e.g., IPsec is useless if key management has been
compromised), from incorrect implementation, compromise of the
security technology used for risk reduction (e.g., a cipher with a
40-bit key), or there might be risks that are not addressed by the
specification (e.g., denial of service attacks on an
underlying link protocol). Particular care should be taken in
situations where the compromise of a single system would compromise
an entire protocol. For instance, in general specification designers
assume that end-systems are inviolate and don't worry about physical
attack. However, in cases (such as a certificate authority) where
compromise of a single system could lead to widespread compromises,
it is appropriate to consider systems and physical security as well.
There should also be some discussion of potential security risks
arising from potential misapplications of the specification or technology
described in the specification.
This section also include specific considerations regarding Digital Signatures, Provenance, Audit Logging, and De-Identification.
Where audit logging is specified, a StructureDefinition profile(s) should be included, and Examples of those logs might be included.
<a name="other-grouping"> </a> </i>
VHL is a building block that is meant to be used together with added security measures, otherwise it is not suitable for exchange in environments where security and provenance cannot be reliably established by other means.
This section is informative, not normative. It is intended to put this profile in context with other profiles. Any required groupings should have already been described above.
The mCSD Profile supports querying for Endpoint(s) for Organizations. The Trust Anchor may store DID (Decentralized IDentifier) as endpoints for Jurisdictions.
<TO DO: insert content>
<TO DO: insert>
IG © 2024+ IHE IT Infrastructure Technical Committee. Package ihe.iti.vhl#0.0.2-current based on FHIR 4.0.1. Generated 2025-04-15
Links: Table of Contents |
QA Report
| New Issue | Issues
Version History |
|
Propose a change