search

IHE / ITI.PCF

The Privacy Consent on FHIR (PCF) Profile provides support for patient privacy consents and access control where a FHIR API is used to access Document Sharing Health Information Exchanges. This profile includes both Consent profiling and access controls profiling of oAuth access token.
Creative Commons Attribution 4.0 International
2 stars 2 forks source link

[Bug]: Consent Resource Profiles Overly Restrictive #28

Closed slagesse-epic closed 1 year ago

slagesse-epic commented 1 year ago

Contact Details

slagesse@epic.com

Section Number

All Consent Profiles

What is wrong

Consent.policy.authority and Consent.policyRule are forbidden. Based on my reading of the description of those fields, they could be included for informational purposes with no expectations on the Consent Enforcer to process them. Therefore, forbidding them is more restrictive than necessary, and it would be better to simply not profile those elements.

Describe the solution you'd like

No response

Relevant log output

No response

Priority

{"Low"=>"Typo or other minor classification that an editor can manage. Requires no group discussion."}

Code of Conduct

JohnMoehrke commented 1 year ago

They are forbidden in PCF as PCF has no use for them. It is certainly possible to populate them, but that population would be use beyond that defined in PCF and thus would be not compliant with PCF.

leaving them optional without a use-case for their use seems not appropriate. However we could define that they are optional, and would be used for some specific meaning. I think we would need some defined meaning with some defined examples.

That said, we could use one of the new replacements for must-support, such as no-error, can-ignore. This does not seem useful.

slagesse-epic commented 1 year ago

I don't see a reason why we need to do anything at all with them. If they are not constrained, then they fall under the base FHIR definition. Which is to say they do not play a role in PCF, but might play a role in other implementation details happening in parallel to PCF.

Forbidding the population of these elements makes support for PCF harder, because it means that a system that wants to populate these cannot be compliant with PCF while populating them. On the other hand, I don't see what problem allowing them would pose, since an actor just doing PCF would ignore them, and and they are not considered modifier elements and so can be safely ignored according to the base FHIR specification.

JohnMoehrke commented 1 year ago

agree to allow. explain that the decision actor can ignore.