The link to the IG mHDS IG web page is incorrect in
https://profiles.ihe.net/ITI/TF/Volume1/ch-50.html
(link is done to mCSD instead)

Updated to IG publisher: NPFS, mXDE
New: PCF, sIPS, DSUBm.

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.

Other #16 just added these in the most minimal way. This issue would address updating the Volume 1 flows and diagrams. Likely needing to create named options and have new diagrams.

I have discovered a number of changes that enable a much better rendering of the CapabilityStatements

1. don't include a text element, so as to allow IG builder to create narrative
2. don't include publisher, this will come from the IG details
3. don't include contact, this will come from the IG detail
4. don't include copyright, this will come from the IG detail
5. don't include a version, this will come from the IG detail
6. don't include a publisher, this will come from the IG detail
7. set status to active
8. set experimental to false
9. description is markdown, so leverage markdown for things like links
10. do not put an empty implementationGuide element
11. fhirVersion should be 4.0.1 (later, hope this comes from the IG detail)

Volume 1 is too long and the length will make the finding of text difficult as there is no index or other way of breaking it up for ease of use. I would suggest breaking it into 6 pages (one per 50.x subsection) with an index to make finding the information easier.

now that mCSD, SVCM, and BALP are published in IG form; use the IGs directly like was done with MHD and PMIR.