[Openid-specs-heart] Patient Consent

Eve Maler eve.maler at forgerock.com
Thu Jul 7 00:42:57 UTC 2016


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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160706/ae3cc1ee/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/20160706/ae3cc1ee/attachment.gif>


More information about the Openid-specs-heart mailing list