[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