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

Adrian Gropper agropper at healthurl.com
Tue Apr 19 01:11:55 UTC 2016


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/e7f015e1/attachment-0001.html>


More information about the Openid-specs-heart mailing list