[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