The MHDS Profile specifies how a collection of IHE profiles can be used by communities for exchanging health information. These IHE profiles include support for patient identification, health document location and retrieval, provider directories, and the protection of privacy and security.
When asked to propose changes on MHDS due to the update of the Secure Retrieve Trial Implementation, I faced some open questions to be discussed in the ITI Technical Committee.
Comparing the options in MHDS with the options in its XDS.b counterpart, I realized that
XDS.b mainly defines actor options for the core document management, e.g. Asynchronous Web Services
Exchange, On-Demand Documents, PIX Feed for patient identity cross referencing. An exception is the
Basic Privacy Enforcement option which adds functionality for authorization, without going into details,
particularly an option for using XUA to convey the user roles and attributes for the role/attribute
based authorization decisions is not defined in XDS.b. This is fine, since the the ITI technical
framework is modular and any actor of the profile can be grouped with any other actor of the
framework, if one requires a specific functionality and the corresponding transactions in an
application.
MHDS on the other side describes the details related to the consent manager and authorization option,
i.e., describes in detail how access decision shall be made by the authorization server actor based in
the consent and the requirement to enforce the decision in the resource server actor, but does
not distinguish between the consent given to authorize the access to resources for the (mobile)
application and the consent to authorize access to resources for the user trying to access using
the application (mobile).
But like in XUA, in IUA we use the OAuth token extensions to transport some additional attributes
(e.g., role, purpose uf use, etc.), which shall be used by the resource server to make access
decisions based on the resource owner consent. Here Secure Retrieve comes into play: Instead of
implementing the decision making in all resource servers of your infrastructure, you can delegate it
to the Authorization Decision Manager actor defined in the Secure Retrieve Trial Implementation and
use an Authorization Decisions Query [ITI-79] transaction to retrieve the access decisions.
Secure Retrieve is more suitable for authorization decisions based on complex rules defined in the
consent. In simple cases the use of Secure Retrieve may add to much complexity and the access decision
can be made be the resource server or even by extending the IUA authorization server. Such cases are
currently discussed in the FHIR community in the context of Smart on FHIR. This approach is handy for
simple situations but will quickly become problematic for more complex authorization rules.
So back to the main question: What is the implication of Secure Retrieve for MHDS?
Answer 1: None, if the current description focusses on simple situations only and alle access
decisions can be made by the IUA authorization server (maybe be extending the scopes defined in IUA).
Answer 2: Add an option for complex situations, in which the authorization rules are complex enough
to justify the use of Secure Retrieve. Using Secure Retrieve the MHDS Document Registry optional
grouping with the IUA resource server actor shall be replaced with the Authorization Decisions
Verifier actor defined in the Secure Retrieve Trial Implementation.
Answer 3: Remove the Consent Manager Option and the Authorization Option. The ITI technical
framework is modular and any actor of the MHDS can be grouped with any other actor of the
framework, if one needs a specific functionality and the corresponding transactions in your
application. This would simplify the MHDS IG and increase it's readability. We can add a note
in the Security Considerations pointing to the possible groupings to manage authorization.
When asked to propose changes on MHDS due to the update of the Secure Retrieve Trial Implementation, I faced some open questions to be discussed in the ITI Technical Committee.
Comparing the options in MHDS with the options in its XDS.b counterpart, I realized that XDS.b mainly defines actor options for the core document management, e.g. Asynchronous Web Services Exchange, On-Demand Documents, PIX Feed for patient identity cross referencing. An exception is the Basic Privacy Enforcement option which adds functionality for authorization, without going into details, particularly an option for using XUA to convey the user roles and attributes for the role/attribute based authorization decisions is not defined in XDS.b. This is fine, since the the ITI technical framework is modular and any actor of the profile can be grouped with any other actor of the framework, if one requires a specific functionality and the corresponding transactions in an application.
MHDS on the other side describes the details related to the consent manager and authorization option, i.e., describes in detail how access decision shall be made by the authorization server actor based in the consent and the requirement to enforce the decision in the resource server actor, but does not distinguish between the consent given to authorize the access to resources for the (mobile) application and the consent to authorize access to resources for the user trying to access using the application (mobile).
While the first is managed by the IUA authorization server, the latter is not intended by IUA. IUA is based on OAuth which also intends to handle the authorization of applications (or clients) to act on behalf of the user, but not the authorization of the user to access the resources (see https://profiles.ihe.net/ITI/IUA/index.html#34-internet-user-authorization-iua-profile and https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-07#name-introduction-4).
But like in XUA, in IUA we use the OAuth token extensions to transport some additional attributes (e.g., role, purpose uf use, etc.), which shall be used by the resource server to make access decisions based on the resource owner consent. Here Secure Retrieve comes into play: Instead of implementing the decision making in all resource servers of your infrastructure, you can delegate it to the Authorization Decision Manager actor defined in the Secure Retrieve Trial Implementation and use an Authorization Decisions Query [ITI-79] transaction to retrieve the access decisions.
Secure Retrieve is more suitable for authorization decisions based on complex rules defined in the consent. In simple cases the use of Secure Retrieve may add to much complexity and the access decision can be made be the resource server or even by extending the IUA authorization server. Such cases are currently discussed in the FHIR community in the context of Smart on FHIR. This approach is handy for simple situations but will quickly become problematic for more complex authorization rules.
So back to the main question: What is the implication of Secure Retrieve for MHDS?
Answer 1: None, if the current description focusses on simple situations only and alle access decisions can be made by the IUA authorization server (maybe be extending the scopes defined in IUA).
Answer 2: Add an option for complex situations, in which the authorization rules are complex enough to justify the use of Secure Retrieve. Using Secure Retrieve the MHDS Document Registry optional grouping with the IUA resource server actor shall be replaced with the Authorization Decisions Verifier actor defined in the Secure Retrieve Trial Implementation.
Answer 3: Remove the Consent Manager Option and the Authorization Option. The ITI technical framework is modular and any actor of the MHDS can be grouped with any other actor of the framework, if one needs a specific functionality and the corresponding transactions in your application. This would simplify the MHDS IG and increase it's readability. We can add a note in the Security Considerations pointing to the possible groupings to manage authorization.