[Openid-specs-heart] Draft HEART Meeting Notes 2015-08-17

Justin Richer jricher at mit.edu
Tue Aug 18 14:12:03 UTC 2015


Right, but they do it during the initial binding of alice’s identity and access tokens to the record. They don’t take in a bunch of attributes from Alice’s IdP and say, “oh, well, let’s go find some Alice that might fit this”. As long as they have the right record up during the binding, then that same record can be pulled up by its local identifier. At that point, the system doesn’t even care that Alice is Alice, they just know that account X has access to record Y because of a specific (and auditable) action.

 — Justin


> On Aug 18, 2015, at 9:51 AM, Maxwell, Jeremy (OS/OCPO) <Jeremy.Maxwell at hhs.gov> wrote:
> 
> Wait, I’m confused.  I know we called identity matching out of scope, which I agree with, but what did I miss that it’s unnecessary?  Even though Alice is mediating the exchange, the provider still needs to know which Alice in the EHR, right?
>  
>  
>  
>  
> From: Openid-specs-heart [mailto:openid-specs-heart-bounces at lists.openid.net] On Behalf Of Adrian Gropper
> Sent: Monday, August 17, 2015 6:41 PM
> To: Sarah Squire
> Cc: openid-specs-heart at lists.openid.net
> Subject: Re: [Openid-specs-heart] Draft HEART Meeting Notes 2015-08-17
>  
> Great notes. One flaw:
>  
> "The data exchange in this use case is patient-mediated, so identity matching is necessary."
>  
> should be is NOT necessary.
>  
> Adrian
> 
> 
> On Monday, August 17, 2015, Sarah Squire <sarah at engageidentity.com <mailto:sarah at engageidentity.com>> wrote:
> Attendees:
>  
> Debbie Bucci
> Abbie Barbir
> Adrian Gropper
> William Kinsley
> Glen Marshall
> Justin Richer
> Sarah Squire
> Michael Magrath
> Jim Kragh
> Josh Mandel
> Chad Evans
> Corey Spears
> Edmund Jay
> Jeremy Maxwell
> Andrew Hughes
> Eve Maler
>  
> 
> Notes:
>  
> Alice Enrolls at PCP Use Case
>  
> Justin’s comment was intended to convey that Alice should be able to login with whatever digital identity she chooses. We don’t want Alice to have to create multiple usernames and passwords.
>  
> Is federated identity core to the HEART project? The ability to use federated identities is core to HEART, but they are not required.
>  
> Identity proofing policies are out of scope for the HEART project
>  
> Leveraging common identity attributes is a core part of the problem statement for this use case.
>  
> Are we using OIDC in this use case? Yes, we are.
>  
> The data exchange in this use case is patient-mediated, so identity matching is necessary.
>  
> We have now finalized this use case.
>  
> New Use Cases
>  
> We would like the next use case to involve UMA, and we would like to be able to influence and harmonize with the FHIR API. What is it that we must profile vs what FHIR must profile?
>  
> We want to bias toward wide ecosystems.
> 
> Adrian will elaborate on his use cases and we can discuss next week.
> 
> Sarah Squire
> Engage Identity
> http://engageidentity.com <http://engageidentity.com/>
> 
> 
> --
>  
> Adrian Gropper MD
> 
> RESTORE Health Privacy!
> HELP us fight for the right to control personal health data.
> DONATE: http://patientprivacyrights.org/donate-2/ <http://patientprivacyrights.org/donate-2/>
>  
> _______________________________________________
> 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/20150818/2c2a75aa/attachment.html>


More information about the Openid-specs-heart mailing list