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

Glen Marshall [SRS] gfm at securityrs.com
Wed Oct 7 00:15:00 UTC 2015


It may be advantageous to work with IHE USA to create a national 
extension and/or implementation guide for the IHE IUA profile, at least 
for SMART of FHIR (Argonaut) OAuth scopes.  This is because IHE is more 
about implementation, while FHIR is a data model. There is sufficient 
cross-coordination and cross-membership between IHE and HL7 for this.

Developing a strategy for forwarding UMA may need a different 
cross-coordination strategy, but I'd still like to see it allied with 
IHE IUA.

*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 17:41, Justin Richer wrote:
> Evidence of that cross communication can be found in the fact that 
> HEART is starting with the Argonauts scope structure. Remember, this 
> information needs to flow both ways, and it is. Smart is currently 
> considering supporting HEART style client authenticating, for instance.
>
> It doesn't mean that both of us will end where we've started, but it 
> does mean that w e are not working in a vacuum on either side.
>
>
>
> -- Justin
>
> / Sent from my phone /
>
>
> -------- Original message --------
> From: Debbie Bucci <debbucci at gmail.com>
> Date: 10/6/2015 11:08 PM (GMT+01:00)
> To: "Glen Marshall [SRS]" <gfm at securityrs.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
>
> John Moerke
> Josh Mandel
> Bill Kinsley
>
> All actively participate with HL7 and offered their time here at HEART 
> and it's greatly appreciated.  Certain I have missed others.  A quick 
> glance at the Listserv show others are quietly following along.
>
> I have been trying to join the security and cbcc workgroups when I can.
>
> There is cross communication occuring already if you look close enough.
>
> On Oct 6, 2015 2:16 PM, "Glen Marshall [SRS]" <gfm at securityrs.com 
> <mailto: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 <tel:%28610%29%20644-2452>
>     Mobile: (610) 613-3084 <tel:%28610%29%20613-3084>
>     gfm at securityrs.com <mailto:gfm at securityrs.com>
>     www.SecurityRiskSolutions.com <http://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>
>>     [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>
>>     <mailto:BKinsley at nextgen.com>
>>     *Cc:* Justin Richer <jricher at mit.edu> <mailto:jricher at mit.edu>;
>>     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 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 *//*
>>             <http://www.nextgen.com/upgradecentral>*/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
>>     <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
>

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


More information about the Openid-specs-heart mailing list