[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