Stream: implementers
Topic: consent
Igor Sirkovich (Mar 10 2016 at 16:37):
Hello, I'm wondering about a status of the Consent Directive profile. My understanding is that it's still work in progress, but I'm wondering what are the timelines and where I can find the most recent draft version to see how different it is from https://www.hl7.org/fhir/consentdirective.html.
John Moehrke (Mar 10 2016 at 16:44):
It is moving, but not fast. Please, Please, Please join us and help us be productive. http://wiki.hl7.org/index.php?title=HL7_FHIR_Consent_Directive_Project
Igor Sirkovich (Mar 11 2016 at 14:52):
Thank you John! I'm not a privacy expert, but I will see how I can contribute. I'm wondering if there is/was a discussion about temporary consent override, which is different from the "Break the Glass", though it has some similarity. In this scenario, a patient has either full or partial block, but at the time of the visit gives a temporary (valid for a few hours) consent to access her/his records. In this scenario, the initial request for data (in our case, medication dispenses) returns "suppressed" in OperationOutcome to indicate that some information was masked, then a provider sends a statement that the patient has signed a temporary consent (the actual consent might be scanned and submitted the consent management system later) and gets access to all the records. We need to define this statement / resource asserting that the patient has signed a temporary consent and are just wondering if anyone has already implemented similar functionality so that we don't reinvent the wheel.
John Moehrke (Mar 11 2016 at 16:50):
Igor, That would be simply a consent with a timebound in Contract.applies set to the small window of time.
John Moehrke (Mar 11 2016 at 16:51):
What help we need is people to come in and say... My urgent need is X... because we are churning on things that are not as productive. I would rather be building this in an agile way.
John Moehrke (Mar 11 2016 at 18:32):
Can I get feedback from this community on what their TOP needs are for Privacy Consent? I am interested in using this to drive progress.
Igor Sirkovich (Mar 11 2016 at 19:11):
Thank you John! I just wanted to confirm whether we can use http://hl7-fhir.github.io/pcd/consentdirective.html to be aligned with the most current version of the consent directive or, because it's work-in-progress, it would be safer to use http://hl7.org/implement/standards/fhir/consentdirective.html
John Moehrke (Mar 11 2016 at 19:13):
Yes.
John Moehrke (Mar 11 2016 at 19:14):
there has not been much improvements since then. Mostly cosmetic in definitions and names of elements
John Moehrke (Mar 11 2016 at 19:14):
shoudl be some new vocabulary apperaring soon.
John Moehrke (Mar 11 2016 at 19:14):
I recommend looking at the examples... I recommend them because I wrote them,. :-)
Igor Sirkovich (Mar 12 2016 at 21:52):
Thank you John!
Pascal Pfiffner (Mar 14 2016 at 17:58):
We're using a (DSTU-2) Contract to indicate consent to participate in a clinical trial in a ResearchKit app. Sounds to me the ConsentDirective is aimed differently, or is the intention to also cover these aspects?
Grahame Grieve (Mar 14 2016 at 20:10):
I think that's in scope
Simone Heckmann (Mar 14 2016 at 20:40):
@Pascal Pfiffner did you look at how C3-Pro is managing Consent? The are doing pretty much the same thing!
Simone Heckmann (Mar 14 2016 at 20:40):
http://c3-pro.chip.org/index.html
Simone Heckmann (Mar 14 2016 at 20:40):
Ah. wait. You're part of the team
Simone Heckmann (Mar 14 2016 at 20:41):
Stupid me.
Pascal Pfiffner (Mar 14 2016 at 21:15):
Thanks Grahame, might make sense to follow this more closely, then. Thanks Simone, good to see people know about it. :)
John Moehrke (Mar 15 2016 at 14:27):
Today we are continuing to create a Privacy Consent Directive as an implementation guide (profile) upon Contract. We have outstanding comments that this path is more complex than creating a resource specic to privacy consent. We will evaluate the complexity once we have it modeled. so we need help getting it modeled so we can get to the evaluation of complexity. It seems logical at times, it seems complex at times...
John Moehrke (May 30 2016 at 13:58):
Given fantastic input from Adrian, Lloyd, Rob, Grahame, and Oliver; I have improved the Consent prototype on the current FHIR build. Please review and continue to offer improvement opportunities. I hope that we can improve this enough for the CBCC committee and FMG committee to agree it is a better pathway. http://hl7-fhir.github.io/consent.html
and I describe the changes I made on my blog at -- http://healthcaresecprivacy.blogspot.com/2016/05/simplified-fhr-privacy-consent.html
Lloyd McKenzie (May 30 2016 at 20:10):
Much improved John. Thank you for taking this on.
Grahame Grieve (May 30 2016 at 21:27):
so David's email demonstrates that it's important to rename the resource. I propose "PrivacyConsent" based on the scope
Lloyd McKenzie (May 30 2016 at 22:26):
Curious to hear from the implementer community - would it make your lives easier to have a single resource that handles all sorts of consent (information disclosure, procedures, etc.) or would you rather have privacy consents as a distinct artifact from other consent types?
Grahame Grieve (May 30 2016 at 22:43):
Personally, I think they are different things. Consent to perform care != Consent to share information != Advance Care Directive
Erich Schulz (May 30 2016 at 22:52):
@Grahame Grieve if you compare the differences in the 3 "declarations of my will" that you list to the differences in the various actions encodable within the prodedure resource then I think you will find they are more similar than different
Grahame Grieve (May 30 2016 at 22:53):
not my personal experience with ACD - a long list of questions and answers....
Erich Schulz (May 30 2016 at 22:55):
X makes statement of behalf of Y, having been given A information by Z, [allowing|disallowing [action B given precondition C]... having received information D
Erich Schulz (May 30 2016 at 22:56):
@Grahame Grieve which is different from "I will allow everyone to see my U&Es, but only my GP to see my urethral swab"?
Grahame Grieve (May 30 2016 at 23:08):
Erich: here's an actual ACD for someone in my family:
Grahame Grieve (May 30 2016 at 23:09):
I have read the Advance Health Care Directive and choose the following options.
If I temporarily lose capacity and am unable to give directions for my health care because of injury
or illness, I want my health-care providers to give me all available treatment.
There are no special conditions that my health-care providers should know about, such as asthma or
any allergy to medication
I do not have any religious beliefs that may affeet my treatment.
If I have a terminal, incurable, or irreversible illness or condition,
. or am in a persistent vegetative state,
. or am permanently unconscious,
. or am so seriously ill or injured that I am unlikely to recover to the extent that I can survive
without the continued use of life-sustaining measures, then:
. I request that everyone responsible for my care initiate only those measures that are considered
necessary to maintain my comfort and dignity, with particular emphasis on the relief of pain
. I request that any treatment that might obstruct my natural dying either not be initiated or be
stopped
. I request that unless required for my dignity and comfort as part of my palliative care, no surgical
operation is to be performed on me
If I am in the terminal phase of an incurable illness:
. I do not want cardiopulmonary resuscitation
. I do not want assisted ventilation
. I do not want artificial hydration
. I do not want artificial nutrition
. I do not want antibiotics
If I am permanently unconscious (in a coma):
. I do not want cardiopulmonary resuscitation
. I do not want assisted ventilation
. I do not want artificial hydration
. I do not want artificial nutrition
. I do not want antibiotics
If I am in a persistent vegetative state:
. I do not want cardiopulmonary resuscitation
. I do not want assisted ventilation
. I do not want artificial hydration
. I do not want artificial nutrition
. I do not want antibiotics
If I am so seriously ill or injured that I am unlikely to recover to the extent that I can live without
the use of life-sustaining measures:
. I do not want cardiopulmonary resuscitation
. I do not want assisted ventilation
. I do not want artificial hydration
. I do not want artificial nutrition
. I do not want antibiotics
Residential Care:
I strongly agree that not being able to recognise people who are important to me would be
unacceptable to me
I strongly agree that not being able to communication would be unacceptable to me
I agree that not being able to eat by mouth would be unacceptable to me
I strongly agree that not having control of my bladder or bowels would be unacceptable to me
If I were in a residential care facility and any of the above unacceptable levels of functioning
applied, I would rather go to hospital if any of the following conditions applied:
. a severe chest infection
. breathing difficulties
. pain that was difficult to control
. a broken bone (eg arm or hiP)
. a urinary tract infection
. chest Pain
If I were in a residential care facility and could no longer speak for myself, and had reached a stage
where I required end-of-life care (palliative care), I would prefer to remain in the residential care
facility rather than go to hospital.
I have not given consent for the removal of my tissue or organs after death'
I do not wish to give consent to the removal of my tissue or organs after death.
I do not have any particular wishes about my health care other than those listed above.
I do not wish to specify anyone who is mi to be contacted about my treatment.
If my doctor is to be involved in my care, his details are:
XXXXXXXXXXXXXXX
My appointed Personal Care and Welfare Attorney is XXXXXXX, of XXXXXXXXXXXXXXXXXX. I did not appoint any other Attorney of that nature.
If XXXXXX is to make decisions in connection with my care as outlined above he should consult
with and if possible obtain agreement from XXXXXXXXXXXXXX.
If I lose the capacity to make health-care decisions for myself and the directions in this directive are
inadequate for any reason, I understand that XXXXXXXXXXXXX can make decisions about health matters for
me.
I understand the nature and the likely effects of each direction in this directive. I understand that a
direction operates only while I have impaired capacity for the matter covered by the direction.
I understand that I may change or revoke a direction in the directive at any time where I have the
capacity to make a decision about the matter covered by the direction.
Erich Schulz (May 31 2016 at 01:03):
yup that that is 90% statements along the lines of "given C I give|withhold consent for B to occur"
Grahame Grieve (May 31 2016 at 01:04):
right 90% of it is. But an ACD has other things as well.
Erich Schulz (May 31 2016 at 01:05):
wrong thread @Grahame Grieve :-)
Rob Hausam (May 31 2016 at 01:06):
ah - that explains it!
Erich Schulz (May 31 2016 at 01:06):
"given informationation D"
Erich Schulz (May 31 2016 at 01:07):
there's some differences in definition of the parties...
Erich Schulz (May 31 2016 at 01:08):
information release is giving permision for transfer between 2 parties
Erich Schulz (May 31 2016 at 01:10):
whereas procedural consent (and ACD) gives consent for "B" to occur in general (performer unspecified)
Erich Schulz (May 31 2016 at 01:11):
so unpacking B... in information consent it is for G to release H to J
Erich Schulz (May 31 2016 at 01:12):
in procedural consent B is "for G to perform K on Y"
Grahame Grieve (May 31 2016 at 01:12):
let's just RDF...
Erich Schulz (May 31 2016 at 01:23):
rdf?
John Moehrke (May 31 2016 at 15:14):
The key isn't how one expresses the various types of Consent in human terms, as this is indeed a set of rules. The differences is in who / what / when / why / where is expected to ENFORCE the rules. This is why I think we need different resources for Privacy Consent vs the other Consents. Because in the case of Privacy consent the access control engine is enforcing; and that engine does not enforce the other things (consent to treat, advanced directives, etc).
Igor Sirkovich (May 31 2016 at 15:25):
I agree with John. From EHR perspective, Privacy Consent plays a totally different role comparing to other consent types.
Elliot Silver (May 31 2016 at 18:24):
@John Moehrke, I think this is an important part of the discussion. Yes, disclosure consent can be modeled with a generic consent resource or contract resource; so can an ACD or consent for surgery. But is there an advantage to doing that? Is a system ever going to do "something" with all consents/contracts for a patient, or is it going to want to handle only privacy consents, or want to handle privacy consents separately from ACDs? Is every query for a consent or contract resource going to need "?type=privacy" tacked on the end?
Let's say Patient adds new elements to link to ACDs and Privacy Consents. Is that one element Consent (0..*) of type Reference(Consent); or, is it one element for each of ACD and Privacy Consent, both of type Reference(Consent) (potentially with an invariant or profile limiting Consent.type to be ACD or privacy accordingly); or, is it two elements, one of type Reference(PrivacyConsent), the other of Reference(AdvancedDirective).
Is there an advantage to using one Resource for these varied concepts rather than individual (tailored) resources?
Erich Schulz (May 31 2016 at 22:05):
the advantages of at least being aware of the similarities is that it will help highlight the similiarities and help choose a more robust pattern
Erich Schulz (May 31 2016 at 22:05):
exchange of information, witnesses to the agreement, declarations by all parties, role of interpreters, limits and scope are all common elements
Erich Schulz (May 31 2016 at 22:12):
standard caveats on consent: decision maker aware of costs,benefits, risks and alternatives (ie "informed") and free of duressand having capacity to process information, and being authorised (for substitue decision makers) to make this decision.
Mohammad Jafari (May 31 2016 at 23:06):
Thanks @John Moehrke. Finally got a chance to go over the latest version. What I'm wondering is, wouldn't "security label" be an obvious part of the Exception clause? It seems to me that a very straightforward way for a patient to decide what to share and what to withhold is based on sensitivity and confidentiality. "Don't share anything HIV-sensitive with this app," or "don't share any restricted information with third party."
John Moehrke (Jun 01 2016 at 12:50):
Hi @Mohammad Jafari This is a fine use-case. It isn't in the model today because no one brought it forward as a use-case that is currently implemented. It would not be hard to add. As I pointed out, my methodology for simplification was to remove anything that wasn't needed by the examples we had.
John Moehrke (Jun 01 2016 at 12:56):
@Erich Schulz fantastic details. Of these attributes, which of them need to be represented in a computable form? I ask because most of these are part of the ceremony, and don't survive into the persisted documentation. That is to say that many of them are considerations that would be used leading up to the conclusion, if they are unacceptable to the patient then the result is rejected. In the case of Privacy Consent we make it very clear that the Consent must be freely given, be informed, etc... These might end up in the paperwork, but they are not interesting to the computable form.
Erich Schulz (Jun 02 2016 at 03:27):
@John Moehrke I think most of these elements are captured in the paperwork - how much can/should be computationally processed is an interesting question.
Erich Schulz (Jun 02 2016 at 03:30):
certainly who all the parties are and what their role is worth capturing.
Erich Schulz (Jun 02 2016 at 03:32):
I dont think the data model is really that complicated - its simply a bunch of assertions by individuals perhaps reference to a "communication" or observation (of mental state) would allow simplification of the base consent resource
Erich Schulz (Jun 02 2016 at 03:44):
I can assure you that a significant amount of time is currently spent by clinical staff verifying that the procedure about to occur matches the consent given - so having a degree of computability seems worthwhile (I work in theatres as a day job)
John Moehrke (Jun 02 2016 at 12:19):
In the case of a consent to treat, seems it would be 'nice' to point at the order it authorizes... do systems do this today? or am I going beyond current practice?
Erich Schulz (Jun 02 2016 at 12:37):
we have consent forms as part of the surgical booking form in the paper system -which are now scanned as pdfs (urg)
John Moehrke (Jun 02 2016 at 12:41):
Erich, So simple management of the scanned paper (pdf) can be done with DocumentReference... what metadata do your systems track besides that this scanned image is a consent-to-treat for patient X?
Erich Schulz (Jun 02 2016 at 12:41):
we track nothing electronically :-(
Erich Schulz (Jun 02 2016 at 12:42):
but the nurses check it three times before patient enters theatre...
Erich Schulz (Jun 02 2016 at 12:42):
then there is a "team time-out" where we all bow in its direction and sprinkle holy water on ourselves
Erich Schulz (Jun 02 2016 at 12:43):
once the patient is in theatre
John Moehrke (Jun 02 2016 at 12:43):
as it should be.
Erich Schulz (Jun 02 2016 at 12:44):
but "lost consent forms" remains a major source of delay
Erich Schulz (Jun 02 2016 at 12:45):
and still surgeons (and sometimes anaesthetists) attack the wrong body part...
John Moehrke (Jun 02 2016 at 12:49):
No question we all want to improve the system. I think using DocumentReference would be a big improvement. You can specify not just the document type (format agnostic), but the format. Most important is the patient, timeframe, pointers to the order it is about, etc. All without creating a new resource. So finding the right scanned image can be automated, and then you just need people to review the PDF.
Erich Schulz (Jun 02 2016 at 12:52):
there are some interesting edge case where CDS could add value
Erich Schulz (Jun 02 2016 at 12:54):
for example substitute decision makers (eg parents of disabled children) in my jurisdiction are unable to consent to sterilising procedures (eg hysterectomy)
Erich Schulz (Jun 02 2016 at 12:55):
(need a court order for this)
Mohammad Jafari (Jun 02 2016 at 18:10):
Thanks @John Moehrke A major use-case: the VA's patient authorization for exchange is based (in part) on sensitivity codes (existence of ETH, HIV, and SCA labels in particualr). I also think consenting based on confidentiality labels could be widely used for mobile apps. Telling a provider to not share any "sensitive" information with a third-party app is arguably one of the simplest and most user-friendly forms of consent to share, I think.
Lloyd McKenzie (Jun 03 2016 at 01:59):
Be very careful about "could be". Many things are possible using extensions. Anything that isn't widely used right now should be in extension space, at least for now, until we get more experience with how implementers choose to use FHIR. We need to be very careful to not try to direct the implementer community by suggesting that things are part of the 80% purely because of wish that they were.
Mohammad Jafari (Jun 03 2016 at 04:00):
@Lloyd McKenzie The VA use-case is not a 'could-be'.
Lloyd McKenzie (Jun 03 2016 at 13:25):
@Mohammad Jafari "is" vs. "could be" is not evaluated on the basis of a single system, but rather on the sum of what's happening in the vast majority of systems. And in this area, the VA is well beyond what most systems today can do. As such, it shouldn't be surprising if some of their requirements end up being met with extensions. With FHIR, the more sophisticated your capabilities, the more extensions you're likely to have in your instances. And that's ok.
Mohammad Jafari (Jun 03 2016 at 14:43):
@Lloyd McKenzie If we are turning down VA's primary consent use-case for being "fringe" I'd really like to see a discussion on a) what use-cases this draft is based on, and b) how the size of those non-fringe systems compares to the VA's.
@John Moehrke
John Moehrke (Jun 03 2016 at 14:54):
We have asked he community this very question... I don't know that the use-cases we have are any more or any less 'supported by systems today'. It is indeed very possible that some of the elements called for by these examples will get moved to extensions. I simply used these examples as evidence that the elements not used by these examples should clearly not be in the model. I didn't even decide if they should not exist at all, or should be extensions... THIS is all yet to be done, I have just prototyped... AND WE NEED the community to tell us what their current systems implement.
Lloyd McKenzie (Jun 03 2016 at 19:17):
@Mohammad Jafari We're not turning down any use-cases. All use-cases need to be supported, but that doesn't mean all content needs to be in core. The VA is indeed a sizable player within the bounds of the U.S., but that's only one of the countries FHIR is intended to support. And I'm not trying to pre-judge exactly what will be in and out. However, as a rule that applies to everything, not just consent, implementers who are doing sophisticated things should expect that a large chunk of their needs will likely be met through the use of extensions. That's the only way we can ensure that things remain truly simple for the simple use-cases - which is one of our objectives. (Those who are already doing complicated things can best handle the incremental complexity of using the extension mechanism.)
David Boerner (Jun 14 2016 at 23:48):
Hi all and @Grahame Grieve I'd like to propose some values for the http://hl7-fhir.github.io/valueset-consent-type.html consent type expansion list. At PatientsKnowBest we handle consent a bit differently, we have patients tag medical data as either General, Sexual, Mental or Social which drives which bits of data are visible to which groups. It's a patient-centric consent engine, http://help.patientsknowbest.com/Privacy-labels.html Would it be possible to have these 4 values added to this list?
Grahame Grieve (Jun 14 2016 at 23:50):
thanks. can you firstly clarify the definitions of each of the 4 things?
David Boerner (Jun 14 2016 at 23:51):
General health: this covers most of the health record and includes information that most health professionals will use to deliver care
Sexual health: includes reproductive health and HIV
Mental health: for example diagnoses of anxiety, depression or schizophrenia
Social care: information about the care from local authority social care team, including disability funding. This is very useful in helping to manage home care services
Grahame Grieve (Jun 14 2016 at 23:57):
reproductive health = about pregnancies?
Grahame Grieve (Jun 14 2016 at 23:57):
and does your system do any form of auto-tagging? and what level of granularity is it tagged at?
David Boerner (Jun 14 2016 at 23:59):
So it does do auto-tagging for data delivered via integrations. For example messages from an STD clinic can be auto-tagged as sexual, same for a reproductive clinic. The patient always has the ability to go into PKB frontend and change the tags.
David Boerner (Jun 15 2016 at 00:00):
Granularity falls at the data point level. Like Diagnosis, Medications, Results (path/rad), Encounters, Messages (between providers and patients), appointments, etc. They roughly correlate to FHIR resources
Grahame Grieve (Jun 15 2016 at 00:01):
ok, so Patient's have different consents for the 4 categories? how do the 4 categories manifest in consent statements?
David Boerner (Jun 15 2016 at 00:04):
Not sure what a consent statement is but basically patients are part of organizations. They can consent a team to view their records, when they do so they can choose which types of data they want that team to be able to view. I've included a screenshot illustrating this behavior
David Boerner (Jun 15 2016 at 00:05):
screen-shot-2016-06-15-at-100400-am.png
Grahame Grieve (Jun 15 2016 at 00:08):
thanks - good information. @John Moehrke - would you think of this as one consent statement per organization, with 4 actions?
Grahame Grieve (Jun 15 2016 at 00:08):
and David, do patients have choices beyond the simple choices indicated there? e..g. what about write?
David Boerner (Jun 15 2016 at 00:14):
By write I think you mean write access? If a team is consented (opted-in) then that professional has the ability to update their record, roughly the same way that a patient can, manually adding allergies, diagnosis, symptoms, etc. More clinical data points like blood results etc must come through integration.
David Boerner (Jun 15 2016 at 00:14):
But overall the privacy labeling is restricted to those 4 categories to make it KISS for patients
Grahame Grieve (Jun 15 2016 at 00:16):
so a team's write access is limited to their view permissions? or they can write any information they want? (either manually or by integration)
David Boerner (Jun 15 2016 at 00:18):
Ah I see. The professional can only see information that matches their privacy permissions. They can still see all the different sections of a patients record (they may just show as empty if for example all their results are sexual and that team doesn' thave that access) They can write any information they want (roughly) it will just be up to the patient to tag that in whatever way they want, as they own the data.
David Boerner (Jun 15 2016 at 00:19):
screen-shot-2016-06-15-at-101847-am.png
David Boerner (Jun 15 2016 at 00:19):
There's a view a provider has into a patient's health data to help visualize
John Moehrke (Jun 15 2016 at 00:26):
Catching up. @David Boerner This sounds like the use-case that @Mohammad Jafari mentioned above. This is one that I am supportive of and am embarrassed that I forgot it. So yes, we need a way to add an exception that is based on security-tags. So there would need to be a way to identify an exception that identities the kind of data that the exception applies to by use of security-tags, then allow for assignment to an actor and/or action. So it would be similar to the period, but different. Given these examples it is becoming more clumsy to use the current except element, so I am open to alternatives.
David Boerner (Jun 15 2016 at 00:31):
@John Moehrke I think you're right, looking back on a comment from @Mohammad Jafari It appears that we do exactly what Mohammad is explaining with a well defined and easy to understand framework from a patient's perspective. Per comment: Thanks @John Moehrke. Finally got a chance to go over the latest version. What I'm wondering is, wouldn't "security label" be an obvious part of the Exception clause? It seems to me that a very straightforward way for a patient to decide what to share and what to withhold is based on sensitivity and confidentiality. "Don't share anything HIV-sensitive with this app," or "don't share any restricted information with third party."
David Boerner (Jun 15 2016 at 00:34):
Are you saying those 4 privacy labels should be added to the consent exception type list http://hl7-fhir.github.io/valueset-consent-except-type.html vs the consent type list? I'll admit I'm new to the consent FHIR concept so I'm catchign up
Grahame Grieve (Jun 15 2016 at 00:36):
I think John was considering them as an additional element.
John Moehrke (Jun 15 2016 at 00:36):
Yes, hence why I am embarrassed... However it is just as likely they use a timeframe, or use an author, or explicitly name objects... so these are the way data is identified, the except.type identifies the rule type, and there could be a recipient and/or action associated... so, yes some more modeling to do. I would love to just prototype it in, but I fear my hands are tied now that the wg has started looking at it.
Grahame Grieve (Jun 15 2016 at 00:36):
are you happy for us to include that first screen shot you provided above in the spec, and provide a consent example based on that?
Brian Postlethwaite (Jun 15 2016 at 00:36):
Our internal team based security model looks effectively like this, and then permissions are allocated to each of those tag associations (we don't however have the exceptions model, and know that it's been missing from ours). So I like what is being suggested here.
John Moehrke (Jun 15 2016 at 00:36):
correct... add an except.securiy-tag element.
David Boerner (Jun 15 2016 at 00:37):
I think that is exactly what we want, and please do feel free to use that screenshot. I can share as many as you'd like.
Grahame Grieve (Jun 15 2016 at 00:38):
well, I'll build it in when I draft this afternoon.
David Boerner (Jun 15 2016 at 00:39):
cheers @Grahame Grieve
Grahame Grieve (Jun 15 2016 at 00:39):
John, you envisage this as a based - opt-out nothing, except for these things, yes?
Grahame Grieve (Jun 15 2016 at 00:39):
you can't just say it straight? I consent to x,y,z, with no exceptions?
John Moehrke (Jun 15 2016 at 00:40):
you can have a base of out-out, and add exceptions of what is allowed.
Grahame Grieve (Jun 15 2016 at 00:40):
yeah I know you can. but it seems more complicated that way to me.
John Moehrke (Jun 15 2016 at 00:40):
like the excemple for consent withholding access except for emergency
John Moehrke (Jun 15 2016 at 00:41):
the base could also be a normal base, with an exception that adds MORE access than normal base, or removes access from normal base.
John Moehrke (Jun 15 2016 at 00:41):
that why they are exceptions
John Moehrke (Jun 15 2016 at 00:42):
so, a general opt-in but also let my GP access very-restricted data.... where the general opt-in policy doesn't authorize any access to very-restricted data
John Moehrke (Jun 15 2016 at 00:43):
or a general opt-in but forbid doctor-bob access to anything.
John Moehrke (Jun 15 2016 at 00:43):
or an opt-out, but authorize my GP access to everything including very-restricted
Grahame Grieve (Jun 15 2016 at 00:43):
ok, but here, in the PKB example, there's no general opt-in. there's nothing, + what I allow as exceptions
John Moehrke (Jun 15 2016 at 00:44):
okay, then that is like the example for emerency access only.
John Moehrke (Jun 15 2016 at 00:44):
http://hl7-fhir.github.io/consent-example-Emergency.html
John Moehrke (Jun 15 2016 at 00:44):
except it is security-tag based, not action based.
Grahame Grieve (Jun 15 2016 at 00:45):
that example is confusing: "Withhold Authorization for Treatment except for Emegency Treatment. Patient "P. van de Heuvel" wishes to have no data at the Good Health Psychiatric Hospital available except for Emegency treatment use." - those are different statements
John Moehrke (Jun 15 2016 at 00:46):
yes... The base policy says NOTHING IS ALLOWED, with an exception that says that emergency treatment is allowed.
Grahame Grieve (Jun 15 2016 at 00:47):
but is it consent about treatment, or about data?
John Moehrke (Jun 15 2016 at 00:47):
OH... access for the prposes of treatment (purposeOfUse).
Grahame Grieve (Jun 15 2016 at 00:47):
you see what's confusing then. I'll clarify it this afternoon
John Moehrke (Jun 15 2016 at 00:48):
I understand the confusion. I used too much short-hnd.
John Moehrke (Jun 15 2016 at 00:49):
the purposeOfUse vocabulary is an 'action' type that is being authorized.
John Moehrke (Jun 15 2016 at 00:49):
so the purposeOfUse of "Teatment", which the hospital RBAC/ABAC knows the full set of Roles/Tasks/Objects/etc...
Grahame Grieve (Jun 15 2016 at 00:52):
btw. the PKB categories:
General health: ??
Sexual health: http://hl7.org/fhir/v3/ActCode::SEX
Mental health: http://hl7.org/fhir/v3/ActCode::PSY
Social care: ??
David Boerner (Jun 15 2016 at 01:06):
those two seem to be correct for sure
Grahame Grieve (Jun 15 2016 at 01:07):
thx, I don't think we have codes for the other two though.
David Boerner (Jun 15 2016 at 01:07):
scrolling through the list 1 min
David Boerner (Jun 15 2016 at 01:09):
GENRL
David Boerner (Jun 15 2016 at 01:09):
GENRL General General care performed by a general practitioner or family doctor as a responsible provider for a patient.
David Boerner (Jun 15 2016 at 01:10):
hmmm but that is specific to a GP / family doctor, doesn't quite relate to our concept
Grahame Grieve (Jun 15 2016 at 01:11):
yes that's in a different part of the heirarchy not in scope here
David Boerner (Jun 15 2016 at 01:12):
are we strictly lookat at level 5?
Grahame Grieve (Jun 15 2016 at 01:14):
according to http://hl7-fhir.github.io/security-labels.html#hcs, the rules are - any code in one of those 5 groups. And each of those has it's own scope definition
Grahame Grieve (Jun 15 2016 at 01:15):
the most appropriate for your kind of tags is http://hl7-fhir.github.io/v3/InformationSensitivityPolicy/vs.html, which says nclude codes from http://hl7.org/fhir/v3/ActCode where concept is-a _InformationSensitivityPolicy - so any codes under _InformationSensitivityPolicy in the heirarchy at http://hl7-fhir.github.io/v3/ActCode/cs.html#_InformationSensitivityPolicy - irrespective of level
Grahame Grieve (Jun 15 2016 at 01:16):
because it's hard to track the scope of that subset in that big page, we just list the actual applicable subset at
Grahame Grieve (Jun 15 2016 at 01:16):
http://hl7-fhir.github.io/v3/InformationSensitivityPolicy/vs.html#expansion
David Boerner (Jun 15 2016 at 01:17):
ok thats an easier list to manage, and yes agreed I don't see an obvious value for General or Social Care
David Boerner (Jun 15 2016 at 01:18):
would you like me to propose 2 new values?
John Moehrke (Jun 15 2016 at 01:21):
general is "N" normal. It isn't a sensitivity code, it is essentially the lack of a sensitivty code
John Moehrke (Jun 15 2016 at 01:22):
I don't know what social-care is... can you gve examples?
David Boerner (Jun 15 2016 at 01:23):
care for those at risk, children, adults with disabilities, aged care.
John Moehrke (Jun 15 2016 at 01:23):
THat sounds like a classification of patient, not a classificaiton of data
Grahame Grieve (Jun 15 2016 at 01:24):
data relating to the care provision in social services is how I would have described it.
David Boerner (Jun 15 2016 at 01:24):
exactly right
David Boerner (Jun 15 2016 at 01:24):
like a diagnosis of PTSD after a child is abused for example
John Moehrke (Jun 15 2016 at 01:24):
okay, then tat sounds more like a classification of a User Functional Role
Grahame Grieve (Jun 15 2016 at 01:24):
Using Confidentiality N doesn't quite sit right with me - I consent to sharing information labelled "N" - unless it has these other labels.
John Moehrke (Jun 15 2016 at 01:25):
the _confidntiality codes are 1..1
John Moehrke (Jun 15 2016 at 01:25):
you can't have both N and R
John Moehrke (Jun 15 2016 at 01:25):
hence why we need this vocabulary cleaned (different topic with Kathleen).
Grahame Grieve (Jun 15 2016 at 01:25):
so PKB would have to label anything with the other codes as R as well?
David Boerner (Jun 15 2016 at 01:26):
sorry N vs. R means what?
Grahame Grieve (Jun 15 2016 at 01:26):
what needs cleaning up?
John Moehrke (Jun 15 2016 at 01:26):
ah, it looks like you cleaned it up.
Abbie Watson (Jun 15 2016 at 01:26):
Social care sometimes involves non-controlled environments and tag-teaming. For instance, a log book kept at a patient's home that home-care assistants might record nutrition intake. From a data privacy perspective, social-care data can sometimes be more vulnerable to sharing.
John Moehrke (Jun 15 2016 at 01:28):
so it seems we (CBCC and Security) have never had that use-case brought to committee.... no worry, it is just vocabulary.
Grahame Grieve (Jun 15 2016 at 01:28):
I think that a tag related to social services data in the InformationSensitivityPolicy makes sense. And there's lots of projects spooling up using FHIR to cross the boundaries in primary/tertiary/ care + social services/ legal system stuff.
Abbie Watson (Jun 15 2016 at 01:29):
Sorry for interrupting. I enabled zulip alerts, and am now getting these discussions in real time.
John Moehrke (Jun 15 2016 at 01:29):
agreed.
John Moehrke (Jun 15 2016 at 01:29):
your interruption was fantastic.
David Boerner (Jun 15 2016 at 01:30):
yes I think that was the best example I've heard for social care yet
Grahame Grieve (Jun 15 2016 at 01:30):
yes no need to be sorry. though you mgiht be sorry later once we really get going.... ;-)
John Moehrke (Jun 15 2016 at 01:31):
social could also be handled as a compartment (very similar but different than RESTful compartments).
John Moehrke (Jun 15 2016 at 01:31):
either way the consent modeling doesn't care, it is a security-tag value to look for.
Grahame Grieve (Jun 15 2016 at 01:33):
... using N is not sitting perfectly with me yet....
David Boerner (Jun 17 2016 at 01:09):
@Grahame Grieve thanks for all your work on consent, this is making things so much clearer. Did you ever end up adding codes to ActCode for General and Social privacy?
Grahame Grieve (Jun 17 2016 at 01:36):
I added one for Social, though it's provisional. I haven't added one for general yes. @John Moehrke said that would just be confidentiality = N. I didn't agree, but we needed discussion about that
John Moehrke (Jun 17 2016 at 12:02):
Note I am not fully convinced that confidentiality = N is sufficient. I just wanted to start the discussion there until we could describe the situation better. Im just trying to use what we have before we create something exactly duplicative.
Grahame Grieve (Jun 17 2016 at 12:27):
I think it's something specific, not the lack of any other classification
John Moehrke (Jun 17 2016 at 13:10):
reality is that data is mostly unclassified. It s only unusual data that gets classified. I have never seen anyone willing to classify general or normal data. It is only through mandatory requirement in CDA that they get a "N", and most have no idea why they are putting an "N" there, so it is wrong sometimes. Thus, "General" sure seems like it will fail in this light.
Grahame Grieve (Jun 17 2016 at 13:18):
well, @David Boerner might want to comment on that. I was given the impression that all the patients do this
David Boerner (Jun 20 2016 at 06:32):
I'm struggling wrapping my mind around exactly what N vs. R means. Could anyone clear that up?
David Boerner (Jun 20 2016 at 06:32):
Most data in PKB is classified as General upon receipt (unless there's a special arrangement) it's then on the patient to reclassify as they see fit.
Grahame Grieve (Jun 20 2016 at 06:49):
N vs R?
Grahame Grieve (Jun 20 2016 at 07:02):
oh right . Confidentiality. I don't think there's any real difference - that stuff is really in the eye of the beholder
John Moehrke (Jun 20 2016 at 13:59):
David, from what you explain your use of "General" is what "N" is intended to define. That is data of "Normal" confidentiality for medical information. It is unfortunate that the world "Normal" was used, as many people think about 'all data', but it is 'all medical data'. So it is "Normal" confidentiality as differentiated from data that is more sensitive (R and V), and different from data that is less sensitive in (M, L, U). The _confidentiality vocabulary is intended to be a continuum of risk with the 'majority' (arithmetic Normal) in the middle.
John Moehrke (Jun 20 2016 at 13:59):
See my blog article on this https://healthcaresecprivacy.blogspot.com/2015/07/how-to-set-confidentialitycode.html
Grahame Grieve (Jun 20 2016 at 22:29):
I don't think that the classiification 'general medical information' is the same as "confidentiality = N' even if the operational consequence is the same
David Boerner (Jun 21 2016 at 15:01):
Agreed with @Grahame Grieve Thanks for that blog on this subject @John Moehrke What is being used as N here doesn't quite fit. Just because something is General doesn't necessarily mean it is N (Normal confidentiality). In our system for example a sexual health encounter could be tagged as General and Sexual, BUT the end user could only view it if they had permission for BOTH General and Sexual privacy. This allows for stacked permission levels that don't fit neatly into just 1 bucket. Does that make sense?
John Moehrke (Jun 21 2016 at 15:10):
Okay, then you are following more of an access control model refered to as "compartment". We have this in the HCS too, an open vocabulary you can define in your context. Compartments might be related to sensitiity, confidentiality, resource-model, etc... but Compartments work more like what you are describing in that data is tagged with the compartments it fits into, and users have clearance levels. If the clearance levels agree with the compartments then access is granted. This is a classic military model (secret, top-secret, etc).
John Moehrke (Jun 21 2016 at 15:13):
so, compartments i an independent set of vectors from sensitivity, confidentiality, etc... BUT, the data tagging system is the same in that these are just vocabulary attached as metadata to each object; and consent/security/business rules can define how data with that tag is to be controlled.
John Moehrke (Jun 21 2016 at 15:15):
unfortunately the word 'compartment' has two meanings for us... one from REST, one from security-tags... although their implementation can overlap (such as "Patient"), they are different.
Grahame Grieve (Jun 21 2016 at 19:54):
well, that makes sense, only these compartments aren't the ones we define. So it's not obvious how to make that work?
Grahame Grieve (Jun 21 2016 at 19:55):
all: we're going to discuss the current Consent draft here, based on the comments here: http://wiki.hl7.org/index.php?title=FHIR_Consent_-_Grahame%27s_model
Grahame Grieve (Jun 22 2016 at 03:17):
ok, following up on this: I have sorted all the comments received into sections against the resource, and commented on all them that relate to the metadata. (e.g. up to .profile)
Grahame Grieve (Jun 22 2016 at 03:21):
I think there's several discussions to have here:
-
confirm the apparent feeling on the CBCC + security calls endorsing the scope that I suggested. @John Moehrke had procedural concerns, but I thought that the scope I proposed was not incosistent with the project statement, since it hedges it's bets
-
the workflow/status discussion
-
category usage - is it even needed if we have policy? I didn't use it in any examples
-
signature - I've proposed to add a note about signatures being in Provenance, and to try and see if there's problems with that approach. Discussion required
Grahame Grieve (Jun 22 2016 at 06:17):
I finished commenting. Additional discussion to have:
- actor role discussion
- presence of actor, action, security label, purpose, and data on the root or not (as opposed to just on the exception)
- 'valueset' in the .data.meaning
- a good value set for action - can we make it extensible?
Ioana Singureanu (Jun 22 2016 at 14:30):
Based on the CBCC call yesterday we identified a couple of items that need more elaboration:
--> how we record the signature/authentication of consent including: signed by proxy, witnessed by someone/notary. Without some way of accomplishing this we will have difficulties with Consent.
--> how we separate the Consent.category (opt-in to information sharing, opt-out of information sharing, basic authorization to disclose, basic consent for purpose, granular consent, basic consent for procedure, basic consent for research enrollment) from the Consent.policy (e.g. HIPAA, 42 CFR Part 2, Title 38, DURSA, Covered California)
Ken Sinn (Jun 22 2016 at 15:05):
Thank you for the responses posted to the wiki, Grahame. I will take a much closer look at the examples, and follow up with any additional questions I may have.
Grahame Grieve (Jun 22 2016 at 20:25):
I think it would be really good to make a list of national policies for USA - so that we can start teasing apart the policy/categorization differences.
Grahame Grieve (Jun 22 2016 at 20:25):
I will draft a list for US people to argue about ;-)
Grahame Grieve (Jun 22 2016 at 20:26):
as for signature: send me an example of what you want in english - signatures and notaries - and I'll prepare an example based on the current model
John Moehrke (Jun 27 2016 at 17:04):
@Grahame Grieve . You commented on my comment on the .data element. http://wiki.hl7.org/index.php?title=FHIR_Consent_-_Grahame%27s_model#data I think there is still some miscommunication. I was expecting the use of the .data to be a listing of nothing (all data on this patient), or a listing of the specific FHIR objects that this consent has something to say about. What the consent has to say is either explained by the base policy (Authorize Research Read) or there is an exception with details. It is in the exception where I expected to put the operation as part of the except.type such as you have included in the .data element. THat is to say there would be an exception type that says 'allow access to the data derived from X object'. By putting this logic in the root, you have duplicated part of the use of exceptions. Seems multiple ways to do the same thing is not a good idea, right? Especially right now when we are striving for as simple of a model as we can get that still functions.
Grahame Grieve (Jun 27 2016 at 20:47):
ok, but that's just an argument about data at the root as a whole, or not, surely? Why would you need to reference data at the root, but not use those options?
John Moehrke (Jun 28 2016 at 02:36):
@Grahame Grieve I am not arguing that we need data at the root... seems to me the except data is just as findable as dupicating the references i the root... but I suspect that I am missing some trick. So yes, I would rather see data at the root go away for now. We can always bring it back in when we have a specific need. I am arguing for all these root level random buckets to be replaced with the structructure we have in exceptions. having very few things at the root.
Grahame Grieve (Jun 28 2016 at 02:37):
I don't recall anyone pushing back against that. and I didn't use them in any of my examples
John Moehrke (Jun 28 2016 at 02:38):
ah, what? I am pushing back.. Others pushed back at these things in meetings prior to you helping us (@Tarik Idris ) and possibly @Ioana Singureanu .
Grahame Grieve (Jun 28 2016 at 02:39):
I mean, I don't recall anuone pushing back against your suggestion to delete them from the root
John Moehrke (Jun 29 2016 at 19:17):
I think we need to make clear that within an exception all elements are in an AND relationship (this period AND this actor(s) AND this action(s) AND this securityLabel(s) ..), and between exceptions is an OR relationship (exception 1 OR exception 2 OR exception 3 ...), and if no exceptions fire then the root policy is executed.
Grahame Grieve (Jun 29 2016 at 19:23):
agree this needs to be clear
John Moehrke (Jun 29 2016 at 19:26):
Discussion today leads us to more than PERMIT and DENY; but tries to bring in various forms of obligations (redaction).
John Moehrke (Jun 29 2016 at 19:27):
can we defer these slicing and dicing.
Grahame Grieve (Jun 29 2016 at 19:49):
well, all those things are possible now, in the action codes and policy references, and I don't think that we need to get particularly involved in them
Grahame Grieve (Jun 29 2016 at 20:01):
open items from the call:
- status/workflow
- definition of author
- improving the value sets
- adding additional examples
- US value set for profiles based on regulations (HIPAA)
Grahame Grieve (Jun 29 2016 at 20:01):
let's move forward on those things please
John Moehrke (Jun 29 2016 at 20:04):
On the topic of 'author'> I think we should define some roles in the front material that we map to elements, rather than just hoping that he element definiton will be read and understood in absence of the overall workflow roles.
Grahame Grieve (Jun 29 2016 at 20:07):
well, ok, though if that gets too long, people just don't read it anyway
Mohammad Jafari (Jun 30 2016 at 00:10):
@John Moehrke (per your previous comment above) agreed. And I feel that we might be falling into the rabbit hole of inventing a new access-control/privacy language which might not be a productive idea. If the structure of the "rule" part of the consent is on track to get more complicated (e.g. more conditions, obligations, etc.) I think it might be helpful to look at the "previous work" for modeling other things that look a lot of consent. EPAL and ODRL come to my mind.
https://www.w3.org/community/odrl/files/2011/11/core-model.png
https://www.zurich.ibm.com/security/enterprise-privacy/epal/Specification
https://www.zurich.ibm.com/security/enterprise-privacy/epal/Specification/uml-overview.png
https://www.w3.org/community/odrl/model/2.0/
Grahame Grieve (Jun 30 2016 at 00:24):
I don't think we want to get more complicated.
John Moehrke (Jun 30 2016 at 01:15):
@Grahame Grieve I think @Mohammad Jafari point is that we should dial back a bit more, and let the more complex issues use a rule encoding language that is desinged as a rule encoding language. I would agree we are at a tipping point, but it is not clear to me what we can live without. Further, with these rule languages, you must bring along your own definitions of elements, and vocabulary, and often comparison rules. So, we might need to invent as much as we have... That said, I think we need more eyes on it. We are gaining eys, and hopefully the ballot will bring us even more.
Grahame Grieve (Jun 30 2016 at 01:18):
yes, I don't know what we could remove. The challenge is that using another lanuage - be it xacml or whatever - means writing a definition of how FHIR and HL7 concepts that people want to refer to map into the other language. At some point in that process there's the reverse tipping point, where you say: wow. This is become pretty arcane and arbitrary, and way beyond what the implementations support off the shelf; it's better to define a DSL that maps into the other language. And presto, you're back where we are.
Grahame Grieve (Jun 30 2016 at 01:18):
so the question is, where are the tipping points. But we agree about lots of eyes
John Moehrke (Jun 30 2016 at 01:21):
I think the tipping point is when we need more complex comparison and combining rules. These are the kind of things that these policy rules languages bring to the party. Mostly combining rules. I suggest that if we can keep to OR rule between exceptions, and AND rule within exceptions; then we likely are good.
Grahame Grieve (Jun 30 2016 at 01:23):
yep. that's a common pattern throughout FHIR, and we should document that explicitly.
Grahame Grieve (Jun 30 2016 at 01:23):
having said that, there's one example that doens't conform.
Grahame Grieve (Jun 30 2016 at 01:41):
check the exception here: http://hl7-fhir.github.io/consent-example-signature.html
John Moehrke (Jun 30 2016 at 01:46):
I looked.. not seeing the problem? Or are you needing to say that within any element within the exceptions the 0..* is an ANY match? Which I think is logical. So if you have 5 codes listed, than any data that has a (at least one) match to a (a least one) code will fire the rule.
John Moehrke (Jun 30 2016 at 01:48):
seems odd that the elements within the exception would be anything other than OR... so between exceptions is OR, within an exception it is AND between elements, but within any one element it is an ANY...
Grahame Grieve (Jun 30 2016 at 01:49):
I'm not sure that's what you want for security labels. how would I say "confidential information about PSYCH stuff"
Grahame Grieve (Jun 30 2016 at 01:49):
that's an AND
John Moehrke (Jun 30 2016 at 01:50):
crap... that is true... so I guess AND within element... so if you really need OR than you just have to have two mostly identical exceptions.
Grahame Grieve (Jun 30 2016 at 01:50):
keeping it simple has a complecity all of it's own....
John Moehrke (Jun 30 2016 at 01:50):
see this is where a policy language like XACML has all kinds of combining rules... like at-least-two, and such.
John Moehrke (Jun 30 2016 at 01:52):
we have specified order of exceptions, right?
Erich Schulz (Jun 30 2016 at 02:30):
DSL? is this my cue to rabbit on about CQL ;-)
Erich Schulz (Jun 30 2016 at 02:36):
which would certainly cope with any logic
Grahame Grieve (Jun 30 2016 at 03:12):
so, with regard to order, there are two possibilities: process in order till a match, then abort, or process in order completely
Grahame Grieve (Jun 30 2016 at 03:12):
I'm pretty sure I heard some weird echo from a CQL fan-boi but I'm not hearing well today
Erich Schulz (Jun 30 2016 at 03:28):
i'll have to update my signature... CQL fan-boi has a ring to it
Robert Horn (Jul 06 2016 at 17:59):
We had some discussion around the "author" element. I may have mis-understood how it was intended to be used. It seemed during discussion to be evolving into being the patient, for the case where the patient could consent directly. It might have been someone consenting on behalf of the patient for other cases, e.g., parents consenting for children.
Robert Horn (Jul 06 2016 at 17:59):
1) Author is a tolerable but inaccurate concept for patient privacy consents. The inaccuracies can be explained and won't cause serious breakage, but they will be confusing.
2) More complex related kinds of agreements will not be able to use author.
The problem with author (for consents) is that the patient is not the author in the normal sense. For a normal authorship, the author really does understand the document fully. If you take a section and ask the author to explain it, they can. If you ask why a section was left out, they can explain that. If a section needs to be modified, the author knows how to do that. The patient cannot do any of those things in a typical consent process.
Take the NHS consent process as an example.
The NHS authors worked hard to balance the needs of medical ethics (in terms of providing care based on reasonable subsets of information, or deny care, etc.) with the privacy desires of patients. They came up with the short hierarchy of categories and subcategories of what will be shared. The patient selects the consent using a guided selection process prepared by the NHS.
In that process, the NHS meets the characteristics of an author. The patient "selects" a specfic consent from among a family of available consents. If instead of "author" the consent elements were "selected by" and "applied to" it would be accurate. But, documenting an abuse of the term author would probably suffice if it makes other things much easier.
A more complex situation is the consent relationship created by HIPAA Business Associates. In this case there are three parties: NEMA, Party A, and Party B. Part A and B need to set up a business associate relationship.
NEMA authored a basic HIPAA Business Associate contract form. In theory the parties could use that, but in the real world Party A takes the NEMA contract and modifies a section or two. Party B responds with some corrections and other modifications. When they finally reach agreement, 95+% is the original NEMA document and less than 5% has been slightly modified. In this situation you could argue that all three are authors. Legally, it's of relatively little interest just how the authorship was split.
The important legal and operational issue is:
- Do Party A and Party B both agree to a document? If so, from FHIR perspective this becomes elements that
- Identify the final document
- Identify Party A, and show how they documented their agreement (e.g., signature).
- Identify Party B, and show how they documented their agreement.
- The contributory authorship of NEMA is unimportant and probably not worth capturing.
- There may be some elements to indicate effective dates, etc. These are inherently nominal and subject to change based on real world events.
That's too complex to squeeze into an author description.
Robert Horn (Jul 06 2016 at 18:06):
One important consideration for FHIR is the needs for interoperability. Internal system designs should not define the standard interfaces. I'll posit that from the point of view of interoperability the things that are needed in a privacy consent agreement are:
- The specific agreement, or reference to where it can be found.
- The kind of agreement, e.g., "a patient consent in compliance with policy X". This is needed as a search key. I also separate the policy from the agreement so that we can have policies that define inclusions and exclusions. This is very normal and deals with most of the agreement variations. A policy may anticipate an agreement that adds some permitted disclosures or removes some permitted disclosures, but only specific kinds of additions and removals are allowed in the policy.
- The parties to the agreement, i.e., the actual parties that agreed.
- The parties subject to the agreement, in this case the patient and the providers. I include both because the providers bear most of the burden of performing the agreement and the patient bears most of the harms from failure to perform. This also makes things like breach notification a lot easier to automate and manage.
- (discuss) Inclusions and exclusions to a policy.
The history, authorship, etc. is secondary. I would leave out anything difficult or controversial and maybe leave out everything.
The most common interoperability use is system A querying the server for "what consents apply to this patient", or "is this patient subject to a consent of type policy X".
The second interoperability use, and a much more difficult one, is to enable processing of the agreement terms without need to fetch and use the actual agreement. This can be done when the policy has some simple sets of inclusions and exclusions. When these sets are captured in the summary object, you can use the object together with pre-programmed decision logic to implement those specific policies. This is very hard to get right. An immediate and tricky example is a policy that allows the agreement to add and exclude selected data items, and that allows the approved disclosure list to add and exclude selected people and organizations. Predicting all the different possible ways to describe "selected data items" quickly becomes a nightmare. Predicting all the different ways to identify selected people and organizations is equally difficult. And then what do you do when the policy includes a possible cross product explosion where it adds a selected data item, but only to certain of the selected people, while adding a different data item to a different set of selected people.
It will help to separate those two parts of consent discussions. The first is much easier to reach consensus than the second.
My personal acceptable limit for the second interoperability use is to not attempt to describe adding or excluding data items, not attempt to describe adding or excluding purposes, and to limit the the inclusions and exclusions of a list of identifiable persons and organizations that are added or excluded for access to all the data items identified by the policy. That hits the high priority for personalization that I have seen. The selection of categories of data items is best done by having multiple policies, like the NHS example. Modifying the data item set on a patient by patient level introduces a difficult negotiation about the medical ethics and medical responsibilities of the providers. It can't be done unilaterally by the patient. It requires a mutual agreement. Similarly, purposes and roles require negotiation and agreement by all the parties. Restrictions and extensions of access for individual person and organization are anticipated and can be handled because problems of medical ethics and responsibilities have been thought through. The policies are ready for that level of personalization.
The specification of personalization for inclusions and exceptions might also be an area for extension profiling as future understanding of the balance between medical ethics and personal privacy evolve.
John Moehrke (Jul 06 2016 at 18:06):
I don't think that is what author was intended to be. Except in the degenerate case where the patient is indeed the author of their own policy. This case is important, but today is unusual. More important, the author of the policy or the author of the consent is important to the legal process; but is not very important to the Interoperability focus of FHIR. That is not to say it isn't important, but rather to say it is possibly of only secondary impoortance.
Robert Horn (Jul 06 2016 at 18:09):
It could well be author was meant to be something else. It's a point for clarification of the definition of author. The actual author is typically a legal team, with possible minor amendments by the patient. I'd be happy to see author become an optional element or even eliminate it. I really care about the parties that made the agreement and the parties that are affected by the agreement. In most cases none of them are the author.
John Moehrke (Jul 06 2016 at 19:54):
Add to recipient element the CareTeam resouce. and as except.actor.reference
Grahame Grieve (Jul 06 2016 at 19:59):
ok
Robert Horn (Jul 06 2016 at 20:01):
And I think we agreed to consent.consentor as a 1..n reference to person/organization.
John Moehrke (Jul 06 2016 at 20:01):
yes.
John Moehrke (Jul 06 2016 at 20:02):
should put patient as 1..1
Robert Horn (Jul 06 2016 at 20:04):
Not sure on patient. Double check how things like mother/child, multiple infant, transplant situations, etc. are handled. Do they do separate or shared consents in practice? 1..1 with an open question to highlight that kind of checking would make sense. These are situations where there is often a need for bi-directional sharing.
Oliver (Jul 06 2016 at 20:05):
I agree with 1...1 for patients but I know Lloyd wanted 1...n. I don't understand the use case. Is that for group therapy consents?
John Moehrke (Jul 06 2016 at 20:06):
if there is multiple children, create multiple instances.. it is far cleaner. THey both can point at one 'source' document.
Robert Horn (Jul 06 2016 at 20:07):
The cases I've seen were information sharing about medically shared conditions, usually mother/child and transplant situations. There may also be policy based choices to use a single consent for multiple children being treated at the same facility. 1..1 and 1..n can both work. It's more a question of what is the real practices that we need to support.
John Moehrke (Jul 06 2016 at 20:08):
it is not all that more complex to be 1..*; but I am pushing back for simplicity. exceptions call for extensions?
Oliver (Jul 06 2016 at 20:09):
1..1 is good
Grahame Grieve (Jul 06 2016 at 20:15):
actually, both need to be optional. I have patient 0..1 and consentor 0..*
Grahame Grieve (Jul 06 2016 at 20:16):
I agree not to make the patient 0..* unless we really really have to
Robert Horn (Jul 06 2016 at 20:16):
Umm, what does it mean to consent with no patient? What does the consent apply to?
Robert Horn (Jul 06 2016 at 20:17):
I can see the uses for no consentor. I prefer to deal with those situations by making the provider the consentor, since most of them are cases where a unilateral decision must be made by the provider due to some special circumstances. But, that is kind of implied by having no consentor.
Grahame Grieve (Jul 06 2016 at 20:19):
http://hl7-fhir.github.io/consent-example-smartonfhir.xml.html
Grahame Grieve (Jul 06 2016 at 20:20):
this is an example of no patient
Robert Horn (Jul 06 2016 at 20:22):
I see. It's a consent delegation of sorts. The real consents are elsewhere.
John Moehrke (Jul 06 2016 at 20:47):
I don't understand the example of no patient. Is there a more readable narrative?
Lloyd McKenzie (Jul 06 2016 at 21:09):
Another example of no patient is "I consent for you to access information of this type" on a patient-independent basis. This can be relevant in research or in other places where the patient has already given up the right to control disclosure or (due to regulation - e.g. reportable results) doesn't have that right in the first place.
John Moehrke (Jul 06 2016 at 21:19):
@Lloyd McKenzie , that is not a Consent.
Lloyd McKenzie (Jul 06 2016 at 21:36):
It's granting permission for disclosure of information - which is going to have to use the same resource.
Lloyd McKenzie (Jul 06 2016 at 21:37):
DAF is going to need to use it for their IG which they're hoping to post a draft of for Jan. ballot.
Lloyd McKenzie (Jul 06 2016 at 21:38):
(And I'm not sure why you say it's not a consent - consent doesn't need to be given by the patient or even necessarily they're representative - it just has to be someone who has the authority to make the decision.)
Grahame Grieve (Jul 06 2016 at 21:39):
Lloyd has captured the essence of the smart on fhir use case there. And I think that it is in scope for this resource
John Moehrke (Jul 07 2016 at 11:22):
In my view that use-case is NOT 'Consent', there is no act of 'consent'. I am not arguing that they are not important use-cases. They are use-cases of a more broad category of Authorization Policy - authorizing a scoped access. However we are trying to enable Consent, originally Privacy-Consent only; while you have forced us to take on other 'consents' like Advanced Directives, consent-to-treat, etc... Now you are forcing us to extend our scope to 'any authorization' use-case? Do you have evidence that a large number of systems today have this kind of authorization policy configuration? My experience says this is not done through the same mechanism as Consent, but rather through normal RBAC configuration of roles/purposes/objects/verb.
Grahame Grieve (Jul 07 2016 at 11:24):
It's not right to say that I've forced this to be taken on. As a matter of process, I suggested that we declare these possibly in scope, but deferred to the future for resolution.
Grahame Grieve (Jul 07 2016 at 11:25):
as to whether this is authorization or not... I'm not convinced by your argument. Consent is always layered on top of authorization - we've talked about this before
Grahame Grieve (Jul 07 2016 at 11:26):
and it seems like words games to say 'user authorises sharing' via OAuth as opposed to 'user consents to sharing' via OAuth. I'm not sure on what grounds you think these are meaningfully different
Grahame Grieve (Jul 07 2016 at 11:26):
in the Heart context, all consenting is done on top of OAuth...
John Moehrke (Jul 07 2016 at 11:29):
First the 'you' was the broad definition of those that are not participating in the consensus discussions. You being Grahame, are participating.
Grahame Grieve (Jul 07 2016 at 11:30):
hah ok
John Moehrke (Jul 07 2016 at 11:32):
I don't understand why you bring in OAuth or HEART. Those are additional efforts and technologies; and ones that can be very orthogonal. In fact using HEART UMA mechanism is potentially a complete overlap with the Privacy-Consent work we were working on. In the case of HEART UMA, they never need to have a computable encoding, as that is an internal design feature of the HEART UMA authority. They move the problem around to have an UMA Authority that makes decisions, that are simply communicated and enforced without ever explaining why.
Grahame Grieve (Jul 07 2016 at 11:33):
I think that it's not that simple. I think that they think it will work that way, but it will still be necessary to store the consent for audit purposes, or exchange the consent internally behind a perimeter
John Moehrke (Jul 07 2016 at 11:33):
I am trying to constrain the use-cases to those that we understand as Privacy-Consent. With this scope we can limit the complexity of the rules and exceptions. If we leave Privacy-Consent and go to 'authorizing anything' then we don't have that constraint to focus us.
Grahame Grieve (Jul 07 2016 at 11:34):
I still think of smart on fhir OAuth as privacy-consent
John Moehrke (Jul 07 2016 at 11:35):
A consent that is not focused on a patient, is not a positive privacy feature; it is a doorway for privacy violations. I want to focus on enabling Privacy, not thwarting Privacy.
John Moehrke (Jul 07 2016 at 11:37):
I indicated that I understand the use-case is valuable and needed... I just disagree that it is a 'consent' use-case.
John Moehrke (Jul 07 2016 at 11:37):
there simply is no act of 'consent'.
John Moehrke (Jul 07 2016 at 11:38):
These things are recognized in our Privacy/Security DAM
John Moehrke (Jul 07 2016 at 11:38):
both of them are.
John Moehrke (Jul 07 2016 at 11:38):
so it isn't with ignorance, it is with definition that we disagree.
Grahame Grieve (Jul 07 2016 at 12:17):
it seems like a difficult differentiation to draw to me. And where do OAuth agreements go if they are not consent?
Grahame Grieve (Jul 07 2016 at 12:17):
a resource that otherwise looks identical?
Lloyd McKenzie (Jul 07 2016 at 14:12):
@Grahame Grieve DAF is going to need support for this in STU3 so we can't defer it very long. There's a need to be able to reference a specific authorization to access the information - and the authorization isn't patient-specific. If necessary, we can create a profile on Basic for now, but it's not going to be able to stay that way for long.
Mohammad Jafari (Jul 07 2016 at 14:48):
I agree with @John Moehrke that the example use-cases here are NOT consent directives —as we know them— although this could become a matter of definition. I think to clarify we need to delineate what kind of authorization policy is and is not considered a consent directive. If we consider consent to cover the case of anyone granting some access rights to some resource, it basically should cover all kind of authorization policies. How about plain organizational policies wherein an administrator grants access rights to some groups of people; are those also a consent? At least that's not what we colloquially call a consent directive.
It might be okay to define the consent like that but we also need to consider that generalizing this to all kinds of authorizations would then call for supporting very general forms of authorization policies, i.e. we may fall back into (re)inventing an authorization language.
Lloyd McKenzie (Jul 07 2016 at 16:08):
The real question is whether systems that need to deal with both patient-specific authorizations and patient-independent authorizations typically capture them in the same system with the same user interfaces and whether the structures for the two use-cases have a high enough degree of overlap that it makes sense to use one resource rather than multiple.
Adrian Gropper (Jul 07 2016 at 19:50):
It's much easier to work from OAuth out than to reach consensus on the meaning of consent. In general, (a) the resource server deals with patient-independent authorizations and provides some notice of these to the patient, and (b) the authorization server manages the policies that are patient-specific and issues scope-related tokens to the resource server. Either way, in the general case, the patient needs a notification endpoint and this probably needs to be captured in FHIR architecture.
The main implementation decision for an OAuth-protected resource is whether the patient's policies are captured at the authorization server or sent to the authorization server somehow. Whatever this decision is, the resource server will need to combine the authorization server authorization scopes with the patient-independent authorization policies. Whatever the final authorization outcome is, the resource server, in good faith, needs to be able to notify a patient-selected endpoint.
All that said, if I was forced to define "consent", I would say that it means that I have specified or agreed to my authorization server and to my notification endpoint.
Grahame Grieve (Jul 07 2016 at 20:50):
well, clearly there's a definition question here. I agree that we don't want the definition to include administrators doing authorization configuration. For me, the notion of consent covers a patient agreeing what data can be shared about their record. That would argue that authorization decisions about application access are different to a patient authorising sharing of their record. Which means, to return to the start of this discussion, that I've talked myself into agreeing that patient should be 1..1, and Smart on FHIR OAuth only becomes consent if it's the person controlling their own record access
Grahame Grieve (Jul 07 2016 at 21:02):
updated the draft accordingly. @Lloyd McKenzie if you're still not happy we can discuss further
Lloyd McKenzie (Jul 07 2016 at 21:06):
@Grahame Grieve So we're going to create essentially a duplicate resource where patient isn't included? I can't think of many other changes needed for the research access use-case. (And systems will need to look at both resource types when determining whether to share data.)
Grahame Grieve (Jul 07 2016 at 21:08):
I don't know. perha[s you should describee the DAF use case in more details
Mohammad Jafari (Jul 07 2016 at 21:14):
@Grahame Grieve I agree that intuitively, "patient making policies about their own record" is the essential part in the definition of consent. If we take the patient out of consent, what remains is a general authorization policy made by someone other than the patient and all authorization policies are made by someone so what remains is not distinguishable from an admin making authorization policies.
Grahame Grieve (Jul 07 2016 at 21:35):
well, I don't agree that it's indistinguishable. There's still a categorical difference. Let's see what Lloyd comes forth with from DAF
Lloyd McKenzie (Jul 07 2016 at 22:29):
I'm going to defer to @Nagesh Bashyam to formally define the use-case.
John Moehrke (Jul 07 2016 at 23:07):
So, I started this by simply asking for Consent.patient to be put back at 1..1; I would love to hear a compelling argument that my request is inconsistent with Consent; but all I hear is non-describing statements that DAF wants to leave patient empty in some use-cases. Please bring forward more than "DAF needs it" discussion. What exactly does DAF need? I understand where the 'authority' comes from in a "consent" as I have described it, it comes from the act of "consent" that the patient gives. -- If we move away from 'Consent' then we need to reconsider calling the resource "Consent", something like "Authorization"; but if we do that then we likely need to drop the other 'Consent' use-cases -- or is DAF going to register non-patient DNR consents? All I ask is compelling discussion, Would be far better to have those that want this change to engage with the community that is working on this effort. --- I am not against "Authorization"; but I am against calling it "Consent" and not having it represent an act of Consent.
Grahame Grieve (Jul 07 2016 at 23:50):
so I've set patient back to 1..1 after the discussion. I found you persuasive. I'll look forward to the DAF use case
Lloyd McKenzie (Jul 08 2016 at 01:38):
It's not just DAF, it's the research community in general. They have a process by which authorization is granted to a particular consumer/study for a particular subset of data (with all of the inclusion/exclusion rules you might have for patient), but the permission is granted independent of patient. DAF simply happens to be an IG that's coming up right away in that space.
Grahame Grieve (Jul 08 2016 at 01:53):
well, I think that a DataUsageApproval resource would actually turn out to be different to a patient consent focused resource.
Grahame Grieve (Jul 08 2016 at 01:53):
similar, perhaps, in structure, but the details would differ in several important respects
Tarik Idris (Jul 08 2016 at 13:13):
Just to add my two cents to the distinction between consent and authorizations. Our implementation allows other systems to influence the authorization rules using consents (documents, not resources at the moment, but that is irrelevant). There are authorization rules that are independent of whether the patient (or a representative) agreed with them. Sometimes you can call them "implicit consent" - because authorization rules e.g. ones that grant access to LEOs or admins are not a matter of explicit agreement by the consentor, but if the patient agreed to treatment in facility X, state law and organizational policy will lead to some automatic authorizations.
Tarik Idris (Jul 08 2016 at 13:15):
Once you have authorization rules that cover more than one patient, as with the example given above where a researcher gets access to data from a bunch of patients, then the fiction of the "implicit consent" stops working, because you couldn't even point to the patient who "implicitly agreed by using our healthcare services".
Tarik Idris (Jul 08 2016 at 13:18):
We generate authorizations based on incoming consents. Technically, consents are currently documents (although they could be FHIR resources) and authorizations are XACML rules (or XACML policies/policySets).
Tarik Idris (Jul 08 2016 at 13:20):
I prefer exchanging consents (that lead to authorizations) over exchanging authorizations directly, because authorizations are usually more fine-grained and force the client to know much more about how the server holds, organizes and protects its data.
Tarik Idris (Jul 08 2016 at 13:24):
By the way, I couldn't participate in the discussions around FHIR consents for a while. I just looked at the current build and am presently surprised. I see a lot of good things in the current version. I only have 2 issues: 1. I am missing a data element in the consent resource itself - there is currently only one in the exception. How can I say that the patient agreed that the named providers have access to everything related to the episode of care X?
Tarik Idris (Jul 08 2016 at 13:28):
and 2: I still prefer modeling exceptions by using a second consent and linking them
Tarik Idris (Jul 08 2016 at 13:30):
On a positive note, I really like the mandatory policy URI and the clarification that the category is for indexing/retrieval!
Robert Horn (Jul 08 2016 at 13:59):
I like sticking with the 1..1 for patient. My model for how Consent is used is that there is a Decision Point. (I'll leave this a bit vague to be technology independent). The Decision Point needs three kinds of input:
- The specific situation for which the decision is to be made. This will be data items requested, people/orgs requesting, date, location, etc. This is different for every decision.
- The disclosure rules that are specific to the Patient. These are all the Consents. There will be multiple Consents in many cases.
- The disclosure rules that apply to all patients, or to entire classes of patient. I will call these policies.
The Decision Point then makes a Decision about what to disclose.
I anticipate that each of these three kinds will have substantial commonality within kind, but be very different. So it's reasonable to have a common structure for consents, but consent structures won't be the same as policy structures.
I looked at my rule books and training material for child abuse reporting, family social worker reporting, device safety, communicable diseases, and HIPAA exceptions. Every one of these agreed that Consent was for the individual patient. They used words out of the regulations for what I called policy. For example, in child abuse reporting the rule book said "If .... then mandatory reporting requires action A. In addition, iff the patient consents, you can also do actions B through Z." All of them frequently paired the policy statement with a consent statement.
An argument for different data structures is also in the rule books. All of the consent discussions were around categories of data and lists or categories of people/orgs. The policies ignored those and were based on specific data values, e.g.," positive TB test", or specific external real world events, e.g., "Law enforcement officer with a warrant". Unlike consents, policies had either "all patients" as in the TB case, or categories like "children under 18" in child abuse. These are very different kinds of information and call for different date structures.
So I don't expect the Consent structure to be appropriate for summarizing the policy structures.
Adrian Gropper (Jul 08 2016 at 14:27):
@Robert Horn "Decision Point" confuses the difference between institutional and individual boundaries in a way that makes it difficult to deal with the real-world problems. It seems convenient when the resource server and authorization server are managed by the same legal entity but if fails in the vast majority of cross-institutional cases. I know, as I have focused on this issue for HIE for the past 10 years.
As soon as the Decision Point is legally separate from the enforcement point (the OAuth Resource Server) the institution responsible for the resource server needs to communicate it's policies and have a strong federation agreement with the Decision Point. Both of these are problematic. Communicating an institution's policies to the Decision Point is complex (and may be beyond the scope of FHIR) and it exposes an institution's policies to potential competitors. Requiring a strong federation agreement is complex because it presumes a new governance structure for the Decision Point.
Experience on the web has shown that separating the resource and authorization servers is much more tractable. Policies are then managed by the separate entities (institutions or individuals) separately. This makes delegation clear and powerful. Even in the cases where the two entities are one, as happens within a single enterprise or with an unusually strong federation, are not really complicated by this OAuth abstraction because they gain in legal and business simplicity what they seem to have give up in added, standards-based, technical complexity.
Grahame Grieve (Jul 08 2016 at 21:10):
well, here's my takeaway from this exchange:
1. Patient is 1..1 still
2. we will need to define how policies are exchanged and made computable in order to close the loop on these things
3. @Robert Horn - can you enumerate the 'categories of data' you found referred to - make sure we cover them
(btw, I'd prefer that #2 happens outside FHIR, but that would depend on whether there is something)
Grahame Grieve (Jul 08 2016 at 21:11):
Tarik - answer to your question #1 is to use exception. Base policy: opt-in, and then details in the exception
Grahame Grieve (Jul 08 2016 at 21:11):
There is examples like this
Ioana Singureanu (Aug 24 2016 at 01:23):
I posted a couple of STU3 Consent examples under on the Cross-Paradigm IG for BH Release on the CBCC GForge site
- Consent for Research
- [Authorization to disclose sensitive information] (http://gforge.hl7.org/gf/download/frsrelease/1199/14597/authorization2disclose-sensitive-data.xml).
Let me know if you have any thoughts/feedback.
John Moehrke (Oct 11 2016 at 20:27):
Anyone wanting to help develop the FHIR Consent, please fill out our doodle poll to find a timeslot we can have a weekly meeting.
http://doodle.com/poll/9qbrhsxvadf73wfn
Ken Sinn (Dec 05 2016 at 20:14):
retracted, pending additional thoughts
John Moehrke (Dec 06 2016 at 17:35):
Note Consent Resource is discussed during a CBCC sub-workgroup call on Fridays http://wiki.hl7.org/index.php?title=HL7_FHIR_Consent_Directive_Project Everyone welcome!!!
Michael Donnelly (Jan 17 2017 at 19:50):
A number of people are in Garden Terrace #129 for the meeting with CBCC and Security about consent. Is this happening?
Alexander Mense (Jan 17 2017 at 19:53):
Securtity currently has a joint meeting with CBCC and Mobile Health in Frio / Hill Level ...
Michael Donnelly (Jan 17 2017 at 19:53):
THanks.
Jayashree Surnar (May 29 2017 at 11:19):
hello all, i'm confusing little bit with the policy/policyRule in consent Resource(http://build.fhir.org/consent.html) from where to take the uri? and in our appln we want to captur the consentingparty info along with their signiture(on papper) in consent? but dnt fined any field on Consent so any suggesions please. Thank you.
Ardon Toonstra (May 29 2017 at 12:40):
Hi Jayashree, the policy/policyRule thing of Consent is also not completely clear for me. Or at least why one of the elements should be filled. But policy/policyrule are links to the enforcing regulation/law of the Consent. This can for example be national law.
Ardon Toonstra (May 29 2017 at 12:41):
I think you can use Consent.consentingParty and Consent.source[X] to capture the consentingparty and their signitures
Ardon Toonstra (May 29 2017 at 12:49):
You can use the DocumentReference by a reference from Consent.Source to include mulitple documents in DocumentReference.content
Jayashree Surnar (May 29 2017 at 12:52):
and one more doubt, in our impl we are creating the questions and capturing the ans using Questionnaire and QR respectively and we decided to link that QR to consent.source[x]. but here again confusing whats the main purpose of policy and source[x]? which one should be used in what scenario?
Jayashree Surnar (May 29 2017 at 12:55):
and source[x] ...0-1 means we can't add multiple resources right?
Ardon Toonstra (May 29 2017 at 12:57):
Right, you can make only one reference to a DocumentReference. But this DocumentReference can have multiple .contents where more than one for example PDF's can be given
Jayashree Surnar (May 29 2017 at 13:25):
and if i have multiple consentingparty then where to capture their corresponding signiture?
Elliot Silver (May 29 2017 at 16:05):
@Ardon Toonstra I believe the multiple content in a DocumentReference are for indivudual pages of a scanned document or similar. I don't think it is for multiple different documents.
Ardon Toonstra (May 29 2017 at 16:17):
@Elliot Silver I think you are right since the whole scope is written in singular from of a document. You can argue if the consentingparty signatures belong to the same consent document
Ardon Toonstra (May 29 2017 at 16:18):
If they are documents on their one, where to put them?
Elliot Silver (May 29 2017 at 16:21):
I've got little experience with Consent, so I'll just present a novice's view... What is the meaning of multiple documents? Can you consent to one policy multiple times? Does it take multiple documents to show agreement to one policy?
Elliot Silver (May 29 2017 at 16:22):
I'm guessing there is only one documentation of actually consenting.
Grahame Grieve (May 29 2017 at 20:22):
@Jayashree Surnar several comments:
- the policy identifies what the user is consenting to. There are pre-defined URLs for general policies, and then jurisdictions will define URLs for their specific regulatory policies. E.g. here: http://hl7.org/fhir/us/core/ - but this hasn't happened yet. In the absence of that, you get to make up URLs for the policies you encounter. At some stage, we'll collect them and start working on this
-
policy vs Questionnaire - the forms for consent usually have the overall structure that the user consents to a general policy and then makes a series of choices (handled as except). The most general policies are opt-in/opt-out, but in most jurisdictions, there are pres-set policies that are some variation of 'sharing as decided by you except where dictated by law' which are applicable (often they have their own variation of opt-in / opt-out, but see https://healthcaresecprivacy.blogspot.com.au/2017/04/stop-using-opt-in-and-opt-out.html)
-
A single consent resource matches to a single agreeement - e.g. a single source. Generally, you would have multiple consents for different agreements
-
we expect that you'd capture the signatures regarding the consent in provenance statements about it
Jayashree Surnar (May 30 2017 at 04:12):
Thank you @Grahame Grieve , if we are creating the questions and capturing the ans using Questionnaire and QR resource respectively and attaching that QR to consent using Consent.source[x], then no need of policy right? and we can capture the consenting party signatures in provenance resource is it correct?
few days back when i discuss about the signature some one said we can capture it in Consent.source[x]...0-1, but its not seems to correct for me thats what asking again.
Grahame Grieve (May 30 2017 at 04:58):
well, whatever you have in the questionnaire is probably backed by real knowledge, but getting the QR won't help any one to understand it, other by human review. The Policy is meant to provide the reference to what underlies the Q/QR
Jayashree Surnar (May 30 2017 at 06:06):
ok thanks again. @Grahame Grieve .and is it better to use provenace resource to capture only the signature or shall we use an extension on consent?which one is best?
Grahame Grieve (May 30 2017 at 06:29):
digital signature? What do you need do with the signature?
Jayashree Surnar (May 30 2017 at 06:56):
we want to captur the consentingparty info along with their signiture(on papper)
Grahame Grieve (May 30 2017 at 06:59):
and then what?
Venkateswara R Davuluri (May 30 2017 at 14:54):
Hi Graphame,
confusing part is..1. when we use Opt-In & Opt-out fields (what ever may be the name), if the data field is boolean (yes=allow, no=deny) it makes it easy to implement. but now in FHIR model it is a URI. How to use this ? We should be linking the description of policy to Policy field itself right, not to Policy rule/choice of patient.
2. If I am using questions to capture different levels of a iteam (Non-invasive Ventilation, has options /responses - yes, no, maybe), then what is the role of exceptions ?
3. Using Provenance to capture validity of Consent seems good. But if I send this consent to another organization how we are validating that validation of consent (provenance) ?
John Moehrke (Jun 05 2017 at 13:41):
Hi all, sorry for the delay.. vacation... Grahame has provided the answers for the STU3 flavor. We are doing some re-organization based on feedback. As you have indicated there is confusion on how to use the elements. First, I would welcome you to our Friday calls to help improve the specification. The model is not all that mature, so we welcome your perspective to help improve it. policyRule is intended to be some identifier that directly ties this consent to a set of executable rules. We use URI as many rules engines have identifiers that can be represented in URI, where the rules encoding might be proprietary or based on some standard (e.g. XACML). Many of the elements in Consent are there to then add Policy Information to that rules engine, some of the elements are there to express the context of the Consent act.
John Moehrke (Jun 05 2017 at 13:48):
3. Not sure Provenance is what you want for what you call a signature. signature on paper, is likely to simply be scanned in as a Binary that is pointed to by a DocumentReference that is pointed to by source[x].
John Moehrke (Jun 05 2017 at 13:48):
2. I would expect your questioneer to populate the Consent.except as necessary given the responses to the questions. The QuestionnaireResponse could be archived as evidence... under source[x].
John Moehrke (Jun 05 2017 at 13:48):
3. When sending any Resource with a use-case that Provenance is important; you would send both the resource and the Provenance... or make Provenance discoverable/retrievable.
John Moehrke (Jun 05 2017 at 13:48):
(2+3) not sure how one uses online questionnaire and also paper... we expected these to be different possible workflows, not clear how they would cooexist.
Venkateswara R Davuluri (Jun 06 2017 at 11:08):
Hi John,
Thank you very much for your response. This explans a lot of things about consent.
We want to capture signature (like signature on paper) in mobile environment.
We are trying to understand the use of Provenance. This resource seems to be important but trying to understand where to use it.
Thank you.
John Moehrke (Jun 06 2017 at 21:34):
Provenance is intended to be used with ALL Resources, when it is important to explicitly express full provenance of a resource or revision of a resource. It is expected that a realm may choose to force Provenance use. This might be a global organization thing, or use-case specific. One possible explicit time to force Provenance is when importing information from an outside source. Such as importing a document or message; may result in a set of FHIR Resources which should have an explicit Provenance that describes where that data came from. But that is not something that the core FHIR specification would do. The Provenance.signature could contain a scanned image of ink on paper, it is expected to be more technical such as an XML-Signature or JSON-Signature. I have co-edited a paper on this -- https://healthcaresecprivacy.blogspot.com/2016/07/extending-fhir-standard-to-handle.html
Richard Townley-O'Neill (Jun 07 2017 at 01:50):
@John Moehrke I found your blog post (https://healthcaresecprivacy.blogspot.com.au/2016/03/provenance-vs-audit-it-is-not.html) more useful than the paper, for a FHIR-person.
Venkateswara R Davuluri (Jun 07 2017 at 04:38):
Thank you. Venkat
Abbie Watson (Mar 17 2018 at 19:59):
If we wanted to recommend that Consent Action Codes include the code of 'none', what would be the correct way to start that process? Filing FHIR Change Request ticket with gForge?
http://hl7.org/fhir/codesystem-consent-action.html
Grahame Grieve (Mar 17 2018 at 20:14):
yes
Abbie Watson (Mar 17 2018 at 20:16):
On it.
Abbie Watson (Mar 18 2018 at 15:21):
Not 100% sure I filed them in the correct spot, but #15795 and #15796 filed for Consent.defaultAction and Consent Action Code none. :)
John Moehrke (Mar 19 2018 at 16:04):
I am not sure I understand 'none'... I might understand 'all', but that is the meaning of the element when it is empty... The definition of Consent.provision.action is "Actions controlled by this rule"... so what is the meaning of a rule that controls no actions?
John Moehrke (Mar 19 2018 at 16:08):
@Abigail Watson it seems you have submitted CR for changes to Consent as is in STU3... We can not make changes to STU3, we can only make changes to current build.
John Moehrke (Mar 19 2018 at 16:10):
Also, have you looked at what we put into the FHIR Connectathon work? some did test using Consent to hold evidence of an OAuth managed consent... http://wiki.hl7.org/index.php?title=201801_Consumer_Centered_Data_Exchange
John Moehrke (Mar 19 2018 at 16:10):
I am not saying i is well written up, but might be helpful
Abbie Watson (Mar 19 2018 at 18:48):
Hi, the idea would be to harmonize the Consent object with OAuth a bit more. Right now, OAuth supports 'all' and 'none' as it's default rules. In effect, it uses the same value set for default rules as it does exceptions.
The way FHIR is currently implemented with policyRule, that default logic has to be implicitly set by server. What I'm proposing would allow it to be explicitly defined within the resource using the same action codable concept as used in the exceptions. It would allow more streamlined OAuth integration.
I'm working through the usecase, and am going to try to bake Consent into our OAuth library. I'll circle back around to this with a code sample and results before pressing further. Want to make sure I have all my facts and claims sorted out.
Also, I'm really confused as to where to access the current build. And thank you for the latest Connectathon work. Am reviewing and harmonizing my own work with the latest.
John Moehrke (Mar 19 2018 at 18:53):
current build is at http://build.fhir.org/
John Moehrke (Mar 19 2018 at 18:54):
I am very interested in what you are doing. Would very much like to work through this with you. This is an effort that everyone would benefit from.
Abbie Watson (Mar 19 2018 at 19:51):
Will be happy to keep you posted. There's interest in this from a half-dozen different directions, and I've got funding to continue working on it through the end of Q2.
Varvara (Sep 09 2019 at 18:40):
Hello, we are currently looking at Consent resource to capture patient consent for primary care services offered by a particular organization. If we chose consent.scope to be 'treatment' and .category = 'patient consent' from FHIR suggested code sets, then what would be the best way to query this particular consent tacking into account that patient may have a lot of other treatment consents in the future? @Andy Stechishin , could you help me here?
Andy Stechishin (Sep 09 2019 at 18:58):
@Varvara I am not the expert on the Consent Resource and its use (looping in @John Moehrke and @David Pyke ). I guess my question would be how many patient treatment consent do you expect (and is there any kind of time constraint that could also be applied)? If the answer is less than 20, pulling the full set and filtering post-retrieval might be your best approach. Other approaches could included extending the scope value set to include more discrete codes (I would advise against this personally) or perhaps adding an extension for treatmentScope. John and David may be able to provide better insight and implementation-based experience on how best to proceed
John Moehrke (Sep 09 2019 at 19:33):
I would offer that this is an opportunity for you to drive the standard. We have not had much experience or experimentation with using Consent for anything other than Privacy Consent.
I would expect the consent to treat to be related to the episode or condition... right?
Varvara (Sep 09 2019 at 19:45):
@Andy Stechishin , thank you so much, I also think that extending the .scope is the last choice. @John Moehrke I would expect that, in case of some particular treatment such as operation, but not necessary for 'primary care'. I was thinking if we can use source.DocumentReference to point on particular consent version and type, do you see it like an option?
John Moehrke (Sep 09 2019 at 19:58):
I don't understand what you are describing. Do you have an example?
Varvara (Sep 12 2019 at 18:15):
Sure, in Consent we have Consent.source which can be a reference to DocumentReference. For example, some organization has 3 different policies which may be signed - can we create three DocumentReference resources with different ids for each policy, so each Consent resource for a given patient will have a reference to one of three DocumentReference resources? so it would be easy to search if patient signed one of three consents: something like find patient consent where Consent.sourceReference.id = some_id. Or DocumentReference should always be different for each patient?
John Moehrke (Sep 12 2019 at 20:44):
If it is a single policy for the organization, then I would expect that to be referenced in Consent.policy.uri or Consent.policyRule
John Moehrke (Sep 12 2019 at 20:45):
the Consent.source[x] is intended to be per-patient evidence that the consent has been achieved.
Varvara (Sep 13 2019 at 21:34):
That makes sense, thank you. Unfortunately for us, Consent.policy.uri is not a search param
Grahame Grieve (Sep 14 2019 at 10:34):
sounds like you could submit a gForge task. But you can also add a custom search parameter for that for your server
John Moehrke (Sep 14 2019 at 18:20):
That makes sense, thank you. Unfortunately for us, Consent.policy.uri is not a search param
it should be. please submit a CR
Varvara (Sep 25 2019 at 17:50):
I did, thank you all for your help)
Ramandeep Dhanoa (Oct 03 2019 at 18:07):
Hi, we are working on mapping our EMR's immunization consent to FHIR. It has different 'Type' (shown in image below), top 3 are consents and rest seems to be 'Flag'. I am wondering if we map top 3 to the consent resource, where would this Type (Consent, Directive, Disclosure) fit? Is it Consent.scope? (Consnet.scope = 'Consent' seems weird) Any thoughts?
L_7AD7.tmp.PNG
Lloyd McKenzie (Oct 03 2019 at 18:11):
That seems like an 'unusual' combination of terms. Do you have examples where each of them are used? That might give you a better sense of how to map.
David Pyke (Oct 03 2019 at 19:18):
Consent Disclosure would likely Scope Consent.scope = Patient-privacy. Consent Consent could be anything, I would assume that would be treatment consent but I'd need to see an example. I can't say anything about Consent Directive as it would be policy dependent so I'll need an example to say anything at all.
Ramandeep Dhanoa (Oct 08 2019 at 18:45):
Example for Directive can be, if a patient is pregnant, do not give this immunization till this date. Disclosure - release of information, example - teenager not giving disclosure of info (in some cases their parents) regarding some vaccine...
David Pyke (Oct 08 2019 at 20:29):
The Directive as you show it would not be handled by Consent. However, Disclosure is exactly what Consent is designed for
Craig Newman (Oct 09 2019 at 18:33):
The CDS workgroup is working on a clinical practice guidelines IG that can be used for thinks like the directive (contraindication) against certain immunizations for pregnant women (and other rules impacting forecasted doses).
http://build.fhir.org/ig/HL7/cqf-recommendations/index.html
Last updated: Apr 12 2022 at 19:14 UTC
