[Openid-specs-heart] Patient Consent

John Moehrke johnmoehrke at gmail.com
Mon Jul 11 18:42:58 UTC 2016


Hi Nancy,

I noticed your note around informing the Doctor of the information that has
been hidden from them. This issue comes up often when we are discussing
this topic. The resolution of this is policy. That is, some use-cases allow
for this kind of disclosure, some forbid it, others leave it unclear. It is
never something we can resolve in a general-purpose way. Often times
clinicians worry that information is being hidden from them. The reality is
that the patient can always choose to not tell their doctor everything,
this has been fact throughout history. There have also been studies that
show that when a clinician is told that data has been withheld, they will
needlessly obsess over that data. I say needlessly obsess, not because I
don't think they are smart people, but because that is what the study
indicated, that is that the data withheld really was more embarrassing than
it was helpful to their new problem.  I am not advocating for blinding from
clinicians, I am happy to advocate for policies that give clinicians under
treatment relationships with all attitude, however I am pointing out that
there are regions in the world where 'no' means 'no'. The USA is special in
the power clinicians have, globally patients have more power. I would like
to keep this concern in the use-case, but keep it as a policy decision that
the HEART system can enable either way..

That said:

1. FHIR does have a mechanism (securityLabel) that can be used to indicate
that information has been masked. If policy allows for this flag to be used
it is there to indicate. It is just a TRUE/FALSE; indicating that there is
information that has been masked. It does not indicate what was masked.
2. FHIR does have a mechanism (operationOutcome) that can be used to
indicate more detailed response on a query. The operationOutcome is a
structure that can contain point-by-point details. If policy allows, then
more detail could be returned in a computable and human readable form.

John



John Moehrke
Principal Engineering Architect: Standards - Interoperability, Privacy, and
Security
CyberPrivacy – Enabling authorized communications while respecting Privacy
M +1 920-564-2067
JohnMoehrke at gmail.com
https://www.linkedin.com/in/johnmoehrke
https://healthcaresecprivacy.blogspot.com
"Quis custodiet ipsos custodes?" ("Who watches the watchers?")

On Wed, Jul 6, 2016 at 7:42 PM, Eve Maler <eve.maler at forgerock.com> wrote:

> Hi Nancy-- Responding point by point below...
>
>
> *Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging
> Technology
> Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
> *ForgeRock Summits and UnSummits* are coming to
> <http://summits.forgerock.com/> *Sydney, London, and Paris!*
>
> On Tue, Jun 28, 2016 at 6:14 AM, Nancy Lush <nlush at lgisoftware.com> wrote:
>
>> I wanted to make a couple of points that I was not able to squeeze in on
>> this last call.  (I tried to send this out yesterday, but it did not go
>> through)
>>
>>
>>
>> 1.      The notion that Alice shares with Dr. Bob – I think we need to
>> leave that phrase just as it is.   It should be understood that Dr. Bob’s
>> administrative staff would prepare that information for Dr. Bob prior to
>> the visit.  But Alice should not have to specify all that detail – all she
>> should have to know is that she is sharing with Dr. Bob. (My opinion and
>> suggestion.)
>>
> I definitely agree that Alice should have an intuitive and simple way to
> share, without weird "access control list" or other "subject of the
> authorization policy" complications. That said, if Dr. Bob's staff, or the
> entire hospital, would be shared with under the actual UMA-enabled system
> (vs. some sort of TPO understanding), if I had my druthers, I think I'd
> prefer it if Alice had in option to share with something like "the Dr. Bob
> care team" or something.
>
> We have been discussing what this could/should look like, without firm
> conclusions yet.
>
>
>> 2.      Regarding what Alice shares …
>>
>> a.      A couple of practical examples that were raised repeatedly
>> during patient engagement work groups include Alice not wanting to share
>> behavioral health information or not wanting to share her HIV diagnosis.
>> Let’s use these two practical examples to be explicit about how the consent
>> is defined.
>>
>> b.      If we are referring to the granting access at FHIR resource
>> level:  If Alice consents to share her problem list with Dr. Bob – what
>> would be the method for her to exclude her HIV diagnosis from the problem
>> list?  Ditto for her behavioral health diagnosis.
>>
> The "default permit with exclusions" pattern is really difficult
> technically -- the minusing out of content is a challenge. A good one to
> discuss.
>
>
>> c.       If Alice consents to share her Medication list with Dr. Bob,
>> could she exclude her med that clearly is used only to treat her HIV?  (And
>> on the other side of the argument, if she were allowed to do that how might
>> that impact drug interaction considerations?)
>>
>
> I think we've since talked about this on a call. There are additional
> subtleties, of course. Purpose-of-use limitations largely exist at a
> nontechnical level of enforcement unless you get into increasingly
> complicated levels of technology that wide ecosystems usually find not very
> workable (encryption, DRM licensing, etc.).
>
>> d.      I suspect that neither tagging or types will solve this.
>>
>> e.      I wanted to raise these cases for consideration and to point out
>> that we will have granularities that will be difficult to define.  That
>> said, I am totally in agreement to ‘not go so deep’ in this first
>> iteration.  Just so long as we are aware of this common set of examples.
>>
>
> Boiling only a small pond, instead of an ocean, is probably a good idea!
> :-)
>
>>
>>
>> Thanks much,
>>
>> Nancy
>>
>>
>>
>>
>>
>>
>>
>> *Nancy Lush          *
>>
>> nancy.lush at lgisoftware.com
>>
>> *Lush Group, Inc*
>>
>> Office: (401) 423-9111
>>
>> 28 Narragansett Ave
>>
>> PO Box 651
>>
>> www.lgisoftware.com
>>
>> Cell:(401) 965-9347
>>
>> Jamestown, RI 02835
>>
>>
>>
>> [image: LGI_logo_small]
>>
>>
>>
>>
>>
>> _______________________________________________
>> Openid-specs-heart mailing list
>> Openid-specs-heart at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>>
>>
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160711/ba86f7fc/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 3006 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160711/ba86f7fc/attachment.gif>


More information about the Openid-specs-heart mailing list