[Openid-specs-heart] Draft HEART Meeting Notes 2015-12-21

Tue Dec 22 22:01:09 UTC 2015

Toward the end of the doc, Aaron is asking what "patient-centered" means to
the HEART community.

Debbie speaks of patient-centered so maybe she's the official keeper of the
term.

As far as I'm concerned, patient-centered means that the patient brings the
context for health information exchange. HIE and interop can occur in three
different ways:
- the patient has no choice (e.g.: the hospital tells the patient they use
X as in CommonWell - period)
- the patient has limited choice (e.g.: the hospital asks the patient to
opt-in or out of the state HIE)
- the patient can specify her HIE (e.g.: the patient can tell the hospital
to use this Authorization Server)
My definition of patient-centered is only the third one.

Adrian

On Tue, Dec 22, 2015 at 4:24 PM, Aaron Seib <aaron.seib at nate-trust.org>
wrote:

> Thanks Adrian – I added some comments to the document with open ended
> questions that I hope spur more clarity – at least for me.
>
>
>
> Aaron
>
>
>
> Aaron Seib, CEO
>
> @CaptBlueButton
>
>  (o) 301-540-2311
>
> (m) 301-326-6843
>
> <http://nate-trust.org>
>
>
>
> *From:* agropper at gmail.com [mailto:agropper at gmail.com] *On Behalf Of *Adrian
> Gropper
> *Sent:* Monday, December 21, 2015 8:08 PM
> *To:* Justin Richer
> *Cc:* Aaron Seib; openid-specs-heart at lists.openid.net
> *Subject:* Re: [Openid-specs-heart] Draft HEART Meeting Notes 2015-12-21
>
>
>
> Updated doc with comments and additions.
>
> Adrian
>
>
>
> On Mon, Dec 21, 2015 at 6:16 PM, Justin Richer <jricher at mit.edu> wrote:
>
> For starters, the decision wasn’t about a single RS having a single AS,
> but a single Resource having a single AS. A resource server (RS) can have
> many resources.
>
>
>
>  — Justin
>
>
>
> On Dec 21, 2015, at 5:59 PM, Aaron Seib <aaron.seib at nate-trust.org> wrote:
>
>
>
> I am hoping that this is helpful to others.
>
>
>
> I think we are a work group divided by a common language at this point and
> maybe if we could get some concrete terms in place that relate to something
> for those of us who are at a loss when it comes to how some of the terms
> being used in various ways by different participants on the call (in what
> seem to be different ways probably because of the inexperience with the
> terms on my part anyhow) we might be able to accelerate a common set of
> terms.
>
>
>
> I wrote this to try to ascertain if my understanding of the discussion
> about assuming a single AS for a given RS was correct and why.  I also
> wanted to try to peel back the onion as far as the difference between an RS
> that related to multiple people (called Bulk Access for some unknowable
> reason as far as I am concerned) versus an RS that is constrained to a
> single person.  And to see if I am even in the right neighborhood when it
> comes to understanding the relationship between a URI and the use of the
> Term Resource Server.
>
>
>
> Please annotate, hyperlink, cross out or otherwise correct the attached
> and help me learn.
>
>
>
> Thank you,
>
>
>
> Aaron
>
>
>
> Aaron Seib, CEO
>
> @CaptBlueButton
>
>  (o) 301-540-2311
>
> (m) 301-326-6843
>
> <image001.jpg>
>
>
>
> *From:* Openid-specs-heart [
> mailto:openid-specs-heart-bounces at lists.openid.net
> <openid-specs-heart-bounces at lists.openid.net>] *On Behalf Of *Sarah Squire
> *Sent:* Monday, December 21, 2015 5:00 PM
> *To:* openid-specs-heart at lists.openid.net
> *Subject:* [Openid-specs-heart] Draft HEART Meeting Notes 2015-12-21
>
>
>
> Attendees:
>
>
>
> Debbie Bucci
>
> Sarah Squire
>
> Justin Richer
>
> Eve Maler
>
> Glen Marshall
>
> Aaron Seib
>
> Kenneth Salyards
>
> Brandon Smith
>
> Adrian Gropper
>
> Thomas Sullivan
>
> Dale Moberg
>
>
>
> *Group consensus decision: we will restrict HEART to use cases where one
> resource is only protected by one authorization server*
>
>
>
> Glen:
>
> I’ll be working on my use case for quick discussion in January.
>
>
>
> Debbie:
>
> Should we talk about one or more authorization servers?
>
>
>
> Aaron:
>
> It seems like sometimes HEART gets bogged down in things that would be
> better served by a policy group.
>
>
>
> Glen:
>
> I was trying to find the boundaries between specs and policy.
>
>
>
> Aaron:
>
> The API task force is dependent on the HEART group
>
>
>
> Glen:
>
> We need to consider the practical operations to move toward a better
> standardized technology
>
>
>
> Aaron:
>
> is there a difference between our approach to an individual as opposed to
> more than one person? We just need to serialize it.
>
>
>
> Justin:
>
> What do you mean by serialize it? The fact that it is being transmitted
> means that it’s by definition serialization.
>
>
>
> Aaron:
>
> I just meant we should go through the list one thing as a time.
>
> Eve:
>
> Are you talking about separating the data so that it’s about one person?
>
>
>
> Aaron:
>
> That’s the way I understand a person would do it.
>
>
>
> Eve:
>
> We could take the approach that if we’re patient-centric, then back
> channel transfer of data about multiple-people. Should multiple people be
> out of scope?
>
>
>
> Debbie:
>
> Except when the multiple people are “my family.”
>
>
>
> Justin:
>
> It’s in scope in our existing use cases.
>
>
>
> Adrian:
>
> Once we allow for multiple patients in a resource, a lot of people who are
> not as sophisticated are going to bundle discovery. The caregiver has
> nothing to do with discovery. As soon as you get to the user having
> role-based access, then there’s a discovery process.
>
>
>
> Sarah:
>
> Why wouldn’t you know what’s on the list?
>
>
>
> Adrian:
>
> If there’s a list, you need discovery
>
>
>
> Justin:
>
> There’s no discovery
>
>
>
> Adrian:
>
> From the client’s perspective, how does it know which authorization server
> to talk to?
>
>
>
> Sarah:
>
> There’s only one authorization server involved in this transaction
>
>
>
> Aaron:
>
> How do we comply with laws saying that medical records of wives should not
> be disclosed to abusive husbands?
>
>
>
> Sarah:
>
> By virtue of this system being patient-centered, the patient can control
> access to her data.
>
>
>
> Justin:
>
> The resource server can deny an access token for any reason, so you could
> do it that way.
>
>
>
> Glen:
>
> If we had a case where there were multiple ASs, it would be possible to
> have a resource server prepared to interpret all of those rules, some of
> which may be mutually exclusive. There is no grammar for the combinatoric
> aspects of multiple ASs.
>
>
>
> Justin:
>
> There is a project working on that called XACML. It doesn’t work at all.
>
>
>
> Glen:
>
> XACML doesn’t handle policies coming out of left field like the domestic
> violence policy.
>
>
>
> Adrian:
>
> Why not work with the UMA we have now rather than involving this
> complicated problem?
>
>
>
> Glen:
>
> I agree. What I was trying to get to is that there is a class of use cases
> that we shouldn’t be dealing with.
>
>
>
> Justin:
>
> I agree there’s a class of use cases that we don’t have the right tools
> for.
>
>
>
> Glen:
>
> In clinical research, we often grab bulk data, so solving for that is
> helpful.
>
>
>
> Adrian:
>
> Is there something about UMA 1.0.1 that works for the single authorization
> server use case
>
>
>
> Eve:
>
> I cannot figure out from this conversation what the multiple records use
> case is a problem.
>
>
>
> Justin:
>
> If a bulk request includes resources with multiple authorization servers,
> we don’t know which AS to talk to. If we define the bulk access record so
> that there’s only one AS, it works fine. Or if there’s an implicit AS it’s
> fine. Throughout all of this, we need to be very clear on the nature of the
> API that’s being protected when we’re designing security profiles.
>
>
>
> Eve:
>
> If data is restricted but then aggregated, is that still UMA?
>
>
>
> Justin:
>
> That’s out of scope. That’s a cache consistency problem.
>
>
>
> Eve:
>
> But we can do it with chained delegation.
>
>
>
> Debbie:
>
> Do they have to be in the same domain?
>
>
>
> Eve:
>
> They just have to be in the same ecosystem
>
>
>
> Eve:
>
> We’re talking about data portability of metadata. A resource set
> identifier is metadata that’s sensitive information that an AS knows about
> a user. You’d have to share it with another AS to be portable across
> networks. So we’re talking about something that I’ve worked on. It’s good
> that we’re talking about it. It’s not trivial for privacy or portability.
>
>
>
> Sarah:
>
> It sounds like it’s not fully baked enough to be within scope for HEART,
> correct?
>
>
>
> Eve:
>
> Correct.
>
>
>
> Adrian:
>
> Can we restrict HEART to use cases where a resource is only protected by
> one authorization server?
>
>
>
> Justin:
>
> I agree.
>
>
>
> Eve:
>
> I think that’s really reasonable. We know about IT that’s creaky. We
> shouldn’t be profiling anything that isn’t in the protocols we’re profiling.
>
>
>
> Debbie:
>
> In doing implementations, we might be able to inform standards an update
> profiles.
>
>
>
> Sarah:
>
> Just to be clear, we are all in agreement that we will restrict HEART to
> use cases where a resource is only protected by one authorization server?
>
>
>
> Glen:
>
> Within the domain? In the IRB case, we would have an authorization server.
>
>
>
> Justin:
>
> That’s fine as long as we use separate resources.
>
>
>
> Glen:
>
> I agree.
>
>
>
> Debbie:
>
> The data might be replicated and the IRB might acknowledge that the
> patient has it’s own authorization server, but may replicate those
> authorizations locally.
>
>
>
> Glen:
>
> Let’s not try to address keeping data in sync.
>
>
>
> Aaron:
>
> So we have two resource types defined, one for an individual, and another
> for multiple individuals in one data set
>
>
>
> Glen:
>
> Right, and that could be authorization for subsequent access.
>
>
>
> Adrian:
>
> But there’s only ever one authorization server associated with one resource
>
>
>
> Justin:
>
> Resources that are addressable.
>
>
>
> Aaron:
>
> I run an Accountable Care Organization. I have three pieces of software.
> Each is a separate data source. I can aggregate them and protect them with
> one AS. I can’t protect one set of data with three ASs.
>
>
>
> Aaron:
>
> FHIR has single and bulk resource types. Are they in the FHIR specs?
>
>
>
> Sarah:
>
> Just do a text search for “user” and “patient”
>
>
>
> Justin:
>
> Actually, they are in the SMART on FHIR, not the vanilla FHIR specs.
>
>
>
> Adrian:
>
> SMART is trying to work out the EHR to EHR use cases. We can help as we
> make progress on that.
>
>
> Sarah Squire
>
> Engage Identity
>
> http://engageidentity.com
> ------------------------------
>
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2016.0.7294 / Virus Database: 4489/11199 - Release Date: 12/17/15
>
> <Seib's grasp of the discussion so
> today.docx>_______________________________________________
> 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/
> ------------------------------
>
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2016.0.7294 / Virus Database: 4489/11199 - Release Date: 12/17/15
>

-- 

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/20151222/189e7a7c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 3141 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151222/189e7a7c/attachment-0001.jpg>