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

Tue Oct 6 15:26:18 UTC 2015

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<mailto: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<mailto:jricher at mit.edu>]
Sent: Tuesday, October 06, 2015 8:12 AM
To: Kinsley, William <BKinsley at nextgen.com<mailto:BKinsley at nextgen.com>>
Cc: openid-specs-heart at lists.openid.net<mailto: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<mailto: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<mailto:BKinsley at nextgen.com>

[http://bridge.nextgen.com/Media/3181]<http://www.oneugm.com/>

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<http://www.nextgen.com/upgradecentral>

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<mailto: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<mailto: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/20151006/a7776855/attachment-0001.html>