[Openid-specs-heart] HEART Meeting notes 2016-05-16

[Eve Maler]

Supplementing with the link I referred to during the call:

The UMA case study "Users Managing Delegated Access to Online Government
Services" conducted by the New Zealand government available on the UMA wiki:

http://kantarainitiative.org/confluence/display/uma/Case+Study%3A+Users+Managing+Delegated+Access+to+Online+Government+Services
(PDF report downloadable here
<http://kantarainitiative.org/confluence/download/attachments/76907066/NZ%20ProjectClosureReport_PoC%20Delegations-Final%20Version%20SIG%20redacted%20Rev1.pdf?api=v2>
)

...documents in Sec 8.4.3.3.3 (p. 46) a desire for "notifications" that can
be achieved by sending email or by other means, with a discussion in Sec
8.4.9 (p. 53) about sending push notifications to an UMA requesting party
through a mobile app from a resource owner's smart device. The case study
didn't, I believe, use FHIR.


*Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging Technology
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
Check out the 2016 schedule <https://summits.forgerock.com> for *ForgeRock
Summits and UnSummits*!

On Tue, May 17, 2016 at 7:04 AM, Debbie Bucci <debbucci at gmail.com> wrote:

> Adrian was given the floor to discuss his concerns that he has labeled
> for point of reference as  “Independent Decision Support at the Point of
> Care for Physicians and Patients"
>
> Adrian indicated there were 4 primary functions needed.  Many in the
> group translated it in different ways but Debbie’s version was:
>
>    -
>
>    Release of Information
>    -
>
>    Notification of Disclosures
>    -
>
>    Subscribe to changes
>    -
>
>    Automated patient right of access.
>
> Eve translated the bullets to both technical and policy work out of the
> UMA workgroup and pointed to relevant/related publication developed in
> close coordination with NZ.
>
> Josh was concerned that Adrian perhaps was proposing an entirely new
> standard.  John and others were trying to get clarification around what
> Adrian was referring to as Data Blocking.
>
> After an hour long of healthy discussion – Josh asked if there were any
> procedure on how to document to handle such a discussion within the group
>  Adrian was concerned about HEART’s functionality/relevance in relation
> to his concerns.    Hope the following points brought up in the meeting
> addresses these concerns:
>
>    -
>
>    HEART’s function is not to create standards but to create profiles of
>    existing recognized standards to encourage interoperable implementations of
>    these standards.  Please see : http://openid.net/wg/heart/charter/
>    -
>
>    All members are encouraged to bring use cases to the group to consider.
>    The functional use case is broken down into technical functionalities
>    that are flagged as core or peripheral to the standards being considered
>    under HEART.
>    -
>
>    We acknowledge that with both the Standards and profiles, there may be
>    implementation decisions made to bridge gaps where existing functionality
>    does not exist.  We strongly encourage those implementers to
>    officially log the gaps and solutions they made back with the relevant
>    Standards Bodies in order to give feedback to future iterations of the
>    Standards.
>
> Standards development is an iterative process and versioning control of
> standards and specs are an implementation reality we have to deal
> with.  Changes are made incrementally
>
> We concluded the discussion by asking Adrian to develop a functional use
> case to bring to the group for consideration.  Subsequently there has
> been a recap discussion posted prior to the notes that we will append to
> these meeting notes to round out context to the discussion
>
> Next week’s meeting (May 23rd) will focus on the comment submitted by
> Mike Jones re:  suggested changes to the HEART profile.   Additionally,
> if permissible, we will revisit and consider the Argonaut report and their
> recommendations as part of this review.   All members interested that may
> have input to the impending updates, please make it a point to attend.
>
> * AI:* Justin is developing a step by step analysis for us to consider.
>
> Will cancel the next two meetings due to conflicts:  May 30th (US
> holiday) and June 5th (Cloud Identity Summit )
> On June 12th We should be prepared to go back to the current use case
> https://bitbucket.org/openid/heart/wiki/Alice_Shares_with_Physicians_and_Others_UMA_FHIR
> and stay with that use case until we complete our final draft semantic
> profile.
> Adrian's new use case is the next in the queue and welcome any others that
> folk may want to submit.
>
>
> _______________________________________________
> 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/20160517/1d044d04/attachment.html>