[Openid-specs-heart] Health Relationship Trust Profile for Fast Healthcare Interoperability Resources (FHIR) OAuth 2.0 Scopes
Glen Marshall [SRS]
gfm at securityrs.com
Tue Oct 6 18:16:18 UTC 2015
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
>
> o 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
>
> o The person that registers a resource with an Authorization
> Server. This is typically the Resource Owner (RO).
> o When a Custodian is in control of multiple Subjects, they are
> able to identify (name) the separate Subjects any way they
> choose.
> o A Custodian can access resources for multiple Subjects in a
> single transaction including, for example, a Patient List.
>
> * User
>
> o Anyone or anything that is not a Subject or a Custodian.
> o 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
>
> o A resource for a single Subject identified by an opaque
> pseudonym as registered with the Authorization Server.
> o The resource may contain Subject identity information or not.
> o When the resource does not contain Subject identity
> information, the Authorization Server is responsible for
> associating the pseudonyms with an identity.
>
> * Multi-Subject Resource
>
> o A resource for multiple Subjects registered with the
> Authorization Server by a Custodian or a User.
>
> * Identified Subject Resource
>
> o A resource for a single Subject that includes Subject
> identifying information in the resource URI as registered with
> the Authorization Server.
> o 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
>
>
>
>
> _________________________________ _
>
> 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://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/
>
>
>
> _______________________________________________
> 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/20151006/42355c07/attachment.html>
More information about the Openid-specs-heart
mailing list