[Openid-specs-heart] Draft HEART Meeting Notes 2016-04-18

Tue Apr 19 01:26:56 UTC 2016

Why couldn't notification coexist alongside authorization for access? And
what does the "mode" of permission have inherently to do with notification
about access?

*Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging Technology
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
Check out the 2016 schedule <https://summits.forgerock.com> for *ForgeRock
Summits and UnSummits*!

On Mon, Apr 18, 2016 at 6:11 PM, Adrian Gropper <agropper at healthurl.com>
wrote:

> Notification is more important than authorization because it enhances the
> security and transparency of the system. Under the "proactive" design
> pattern the Grantor is not notified of releases so the only way that
> breaches come to light is via whistle-blowers or when records show up on
> the market. We expect notification from banks and many internet businesses
> but the only notification we get in healthcare are the bills - usually 1-2
> months after the service.
>
> Once we establish a practical way to notify Grantors of data access, we
> also have a way of managing updates to interested parties - a medical home
> EHR, a PHR, or an encounter notification service. As we move beyond the
> paper mindset that Justin points out, we can have contemporaneous
> "Accounting for Disclosures" for all transactions including those that are
> currently exempt under HIPAA T/P/O. Once my authorization server is
> notified of a TPO transaction that it has no power to authorize or deny
> (because it's TPO) my AS can trigger an update of medical home EHRs, PHRs,
> or encounter notification services. Who would not want that?
>
> Adrian
>
> Adrian
>
> On Mon, Apr 18, 2016 at 7:50 PM, Eve Maler <eve.maler at forgerock.com>
> wrote:
>
>> True, "proactive" and "reactive" aren't the whole story either, they were
>> just a quick shorthand. This is where dealing with UMA and other systems
>> has been highlighting the fact for me that the usual language of
>> permissions (which doesn't really use those two words either) isn't very
>> rich, and I've actually been working to develop a classification system
>> that offers more depth. More anon, maybe...
>>
>>
>> *Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging
>> Technology
>> Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
>> Check out the 2016 schedule <https://summits.forgerock.com> for *ForgeRock
>> Summits and UnSummits*!
>>
>> On Mon, Apr 18, 2016 at 4:24 PM, Justin Richer <jricher at mit.edu> wrote:
>>
>>> Also, a point I raised on the call:
>>>
>>> Keep in mind that many of the historically “proactive” use cases are
>>> likely proactive precisely because there’s no reasonable way for people to
>>> be reactive in a paper-based system. So instead of asking people in-situ
>>> when making decisions, we clear everything up front so that we don’t have
>>> to ask again.
>>>
>>> Yes, we can model that with technology. My question to the group is:
>>> should we? I think sometimes it makes sense, and others it does not. We
>>> need to carefully weigh that.
>>>
>>> And ultimately, the line of “proactive/reactive” is fuzzy at best. What
>>> do we call it when Alice gets notified of the enforcement of a proactive
>>> policy, which she can then quickly change on the fly? What if Alice makes a
>>> reactive decision and tells the system to remember it (TOFU)?
>>>
>>>  — Justin
>>>
>>> On Apr 18, 2016, at 5:13 PM, Eve Maler <eve.maler at forgerock.com> wrote:
>>>
>>> Thanks, Sarah! Piling on: Here is the snippet with the latest edited
>>> list of sharing scenarios to consider:
>>>
>>>
>>> *We suggest to modularize our work on this use case, such that we can
>>> add "Step" sections whenever we're satisfied with previously vetted
>>> sections. Can we prioritize sharing scenarios in the group?*
>>>
>>>    - *(Proactive flow?:) Alice setting up provisioning of basic data on
>>>    first visits to Dr. Bob (and Dr. Erica for extra credit?): PHR A to EHR B
>>>    and EHR E.*
>>>    - *Alice being able to monitor and control access by Dr. Bob: Alice
>>>    interacting with SMH A.*
>>>    - *(Proactive flow?:) Alice sharing her medication list with her
>>>    spouse: PHR A to app C.*
>>>    - *(Reactive flow?:) Agreeing to do data donation under certain
>>>    conditions: EHR A to Aggregator*
>>>    - *(Proactive flow?:) Sharing mother’s medical concerns with
>>>    daughter: PHR D to app A*
>>>    - *(Proactive flow:) Consent directives: Rules set ahead of time for
>>>    EHR access by family members and others?*
>>>    - *(Reactive flow:) Alice approves access to physician requests for
>>>    records?*
>>>    - *(lots of other flows possible...)*
>>>
>>> Can people please weigh in on how they would prioritize these scenarios
>>> (and any other new ones, or edited versions of these) for building out the
>>> Steps? I don't think it would take all that long to write Steps for any
>>> (say) top-two flows if we narrow it down.
>>>
>>>
>>>
>>> *Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging
>>> Technology
>>> Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
>>> Check out the 2016 schedule <https://summits.forgerock.com/> for *ForgeRock
>>> Summits and UnSummits*!
>>>
>>> On Mon, Apr 18, 2016 at 2:04 PM, Sarah Squire <sarah at engageidentity.com>
>>> wrote:
>>>
>>>> Also, here's a link to the use cases we discussed today:
>>>>
>>>>
>>>> https://bitbucket.org/openid/heart/wiki/Alice_Shares_with_Physicians_and_Others_UMA_FHIR
>>>>
>>>> Thanks to Jim for the reminder!
>>>>
>>>> Sarah Squire
>>>> Engage Identity
>>>> http://engageidentity.com
>>>>
>>>> On Mon, Apr 18, 2016 at 1:59 PM, Sarah Squire <sarah at engageidentity.com
>>>> > wrote:
>>>>
>>>>> Attending:
>>>>> Eve Maler
>>>>> Tom Sullivan
>>>>> William Kinsley
>>>>> Josh Mandel
>>>>> Adrian Gropper
>>>>> Dale Moberg
>>>>> Scott Shorter
>>>>> Cait Ryan
>>>>> Simon Gordon
>>>>> Justin Richer
>>>>> Sarah Squire
>>>>> Glen Marshall
>>>>> Edmund Jay
>>>>> Jin Wen
>>>>> Kathleen Connor
>>>>> Jim Kragh
>>>>> Julie Maas
>>>>>
>>>>> Upcoming events:
>>>>> IIW
>>>>> EIC
>>>>> Cloud Identity Summit
>>>>> SOUPS
>>>>> Datapolooza
>>>>> OSCON
>>>>> IEEE Security and Privacy
>>>>>
>>>>> Is there an interest in trying to find alternate dates? Why don’t we
>>>>> construct a Doodle poll of dates where we know we definitely have an
>>>>> overlap?
>>>>>
>>>>> Action Item: Sarah will construct a Doodle poll.
>>>>>
>>>>> Eve:
>>>>> UMA FHIR Use Case: We’ve made small changes, but the content of the
>>>>> characters and flows hasn’t changed.
>>>>>
>>>>> We have sharing scenarios to consider. These need some group input.
>>>>>
>>>>> Jin:
>>>>> One case is a patient visiting a healthcare organization and then
>>>>> transferring his or her medical history. This would be an EHR to EHR
>>>>> transfer.
>>>>>
>>>>> Eve:
>>>>> There’s also sharing the medication list with Alice’s husband.
>>>>> What should we call a healthcare information consuming application?
>>>>>
>>>>> Kathleen:
>>>>> Maybe we could just call it a health app. Just leave the portal as a
>>>>> PHR and then everything else is an app. There are apps that a healthcare
>>>>> consumer might want to use in concert with other apps that have nothing to
>>>>> do with health.
>>>>>
>>>>> William:
>>>>> Are we differentiating between HIPAA covered apps and non-HIPAA
>>>>> covered apps?
>>>>>
>>>>> Eve:
>>>>> We could. Non-PHR seems to be the more relevant distinction.
>>>>>
>>>>> Adrian:
>>>>> What are we trying to do here? Why do we need separate use cases for
>>>>> all of these subcategories?
>>>>>
>>>>> Eve:
>>>>> In this case, it’s the people motivated to share. In the first case,
>>>>> Alice doesn’t want to fill in a clip board. In the sharing with husband
>>>>> case, Alice’s husband needs to know so he can help with care.
>>>>>
>>>>> Glen:
>>>>> That is of interest in setting up the use case, but not after.
>>>>>
>>>>> Eve:
>>>>> We could do a whole series of use cases, but we’re starting to see
>>>>> this as modular. If we documented each of the flows, we could easily
>>>>> prioritize them. For me, sharing with husband is the highest priority.
>>>>>
>>>>> Adrian:
>>>>> Would you consider two motivations as part of this list? Alice gathers
>>>>> different portals into one, and the desire to be “in the loop” for anything
>>>>> involving healthcare at a particular provider, i.e. wanting transparency.
>>>>>
>>>>> Eve:
>>>>> We would only branch off if we had other characters or flows. There
>>>>> are many motivations that are not listed here. The motivations you are
>>>>> talking about are outside of an UMA flow. We could have a use case
>>>>> involving central management of two EHRs by adding another doctor. Do we
>>>>> have an authoritative data source?
>>>>>
>>>>> Adrian:
>>>>> They would both be authoritative for different data. If there is no
>>>>> trigger update mechanism, then the PHR doesn’t solve that problem.
>>>>>
>>>>> Bill:
>>>>> I think we need to figure out what the scope of the use case is. The
>>>>> purpose of the PHR was to provide a single point of truth. I think what
>>>>> you’re trying to say is there is no single point of truth. Is that true?
>>>>>
>>>>> Adrian:
>>>>> Every FHIR endpoint is authoritative for something, and what matters
>>>>> is what triggers updates of another system. How do we create a surveillance
>>>>> system so that a doctor can find out when their patients are seen
>>>>> elsewhere?
>>>>>
>>>>> Bill:
>>>>> Having a single point of truth simplifies the use cases. I think that
>>>>> creates a complex use case.
>>>>>
>>>>> Sarah:
>>>>> How is this different from our oauth delegation use case?
>>>>>
>>>>> Adrian:
>>>>> Being able to specify an authorization server to multiple resources.
>>>>> And we have lots of directory problems.
>>>>>
>>>>> Sarah:
>>>>> Directory problems are outside the scope of HEART, and it sounds like
>>>>> you’re talking about Alice to Alice delegation, which has already been
>>>>> solved with oauth.
>>>>>
>>>>> Bill:
>>>>> Aren’t we supposed to be protocol agnostic?
>>>>>
>>>>> Justin:
>>>>> We’re trying to increase security, and we are definitely going to use
>>>>> FHIR. HEART is a longer term utopian project, whereas Argonauts is a
>>>>> current-state project. We are more forward-looking.
>>>>>
>>>>> Bill:
>>>>> I’m just saying we shouldn’t be too concerned with Argonauts because
>>>>> they’re jumping and doing things now, and that’s not our goal.
>>>>>
>>>>> Justin:
>>>>> Agreed, we just want to make sure that HEART remains realistic and
>>>>> implementable and becomes a next-generation option for the healthcare space.
>>>>>
>>>>> Eve:
>>>>> I’m trying to figure out how to summarize where we are. Our first use
>>>>> case is exchange between EHR and PHR. Is that controversial?
>>>>>
>>>>> Adrian:
>>>>> I just said it was unnecessary.
>>>>>
>>>>> Eve:
>>>>> But whoever is authoritative should be the source of truth. In the
>>>>> case of medications, the patient is authoritative.
>>>>>
>>>>> Adrian:
>>>>> The distinction between EHR and PHR is arbitrary.
>>>>>
>>>>> Eve:
>>>>> You obviously feel strongly about PHR mucking up the works. I don’t
>>>>> understand why it can’t be authoritative.
>>>>>
>>>>> Adrian:
>>>>> It’s not wrong, but it doesn’t serve the purpose of filling in the
>>>>> clipboard. You want to be able to do that even if the patient doesn’t have
>>>>> a PHR.
>>>>>
>>>>> Kathleen:
>>>>> It’s not a problem to me that there are different endpoints.
>>>>>
>>>>> Justin:
>>>>> Reminder that there’s no call next week due to the OpenID Foundation
>>>>> meeting. There will be a HEART get-together there.
>>>>>
>>>>>
>>>>> Sarah Squire
>>>>> Engage Identity
>>>>> http://engageidentity.com
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>>
>>
>> _______________________________________________
>> Openid-specs-heart mailing list
>> Openid-specs-heart at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>>
>>
>
>
> --
>
> Adrian Gropper MD
>
> PROTECT YOUR FUTURE - RESTORE Health Privacy!
> HELP us fight for the right to control personal health data.
> DONATE: http://patientprivacyrights.org/donate-2/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160418/615cdba4/attachment.html>