Difference between revisions of "FHIR Consent July 13, 2016"
Line 141: | Line 141: | ||
...a declaration for a request for data, because I am gong to use for POU (i.e. treatment purpose) | ...a declaration for a request for data, because I am gong to use for POU (i.e. treatment purpose) | ||
requester may assert why they are making the requeset--its an attribute request, not of the user (or of the data), POU is if used its an environmental attribuete, not a code on the data--any healthcare data can be used for a number of things...we lable the RULES of how/we apply to the data | requester may assert why they are making the requeset--its an attribute request, not of the user (or of the data), POU is if used its an environmental attribuete, not a code on the data--any healthcare data can be used for a number of things...we lable the RULES of how/we apply to the data | ||
+ | |||
+ | |||
+ | more guidance requested for front matter | ||
+ | |||
+ | motion to adjorn (JohnMoerke) --[[User:Suzannegw|Suzannegw]] ([[User talk:Suzannegw|talk]]) 16:30, 13 July 2016 (EDT) | ||
proposal: ''use purpose'' (vs purpose of use) | proposal: ''use purpose'' (vs purpose of use) |
Latest revision as of 20:30, 13 July 2016
HL7 CBCC FHIR Consent Working Meeting
Back to FHIR Consent Directive Project Main Page
Attendees
Member Name | x | Member Name | x | Member Name | x | Member Name | |||||
---|---|---|---|---|---|---|---|---|---|---|---|
x | Johnathan ColemanCBCC Co-Chair | x | Kathleen Connor FM Co-Chair | x | John MoehrkeSecurity Co-Chair | x | [mailto: Grahame Grieve] FHIR | ||||
Alexander Mense Security Co-Chair | . | Jim Kretz | x | Tarik Idris | x | Ken Salyards | |||||
x | Suzanne Gonzales-Webb CBCC Co-Chair | . | Diana Proud-Madruga | x | [mailto: Oliver Lawless] | [mailto: Patrick Loyd] | |||||
x | M'Lynda Owens | x | David Staggs | x | Glen Marshall | x | Ken Sinn (Canada) | ||||
x | Rob Horn | Beth Pumo | William Kinsley | . | [mailto: Wayne Kubick] | ||||||
x | Serafina Versaggi | . | [mailto: David Pyke] | x | Mike Davis | x | Mohammad Jafari (VA/ESC) | ||||
Igor Sirkovich | Adrian Gropper | . | [mailto: Andrew Rampolla (SSA)] | [mailto: Eve Mahler] | |||||||
[mailto: Joe Lamy], Aegis | x | [mailto: Ioana | x | [mailto: Tank Idris |
Back to FHIR Consent Directive Project Main Page
Agenda
- FHIR Consent changes made by Grahame - update
- Discussions from e-mail/blog
- *preference over e-mail discussion or blog?
Meeting minutes
John is confident that we're ready for ballot and that results from implementation will be enlightening.
- Kathleen feels that there are at least two issues that need to completed before Friday.
- Security labels (bifurcated or one)
- how can we ensure Provenance that holds the signature, is there a way to make sure if the policy reuires..
- POU as an attribute of consent; we need a way to have if the consent is a part of POU - ioana
- it doesn'thave it any more at term level or at the top
- we are working on defining the wording of POU (will be avialbel next week) Mike
- POU as an attribute of consent; we need a way to have if the consent is a part of POU - ioana
We need to timebox the issues
POU I'm giving you the consent to disclose my information to be more explicit, you start execptions
- to make the change back, that would be acceptable
MOTION (John/KenSalyard): make a coded element; to add the POU as in treatment, research, etc. to the root; to support POU as specified in a consent.
Discussion: this is a way to discover to find applicable ways for POU (discoverability of relevant consent); what does this mean when this element is empty? (answer: TBD... currently we will make the 1:1 the use case for this element is to discover consents that apply to a POU. (It should not change the meaning of the policy)
Objections: 1 (Kathleen); abstentions: 1 (M'Lynda); Affirmative: 15
Discussion: Cardinality - cases for 0 to many / 1 to many
- if policy is complex with multiple POU; in different circumstance not all can be used for discoverable
- 0 to many could be a good choice; if null it could mean any purpose which makes query difficult. with null POU it can mean any purpose; I'm not hearing a good case for a null value.
- what is the meaning we attaché to null
- does this require a national extension
one possibility is that consent is implied (as a use case for POU as null)
- patients are asked for at least one reason; we are specifically prohibited for asking information like this
- what should go in the resource.. what mike is saying we need at least one search that is valid
0 to many is sufficient...and determine/confirm the value once implemented
- what does zero (0) mean;
- an open ended consent that is organizationally constrained; if organization does not have to specifiy POU
- to be clear this is for discoverablity / and not computability purposes.
MOTION: to go with zero to many for Cardinality (Kathleen/Glen) Abstentions: none; Against: none; Favor: 16
Will this element say that this is directed toward discoverability (vs something else...) is there a way to label
'POLICY to be 1 to 1 allowing policy to nest as they did originally.
- if patient agrees to more than one policy; if multiple consent or single; if you have multiple you can combine to create a single policy and everyone had a touch to understand what that single policy is.
- this issue comes up in OASIS XACML they define policy of rule sets-they use the notion that policy can be a set of rules; the cardinality of policies can be one. but can be composed of multiple rules
MOTION: Leave the resource as is and add an extension to track the policy origin of the rules to which the exception applies to. Grahame/Kathleen VOTE: Objections: none; Abstentions: none; Affirmative: 14
Discussion: Those who need to apply policy as an extension can do so.
Security Labels suggest to go to security labels and let implementers figure out how to parse them
the purpose element should point at POU element
security label we have handling instructions that are policy elements that apply to it, but are not labels on the data...but they are not the label . its reasonable that they're together.. its not specific that wherete its a confidentiality is normal or restrictive; it applies to this particular thing overall its not contingent here where we use the purpose on the exception i.e. where we hold authorization for treatment except for emergency treatment what john is the reason for the purpose element for an exception is that these are actions for this exception applies. if someone is doing a query with their security assertion containing a POU for treatment; if I have an exception i.e. emergency treatment then that is a way the exception rule in fhire
- can header do the same thing
No there is ambiguity; it doesn't make sense to tag a lab result with a POU
- these are handling caveats not part of the
POU has multiple meanings ; it can e a rule or environmental attricbute -- depending on how you use it. its a compact way of stating
MOTION: clarify the definition of POU and clearly delineate from security labels and AND limit the valueSet for POU to ActReason //motion removed; per request.
the main different is the context of the transaction; if there is a POU obligation as a data label on a data object--this is separate from the data being used for x purpose
- what am I going to do with the data when I get it
- is there a restriction on the data
...a declaration for a request for data, because I am gong to use for POU (i.e. treatment purpose) requester may assert why they are making the requeset--its an attribute request, not of the user (or of the data), POU is if used its an environmental attribuete, not a code on the data--any healthcare data can be used for a number of things...we lable the RULES of how/we apply to the data
more guidance requested for front matter
motion to adjorn (JohnMoerke) --Suzannegw (talk) 16:30, 13 July 2016 (EDT)
proposal: use purpose (vs purpose of use) Mike/Mohammed working on white paper and will share with clarify if policy rather than an attribute value consent accept handling caveat
Provenance