1. HL7 can only produce Interoperability standards. It can't define Policy, Architecture, or Implementations.
2. We thus can't just pick one architecture (e.g. OAuth+UMA) and stop. We must build to fit a reasonable set of architectures.
3. We thus can't jut pick one policy (e.g. patient home) and stop. We must build to fit reasonable a set of policies.
4. We thus can't just pick one implementation (e.g. single server) and stop. We must build to fit a reasonable set of implementations.
5. FHIR should focus on only what systems do today, not what we want them to do.
6. FHIR should put into common extensions those things that we want them to do (e.g. Identified disclosure notification endpoint)
7. Simple is always better
This means that sometimes a specific Policy, Architecture, and Implementation might not need our solution at all. This is likely the case if someone picks the HEART (OAuth+UMA) model, were the current FHIR Consent adds no value since all the consent policy management is handled inside the UMA authority.
Adrian 'working defintion of consent' is much like what we have used. I reproduce it here with attribution as I like his structure:
I (Adrian) propose a working definition of consent as:
- A contract between a person and an institution that describes a policy of the person and a duty of the institution.
- A policy is not an attribute. An attribute can be measured and asserted by a lab or a nurse. A policy can only be asserted by the patient or their custodian - hence, the need for a contract.
- A contract combines a series of terms into one accountable transaction.
- The terms of a consent transaction MUST include:
- An institution that carries the duty of interpretation.
- A subject - the patient
- A custodian who is allowed to assert a policy (the patient or legal guardian of the patient)
- A resource (potentially any non-aggregated FHIR resource, including de-identifed person-level resources)
- A policy to be interpreted by the institution related to use of the resource (this will become a scope for authorization to access the resource at some future time).
- A notification endpoint chosen entirely by the custodian for transparency in how the institution is interpreting the policy to issue each authorization.
- A signature of the custodian
- A signature of the institution that will issue the authorizations
- A jusrisdiction for the contract,
I think this maps well to what I have already created in the FHIR Consent resource:
That said, we can always improve. I welcome these constructive comments. I welcome suggestions for better name of the Resource (Consent) and better names and definitions for the element names.
I have already realized through discussions with Adrian, Oliver, Rob, Kathleen, and Lloyd that the model I have could be further simplified, extended, and clarified.