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

Tue Oct 6 18:25:06 UTC 2015

Glen,

I am active in HL7, IHE, and HEART. I am one of the co-chairs of the HL7 Security Workgroup.  

I think that HL7 has some standards that we can leverage, such as role vocabulary. The general response is that roles are not something that is agreed to across different organizations. I think however we are speaking of some very high-level roles, not the kind of detailed roles used in healthcare.

I also think that IHE is an appropriate place for the HEART work to be formally balloted and be maintained as a standard.

John

From: Openid-specs-heart [mailto:openid-specs-heart-bounces at lists.openid.net] On Behalf Of Glen Marshall [SRS]
Sent: Tuesday, October 06, 2015 1:16 PM
To: 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

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 <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.SecurityRiskSolutions.com&d=BQMDaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=U7MtcgfavUVbMbA5CC3U22PXudg66Rw_peiDqSunJcg&s=QTi4-6CEjr03D3Gvg0jamO2RYcvFZ3M350XC0G-Q-M0&e=> 

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  <mailto:BKinsley at nextgen.com> <BKinsley at nextgen.com>
Cc: Justin Richer  <mailto:jricher at mit.edu> <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

  <http://bridge.nextgen.com/Media/3140> 

  ________________________________   

William Kinsley , CISSP
Enterprise Architect, Ambulatory
NEXTGEN HEALTHCARE
Solutions for: Ambulatory, Inpatient and Community Connectivity
795 Horsham Road, Horsham, PA 19044
(215) 657-7010 x21128 <tel:%28215%29%20657-7010%20x21128>  
BKinsley at nextgen.com

 <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.oneugm.com_&d=BQMDaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=U7MtcgfavUVbMbA5CC3U22PXudg66Rw_peiDqSunJcg&s=P2MUPeMTsoXr3hOJyU8hXcD7IQX492sU6kF_xjm_aE8&e=> 

Be ready for MU and ICD-10 in 2015. Start your EHR version 5.8 and KBM version 8.3 upgrade today. Get the resources you need at www.nextgen.com/upgradecentral <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.nextgen.com_upgradecentral&d=BQMDaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=U7MtcgfavUVbMbA5CC3U22PXudg66Rw_peiDqSunJcg&s=C69skpTF7riP2iF-K9KjpyilxS8itv-CnF4UeDW13nM&e=> 

This message, and any documents attached hereto, may contain confidential or proprietary information intended only for the use of the addressee(s) named above or may contain information that is legally privileged. If you are not the intended addressee, or the person responsible for delivering it to the intended addressee, you are hereby notified that reading, disseminating, distributing or copying this message is strictly prohibited. If you have received this message by mistake, please immediately notify us by replying to the message and delete the original message and any copies immediately thereafter. Thank you for your cooperation.

_______________________________________________
Openid-specs-heart mailing list
Openid-specs-heart at lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs-heart <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart&d=BQMDaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=U7MtcgfavUVbMbA5CC3U22PXudg66Rw_peiDqSunJcg&s=eIjJyHz8EjrJdbY-T9RvKjvQv1sQTrl8Nhndw80cDag&e=> 

_______________________________________________
Openid-specs-heart mailing list
Openid-specs-heart at lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs-heart <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart&d=BQMDaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=U7MtcgfavUVbMbA5CC3U22PXudg66Rw_peiDqSunJcg&s=eIjJyHz8EjrJdbY-T9RvKjvQv1sQTrl8Nhndw80cDag&e=> 

-- 

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE:  <https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.org_donate-2D2_&d=BQMDaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=U7MtcgfavUVbMbA5CC3U22PXudg66Rw_peiDqSunJcg&s=MPiJJerE2uj-zBd6aJDuY7j8OmAM0F5s6dakk58b7pM&e=> 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 <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart&d=BQMDaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=U7MtcgfavUVbMbA5CC3U22PXudg66Rw_peiDqSunJcg&s=eIjJyHz8EjrJdbY-T9RvKjvQv1sQTrl8Nhndw80cDag&e=> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151006/4a7b3a54/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6966 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151006/4a7b3a54/attachment.p7s>