[Openid-specs-heart] "Scope" of sharing and purpose of use
Aaron Seib
aaron.seib at nate-trust.org
Mon Dec 14 23:15:14 UTC 2015
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 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>
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>
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]
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
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]
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>
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]
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>
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]
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>
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 list
Openid-specs-heart at lists.openid.net
http://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>
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]
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
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]
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>
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]
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>
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]
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>
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 list
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/20151214/ce5d33f7/attachment-0001.html>
More information about the Openid-specs-heart
mailing list