[Openid-specs-heart] Draft HEART Meeting Notes 2016-09-12

Tue Sep 13 14:17:52 UTC 2016

Nancy,

"Share all" is not specific enough for the first bite at flows. That's
because, in the proactive flow I described in the "How about" case an hour
ago, Alice probably wants to register "all" of her patient-level resources
with the authorization server (as would be typical today with opt-in or out
of HIE). However, Dr.Bob does _not_ necessarily want "all" of what's
available. Getting "all" brings Dr.Bob a lot of information he does not
want to process and consequent liability (this was well discussed in my
medical society). There's a reason why a typical paper "first visit"
clipboard form does not ask for things like previous lab results.

The first bite at HEART flows needs to consider the FHIR resources and
scopes in a clear and realistic way. Therefore I suggest we clarify the
first bite as above by saying that Alice registers all patient-level
resources but Dr. Bob only requests the resources the FHIR standard can
give him that's closest to current meds and allergies, whatever these are.

Adrian

On Tue, Sep 13, 2016 at 8:50 AM, Nancy Lush <nlush at lgisoftware.com> wrote:

> Hi Eve,
>
>
>
> These are desirable scenarios, but start to add different complications.
>   I am suggesting that we do the simple case (Share all) for the first pass.
>
>
>
> FYI, we discussed your second point in the meeting.  We discussed using
> the medication statement (medications) as an example in the first use case.
>
>
>
> I think there are other complications around ‘first visit’ that will
> quickly get us back in the mud.  While this is something that will be
> valued by patients, if we address it first I think it will confuse our core
> objectives.  I also think that if we define our core user stories, the
> implementers will find ways to implement this particular objective.
>
>
>
> -Nancy
>
>
>
> *From:* Eve Maler [mailto:eve.maler at forgerock.com]
> *Sent:* Tuesday, September 13, 2016 7:49 AM
> *To:* Nancy Lush <nlush at lgisoftware.com>
> *Cc:* Sarah Squire <sarah at engageidentity.com>; HEART List <
> openid-specs-heart at lists.openid.net>
>
> *Subject:* Re: [Openid-specs-heart] Draft HEART Meeting Notes 2016-09-12
>
>
>
> I thought "first visit" was the specific circumstance that gave form,
> shape, and purpose to *why* Alice was sharing her data in the first place
> (for example, different data may be involved if it's a first visit vs. if
> it's a switch in doctors, which means the resource set profiling might be
> different). Otherwise, why is Alice taking this action?
>
>
>
> (Another circumstance could be "Alice shares her medication list (or
> allergies list) with her husband". This is something I'd like to do.)
>
>
>
> But I may be wrong.
>
>
>
> *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/> *London and Paris!*
>
>
>
> On Tue, Sep 13, 2016 at 1:31 PM, Nancy Lush <nlush at lgisoftware.com> wrote:
>
> In keeping with the objective of ‘we need to significantly narrow this
> document’ we should not be diverted by the “first visit” in this first
> pass.  That should be added to the list of ‘challenges’ that need to be
> discussed and addressed later.  We are having difficulty just finishing one
> simple user story using the full set of technology we would like to use.
> We are continually bogged down in the exceptions.
>
>
>
> Keep it simple, that is complicated enough:  Alice proactively gives Dr.
> Bob access to all of her basic data.
>
> I suspect that once we walk through this story completely, then the others
> will be much simpler to expand.
>
>
>
> -Nancy
>
>
>
> *From:* Openid-specs-heart [mailto:openid-specs-heart-
> bounces at lists.openid.net] *On Behalf Of *Eve Maler
> *Sent:* Tuesday, September 13, 2016 4:34 AM
> *To:* Sarah Squire <sarah at engageidentity.com>
> *Cc:* HEART List <openid-specs-heart at lists.openid.net>
> *Subject:* Re: [Openid-specs-heart] Draft HEART Meeting Notes 2016-09-12
>
>
>
> Hi folks-- Sorry I couldn't make this meeting due to my travel. I agree
> with getting more specific about the use cases. This is what the "flows"
> were/are supposed to accomplish. Did people look at those on the call? One
> question of specificity that came up earlier was sharing "first visit" data
> prior to going to the appointment vs. arranging for transfer of records
> when switching doctors. We could imagine a matrix of these two against the
> option of proactive (Alice shares) vs. reactive (Alice approves an access
> request) flows.
>
>
>
> Regarding delegating access to the policies themselves, I continue to
> think that this is "PhD-level UMA" (or not an UMA use case, e.g., XACML or
> something), and Occam's Razor suggests leaving this this out unless/until
> someone can state the specific need for Alice to share her policies. Then
> we'd know the context(s) for doing so.
>
>
>
> *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/> *London and Paris!*
>
>
>
> On Mon, Sep 12, 2016 at 11:07 PM, Sarah Squire <sarah at engageidentity.com>
> wrote:
>
> Attendees:
>
> Debbie Bucci
>
> Adrian Gropper
>
> Dale Moberg
>
> Edmund Jay
>
> Glen Marshall
>
> Jim Kragh
>
> Julie Maas
>
> Kenneth Salyards
>
> Luis Maas
>
> Nancy Lush
>
> Sarah Squire
>
> Thomas Sullivan
>
> Walter Kirk
>
>
>
> Debbie:
>
> Meeting is still on for September 19th.
>
> MEETING CANCELLED on September 26th.
>
>
>
> Sarah:
>
> The UMA use case as it stands now (https://bitbucket.org/openid/
> heart/wiki/Alice_Shares_with_Physicians_and_Others_UMA_FHIR) is extremely
> broad and talks about a lot of different scenarios. If we want to optimize
> for interoperability (which I think we do) we need to significantly narrow
> this document. I think it might help to write a few short user stories -
> things like “Dr. Bob can request Alice’s current medications” “Alice can
> reactively approve or deny Dr. Bob’s request.”
>
>
>
> Smaller bite-size stories like this will make it much easier for us to
> actually write the spec and make sure that the features we want are
> possible in a wide-ecosystem cross-domain context without any requirement
> for systems to agree beforehand on how to format requests across the wire.
>
>
>
> Does that make sense?
>
>
>
> Nancy:
>
> I agree completely.
>
>
>
> Debbie:
>
> Is the suggestion to boil this down to smaller peices?
>
>
>
> Sarah:
>
> Right, shorter user stories that indicate specific features.
>
>
>
> Adrian:
>
> Do we need to discuss how Dr. Bob got the address for the resource?
>
>
>
> Sarah:
>
> We talk a little about that in the security profile, I think maybe we
> suggest webfinger? We could certainly talk about it more in the semantic
> profile.
>
>
>
> Debbie:
>
> Is there something we should start walking through?
>
>
>
> Sarah:
>
> My question to the group is whether there are things in this use case,
> flows or functionality, that we don’t want to profile?
>
>
>
> Glen:
>
> I don’t think we should address discovery beyond recommendations. It would
> be a significant increase in scope.
>
>
>
> Sarah:
>
> Agreed
>
>
>
> Adrian:
>
> But we do have to be clear about how we relate resource discovery to the
> use cases that we present.
>
>
>
> Nancy:
>
> Let’s note that it exists and revisit it later.
>
>
>
> Debbie:
>
> Is there anything in the Data and Services section that we would take out?
>
>
>
> Sarah:
>
> We need to figure out which features and flows we want to enable and how
> one server would indicate to another server which flow it is using.
>
>
>
> Adrian:
>
> Can we do the medications use case first?
>
>
>
> Sarah:
>
> It’s actually irrelevant which FHIR resource we talk about. We don’t
> define the FHIR taxonomy. We are talking about features and flows that we
> will need to enable.
>
>
>
> Nancy:
>
> We can use medication as an example, but we should be generic in the
> specification as to which FHIR resource we are talking about.
>
>
>
> Ken:
>
> I don’t think it’s scalable to have a patient decide the policies on their
> resources.
>
>
>
> Debbie:
>
> It will be much simpler in practice. I do think that a patient will be
> able to say “share my medication list with Dr. Bob”
>
>
>
> Sarah:
>
> So, for example, we need to decide whether we want a proactive or reactive
> flow or both.
>
>
>
> Debbie:
>
> So I think we’ve always said that consent and delegation are in scope.
>
>
>
> Sarah:
>
> So we’re looking at the “Summary of sharing scenarios” section of the
> document. Do we want to profile all of these flows? We also need to profile
> how claims are going to work. If Alice is proactively setting policies, she
> will need to indicate what claims Dr. Bob has to fulfill before he gets
> access to her resources.
>
>
>
> Debbie:
>
> I would also like to see a flow where Alice delegates access.
>
>
>
> Sarah:
>
> Are we talking about delegating access to data? Or access to the policies
> themselves?
>
>
>
> Debbie:
>
> The policies themselves.
>
>
>
> Sarah:
>
> Okay, because there’s really no concept of that in the UMA protocol. It
> would just be switching the Resource Owner.
>
>
>
> Debbie:
>
> So we can talk about that in the spec. Maybe just make it auditable.
>
>
>
> 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
>
>

-- 

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/20160913/0f08d125/attachment-0001.html>