JohnMoehrke
commented
7 months ago We have explicitly not included this in Permission. One rational is that we needed use-cases to drive the solution, rather than just including the solution without a use-case.
Is this asking only of a Permission being able to reference the basis upon which it fits, like Consent supports, without any specifics about what that basis is or how this Permission instance fits. Where the basis pointer could be to an identifier in XACML, or an opaque URL? Or do you want some stack of Permission logic?
It is not clear to me why we should support this in FHIR. I think this is a case where the logic is getting beyond the benefits of having a permission structure that understands the FHIR resource model. Thus for these kind of policy encodings, I would rather we explicitly identify them and indicate that these should be handled by a more formal policy language. We do not intend to invent another standard where there are already standards that exist.
So it is either that we don't yet have a use-case, or that it is legitimately beyond the scope or need of FHIR.
Consent has a policy basis to define/annotate its default behavior (whether being actionable or not), what about Permission?
The policy basis can be defined at org and patient level, not individual policy level. So this resource level field is more for annotation purpose i.e. knowing whether it can be enforced (therefore non-actionable)?
What happens if at the whole system level is default permit, and individual patient wants to have default deny? Which one take more precedence (answer most likely up to each organization, but is there any broader policy/standard that you are aware of?)
In GCP's access control model, deny always win, and its deny by default across both patient and admin: https://cloud.google.com/healthcare-api/docs/fhir-access-control-technical#consent_directive_properties