[Openid-specs-heart] Please VOTE before Election Day: What’s hindering adoption of HEART?

Eve Maler eve.maler at forgerock.com
Wed Nov 1 14:46:47 UTC 2017


Great thoughts.

I would never have bothered working on SAML starting in late 2000 (or any
other standards :-) ) if I didn't think it had differentiating value. When
we published a finished 1.0 two years later, I thought "Great, everyone,
start using it!" Real adoption took much longer, not just because
technology refresh rates were at least three years at the time, but because
it challenged business models. SAML went through a 1.1 and then a 2.0. Ten
years later, something like 90% of broadly used business SaaS services
supported SAML 2.0 as SPs because so many enterprises already served as
IdPs. Adoption wasn't guaranteed to happen, but while code is really really
important, solving the right problem is king.

It does seem there are challenges with the US healthcare business
environment that erect barriers. At the same time, I am
having conversations with US-connected businesses, especially involving
IoT, interested in HEART (particularly involving UMA because it's the
patient-centric piece). And organizations from around the world are also
reaching out with interest.

Perhaps it's unnecessary to assume that adoption is unusually hindered when
considering that a standard like this affects a whole BLT sandwich
(business, legal, technical). A question might be: What do you intend to do
differently with the answer? (Along the lines of Why perform this
diagnostic test? :-) ) I intend to keep doing the work, collecting use
cases and spec feedback, and getting the word out.


*Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging Technology
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

On Wed, Nov 1, 2017 at 5:59 AM, John Moehrke <johnmoehrke at gmail.com> wrote:

> Adrian,
>
> I think you are very quick to place others names on the list of reasons
> HEART has failed...
>
> The fastest standards get implemented within 5 years, most take longer. I
> could be that we haven't waited long enough.
>
> I really like the idea of HEART, but I am not sure it will get
> implemented, because it presents more complexity, while not solving a
> problem that the data holders believe they have. I will put the word
> 'believe' in that sentence, but I am more on the side that they do not have
> a problem that HEART solves.  I am not saying that the vision of HEART is
> false, it is a fantastic vision. There are just no obvious stepping-stones
> from where we are today to this nirvana.
>
> For HEART to exist a large number of HEART authorities must exist. They
> must convince custodians that they are trustworthy, and do represent the
> patient. They must convince the patient that they are trustworthy and will
> accurately represent the patient.  There must be many, so that the patient
> has choice. There must be some mechanism where this trust is developed and
> maintained  There must be blunt discussions of what happens when
> failure-modes happen. This is a case where these must be built and prove
> themselves before the system will work, yet they can't prove themselves
> until the system is working. Too risky for everyone.
>
> There is a subset of the population that would benefit from HEART, those
> that frequent many different and unconnected healthcare providers. I don't
> know how big this group is. I 'think' that subset is small relative to the
> whole population. I 'think' that subset is generally not the technically
> engaged, or technically adventuresome. Yes, there is a couple dozen that
> are, but most are not.
>
> Many healthcare providers have fully functional interactions with their
> patient population. This includes a user identity. That user identity has
> Privacy controls. That user identity has access to a Portal where that
> patient can obtain their patient data. That identity is being enabled to be
> able to use the FHIR API in many cases.  Note that there is  little
> interest in moving to a federated identity, because of the risk of exposing
> metadata and patterns of behavior to that third-party. Although we are
> encouraging OAuth be used with FHIR, everyone has placed the OAuth
> authority within the same walls as their FHIR Server. Thus, it isn't really
> a federation, it is just using the technology so that apps can be enabled
> and managed using OAuth. This is a win, but not a full identity federation
> win. Time might solve this one.
>
> I realize that some healthcare providers are still blocking data. I have
> had fantastic access to my data for a decade. The VHA provides full access
> for veterans to their data.  In all cases I know of through my family they
> have access. And ALL of us are on the eHEX nationwide health information
> exchange.  I don't know who these data blockers are, and it is sick that we
> keep abusing the whole industry because of these abusive healthcare
> providers. I don't understand why we are not yet naming and shaming these
> organizations.  We should be abusing THOSE organizations, not the whole of
> healthcare.
>
> Thus, HEART is a great idea but it is too difficult: technically, legally,
> human, risk...
>
> john
>
> John Moehrke
> Principal Engineering Architect: Standards - Interoperability, Privacy,
> and Security
> CyberPrivacy – Enabling authorized communications while respecting Privacy
> M +1 920-564-2067 <(920)%20564-2067>
> JohnMoehrke at gmail.com
> https://www.linkedin.com/in/johnmoehrke
> https://healthcaresecprivacy.blogspot.com
> "Quis custodiet ipsos custodes?" ("Who watches the watchers?")
>
> On Tue, Oct 31, 2017 at 8:24 PM, Danny van Leeuwen <danny at health-hats.com>
> wrote:
>
>> J other people don’t know about it and don’t understand it’s balue
>>
>> All 3 votes
>>
>> On Tue, Oct 31, 2017 at 8:55 PM Adrian Gropper <agropper at healthurl.com>
>> wrote:
>>
>>> Only one vote so far.
>>>
>>> Adrian
>>>
>>> On Fri, Oct 27, 2017 at 11:46 PM Adrian Gropper <agropper at healthurl.com>
>>> wrote:
>>>
>>>> A - Our standards work is incomplete
>>>> B - Implementation of our profiles is too expensive
>>>> C - Why would a hospital want to make patient-directed access easier?
>>>> D - HEART distracts the patient from the hospital’s portal experience
>>>> E - US regulations are inadequate from a patient rights perspective
>>>> F - NATE and other HIE groups don’t see the value of HEART to their
>>>> business or mission
>>>> G - Patient-directed exchange does not allow the patient to pay for API
>>>> access
>>>> H - CMS and VA have not endorsed HEART or put it on their road map
>>>> I - We have not done enough PR and promotion
>>>> J - Other ___________________________________
>>>>
>>>> Please vote on the list above. Each person has 3 votes to cast on one
>>>> or more of the options.
>>>>
>>>> If you want your vote to be “secret” just send it to me and I promise I
>>>> won’t share or even save your name. I will simply report the total count of
>>>> people who voted as it grows and then tally the totals *before the Nov
>>>> 6 call.*
>>>>
>>>> Please share this email with anyone you know that has any idea of what
>>>> we’re doing with UMA or HEART.
>>>>
>>>> Thank you,
>>>>
>>>> Adrian
>>>> --
>>>>
>>>> Adrian Gropper MD
>>>>
>>>> PROTECT YOUR FUTURE - RESTORE Health Privacy!
>>>> HELP us fight for the right to control personal health data.
>>>> DONATE: https://patientprivacyrights.org/donate-3/
>>>>
>>> --
>>>
>>> Adrian Gropper MD
>>>
>>> PROTECT YOUR FUTURE - RESTORE Health Privacy!
>>> HELP us fight for the right to control personal health data.
>>> DONATE: https://patientprivacyrights.org/donate-3/
>>> _______________________________________________
>>> Openid-specs-heart mailing list
>>> Openid-specs-heart at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>>>
>> --
>> Danny van Leeuwen
>> Danny at health-Hats.com
>> 617-304-4681 <(617)%20304-4681>
>> Blog: www.health-hats.com
>> Twitter: @healthhats
>>
>> _______________________________________________
>> 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/20171101/8e117dc3/attachment.html>


More information about the Openid-specs-heart mailing list