[Openid-specs-heart] I asked the Society for Participatory Medicine list: What do you want from HEART?

Eve Maler eve.maler at forgerock.com
Fri Jul 15 22:24:32 UTC 2016 

Sorry, let me walk through them one by one. Below...


*Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging Technology
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
*ForgeRock Summits and UnSummits* are coming to
<http://summits.forgerock.com/> *Sydney, London, and Paris!*

On Thu, Jul 14, 2016 at 5:19 AM, Danny van Leeuwen <danny at health-hats.com>
wrote:

> Eve, I'm struggling to understand what you are saying in response to
> Society issues.
>
> 1. Definition: *Agile *user. Is that someone who is tech savvy and
> comfortable playing and troubleshooting on their own with the current
> clunky systems? If that's the case, any design needs to consider the
> non-agile user.
>

"Agile" (capital A), short for Agile software development
<https://en.wikipedia.org/wiki/Agile_software_development>, is actually a
term of art. I'm sorry for having thrown it into the message without
context. "User stories <https://en.wikipedia.org/wiki/User_story>" are a
lightweight technique in Agile and similar methodologies for capturing
requirements, and they go like this:

"As a (role), I want (some goal) so that (some benefit)."


> 2. *With an UMA architecture in mind, we can fairly precisely name what
> those services/apps/tools might be. *I don't know what this means.  How
> does knowledge of UMA architecture allow you to precisely name
> services/apps/tools? Where can I find that putative list?
>

I was observing that several of the SPM list items express requirements
that map pretty nicely to the roles and services that UMA makes available.
To wit:


   - As the patient, I am the primary steward of my health information
*wherever
   it is*.
   - As the primary steward, I have full access to all of my health
   information. Primary steward maps roughly to the UMA resource owner
   role. ?
   - As the primary steward, I can determine who has access to which
   segments of my health information. The UMA authorization server role in
   concert with the other roles enables the resource owner to control access.
   - As the primary steward, I am notified about changes and access by
   others to my health information. The UMA protocol alone doesn't (yet?)
   solve this.
   - Stewardship of my health information is done through a single tool
   (web page or application) *across my service providers*. The UMA
   authorization server role presents an opportunity for this centralization
   (though it doesn't force it). The service providers would be UMA resource
   servers.



> 3. I really like the UMA WG exercise format, but I struggle with feeling
> like I need a dictionary with me for every line.  It feels like Pokemon to
> me.  As my grandson says, 'Opa, you just don't get it.' I feel the same way
> with much of the HEART work. I understand about 25%.  I stick with it
> because I know it's critical and you all have way more expertise than I do.
> My energy to do the work to understand waxes and wanes.
>

That exercise was for a particular purpose in the UMA WG context; didn't
mean to derail you here. Treat it as meaning something only for a) Agile
aficionados who b) want to see how the UMA protocol sausage was made...


> 4. My barometer is that I need to be able to explain this to my blog
> readers who include people at the center of care (individuals, care
> partners, clinicians, direct care and support staff), policy wonks and
> informatics professionals. I can't do that yet. My sense is that the WG may
> be missing something if it isn't understandable to an educated (*agile?)* lay
> person such as myself. The WG doesn't yet know what it doesn't know about
> the life flow of the end users / beneficiaries of its work.
>

Agreed that implementation for people at the center of care ultimately
shouldn't require them to know this level of detail. Protocol
specifications and profiles do involve some technical work, but ultimately
it should certainly be possible to design "user journeys" and user
experiences/interfaces that meet the requirements of these users.

The reason, by the way, that user stories are so important is that they put
those in the position of *designing* solutions into the shoes of those
*requiring* those solutions. In the UMA design work, we actually did make
changes to our protocol to ensure that certain user experience flows would
be possible.

I hope this helps!


> I'm willing to engage more, but I'll need some help translating.
>
> On Wed, Jul 13, 2016 at 12:49 PM, Eve Maler <eve.maler at forgerock.com>
> wrote:
>
>> The SPM list is interesting, and, I think, complementary to and an
>> extension of privacy principles. It's not talking strictly about data and
>> its exposure; it sets up a strong new data stewardship role for a patient,
>> and then defines a relationship between that steward and various putative
>> services/apps/tools out in the world.
>>
>> (With an UMA architecture in mind, we can fairly precisely name what
>> those services/apps/tools might be.)
>>
>> These are stated nearly in the form of agile user stories: As the
>> patient, I want to do X, so that I can (benefit in terms of) Y. Once upon a
>> time, the UMA WG partially went through an exercise
>> <http://kantarainitiative.org/confluence/display/uma/User+Stories> like
>> that to assist in our protocol design effort.
>>
>>
>>
>> *Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging
>> Technology
>> Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
>> *ForgeRock Summits and UnSummits* are coming to
>> <http://summits.forgerock.com/> *Sydney, London, and Paris!*
>>
>> On Tue, Jul 12, 2016 at 2:51 PM, Adrian Gropper <agropper at healthurl.com>
>> wrote:
>>
>>> The Principles of Privacy will only take you so far in the design of a
>>> product, service, or HEART. At some point we need to apply Privacy
>>> Engineering (
>>> https://ethics.berkeley.edu/privacy/resources/privacy-risk-management-framework-nistir-8062
>>> ) to achieve a particular set of goals. I submit that the SPM bullet points
>>> are a reasonable goal for HEART.
>>>
>>> A less pedantic way to look at the bullets is simply to see them as the
>>> essence of patient-centered design and focus HEART (and UMA) on solving the
>>> multiple portals problem. From the patient's perspective, the only way to
>>> solve the multiple portals problem is to be able to specify the
>>> Authorization Server to every resource server. That means that regardless
>>> of whether a resource server happens to be FHIR or whatever RESTful
>>> standard my bank exposes for my health savings account or whatever standard
>>> some wearable uses to stream my location coordinates, I can register and
>>> manage all of these resources from my one chosen AS.
>>>
>>> If HEART doesn't take this perspective as we design our deliverable, who
>>> does?
>>>
>>> Adrian
>>>
>>>
>>>
>>> On Tue, Jul 12, 2016 at 4:16 PM, John Moehrke <johnmoehrke at gmail.com>
>>> wrote:
>>>
>>>> This is fine, but is simply another way of stating the well established
>>>> Principles of Privacy... right?  I like how nicely compact your bullets
>>>> are. I am just trying to determine if you think you have uncovered
>>>> something missing....
>>>>
>>>> I have a blog where I catalog the various standards on the definition
>>>> of Privacy -- principles. and cross-reference them
>>>>
>>>> https://healthcaresecprivacy.blogspot.com/2015/04/privacy-principles.html
>>>>
>>>> John
>>>>
>>>> John Moehrke
>>>> Principal Engineering Architect: Standards - Interoperability, Privacy,
>>>> and Security
>>>> CyberPrivacy – Enabling authorized communications while respecting
>>>> Privacy
>>>> M +1 920-564-2067
>>>> JohnMoehrke at gmail.com
>>>> https://www.linkedin.com/in/johnmoehrke
>>>> https://healthcaresecprivacy.blogspot.com
>>>> "Quis custodiet ipsos custodes?" ("Who watches the watchers?")
>>>>
>>>> On Sun, Jul 10, 2016 at 11:18 AM, Danny van Leeuwen <
>>>> danny at health-hats.com> wrote:
>>>>
>>>>> TX Adrian
>>>>>
>>>>>
>>>>> On Sunday, July 10, 2016, Adrian Gropper <agropper at healthurl.com>
>>>>> wrote:
>>>>>
>>>>>> Here's what the thread of patients and physicians came up with:
>>>>>>
>>>>>>    - As the patient, I am the primary steward of my health
>>>>>>    information *wherever it is*.
>>>>>>    - As the primary steward, I have full access to all of my health
>>>>>>    information.
>>>>>>    - As the primary steward, I can determine who has access to which
>>>>>>    segments of my health information.
>>>>>>    - As the primary steward, I am notified about changes and access
>>>>>>    by others to my health information.
>>>>>>    - Stewardship of my health information is done through a single
>>>>>>    tool (web page or application) *across my service providers*.
>>>>>>
>>>>>> Adrian
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> 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/
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Danny van Leeuwen
>>>>> 617-304-4681
>>>>>
>>>>> *Blog www.health-hats.com <http://www.health-hats.com/> discovering
>>>>> the magic levers of best health*
>>>>> Twitter <https://twitter.com/HealthHats>
>>>>> LinkedIn <https://www.linkedin.com/in/healthhatsdannyvl>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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/
>>>
>>> _______________________________________________
>>> 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
>>
>>
>
>
> --
> Danny van Leeuwen
> 617-304-4681
>
> *Blog www.health-hats.com <http://www.health-hats.com/> discovering the
> magic levers of best health*
> Twitter <https://twitter.com/HealthHats>
> LinkedIn <https://www.linkedin.com/in/healthhatsdannyvl>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160715/68d4a95b/attachment.html>

More information about the Openid-specs-heart mailing list