[Openid-specs-heart] "Scope" of sharing and purpose of use
Adrian Gropper
agropper at healthurl.com
Mon Dec 14 23:46:06 UTC 2015
The trick is: how does the doc and the patient get an email with a page of
data from http://www.goodrx.com/ 3 seconds after the doc clicks "Enter" on
a prescription?
GoodRx has a nice API. The patient portal will have a nice API with MU3.
The patient will use HEART to connect the two APIs and save a bundle of
money. The same thing will apply to patient's payer for things other than
drugs, if they put up an MU3 API.
Adrian
On Mon, Dec 14, 2015 at 6:15 PM, Aaron Seib <aaron.seib at nate-trust.org>
wrote:
> Is any payer the same as any other payer? Surely this is not always true
> but we can say the majority are similar.
>
> I think it is appropriate to leave research for later as the clinical and
> financial considerations may be modified versions of many use cases. All
> fall under the umbrella of Analysis in the sense of figuring out what works
> at a population level and calculating acceptable performance ranges.
>
> The question is what payment info does a doc need to do good by his
> patients? Does he have access to it and can he talk accurately about the
> cost to the consumer to help her make a decision that is right for her.
>
>
>
> Aaron Seib
> @CaptBlueButton
> (O) 301-540-9549
> (M) 301-326-6843
>
> "The trick to earning trust is to avoid all tricks. Including tricks on
> yourself."
>
>
>
> -------- Original message --------
> From: "Glen Marshall [SRS]" <gfm at securityrs.com>
> Date: 2015/12/14 4:57 PM (GMT-05:00)
> To: Aaron Seib <aaron.seib at nate-trust.org>,
> openid-specs-heart at lists.openid.net
> Subject: Re: [Openid-specs-heart] "Scope" of sharing and purpose of use
>
> Aaron,
>
> I have not problem adding "payer", which would include all of the
> revenue-cycle actors who author and share data with each other on behalf of
> a payee -- provider or health consumer. Outside of electronic access
> control's scope they may have legal, contractual, or policy-based
> restrictions on authorship and sharing. Some, but not all, of those
> restrictions may be automated as access controls. For analysis sake, any
> payer is the same as any other payer. This includes things like primary
> and secondary insurance who coordinate benefits, and intermediate
> billing/collection services that some providers use.
>
> I like simplicity. The distinctions created by various sorts of laws,
> regulations, contracts, etc. are out of scope for payers relative to the
> HEART discussions.
>
> FWIW, I left the research leg out for now. I think it could be a
> policy-defined special case within provider. But the access to a single
> consumer versus bulk access to multiple health consumers may be a
> differentiator. Same/same for payers who reimburse for a patient
> population rather than single health consumers.
>
> *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 12/14/15 16:33, Aaron Seib wrote:
>
>
> That would be amazing.
> The only add I think is important to consider is adding an actor called Payer. More and more the lines that differentiate a.Payer from a Provider and a Payer from a Consumer.have.blurred but if we can work in that third leg there may be more evident ways to incorporate business cases as part of the analysis.
> I am not alone in thinking we'd be further along with clinical interop if we hadn't artificially segregated administration Dara for some reason about a decade ago.
>
>
> Aaron Seib at CaptBlueButton
> (O) 301-540-9549(M) 301-326-6843
> "The trick to earning trust is to avoid all tricks. Including tricks on yourself."
>
>
> -------- Original message --------
> From: "Glen Marshall [SRS]" <gfm at securityrs.com> <gfm at securityrs.com>
> Date: 2015/12/14 4:04 PM (GMT-05:00)
> To: openid-specs-heart at lists.openid.net
> Subject: Re: [Openid-specs-heart] "Scope" of sharing and purpose of use
>
>
> Somehow this thread has confused me. It may be only a temporary
> lapse, but I'd like to re-wrap my head around some actors and the
> sort of access rights they have:
>
>
> Providers - Am I correct in saying this category includes
>
> Health institutions - hospitals, ambulatory clinics, skilled
> nursing facilities, physical rehab, substance abuse rehab,
> long-term care, etc.
>
>
> Professional practitioners, e.g., physicians, PAs, NPs, RNs,
> LPNs, dentists, podiatrists, chiropractors, licensed massage
> therapists, non-Western medicine modalities
> Employees and business associates of the above, authorized
> to act on their behalf in role- or contract-limited ways.
>
> Health consumers
>
> Patients
> Authorized representatives of patients - relatives or others
> who have been granted authorities of various sorts.
>
>
>
>
>
>
> For simplicity's sake, I would like to assume that the providers
> category has the general ability to author and share health data
> with each other on behalf of multiple health consumers. Outside of
> electronic access control's scope they may have legal, contractual,
> or policy-based restrictions on authorship and sharing. Some, but
> not all, of those restrictions may be automated as access controls.
> For analysis sake, any provider is the same as any other provider.
>
>
>
> Also for simplicity's sake, I would like to assume that health
> consumers have the general equal ability to author and share data
> with providers on behalf of a single patient. Outside of electronic
> access control's scope they may have legal, contractual, or
> policy-based restrictions on authorship and sharing. Some, but not
> all, of those restrictions may be automated as access controls. For
> analysis sake, any health consumer is the same as any other health
> consumer.
>
>
>
> Simplicity includes not trying to automate all restrictions. It
> also means we can overlook most granularities within the actor types
> unless law or regulation requires a differentiation, e.g., as in
> psychiatric notes or substance-abuse treatment.
>
>
>
> For the providers, I'd like to assume that their dominant
> requirement for data access is treatment, payment, or operation with
> a guarantee of high availability and integrity.
>
>
>
> For the health consumers, I assume that their dominant requirement
> is providers having and using adequate knowledge of their health.
> Their secondary requirement is confidentiality.
>
>
>
> Privacy is a policy-level concept that is supported by security
> controls - technical, administrative, physical, and environmental.
>
>
>
> Can we publish a map fir the above vocabulary to the terminology
> used by cross-industry concepts under discussion?
>
>
>
>
> 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 12/14/15 12:10, Aaron Seib wrote:
>
>
>
>
>
>
> <!--
> /* Font Definitions */
> @font-face
> {font-family:Calibri;
> panose-1:2 15 5 2 2 2 4 3 2 4;}
> @font-face
> {font-family:Tahoma;
> panose-1:2 11 6 4 3 5 4 4 2 4;}
> @font-face
> {font-family:Verdana;
> panose-1:2 11 6 4 3 5 4 4 2 4;}
> /* Style Definitions */
> p.MsoNormal, li.MsoNormal, div.MsoNormal
> {margin:0in;
> margin-bottom:.0001pt;
> font-size:12.0pt;
> font-family:"Times New Roman","serif";}
> a:link, span.MsoHyperlink
> {mso-style-priority:99;
> color:blue;
> text-decoration:underline;}
> a:visited, span.MsoHyperlinkFollowed
> {mso-style-priority:99;
> color:purple;
> text-decoration:underline;}
> p
> {mso-style-priority:99;
> mso-margin-top-alt:auto;
> margin-right:0in;
> mso-margin-bottom-alt:auto;
> margin-left:0in;
> font-size:12.0pt;
> font-family:"Times New Roman","serif";}
> p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
> {mso-style-priority:99;
> mso-style-link:"Balloon Text Char";
> margin:0in;
> margin-bottom:.0001pt;
> font-size:8.0pt;
> font-family:"Tahoma","sans-serif";}
> p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
> {mso-style-priority:34;
> margin-top:0in;
> margin-right:0in;
> margin-bottom:0in;
> margin-left:.5in;
> margin-bottom:.0001pt;
> font-size:12.0pt;
> font-family:"Times New Roman","serif";}
> span.BalloonTextChar
> {mso-style-name:"Balloon Text Char";
> mso-style-priority:99;
> mso-style-link:"Balloon Text";
> font-family:"Tahoma","sans-serif";}
> span.EmailStyle21
> {mso-style-type:personal;
> font-family:"Calibri","sans-serif";
> color:#1F497D;}
> span.EmailStyle22
> {mso-style-type:personal-reply;
> font-family:"Calibri","sans-serif";
> color:#1F497D;}
> .MsoChpDefault
> {mso-style-type:export-only;
> font-size:10.0pt;}
> @page WordSection1
> {size:8.5in 11.0in;
> margin:1.0in 1.0in 1.0in 1.0in;}
> div.WordSection1
> {page:WordSection1;}
> /* List Definitions */
> @list l0
> {mso-list-id:932512138;
> mso-list-type:hybrid;
> mso-list-template-ids:-2062537032 1143393074 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
> @list l0:level1
> {mso-level-text:"\(%1\)";
> mso-level-tab-stop:none;
> mso-level-number-position:left;
> margin-left:1.0in;
> text-indent:-.25in;}
> @list l0:level2
> {mso-level-number-format:alpha-lower;
> mso-level-tab-stop:none;
> mso-level-number-position:left;
> margin-left:1.5in;
> text-indent:-.25in;}
> @list l0:level3
> {mso-level-number-format:roman-lower;
> mso-level-tab-stop:none;
> mso-level-number-position:right;
> margin-left:2.0in;
> text-indent:-9.0pt;}
> @list l0:level4
> {mso-level-tab-stop:none;
> mso-level-number-position:left;
> margin-left:2.5in;
> text-indent:-.25in;}
> @list l0:level5
> {mso-level-number-format:alpha-lower;
> mso-level-tab-stop:none;
> mso-level-number-position:left;
> margin-left:3.0in;
> text-indent:-.25in;}
> @list l0:level6
> {mso-level-number-format:roman-lower;
> mso-level-tab-stop:none;
> mso-level-number-position:right;
> margin-left:3.5in;
> text-indent:-9.0pt;}
> @list l0:level7
> {mso-level-tab-stop:none;
> mso-level-number-position:left;
> margin-left:4.0in;
> text-indent:-.25in;}
> @list l0:level8
> {mso-level-number-format:alpha-lower;
> mso-level-tab-stop:none;
> mso-level-number-position:left;
> margin-left:4.5in;
> text-indent:-.25in;}
> @list l0:level9
> {mso-level-number-format:roman-lower;
> mso-level-tab-stop:none;
> mso-level-number-position:right;
> margin-left:5.0in;
> text-indent:-9.0pt;}
> @list l1
> {mso-list-id:1833597363;
> mso-list-type:hybrid;
> mso-list-template-ids:-1192981228 1143393074 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
> @list l1:level1
> {mso-level-text:"\(%1\)";
> mso-level-tab-stop:none;
> mso-level-number-position:left;
> text-indent:-.25in;}
> @list l1:level2
> {mso-level-number-format:alpha-lower;
> mso-level-tab-stop:none;
> mso-level-number-position:left;
> text-indent:-.25in;}
> @list l1:level3
> {mso-level-number-format:roman-lower;
> mso-level-tab-stop:none;
> mso-level-number-position:right;
> text-indent:-9.0pt;}
> @list l1:level4
> {mso-level-tab-stop:none;
> mso-level-number-position:left;
> text-indent:-.25in;}
> @list l1:level5
> {mso-level-number-format:alpha-lower;
> mso-level-tab-stop:none;
> mso-level-number-position:left;
> text-indent:-.25in;}
> @list l1:level6
> {mso-level-number-format:roman-lower;
> mso-level-tab-stop:none;
> mso-level-number-position:right;
> text-indent:-9.0pt;}
> @list l1:level7
> {mso-level-tab-stop:none;
> mso-level-number-position:left;
> text-indent:-.25in;}
> @list l1:level8
> {mso-level-number-format:alpha-lower;
> mso-level-tab-stop:none;
> mso-level-number-position:left;
> text-indent:-.25in;}
> @list l1:level9
> {mso-level-number-format:roman-lower;
> mso-level-tab-stop:none;
> mso-level-number-position:right;
> text-indent:-9.0pt;}
> ol
> {margin-bottom:0in;}
> ul
> {margin-bottom:0in;}
> -->
>
> Getting
> closer to understanding…
>
>
> Aaron
> Seib, CEO
> @CaptBlueButton
>
> (o)
> 301-540-2311
> (m)
> 301-326-6843
>
>
>
>
>
> From:
> Justin Richer [mailto:jricher at mit.edu <jricher at mit.edu>]
>
> Sent: Monday, December 14, 2015 11:23 AM
>
> To: Aaron Seib
>
> Cc: Adrian Gropper;
> openid-specs-heart at lists.openid.net
>
> Subject: Re: [Openid-specs-heart] "Scope" of
> sharing and purpose of use
>
>
>
> “Permission Type” is really a whole lot
> simpler than people are making it out to be.
>
>
>
>
>
>
>
> “patient” means “get me a single specific
> record for a single specific person”. When there is no other
> indicator (the “aud” parameter) this is the record for the
> currently logged in person. This is going to be a common
> enough use case, and it’s the default OAuth case, that
> optimizing for this makes sense.
>
>
>
>
>
> “user” means “get me all of the records
> that I have access to”. There is no record indicator here in
> the query because it’s basically a get-all-the-stuff type of
> request. What matches might be a single record. It might be
> many records. It might be aggregate data. But it’s not a
> query for a specific record when this permission type is
> used.
>
>
>
>
>
> Both of these can be in cases where Alice
> has user-to-user delegated access (her little sister Joanne has
> granted her access to her records at Regional Hospital
> where they both had their babies) to her family
> members. For the “patient” scope with no “aud” parameter,
> the token is good for Alice’s record. For the “patient”
> scope with an “aud” parameter, the token is good for the
> record indicated by that aud parameter. But just that one
> specific record! Using this token to get other records will
> fail. For the “user” scope it’s a request for all records
> Alice has access to. She can’t specify which one, since
> that’s not what this kind of scope is for.
>
> I
> think that is clear. I think where the consternation
> comes from is when the User isn’t a consumer but a list of
> people who have claimed TPO access rights to a set of
> records (patients). Is the Heart Profile silent on that.
> This is where the policy gets confounded if each of the
> patients doesn’t have the chance to first “recognize” that
> the person who claims to have a Tx relationship with them
> is in fact a doc that they believe they have a treatment
> relationship with. This is the fly in the ointment that
> has Serpico buzzing and I think rightly so. Not that we
> have to address the issue that he described as Discovery
> for the HEART work to make progress and sense – it just
> needs to be clearly isolated.
>
> The
> bottom line is there are creative trial lawyers who will
> ascert that a breach occurred is some Provider was claimed
> to have had a Treatment relationship with someone when in
> fact they didn’t. Perhaps Permission Type is too simple
> if it can’t address this concern. That or make it easy
> enough for us to demarcate the breadth of where it comes
> into play and put it in a parking lot for a future need.
>
> This
> is a real case we had at the state level. Male Doc is
> working in a practice. He has access to the EMR that
> every other doc in his practice has access to so could see
> the data of all the patients that went there. Turns out
> the Husband of the woman he is committing adultery with
> was a patient of another doc at the practice. This guy is
> a father and has two kids. Husband and Wife split up.
> Doc and woman get married and want to get custody of the
> kids. Doc looks at ex-husbands medical records and finds
> some sensitive information that the new couples lawyers
> use to argue that the dad isn’t a fit parent. Fortunately
> – the father’s lawyer figures it out and puts the keibash
> on using that breached data and the Judge makes his
> custody decision sans the sensitive health information
> that shouldn’t be available (and later in another court
> room the doc gets convicted of a HIPAA violation).
>
> The
> concern that we are all twisting around seems to be the
> lack of distinction about the permission types. Maybe
> there is a way to clarify it using another construct that
> I haven’t come up with. Is this kind of concern addressed
> somewhere else?
>
>
>
>
>
>
>
>
> — Justin
>
>
>
>
>
>
>
>
>
> On Dec 13, 2015, at 11:10 PM, Aaron
> Seib <aaron.seib at nate-trust.org> <aaron.seib at nate-trust.org>
> wrote:
>
>
>
>
>
> I
> still don’t think I am 100% on what Discovery
> means in this context.
>
>
>
>
>
> Here
> is the def you provided:
>
>
>
>
> Discovery
> means: the user(1) doesn't know who will
> be on the list. That puts a lot of responsibility on
> the RS to do the right thing(2).
> In HIEs for example, they insist the user is a
> practicing physician because they want to reduce
> their liability if someone's name pops up on a list
> that the user should not have seen.
>
>
>
> (1) Who
> is the user? I am still looking to the
> Permission Type
> to see if I can get that set of terms to line up
> in my head. Patient was a permission type which
> in the health domain correlates to the patient who
> is the subject of the PHI that the Resource Server
> may be disclosing. The assumption being that we
> can match the identity of the person who is using
> a client application to connect to the resource
> server (owned by the institution that operates
> the Resource Server – in the API TF scope the
> typical example being a EMR used by the caregiver
> that the patient has had treatment) with the
> Medical Record Number (MRN) or equivalent in the
> Resource Servers enterprise context (I don’t see
> any reason why we can’t say that an HIE with an
> MPI might be able to simplify this by correlating
> the MPI values to the person who is using the
> client app to access data about themselves across
> Resource Servers that have data about that person
> “Patient”).
> (2) Do
> the Right Thing -
>
>
>
>
> Sorry
> for all the verbiage – I want to get my meager
> understanding spelt out so it can be corrected.
> This may not be fruitful but it occurs to me
> that something that isn’t apparent that is
> becoming more apparent to me as I wrestle with
> this is that the idea of User may be better
> understood as a set of several or more
> sub-categories.
>
> user
> The scope is for a bulk set of records (I
> am assuming that it is implied here that set of
> records is meant to convey data for more than
> one person – the notion of a record is not clear
> to me here I must admit) or for aggregate
> data not representing a single patient (is
> this meant to be a distinction or a reiteration
> of the bulk set of records? What is the
> difference?), based on what is available to
> the current user (here is where the turn
> of phrase seems to be slipping. I am still
> struggling with the some notion being conveyed
> here.
>
> The question that comes to mind is if we
> look at the set of records being made available
> ‘to the current user’ is that person’s record one
> of those found in the set of records? There seem
> to be a couple of distinctions that are probably
> implied but might help to make explicit. At a
> minimum there are two cases that come to mind:
> (1) The case where the ‘Current User’ may
> have a record in the set being returned and any
> other person’s record being disclosed is permitted
> because that other person granted the User
> permission.
> (2) The case where the ‘Current User’ does
> not have a record in the current set and is
> accessing them as a result of capacity being
> vested in them by the Record owner, because of
> their professional role.
>
> I am not sure if there is a more precise
> way to look at it but it would seem to be that the
> root difference has something to do with how the
> User got the permission. It may not be evident I
> am seeing the difference being based on how the
> user got the permission. In case (1) I think of
> the person as a family care giver who has access
> to other ‘family’ members records because they
> granted that to him\her to have access and it is
> not in the role of providing treatment as
> traditionally defined by HIPAA. In the (2) case I
> see it being derived based on the fact that the
> person is in a Treatment role as defined by HIPAA
> and the Record Owner (i.e., the Hospital et al)
> gives them permission to access certain records.
>
> I think the key to unraveling this not
> is to differentiate between users who are not
> acting in a professional capacity from those that
> are as the applicable authorization to disclose is
> derived from two separate authorities. In Case
> (1) the User is getting permission to access those
> other records because the patients whom the
> records are about gave him\her permision as they
> may given their right to share with whomever they
> please while under case (2) they are getting
> permission as an aspect of their professional
> requirements as warranted by the resource owner.
>
> Not sure if this is half baked or not
> but there if there is a fly in the ointment it
> seems to me that it has to do with what John
> referred to as purpose of use earlier on. Assume
> that the User in case 2 has a purpose of use to be
> treatment and I think it is easier to digest. The
> word to use for the Consumer’s purpose of use
> alludes me right now.
>
> I think the unifying issue is that the
> user’s purpose of use must be the same for all the
> records being retrieved.
>
> I think that is the issue with Discovery
> that is hard to get a grasp on.
>
> If an HIE is granting permission to a
> Requesting party (why do we use the word User
> rather then requeting party here?) for a set of
> records it should only be for one or the other
> purpose of use and the purpose of use must match
> the part being played for the transaction being
> responded to by the RS as known to the RO.
>
>
>
>
> Aaron
> Seib
>
>
> NATE,
> CEO
>
>
> @CaptBlueButton
>
>
> (o)
> 301-540-2311
>
>
> (m)
> 301-326-6843
>
>
>
>
>
>
>
>
> From:
> agropper at gmail.com
> [mailto:agropper at gmail.com <agropper at gmail.com>]
> On Behalf Of Adrian Gropper
>
> Sent: Friday, December 11, 2015 5:29 PM
>
> To: Aaron Seib
>
> Cc: openid-specs-heart at lists.openid.net
>
> Subject: Re: [Openid-specs-heart] "Scope"
> of sharing and purpose of use
>
>
>
>
>
>
>
> Hi Aaron, Thanks
> for highlighting the important issue of
> discovery.
>
>
>
> Discovery means: the user doesn't know who
> will be on the list. That puts a lot of
> responsibility on the RS to do the right
> thing. In HIEs for example, they insist the
> user is a practicing physician because they
> want to reduce their liability if someone's
> name pops up on a list that the user should
> not have seen.
>
>
>
> I meant RO (resource owner), It makes no sense
> for the RS to send a notice to themselves.
>
> Yes,
> RqP is the Requesting Party which is the party
> that controls the Client that is accessing the
> AS and the RS. The RqP might be the patient
> subject (the RO) themselves using an app or PHR
> but that case would be handled by OAuth. (We
> call that the Alice-to-Alice case). UMA is
> interesting because it allows the RqP user to be
> someone other than Alice therefore enabling true
> health information exchange. This is what makes
> HEART so useful and our HEART Profiles so
> important.
>
>
> Adrian
>
>
>
>
>
>
>
>
> On Fri, Dec 11, 2015 at
> 4:53 PM, Aaron Seib <aaron.seib at nate-trust.org> <aaron.seib at nate-trust.org>
> wrote:
>
>
>
> Hi
> – I meant to ask you last week. When you
> say Discovery in the first bullet I am not
> sure I know what you mean. Can you expand
> on that for me? I think I get everything
> except that below.
>
> I
> don’t know why we are trying to be so
> cryptic on the work group. This is
> unfortunate.
>
> You
> use RO below and I think it might be a
> typo but have to confirm. Is it meant to
> have been something else?
>
> What
> is RqP an abbreviation of? Requesting
> Party?
>
> From:
> Openid-specs-heart [mailto:openid-specs-heart-bounces at lists.openid.net <openid-specs-heart-bounces at lists.openid.net>]
> On Behalf Of Adrian Gropper
>
> Sent: Friday, December 11, 2015
> 3:37 PM
>
> To: Moehrke, John (GE Healthcare)
>
> Cc: openid-specs-heart at lists.openid.net
>
> Subject: Re: [Openid-specs-heart]
> "Scope" of sharing and purpose of use
>
>
>
> Let
> me attempt at mediation :-)
>
>
> -
> We're talking about resources that have
> a single subject (the patient) Resources
> with more than one subject, such as a
> patient list are a completely different
> matter because
> they involve discovery (I don’t get
> this? Discovery of what? The
> identity of each person in the list?).
> The special case of a mom with 2 kids
> can simply, if inelegantly, be handled
> by polling for each of the subjects.
> There's no discovery involved.
>
>
> -
> The major difference between OAuth and
> UMA is that in UMA the resource is under
> the control of a separate legal entity.
> Therefore, when a client (and the
> client's user) shows up to request the
> resource, the client may present claims
> or attributes to either or both the
> resource server (RS) and/or the
> authorization server (AS). To say this
> another way: In UMA there's some kind of
> legal agreement between the resource
> server and the authorization server. In
> OAuth there is none because they are the
> same.
>
>
> -
> The sharing of control between the RS
> and the AS is subject to institutional,
> local, and federal controls. All of the
> situations that John listed boil down to
> "good faith" and "notice" to the RO
> when the resource server acts on the
> instructions of the AS based on the
> actual attributes of the client (C) by client
> attributes do you mean attributes of
> MSHV or of the User of MSHV, Aaron
> Seib? and the client's
> user (RqP –
> this is Aaron Seib, right? What does
> RqP stand for?).
>
>
> Adrian
>
>
>
>
>
>
>
> On
> Fri, Dec 11, 2015 at 3:01 PM,
> Moehrke, John (GE Healthcare) <John.Moehrke at med.ge.com> <John.Moehrke at med.ge.com>
> wrote:
>
>
> Hi
> Eve,
>
> It
> is clear that there is a
> communications problem between
> those that are comfortable in
> the language of speaking about
> OAuth/UMA, and those that are
> comfortable in the language of
> speaking about Healthcare
> Access Control needs. I can
> read every word you have said,
> but I have no idea what you
> said.
>
> I
> think one of our problems is
> that we keep skipping from
> use-cases where the “user” is
> the “patient” trying to access
> their own data; and use-cases
> where the “user” is a
> clinician trying to help the
> “patient”. There are many MORE
> use-cases including parents,
> children, guardians. There are
> many MORE use-cases around
> researchers, public-health,
> billing, payers. And there are
> a huge variety of all of
> these. There are authorization
> mechanisms that stem from
> direct authorization by the
> patient, to indirect because
> of context, and the ultimate
> for healthcare ‘because their
> life is in jeopardy and I am a
> licensed clinician that can
> save their life’. Followed by
> many medical-ethical traps
> like having a personal
> discussion about a
> particularly tragic test
> result before the lab fact is
> directly exposed.
>
> We
> need to solve all of these,
> however to solve any one would
> be helpful.
>
> John
>
> From:
> Eve Maler [mailto:eve.maler at forgerock.com <eve.maler at forgerock.com>]
>
>
> Sent: Friday, December
> 11, 2015 11:43 AM
>
> To: Moehrke, John (GE
> Healthcare)
>
> Cc: openid-specs-heart at lists.openid.net
>
> Subject: "Scope" of
> sharing and purpose of use
>
>
>
>
> Hi
> John-- (I changed the
> subject line and deleted
> older parts of the
> thread.)
>
>
>
>
> When
> you say "scope" here, I
> suspect you mean "scope"
> of the sharing use case,
> rather than something
> like an OAuth or UMA
> scope, so I'm just
> checking. So a
> "single-patient scope"
> means that the only
> human we're paying
> attention to in the use
> case is the patient, and
> "any application with
> users that are
> authorized to multiple
> patients" seems to mean
> a use case that involves
> party-to-party sharing,
> with multiple humans
> involved. However, you
> follow the latter with
> "would need to get
> multiple scopes", so I'm
> not sure. Note that
> "getting multiple
> scopes" as a technical
> construct doesn't have
> anything to do with
> sharing with an
> autonomous third party.
>
>
>
>
>
> FWIW,
> here is how I think, at
> a high level, about configuring
> the delegation of
> rights to access
> resources. It's
> all about parts of
> speech.
>
>
>
>
>
> OAuth
> lets a user (patient) do
> this configuration at
> run time while using a
> client app, by opting in
> to the authorization
> server's issuance of an
> access token to that
> app. By contrast, UMA
> lets a user (patient) do
> this configuration
> anytime, generally by
> instructing the
> authorization server to
> check whether some
> combination of the
> client app and the
> requesting party using
> the app meet various
> requirements (policy).
> So OAuth is kind of an
> attenuated version of
> UMA wrt the constraints
> on delegation of access
> rights.
>
>
>
>
>
> system
> subject
> verb
> object
> adjective
>
>
> OAuth
> client ID
> OAuth scopes
> (implicitly
> some endpoints) n/a
>
>
>
> (and always
> Alice)
>
>
> UMA
> claims-based
> eg Bob, UMA scopes
> over... UMA
> resource sets
> claims-based e.g.
> TPO,
>
>
>
> client
> ID/type, etc.
>
>
> time limitations, etc.
>
>
>
>
>
> It's
> possible to conflate
> purpose-of-use into the
> UMA scopes system, but
> it's as awkward as
> conflating (ordinarily
> implicit) resource sets
> into the OAuth scopes
> system (resource1.read,
> resource1.write, etc.),
> which is why OAuth has
> invented the audience
> parameter to try and
> solve the problem of a
> single authorization
> server protecting
> several APIs. This is
> why I suggest using a
> claims-based system
> above.
>
>
>
>
>
>
>
>
> Eve
> Maler
>
> ForgeRock
> Office of the
> CTO | VP
> Innovation
> & Emerging
> Technology
>
> Cell +1 425.345.6756 |
> Skype: xmlgrrl
> | Twitter:
> @xmlgrrl
>
> Join our ForgeRock.org OpenUMA community!
>
>
>
>
>
>
>
>
> On
> Mon, Dec 7, 2015 at
> 2:00 PM, Moehrke, John
> (GE Healthcare) <John.Moehrke at med.ge.com> <John.Moehrke at med.ge.com>
> wrote:
>
>
> The
> discussion on
> the call today
> was too hard to
> break into. Even
> for a big mouth
> like me.
>
> I
> am okay with
> limiting our
> next couple of
> profiles to
> single patient
> scopes. As much
> of the email
> discussion has
> pointed out
> patient
> controlled
> access is our
> primary scope,
> and logically
> (if not
> technically)
> this is easy to
> understand with
> scopes that are
> single patient.
>
>
> Yes
> this means that
> any application
> with users that
> are authorized
> to multiple
> patients would
> need to get
> multiple scopes;
> so be it. For
> now… For
> Enterprise use,
> this is
> troubling; but
> for most uses
> that happen from
> outside of an
> enterprise or
> between
> enterprises this
> limitation is
> not
> unreasonable.
> The most common
> APIs in
> healthcare for
> this are already
> patient centric.
> So it is not a
> big problem.
>
> The
> user experience
> does not need to
> be impacted by
> this profiled
> limitation
>
> The
> future does not
> need to be
> impacted by this
> profiled
> limitation.
>
> Which
> means that one
> viewpoint for
> scope can be the
> identity of the
> patient that one
> is asking for
> access to. This
> is not the only
> scope we will
> ever support;
> but is one
> method that
> would satisfy
> some use-cases
> today.
>
> Another
> view on scope,
> that I have been
> involved with in
> other groups, is
> to use a
> high-level
> vocabulary that
> is used often in
> the Access
> Control policy –
> PurposeOfUse.
> This vocabulary
> is items like:
> Treatment,
> Payment,
> Research,
> Emergency, etc…
>
> To
> go deeper than
> these two
> vectors through
> scopes in a
> general purpose
> healthcare
> access control
> infrastructure
> is futile.
> Next
> level deeper in
> scopes would
> come from
> workflow centric
> implementation
> guides. That is
> a specification
> that is defining
> a workflow,
> could define a
> scope(s) for
> that workflow.
>
> John
>
>
>
> _______________________________________________
>
> 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/
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> No
> virus found in this message.
>
> Checked by AVG - www.avg.com
>
> Version: 2016.0.7294 / Virus Database:
> 4483/11158 - Release Date: 12/11/15
>
>
>
>
>
>
>
>
>
>
> --
>
>
>
>
>
>
>
>
>
>
>
>
>
> 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
>
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>
>
>
>
>
>
> No
> virus found in this message.
>
> Checked by AVG - www.avg.com
>
> Version: 2016.0.7294 / Virus Database: 4483/11177 - Release
> Date: 12/14/15
>
>
>
>
>
>
> _______________________________________________
> Openid-specs-heart mailing listOpenid-specs-heart at lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>
>
>
>
>
> That would be amazing.
>
> The only add I think is important to consider is adding an actor called
> Payer. More and more the lines that differentiate a.Payer from a Provider
> and a Payer from a Consumer.have.blurred but if we can work in that third
> leg there may be more evident ways to incorporate business cases as part of
> the analysis.
>
> I am not alone in thinking we'd be further along with clinical interop if
> we hadn't artificially segregated administration Dara for some reason about
> a decade ago.
>
>
>
> Aaron Seib
> @CaptBlueButton
> (O) 301-540-9549
> (M) 301-326-6843
>
> "The trick to earning trust is to avoid all tricks. Including tricks on
> yourself."
>
>
>
> -------- Original message --------
> From: "Glen Marshall [SRS]" <gfm at securityrs.com> <gfm at securityrs.com>
> Date: 2015/12/14 4:04 PM (GMT-05:00)
> To: openid-specs-heart at lists.openid.net
> Subject: Re: [Openid-specs-heart] "Scope" of sharing and purpose of use
>
> Somehow this thread has confused me. It may be only a temporary lapse,
> but I'd like to re-wrap my head around some actors and the sort of access
> rights they have:
>
> - Providers - Am I correct in saying this category includes
> - Health institutions - hospitals, ambulatory clinics, skilled
> nursing facilities, physical rehab, substance abuse rehab, long-term care,
> etc.
> - Professional practitioners, e.g., physicians, PAs, NPs, RNs,
> LPNs, dentists, podiatrists, chiropractors, licensed massage therapists,
> non-Western medicine modalities
> - Employees and business associates of the above, authorized to act
> on their behalf in role- or contract-limited ways.
> - Health consumers
> - Patients
> - Authorized representatives of patients - relatives or others who
> have been granted authorities of various sorts.
>
>
> For simplicity's sake, I would like to assume that the providers category
> has the general ability to author and share health data with each other on
> behalf of multiple health consumers. Outside of electronic access
> control's scope they may have legal, contractual, or policy-based
> restrictions on authorship and sharing. Some, but not all, of those
> restrictions may be automated as access controls. For analysis sake, any
> provider is the same as any other provider.
>
> Also for simplicity's sake, I would like to assume that health consumers
> have the general equal ability to author and share data with providers on
> behalf of a single patient. Outside of electronic access control's scope
> they may have legal, contractual, or policy-based restrictions on
> authorship and sharing. Some, but not all, of those restrictions may be
> automated as access controls. For analysis sake, any health consumer is
> the same as any other health consumer.
>
> Simplicity includes not trying to automate all restrictions. It also
> means we can overlook most granularities within the actor types unless law
> or regulation requires a differentiation, e.g., as in psychiatric notes or
> substance-abuse treatment.
>
> For the providers, I'd like to assume that their dominant requirement for
> data access is treatment, payment, or operation with a guarantee of high
> availability and integrity.
>
> For the health consumers, I assume that their dominant requirement is
> providers having and using adequate knowledge of their health. Their
> secondary requirement is confidentiality.
>
> Privacy is a policy-level concept that is supported by security controls -
> technical, administrative, physical, and environmental.
>
> Can we publish a map fir the above vocabulary to the terminology used by
> cross-industry concepts under discussion?
>
> *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 12/14/15 12:10, Aaron Seib wrote:
>
> Getting closer to understanding…
>
>
>
> Aaron Seib, CEO
>
> @CaptBlueButton
>
> (o) 301-540-2311
>
> (m) 301-326-6843
>
> <http://nate-trust.org>
>
>
>
> *From:* Justin Richer [mailto:jricher at mit.edu <jricher at mit.edu>]
> *Sent:* Monday, December 14, 2015 11:23 AM
> *To:* Aaron Seib
> *Cc:* Adrian Gropper; openid-specs-heart at lists.openid.net
> *Subject:* Re: [Openid-specs-heart] "Scope" of sharing and purpose of use
>
>
>
> “Permission Type” is really a whole lot simpler than people are making it
> out to be.
>
>
>
>
>
> “patient” means “get me a single specific record for a single specific
> person”. When there is no other indicator (the “aud” parameter) this is the
> record for the currently logged in person. This is going to be a common
> enough use case, and it’s the default OAuth case, that optimizing for this
> makes sense.
>
>
>
> “user” means “get me all of the records that I have access to”. There is
> no record indicator here in the query because it’s basically a
> get-all-the-stuff type of request. What matches might be a single record.
> It might be many records. It might be aggregate data. But it’s not a query
> for a specific record when this permission type is used.
>
>
>
> Both of these can be in cases where Alice has user-to-user delegated
> access (her little sister Joanne has granted her access to her records at
> Regional Hospital where they both had their babies) to her family
> members. For the “patient” scope with no “aud” parameter, the token is good
> for Alice’s record. For the “patient” scope with an “aud” parameter, the
> token is good for the record indicated by that aud parameter. But just that
> one specific record! Using this token to get other records will fail. For
> the “user” scope it’s a request for all records Alice has access to. She
> can’t specify which one, since that’s not what this kind of scope is for.
>
>
>
> I think that is clear. I think where the consternation comes from is when
> the User isn’t a consumer but a list of people who have claimed TPO access
> rights to a set of records (patients). Is the Heart Profile silent on
> that. This is where the policy gets confounded if each of the patients
> doesn’t have the chance to first “recognize” that the person who claims to
> have a Tx relationship with them is in fact a doc that they believe they
> have a treatment relationship with. This is the fly in the ointment that
> has Serpico buzzing and I think rightly so. Not that we have to address
> the issue that he described as Discovery for the HEART work to make
> progress and sense – it just needs to be clearly isolated.
>
>
>
> The bottom line is there are creative trial lawyers who will ascert that a
> breach occurred is some Provider was claimed to have had a Treatment
> relationship with someone when in fact they didn’t. Perhaps Permission
> Type is too simple if it can’t address this concern. That or make it easy
> enough for us to demarcate the breadth of where it comes into play and put
> it in a parking lot for a future need.
>
>
>
> This is a real case we had at the state level. Male Doc is working in a
> practice. He has access to the EMR that every other doc in his practice
> has access to so could see the data of all the patients that went there.
> Turns out the Husband of the woman he is committing adultery with was a
> patient of another doc at the practice. This guy is a father and has two
> kids. Husband and Wife split up. Doc and woman get married and want to
> get custody of the kids. Doc looks at ex-husbands medical records and
> finds some sensitive information that the new couples lawyers use to argue
> that the dad isn’t a fit parent. Fortunately – the father’s lawyer figures
> it out and puts the keibash on using that breached data and the Judge makes
> his custody decision sans the sensitive health information that shouldn’t
> be available (and later in another court room the doc gets convicted of a
> HIPAA violation).
>
>
>
> The concern that we are all twisting around seems to be the lack of
> distinction about the permission types. Maybe there is a way to clarify it
> using another construct that I haven’t come up with. Is this kind of
> concern addressed somewhere else?
>
>
>
>
>
> — Justin
>
>
>
>
>
> On Dec 13, 2015, at 11:10 PM, Aaron Seib <aaron.seib at nate-trust.org>
> wrote:
>
>
>
> I still don’t think I am 100% on what Discovery means in this context.
>
>
>
> Here is the def you provided:
>
>
>
> Discovery means: the user(1) doesn't know who will be on the list. That
> puts a lot of responsibility on the RS to *do the right thing*(2). In
> HIEs for example, they insist the user is a practicing physician because
> they want to reduce their liability if someone's name pops up on a list
> that the user should not have seen.
>
>
>
> (1) Who is the user? I am still looking to the Permission Type
> <http://openid.bitbucket.org/HEART/openid-heart-fhir-oauth2.html#rfc.section.2.1>
> to see if I can get that set of terms to line up in my head. Patient was a
> permission type which in the health domain correlates to the patient who is
> the subject of the PHI that the Resource Server may be disclosing. The
> assumption being that we can match the identity of the person who is using
> a client application to connect to the resource server (owned by the
> institution that operates the Resource Server – in the API TF scope the
> typical example being a EMR used by the caregiver that the patient has had
> treatment) with the Medical Record Number (MRN) or equivalent in the
> Resource Servers enterprise context (I don’t see any reason why we can’t
> say that an HIE with an MPI might be able to simplify this by correlating
> the MPI values to the person who is using the client app to access data
> about themselves across Resource Servers that have data about that person
> “Patient”).
>
> (2) Do the Right Thing -
>
>
>
> Sorry for all the verbiage – I want to get my meager understanding spelt
> out so it can be corrected. This may not be fruitful but it occurs to me
> that something that isn’t apparent that is becoming more apparent to me as
> I wrestle with this is that the idea of User may be better understood as a
> set of several or more sub-categories.
>
> user
>
> The scope is for a bulk set of records *(I am assuming that it is implied
> here that set of records is meant to convey data for more than one person –
> the notion of a record is not clear to me here I must admit)* or for
> aggregate data not representing a single patient *(is this meant to be a
> distinction or a reiteration of the bulk set of records? What is the
> difference?)*, based on what is available *to the current user* *(here is
> where the turn of phrase seems to be slipping. I am still struggling with
> the some notion being conveyed here*.
>
>
>
> The question that comes to mind is if we look at the set of records being
> made available ‘to the current user’ is that person’s record one of those
> found in the set of records? There seem to be a couple of distinctions
> that are probably implied but might help to make explicit. At a minimum
> there are two cases that come to mind:
>
> (1) The case where the ‘Current User’ may have a record in the set being
> returned and any other person’s record being disclosed is permitted because
> that other person granted the User permission.
>
> (2) The case where the ‘Current User’ does not have a record in the
> current set and is accessing them as a result of capacity being vested in
> them by the Record owner, because of their professional role.
>
>
>
> I am not sure if there is a more precise way to look at it but it would
> seem to be that the root difference has something to do with how the User
> got the permission. It may not be evident I am seeing the difference being
> based on how the user got the permission. In case (1) I think of the
> person as a family care giver who has access to other ‘family’ members
> records because they granted that to him\her to have access and it is not
> in the role of providing treatment as traditionally defined by HIPAA. In
> the (2) case I see it being derived based on the fact that the person is in
> a Treatment role as defined by HIPAA and the Record Owner (i.e., the
> Hospital et al) gives them permission to access certain records.
>
>
>
> I think the key to unraveling this not is to differentiate between users
> who are not acting in a professional capacity from those that are as the
> applicable authorization to disclose is derived from two separate
> authorities. In Case (1) the User is getting permission to access those
> other records because the patients whom the records are about gave him\her
> permision as they may given their right to share with whomever they please
> while under case (2) they are getting permission as an aspect of their
> professional requirements as warranted by the resource owner.
>
>
>
> Not sure if this is half baked or not but there if there is a fly in the
> ointment it seems to me that it has to do with what John referred to as
> purpose of use earlier on. Assume that the User in case 2 has a purpose of
> use to be treatment and I think it is easier to digest. The word to use
> for the Consumer’s purpose of use alludes me right now.
>
>
>
> I think the unifying issue is that the user’s purpose of use must be the
> same for all the records being retrieved.
>
>
>
> I think that is the issue with Discovery that is hard to get a grasp on.
>
>
>
> If an HIE is granting permission to a Requesting party (why do we use the
> word User rather then requeting party here?) for a set of records it should
> only be for one or the other purpose of use and the purpose of use must
> match the part being played for the transaction being responded to by the
> RS as known to the RO.
>
>
>
> Aaron Seib
>
> NATE <http://www.nate-trust.org/>, CEO
>
> @CaptBlueButton
>
> (o) 301-540-2311
>
> (m) 301-326-6843
>
>
>
>
>
> *From:* agropper at gmail.com [mailto:agropper at gmail.com <agropper at gmail.com>]
> *On Behalf Of *Adrian Gropper
> *Sent:* Friday, December 11, 2015 5:29 PM
> *To:* Aaron Seib
> *Cc:* openid-specs-heart at lists.openid.net
> *Subject:* Re: [Openid-specs-heart] "Scope" of sharing and purpose of use
>
>
>
> Hi Aaron, Thanks for highlighting the important issue of discovery.
>
> Discovery means: the user doesn't know who will be on the list. That puts
> a lot of responsibility on the RS to do the right thing. In HIEs for
> example, they insist the user is a practicing physician because they want
> to reduce their liability if someone's name pops up on a list that the user
> should not have seen.
>
> I meant RO (resource owner), It makes no sense for the RS to send a notice
> to themselves.
>
> Yes, RqP is the Requesting Party which is the party that controls the
> Client that is accessing the AS and the RS. The RqP might be the patient
> subject (the RO) themselves using an app or PHR but that case would be
> handled by OAuth. (We call that the Alice-to-Alice case). UMA is
> interesting because it allows the RqP user to be someone other than Alice
> therefore enabling true health information exchange. This is what makes
> HEART so useful and our HEART Profiles so important.
>
> Adrian
>
>
>
> On Fri, Dec 11, 2015 at 4:53 PM, Aaron Seib < <aaron.seib at nate-trust.org>
> aaron.seib at nate-trust.org> wrote:
>
> Hi – I meant to ask you last week. When you say Discovery in the first
> bullet I am not sure I know what you mean. Can you expand on that for me?
> I think I get everything except that below.
>
>
>
> I don’t know why we are trying to be so cryptic on the work group. This
> is unfortunate.
>
>
>
> You use RO below and I think it might be a typo but have to confirm. Is
> it meant to have been something else?
>
>
>
> What is RqP an abbreviation of? Requesting Party?
>
>
>
> *From:* Openid-specs-heart [ <openid-specs-heart-bounces at lists.openid.net>
> mailto:openid-specs-heart-bounces at lists.openid.net
> <openid-specs-heart-bounces at lists.openid.net>] *On Behalf Of *Adrian
> Gropper
> *Sent:* Friday, December 11, 2015 3:37 PM
> *To:* Moehrke, John (GE Healthcare)
> *Cc:* openid-specs-heart at lists.openid.net
> *Subject:* Re: [Openid-specs-heart] "Scope" of sharing and purpose of use
>
>
>
> Let me attempt at mediation :-)
>
> - We're talking about resources that have a single subject (the patient)
> Resources with more than one subject, such as a patient list are a
> completely different matter because they involve discovery (I don’t get
> this? Discovery of what? The identity of each person in the list?). The
> special case of a mom with 2 kids can simply, if inelegantly, be handled by
> polling for each of the subjects. There's no discovery involved.
>
> - The major difference between OAuth and UMA is that in UMA the resource
> is under the control of a separate legal entity. Therefore, when a client
> (and the client's user) shows up to request the resource, the client may
> present claims or attributes to either or both the resource server (RS)
> and/or the authorization server (AS). To say this another way: In UMA
> there's some kind of legal agreement between the resource server and the
> authorization server. In OAuth there is none because they are the same.
>
> - The sharing of control between the RS and the AS is subject to
> institutional, local, and federal controls. All of the situations that John
> listed boil down to "good faith" and "notice" to the RO when the resource
> server acts on the instructions of the AS based on the actual attributes of
> the client (C)* by client attributes do you mean attributes of MSHV or of
> the User of MSHV, Aaron Seib?* and the client's user (RqP – this is Aaron
> Seib, right? What does RqP stand for?).
>
> Adrian
>
>
>
> On Fri, Dec 11, 2015 at 3:01 PM, Moehrke, John (GE Healthcare) <
> <John.Moehrke at med.ge.com>John.Moehrke at med.ge.com> wrote:
>
> Hi Eve,
>
>
>
> It is clear that there is a communications problem between those that are
> comfortable in the language of speaking about OAuth/UMA, and those that are
> comfortable in the language of speaking about Healthcare Access Control
> needs. I can read every word you have said, but I have no idea what you
> said.
>
>
>
> I think one of our problems is that we keep skipping from use-cases where
> the “user” is the “patient” trying to access their own data; and use-cases
> where the “user” is a clinician trying to help the “patient”. There are
> many MORE use-cases including parents, children, guardians. There are many
> MORE use-cases around researchers, public-health, billing, payers. And
> there are a huge variety of all of these. There are authorization
> mechanisms that stem from direct authorization by the patient, to indirect
> because of context, and the ultimate for healthcare ‘because their life is
> in jeopardy and I am a licensed clinician that can save their life’.
> Followed by many medical-ethical traps like having a personal discussion
> about a particularly tragic test result before the lab fact is directly
> exposed.
>
>
>
> We need to solve all of these, however to solve any one would be helpful.
>
>
>
> John
>
>
>
> *From:* Eve Maler [mailto: <eve.maler at forgerock.com>
> eve.maler at forgerock.com]
> *Sent:* Friday, December 11, 2015 11:43 AM
> *To:* Moehrke, John (GE Healthcare)
> *Cc:* <openid-specs-heart at lists.openid.net>
> openid-specs-heart at lists.openid.net
> *Subject:* "Scope" of sharing and purpose of use
>
>
>
> Hi John-- (I changed the subject line and deleted older parts of the
> thread.)
>
>
>
> When you say "scope" here, I suspect you mean "scope" of the sharing use
> case, rather than something like an OAuth or UMA scope, so I'm just
> checking. So a "single-patient scope" means that the only human we're
> paying attention to in the use case is the patient, and "any application
> with users that are authorized to multiple patients" seems to mean a use
> case that involves party-to-party sharing, with multiple humans involved.
> However, you follow the latter with "would need to get multiple scopes", so
> I'm not sure. Note that "getting multiple scopes" as a technical construct
> doesn't have anything to do with sharing with an autonomous third party.
>
>
>
> FWIW, here is how I think, at a high level, about *configuring the
> delegation of rights to access resources*. It's all about *parts of
> speech*.
>
>
>
> OAuth lets a user (patient) do this configuration at run time while using
> a client app, by opting in to the authorization server's issuance of an
> access token to that app. By contrast, UMA lets a user (patient) do this
> configuration anytime, generally by instructing the authorization server to
> check whether some combination of the client app and the requesting party
> using the app meet various requirements (policy). So OAuth is kind of an
> attenuated version of UMA wrt the constraints on delegation of access
> rights.
>
>
>
> system subject verb object
> adjective
>
> OAuth client ID OAuth scopes
> (implicitly some endpoints) n/a
>
> (and always Alice)
>
> UMA claims-based eg Bob, UMA scopes over... UMA
> resource sets claims-based e.g. TPO,
>
> client ID/type, etc.
> time limitations, etc.
>
>
>
> It's possible to conflate purpose-of-use into the UMA scopes system, but
> it's as awkward as conflating (ordinarily implicit) resource sets into the
> OAuth scopes system (resource1.read, resource1.write, etc.), which is why
> OAuth has invented the audience parameter to try and solve the problem of a
> single authorization server protecting several APIs. This is why I suggest
> using a claims-based system above.
>
>
> *Eve Maler *ForgeRock Office of the CTO | VP Innovation & Emerging
> Technology
> Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
> Join our ForgeRock.org OpenUMA
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__forgerock.org_openuma_&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=PHeMeoVZ7WGQVkHh4j1pjEo3WjxiOtW0zWBvptezqXM&s=BWKe_zUfK7VyJCEdTSN-5cG7TelP0b1X-x3kyeaODmk&e=>
> community!
>
>
>
> On Mon, Dec 7, 2015 at 2:00 PM, Moehrke, John (GE Healthcare) <
> <John.Moehrke at med.ge.com>John.Moehrke at med.ge.com> wrote:
>
> The discussion on the call today was too hard to break into. Even for a
> big mouth like me.
>
>
>
> I am okay with limiting our next couple of profiles to single patient
> scopes. As much of the email discussion has pointed out patient controlled
> access is our primary scope, and logically (if not technically) this is
> easy to understand with scopes that are single patient.
>
>
>
> Yes this means that any application with users that are authorized to
> multiple patients would need to get multiple scopes; so be it. For now…
> For Enterprise use, this is troubling; but for most uses that happen from
> outside of an enterprise or between enterprises this limitation is not
> unreasonable. The most common APIs in healthcare for this are already
> patient centric. So it is not a big problem.
>
>
>
> The user experience does not need to be impacted by this profiled
> limitation
>
>
>
> The future does not need to be impacted by this profiled limitation.
>
>
>
> Which means that one viewpoint for scope can be the identity of the
> patient that one is asking for access to. This is not the only scope we
> will ever support; but is one method that would satisfy some use-cases
> today.
>
>
>
> Another view on scope, that I have been involved with in other groups, is
> to use a high-level vocabulary that is used often in the Access Control
> policy – PurposeOfUse. This vocabulary is items like: Treatment, Payment,
> Research, Emergency, etc…
>
>
>
> To go deeper than these two vectors through scopes in a general purpose
> healthcare access control infrastructure is futile.
>
> Next level deeper in scopes would come from workflow centric
> implementation guides. That is a specification that is defining a workflow,
> could define a scope(s) for that workflow.
>
>
>
> John
>
>
>
> _______________________________________________
> Openid-specs-heart mailing list
> <Openid-specs-heart at lists.openid.net>Openid-specs-heart at lists.openid.net
> <http://lists.openid.net/mailman/listinfo/openid-specs-heart>
> 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/>
> <http://patientprivacyrights.org/donate-2/>
> http://patientprivacyrights.org/donate-2/
> ------------------------------
>
> No virus found in this message.
> Checked by AVG - <http://www.avg.com/>www.avg.com
> Version: 2016.0.7294 / Virus Database: 4483/11158 - Release Date: 12/11/15
>
>
>
>
> --
>
>
>
> 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/>
> <http://patientprivacyrights.org/donate-2/>
> http://patientprivacyrights.org/donate-2/
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>
> ------------------------------
>
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2016.0.7294 / Virus Database: 4483/11177 - Release Date: 12/14/15
>
>
> _______________________________________________
> Openid-specs-heart mailing listOpenid-specs-heart at lists.openid.nethttp://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/20151214/a1033ea9/attachment-0001.html>
More information about the Openid-specs-heart
mailing list