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

Debbie Bucci debbucci at gmail.com
Wed May 18 02:10:49 UTC 2016


Notifications were always in scope.  One type of notification was in the
form of a consent receipt.  You may recall Sarah doing some research and
comparing to ...was it HL7?   The receipt could be use to acknowledge a
number of state changes.

I am very familiar with topics/queues and pub/sub from my SOA
infrastructure days.  A brief glance  at subscriptions seem to be a similar
pattern.

Dont think its a scope issue.  It could be a implementation choice in use
cases to  use a subscription to deliver a message that either acknowledges
a receipt or triggers another process in the work flow

I think that would cover your 3 examples listed below.

On May 17, 2016 8:45 PM, "Adrian Gropper" <agropper at healthurl.com> wrote:

> As mentioned in the other thread, there are three different kinds of
> notification under HIPAA (and probably in the general case):
> (1) a resource has changed - this is p53 of the NZ doc
> (2) a client is being registered that requires specific affirmation by the
> Grantor
> (3) accounting for disclosures - the resource server has been accessed by
> a client
>
> The FHIR spec lists 4 different standards for push notifications
> http://hl7.org/fhir/subscription.html .
>
> I believe all three of these kinds of notification are in-scope for HEART.
> The three endpoints do not all have to be the same, do not all have to be
> UMA, and we may want to restrict some of the 4 options offered in the FHIR
> spec.
>
> Can we add these three kinds of notification to the current use case as
> proposed by Eve?
>
> Adrian
>
>
> On Tuesday, May 17, 2016, Eve Maler <eve.maler at forgerock.com> wrote:
>
>> 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
>>>
>>>
>>
>
> --
>
> 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/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160517/e72534fc/attachment-0001.html>


More information about the Openid-specs-heart mailing list