[Openid-specs-heart] Health Relationship Trust Profile for Fast Healthcare Interoperability Resources (FHIR) OAuth 2.0 Scopes

Tue Oct 6 19:28:15 UTC 2015

I have been involved at HL7 but not on this specific topic.  I am sure we could talk to Jaffe and find out how best to proceed if that is a shared sentiment.

Sent from my Verizon Wireless 4G LTE smartphone

<div>-------- Original message --------</div><div>From: Josh Mandel <Joshua.Mandel at childrens.harvard.edu> </div><div>Date:10/06/2015  2:24 PM  (GMT-05:00) </div><div>To: "Glen Marshall [SRS]" <gfm at securityrs.com> </div><div>Cc: openid-specs-heart at lists.openid.net </div><div>Subject: Re: [Openid-specs-heart] Health Relationship Trust Profile for Fast Healthcare Interoperability Resources (FHIR) OAuth 2.0 Scopes </div><div>
</div>I know at least John Moehrke and I are both actively involved in HL7.

On Tue, Oct 6, 2015 at 2:16 PM, Glen Marshall [SRS] <gfm at securityrs.com> wrote:
Who on this listserve is active in HL7?  I used to be, but am not now.  But I am fairly certain that if we want to be influential on HL7 and Argonaut's work, HEART must initiate and become actively     engaged with HL7.
Glen F. Marshall
Consultant
Security Risk Solutions, Inc.
698 Fishermans Bend
Mount Pleasant, SC 29464
Tel: (610) 644-2452
Mobile: (610) 613-3084
gfm at securityrs.com
www.SecurityRiskSolutions.com

On 10/6/15 11:26, Kinsley, William wrote:
I am more concerned with what I interpret as Argonaut’s hard coding specific security roles and that they are not representative of the OAuth and UMA approach. This is serving as a wake call to us (the HEART WG) that without any guidance from us, they are going to create a de facto security/privacy standard that will be difficult to unwind once it is adopted by other projects in the industry.

 Bill

From: agropper at gmail.com [mailto:agropper at gmail.com] On Behalf Of Adrian Gropper
Sent: Tuesday, October 06, 2015 11:19 AM
To: Kinsley, William <BKinsley at nextgen.com>
Cc: Justin Richer <jricher at mit.edu>; openid-specs-heart at lists.openid.net
Subject: Re: [Openid-specs-heart] Health Relationship Trust Profile for Fast Healthcare Interoperability Resources (FHIR) OAuth 2.0 Scopes

To begin the discussion, I would suggest three terms with healthcare / generic names:

Patient / Subject
The Subject of the resource when the resource refers to only one person. The Subject is also the Principal when they register their resource with the Authorization Server.
Custodian / Principal
The person that registers a resource with an Authorization Server. This is typically the Resource Owner (RO).
When a Custodian is in control of multiple Subjects, they are able to identify (name) the separate Subjects any way they choose.
A Custodian can access resources for multiple Subjects in a single transaction including, for example, a                 Patient List.
User
Anyone or anything that is not a Subject or a Custodian.
A User can access resources for multiple Subjects in a                 single transaction including, for example, a Patient List.
I hope we can map this to FHIR:

Pseudonymous Subject Resource
A resource for a single Subject identified by an opaque                 pseudonym as registered with the Authorization Server.
The resource may contain Subject identity information or not.
When the resource does not contain Subject identity information, the Authorization Server is responsible for associating the pseudonyms with an identity.
Multi-Subject Resource
A resource for multiple Subjects registered with the Authorization Server by a Custodian or a User.
Identified Subject Resource
A resource for a single Subject that includes Subject identifying information in the resource URI as registered with the Authorization Server.
An identified subject resource must be protected as                 personally identified information (PII).
Adrian

On Tue, Oct 6, 2015 at 10:05 AM, Kinsley, William <BKinsley at nextgen.com> wrote:

This is very informative detail of what the Argonaut                       project is doing and I don’t want to deter the                       information sharing process. I also think this is a reminder that these groups are proceeding without our guidance and that we need to discuss                       what is our timeline to produce some type of guidance to help them implement a process that is aligned with the finial product the HEART workgroup delivers.

Bill   

From: Justin Richer [mailto:jricher at mit.edu] 
Sent: Tuesday, October 06, 2015 8:12 AM
To: Kinsley, William <BKinsley at nextgen.com>
Cc: openid-specs-heart at lists.openid.net
Subject: Re: [Openid-specs-heart] Health Relationship Trust Profile for Fast Healthcare Interoperability Resources (FHIR) OAuth 2.0 Scopes

To clarify the objective, we were presenting the first draft of one of the outputs of this working group.

The HEART working group exists specifically to create these technical specifications. All of the discussions on use cases are intended to drive work on these specifications. 

Also, the group should note that the terms “patient” and “user” were imported directly from the Argonauts projects. 

 — Justin

On Oct 5, 2015, at 11:31 PM, Kinsley, William <BKinsley at nextgen.com> wrote:

This document was presented quickly during the last few minutes of our call and I am not sure what the objective was. However, it did raise some questions that could not be addressed at the time, specifically paragraph 2.1 “Permission type” raised some questions which I broke out below:

1.                                   The term “Patient” and “User” seem misleading and the purpose is not clear.

a.                                    A patient can have access to multiple patient records. For example, a parent who has five children at the same pediatrician would be a patient that can access multiple patient records.

b.                                   It also sounds like we are hardcoding two specific security roles, which would seem to contradict what we are trying to support in HEART (i.e. RBAC vs ABAC).

c.                                    There can be resource that are not related to specific patient or patients in general such as “Organization”, “HealthcareService”, “Practitioner”, etc.

Bill

  ________________________________  

 <
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151006/d1ec198c/attachment-0001.html>