Difference between revisions of "FHIR Consent - Grahame's model"
JohnMoehrke (talk | contribs) |
|||
Line 18: | Line 18: | ||
* blah blah | * blah blah | ||
* blah blah blah | * blah blah blah | ||
+ | |||
+ | ==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" |
Revision as of 00:31, 19 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/
Informal Comments and Questions
please provide your comments and questions here.
John Moehrke Comments/questions
- blah
- blah blah
- blah blah blah
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"