I doubt that I'm alone in being totally confused by Eve's use-case as it relates to developing a HEART profile. But just in case, I'm putting my concern in a separate thread. I'm cross-posting to the UMA group because there's an active thread there about scopes right now.
Let me try to convince you that there's no need for HEART to be profiling privacy and that trying to do so would do more harm than good.
During today's HEART call we agreed that "Alice completely trusts her UMA Authorization Server." I take this to mean that Alice has no reason to restrict her Resource Type registration with the UMA Authorization Server to anything less than 'FHIR'/patient/* . Any subsequent restrictions or scoping would then be decided by the AS based on Alice's policies and client needs.
FHIR, in its evolving wisdom, will define and standardize hundreds of resource types below patient as 'FHIR'/patient/xyz. Alice's AS will take the applicable FHIR standard and expose a policy-setting UI to Alice well before the time that the FHIR client shows up.
The FHIR clients will have access to the FHIR standard and will therefore know what the standard resource types are. Of course, some FHIR resource servers may not implement the entire set of hundreds of potential resource types, maybe because they don't handle that kind of patient data, but let's not get ahead of ourselves.
The point of UMA is that Alice can set and can change her policies at any time between the time of resource registration and before the FHIR client shows up to her AS. Alice can do this policy setting based on either:
- the published set of FHIR patient-level resource types, or
- the subset of resource types that the particular FHIR Resource Server actually supports for all patients, or
- the subset of resource types that the FHIR Resource Server supports in her particular case.
Which brings us to my question: What purpose is served by HEART profiling some subset of the FHIR patient-level resource types? Presumably it's to improve her user experience at her AS by "graying out" privacy options supported by the FHIR standard but not offered by that particular FHIR Resource Server. This "graying out" is purely a user experience issue. It has nothing to do with interoperability because no harm is done if Alice chooses to restrict or enable resource types that are not supported by the particular resource server anyway.
Much as I like to advocate for a good user experience, giving the FHIR Resource Server a particular subset of "privacy-related" resource types as a profile will do much more harm to interoperability and information blocking than it will do good. It sets a low bar. It restricts the kind of policies that Alice could set if the scope calculus is always done at the point when the FHIR client presents to the AS.
In general, (not just FHIR or HEART) any resource server is free to publish the actual subject-level resource types it supports. This is easier when there's a standard. UMA may or may not also provide an endpoint for communicating the resource types that a particular resource server makes available to as particular resource subject. This is a nice-to-have to improve the user experience by "graying out" the resource types that are not available for that particular subject but it is not an interoperability issue.
PS: It is often pointed out that merely "graying out" certain resource types for a particular subject could leak private information. This is not an issue if "Alice completely trusts her UMA Authorization Server." In cases where Alice does not have complete trust of her AS, then indeed, she needs to restrict the types of resources that are registered with the AS by using the FHIR resource server's patient portal or some other out-of band mechanism that is beyond both UMA and HEART.
Adrian