Difference between revisions of "FHIR Consent - Grahame's model"
(Provided comments on behalf of BHITS/SAMHSA) |
|||
| Line 19: | Line 19: | ||
* blah blah blah | * blah blah blah | ||
| − | == | + | == SAMHSA/BHITS Project Comments/Questions == |
| − | |||
| − | |||
* We need to record how signed the consent! This is a "must have" requirement. Unfortunately "author" is ambiguous. We struggled to find a purpose for in CDA and it was hard to do. We need to record the organization/provider how receives the consent (e.g. authorization to disclose data for research) from a patient or their proxy. Someone has to sign this consent and we need to record that. | * We need to record how signed the consent! This is a "must have" requirement. Unfortunately "author" is ambiguous. We struggled to find a purpose for in CDA and it was hard to do. We need to record the organization/provider how receives the consent (e.g. authorization to disclose data for research) from a patient or their proxy. Someone has to sign this consent and we need to record that. | ||
* Consent.category does not meet any existing requirements ("Classification of the consent statement - for indexing/retrieval" - any of the data elements could be used for retrieval, the patient record will likely be most frequently used for that purpose) and value set would not work for 42CFR or Title 38 comments [http://hl7-fhir.github.io/valueset-consent-category.html] but it's optional so not an issue. | * Consent.category does not meet any existing requirements ("Classification of the consent statement - for indexing/retrieval" - any of the data elements could be used for retrieval, the patient record will likely be most frequently used for that purpose) and value set would not work for 42CFR or Title 38 comments [http://hl7-fhir.github.io/valueset-consent-category.html] but it's optional so not an issue. | ||
| Line 29: | Line 27: | ||
* Consent.securityLabel - not sure how this applies to a consent. | * Consent.securityLabel - not sure how this applies to a consent. | ||
* Consent.data.meaning -- may be better described as "Consent.data.type" because the "meaning" is tricky but the "coded type" is more straightforward. | * Consent.data.meaning -- may be better described as "Consent.data.type" because the "meaning" is tricky but the "coded type" is more straightforward. | ||
| − | |||
* Consent.except -- may be better described as Consent.condition. | * Consent.except -- may be better described as Consent.condition. | ||
* Consent.except.actor is referring to the Consent.actor? Should we just use a contained resource? Is this where we refer to receving provider? | * Consent.except.actor is referring to the Consent.actor? Should we just use a contained resource? Is this where we refer to receving provider? | ||
* Consent.except.data is referring to the Consent.data or is it another structure distinct from the Consent.data? Basically can I specify some data in Consent.data and some additional data sets in Consent.condition/except? | * Consent.except.data is referring to the Consent.data or is it another structure distinct from the Consent.data? Basically can I specify some data in Consent.data and some additional data sets in Consent.condition/except? | ||
| − | |||
| − | |||
==Lloyd McKenzie comments/questions== | ==Lloyd McKenzie comments/questions== | ||
Revision as of 03:07, 20 June 2016
Notes of June 17th, 2016
Grahame has drafted a Consent resource that in his view harmonizes various proposals including Privacy Consent Directive IG, Privacy Consent Resource, Consent Tracker.
http://hl7-fhir.github.io/consent.html
Grahame will present this to the CBCC workgroup during the regular CBCC Tuesday meeting on June 21. (See CBCC for details)
Please review Grahame's model first. Please add comments below that we can use for future discussions and improvements. (Rather than email list that tends to be noisy and lossy)
STU3 timeframe can be found described at https://onfhir.hl7.org/2016/05/20/fhir-meeting-report-montreal-may-2016/
Contents
Informal Comments and Questions
please provide your comments and questions here.
John Moehrke Comments/questions
- blah
- blah blah
- blah blah blah
SAMHSA/BHITS Project Comments/Questions
- We need to record how signed the consent! This is a "must have" requirement. Unfortunately "author" is ambiguous. We struggled to find a purpose for in CDA and it was hard to do. We need to record the organization/provider how receives the consent (e.g. authorization to disclose data for research) from a patient or their proxy. Someone has to sign this consent and we need to record that.
- Consent.category does not meet any existing requirements ("Classification of the consent statement - for indexing/retrieval" - any of the data elements could be used for retrieval, the patient record will likely be most frequently used for that purpose) and value set would not work for 42CFR or Title 38 comments [1] but it's optional so not an issue.
- Question 1: is the Consent.organization the entity that received the consent from the patient or their proxy? It's unclear...
- Consent.policy "policy that this consents to"... I think I understand the intent but we need to clarify how the consent relates to a specific policy (e.g. DURSA, 42 CFR Part 2, Title 38) .
- Consent.actor - this was amibiguous in Contract and it's unclear "Who|what controlled by this concept (or group, by role)" - what concept? It would be nice if we could clarify these data elements.
- Consent.securityLabel - not sure how this applies to a consent.
- Consent.data.meaning -- may be better described as "Consent.data.type" because the "meaning" is tricky but the "coded type" is more straightforward.
- Consent.except -- may be better described as Consent.condition.
- Consent.except.actor is referring to the Consent.actor? Should we just use a contained resource? Is this where we refer to receving provider?
- Consent.except.data is referring to the Consent.data or is it another structure distinct from the Consent.data? Basically can I specify some data in Consent.data and some additional data sets in Consent.condition/except?
Lloyd McKenzie comments/questions
The name/value pair "actor" relationship goes against MnM's recommended practice of having explicit associations. Explicit named associations makes profiling easier, makes it easier to manage the 80%, allows proper assertion of w5 mappings, allows consistent ordering of elements with other resources, etc. The need for "additional" relationships can be handled by extensions (which is also easier to discover and manage than a reference to some code from an unknown code system). As well, some of the listed codes seem like they either don't apply (or at least probably aren't in the 80%) where actor is re-used in "except".
Similar concern for "data". Are we confident all of the data.meaning codes are in the 80%? If not, it should also be represented with explicit relationships rather than a name-value pair.
I don't understand "purpose"
