Nesting Permission within Consent resource use cases?

[sherry-s-yuan]

Currently the use cases for Permission and Consent seems disjoint, Consent seems to be only for Patients, and Permission is for store administrators, under what use cases would Permission needs to be nested in a Consent resource?

[JohnMoehrke]

The use-case that I have already put into the publication is one where the organization enforcing Consent does not want to use the Consent.provision structure, and prefers the structure in Permission. We allow this, we do not mandate either architecture.

[sherryyuan-gcp]

Thanks for the clarification, this certainly might become a user need in the future. I have few more question about this topic:

1. If Permission is used directly as Consent.provision, wouldn't there be a lot of duplicated fields (e.g. status, date, justification etc)? or is the proposal to only re-use the rule field
2. Consent provision currently have a recursive structure, if user uses Permission, the exception needs to be represented in a ordered list way?
3. Would it make sense to have admin policy rules to appear in a patient consent? (given the other proposed permission use cases)

[JohnMoehrke]

1. duplicate fields are not a problem. That region can choose what to do.
2. Yes. That benefit of Permission may be one reason they choose to use Permission over Consent.provisions
3. I don't understand the question.

Core standards role is to enable variations that are reasonable. The role of an Implementation Guide is to constrain for that IG defined use-case and setting. That is to say that an IG can certainly pick. However if we don't have the core standard able to support the variations, then no IG can chose.

[sherryyuan-gcp]

Thanks! supporting variation makes sense

Some clarification for question 3: base on the proposed permission use cases, permission resource need to encode rules such as Use permission to enforce rules on when the AuditEvent/Provenance should be generated. When such rule appear in Consent resource, it would be somewhat confusing for Patient to be able to control this?

This is just one of the example use case, there may be other admin-specific activities/use cases not applicable to Consent resource.

[JohnMoehrke]

note, it would be more productive to have these chat discussion on chat.fhir.org

that which shows up in a Consent.provision would only be rules specific to that individual patient. If an organization wants to enable individual rules around ANYTHING they can do that. It is not HL7 role to forbid any organization from making stupid policies. We must enable any reasonable policy. I think it is reasonable for a PHR product to allow a patient to turn on/off an accounting of disclosures. I am not about to model that, but I am not going to forbid that kind of policy.