[Openid-specs-heart] HEART Meeting notes 2016-05-16
Adrian Gropper
agropper at healthurl.com
Wed May 18 03:13:36 UTC 2016
Accounting for Disclosures
On Tuesday, May 17, 2016, Grahame Grieve <grahame at healthintersections.com.au>
wrote:
> A4D?
>
> Grahame
>
>
> On Wed, May 18, 2016 at 12:55 PM, Adrian Gropper <agropper at healthurl.com
> <javascript:_e(%7B%7D,'cvml','agropper at healthurl.com');>> wrote:
>
>> I'm glad to hear they're in scope.
>>
>> Thing is, that notifications have two components: the endpoint and the
>> message format. As I recall, MVCR consent receipts are more about the
>> message format than the endpoint. I much prefer the FHIR Subscriptions
>> approach because it doesn't trigger a standards project related to the
>> format and therefore makes implementation much faster.
>>
>> All three notification types are perfectly compatible with a
>> human-readable format. In some cases, as the FHIR Subscription
>> standard points out, having a message content at all is an unacceptable and
>> unnecessary privacy liability. This applies to type (1) notifications where
>> any contact with the notification endpoint triggers a query to the FHIR
>> endpoint.
>>
>> Type (2) notifications need to be human-formatted by definition to meet
>> the intent of HIPAA and today's API Task Force recommendation. Nothing
>> would be served by trying to standardize the format as each FHIR endpoint
>> has a right to issue whatever warning it feels is appropriate to the
>> particular client and situation. Although there was interest in the
>> API discussion today in evolving a Model Privacy Notice related to this
>> Type (2) notification, that work, if and when it's available, is also meant
>> for human-readable format and it was deemed unlikely to cover all of the
>> warning situations. There are no privacy issues with Type (2) messages
>> because they need not contain any PHI. This makes them much more
>> user-friendly since they can be delivered via SMS and other insecure
>> channels.
>>
>> Type (3) notifications - A4D - are the only ones that might benefit from
>> a standard format. Even so, standard formatting is not expected - we are
>> perfectly happy to receive activity messages from banks and merchants even
>> though their format is all over the place. In addition, type (3) messages
>> do have privacy implications if they contain any PHI or even indication of
>> the metadata. Therefore, it would be preferable to make these opaque or
>> content-free and allow the recipient to query the FHIR server for A4D if
>> they choose.
>>
>> @Grahame: Does FHIR already specify an A4D resource?
>>
>> Is the discussion above an appropriate addition to the current use-case?
>>
>> Adrian
>>
>> On Tuesday, May 17, 2016, Debbie Bucci <debbucci at gmail.com
>> <javascript:_e(%7B%7D,'cvml','debbucci at gmail.com');>> wrote:
>>
>>> 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/
>>>>
>>>>
>>
>> --
>>
>> 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/
>>
>>
>
>
> --
> -----
> http://www.healthintersections.com.au / grahame at healthintersections.com.au
> <javascript:_e(%7B%7D,'cvml','grahame at healthintersections.com.au');> /
> +61 411 867 065
>
--
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/6de286ff/attachment.html>
More information about the Openid-specs-heart
mailing list