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

[Kinsley, William]

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<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
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

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