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

Tue Apr 19 11:32:20 UTC 2016

If I am reading this right .... I would vote for provisioning of data
[prior to ] first visit -  often data is requested up front before initial
visit

And

Consent [advanced ?] Directives.  Those are often registered by the state.

Not easy but use cases with visible returns imo.
On Apr 18, 2016 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160419/6f306e5c/attachment.html>