[Openid-specs-heart] Health Relationship Trust Profile for Fast Healthcare Interoperability Resources (FHIR) OAuth 2.0 Scopes
Adrian Gropper
agropper at healthurl.com
Tue Oct 6 15:18:37 UTC 2015
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>
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]
> *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>
> 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
> 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
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>
>
> _______________________________________________
> Openid-specs-heart mailing list
> 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/dc56e5a9/attachment.html>
More information about the Openid-specs-heart
mailing list