[Openid-specs-heart] HEART stepping stones

Eve Maler eve.maler at forgerock.com
Tue Apr 21 15:59:44 UTC 2015


Also a bit hesitant, but in order to encourage others to jump in the
pool... :)


*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 <http://forgerock.org/openuma/> community!

On Mon, Apr 20, 2015 at 7:40 AM, Debbie Bucci <debbucci at gmail.com> wrote:

> Hesitant to speak up but since John asked ...
>
> With regard to UMA Authorization Servers, are you suggesting that we
> consider a mix of personally-controlled and institutionally-controlled
> Authorization Servers or just one or the other?
>
> *Mixed.  I could see places where an Authorization service would/could be
> logically stood up outside an institutions borders (in case of Health IT -
> ACO, HIE etc).   Additionally if these entities focus on patient/consumer
> value add service, those authorization services could/should allow the
> patient to add additional end points ...perhaps even federate with other
> known/trusted authorization services.   Including Adrian's 5.00 a month
> service - providing the binding is strong enough to be trusted.*
>

When I think about "considering" authorization servers/services, it makes
me think we (HEART?) have the power to determine the answer. I'm not sure
we do. Someone I knew in the standards game used to talk about "sanction
vs. traction", sanction being formal blessing, and traction being ecosystem
adoption. With individual preferences and proclivities in the mix,
weird/cool things could happen. If constrained by regulation, certain
market distortions are certain to take place.

I would really hope that we don't sequester *sources* of data in our use
cases. Our charter certainly doesn't, and life doesn't work that way. This
is why I was trying to point out in my first response to John that we have
new examples of data coming from patients as the most-upstream resource
owners now. It would seem important for clinical purposes, not just for
generic consumer purposes, to accommodate this in the access control
picture.


>
> With regard to interface scopes, are there particular scopes that should
> be considered before others?
>
> *Don't understand this question.  I think its use case driven*
>

I took this to mean that there are various standardized permission scopes
that are worth driving towards in our work here -- but I'm not sure.


> With regard to identity management and identity federation, would we
> consider patient ID before or after provider ID?
>
> *In order to access the API the identity negotiation would need to be
> completed upfront. In the in PoF demonstration - we repeated said it was
> out of scope but if you looked closely ... Alice did use a federated
> credential.  John did bring up identity proofing/LOA/trust in one of the
> early calls.  Even though we do not deal with it directly it does need to
> be represented/addressed and is a necessary part of the
> authorization/access "calculus".     I know there are a number of folks on
> this list already tackling this problem space and are looking for way to
> integrate into these profiles/workflow.  We should let them help us.   *
>

What Deb said.


>
> With regard to patient matching and discovery, would we try to keep these
> in or out of scope for the early parts of the roadmap?
>
> *If we presume the patient is mediating in the center and has a a explicit
> binding to their resources  - there are  no  matching issues. *
>

What Deb said. :-)


>
> *Client dynamic registration and AS discovery would be in scope from my
> POV.*
>
> *There has been a very promising discussion on the UMA list about a
> webfinger-ish personal discovery service.  Not real yet though- a gap that
> I hope get closed in the near future.*
>

I'm hoping to actually read that thread soon! Whre.


>
>
> Is there a class of providers or data holders (hospitals, payers, labs,
> public facilities, etc...) that we could prioritize?
>
> *Do we need to prioritize?  Who's willing to share? Please  let us know!*
>

Ditto! :-)


>
> *Separate concerns - *
>
> *If we believe the JOSE/JWT is essential for secure data exchange - we
> should stand behind it not compromise.*
> *If we unearth some real policy concerns (US and International) or gaps in
> the standards  - how do we place in parking lot/acknowledge for others to
> tackle.  Ae there folk on this list willing to take on some of those
> challenges?*
>

I firmly believe that there is no inherent difference between the security
characteristics of JSON/JOSE/JWT and XML/XML Encryption/SAML -- it's all
just punctuation for data. The "security and privacy knobs can always be
cranked up to 11" if that's what we want to do.

Eve


>
> *Deb*
>
> *P.S.  Disclaimer - Deb's personal views  mindfully sent using Deb's
> personal email.*
>
>
>
>
> On Sun, Apr 19, 2015 at 9:47 PM, Adrian Gropper <agropper at healthurl.com>
> wrote:
>
>> Then this is an excellent discussion. It suggests that there's a roadmap
>> and some metric for achievability.
>>
>> For example:
>>
>> With regard to UMA Authorization Servers, are you suggesting that we
>> consider a mix of personally-controlled and institutionally-controlled
>> Authorization Servers or just one or the other?
>>
>> With regard to interface scopes, are there particular scopes that should
>> be considered before others?
>>
>> With regard to identity management and identity federation, would we
>> consider patient ID before or after provider ID?
>>
>> With regard to patient matching and discovery, would we try to keep these
>> in or out of scope for the early parts of the roadmap?
>>
>> Is there a class of providers or data holders (hospitals, payers, labs,
>> public facilities, etc...) that we could prioritize?
>>
>> Adrian
>>
>>
>>
>> On Sun, Apr 19, 2015 at 9:33 PM, Moehrke, John (GE Healthcare) <
>> John.Moehrke at med.ge.com> wrote:
>>
>>> I am not trying to limit the destination. I am trying to define the next
>>> achievable step.
>>>
>>>
>>>
>>> John
>>>
>>>
>>>
>>> *From:* agropper at gmail.com [mailto:agropper at gmail.com] *On Behalf Of *Adrian
>>> Gropper
>>> *Sent:* Sunday, April 19, 2015 5:13 PM
>>>
>>> *To:* Moehrke, John (GE Healthcare)
>>> *Cc:* Eve Maler; openid-specs-heart at lists.openid.net
>>> *Subject:* Re: [Openid-specs-heart] HEART stepping stones
>>>
>>>
>>>
>>> Hello John,
>>>
>>>
>>>
>>> There's no need for you to take my perspective personally.
>>>
>>>
>>>
>>> "Data created fully by the patient" seems to be urging us to down-scope
>>> HEART to the non-HIPAA domain.
>>>
>>>
>>>
>>> Adrian
>>>
>>>
>>>
>>> On Sun, Apr 19, 2015 at 5:21 PM, Moehrke, John (GE Healthcare) <
>>> John.Moehrke at med.ge.com> wrote:
>>>
>>> Hi Adrian,
>>>
>>>
>>>
>>> Interesting misrepresentation of what I said. I am disappointed that you
>>> feel it necessary to misrepresent what I said. I am also disappointed that
>>> you feel it necessary to bring in other negative topics that I said nothing
>>> about. I am trying to find ground that we can progress forward on; while
>>> you seem to be just wanting to make personal assaults.
>>>
>>>
>>>
>>> Looking for the constructive message in your comment, I think you are
>>> suggesting that we scope our efforts to the flow of information from the
>>> patient possession to points-elsewhere. I am fine with that kind of a
>>> scope. It also avoids the issues I was bringing up.  I very much agree that
>>> data created fully by the patient is, and should be, totally controlled by
>>> the patient.  This scope also avoids the concerns that encumber healthcare
>>> provider environments:  Medical Ethics concerns, Safety concerns, and
>>> concerns of wrongful disclosure.
>>>
>>>
>>>
>>> John
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *From:* agropper at gmail.com [mailto:agropper at gmail.com] *On Behalf Of *Adrian
>>> Gropper
>>> *Sent:* Sunday, April 19, 2015 12:42 PM
>>> *To:* Moehrke, John (GE Healthcare)
>>> *Cc:* Eve Maler; openid-specs-heart at lists.openid.net
>>> *Subject:* Re: [Openid-specs-heart] HEART stepping stones
>>>
>>>
>>>
>>> John, I find your perspective both paternalistic and unscalable.
>>>
>>>
>>>
>>> US healthcare is awash in lack of transparency and the result is
>>> $1Trillion of unwarranted care. It's paternalistic and incredibly
>>> self-serving to presume that just because the institution has been given a
>>> right to use patient data without any accountability as long as the data is
>>> for Treatment, Payment, or Operations or De-Identified, or "Break the
>>> Glass", or prescription drug monitoring, or just plain lack of segmentation
>>> for access, that it's good policy. The current regulations are the result
>>> of heavy and effective lobbying by a very well organized industry trying to
>>> protect its secrets by avoiding the HIPAA accounting for disclosures and
>>> and patient right of access because they're "too hard". Think of HEART as
>>> trying to fix the "too hard" problem.
>>>
>>>
>>>
>>> Your perspective is also unscalable as more and more health-related data
>>> originates in wearables as well home and environmental monitors, and then
>>> ends-up in trans-national analytics completely outside of the HIPAA regs.
>>> It's also unscalable as patient data such as genomes can no longer be
>>> collected under informed consent because nobody has any idea of how your
>>> genomic information will be interpreted three years from now and how that
>>> interpretation might affect you or your children. It's also unscalable as
>>> the ability to promise de-identification for research becomes less and less
>>> realistic.
>>>
>>>
>>>
>>> The simple fact is that surveillance, data processing, and data storage
>>> is now effectively free compared to the economic value of the patient data.
>>> Rent-seeking-behavior by politically astute institutions has been effective
>>> for the past few years but the natives are getting restless. If you want to
>>> read more:
>>> http://thehealthcareblog.com/blog/2015/04/16/last-chance-for-meaningful-use/ and
>>> I hope you make the comments above on the blog.
>>>
>>>
>>>
>>> Adrian
>>>
>>>
>>>
>>>
>>>
>>> --
>>>
>>> Adrian Gropper MD
>>> Ensure Health Information Privacy. Support Patient Privacy Rights.
>>> http://patientprivacyrights.org/donate-2/
>>>
>>>
>>>
>>
>>
>>
>> --
>> Adrian Gropper MD
>> Ensure Health Information Privacy. Support Patient Privacy Rights.
>> *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
>>
>>
>
> _______________________________________________
> 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/20150421/6ab9205f/attachment-0001.html>


More information about the Openid-specs-heart mailing list