[Openid-specs-heart] HEART Meeting notes 2016-05-16
Debbie Bucci
debbucci at gmail.com
Wed May 18 13:04:34 UTC 2016
Please keep it simple and terminology constant across threads ! If you
expand too far too you will loose me. When I see JASON I think additional
metadata tagging of information. Please don't introduce
You asked about use of subscriptions to existing use cases.
I did not suggest anything would be exchanged beyond a notification but I
do (strongly) believe all service will log/audit
At some point Alice (grantor?) may want need to know more. Doesn't grantor
consent/authorize?
On May 18, 2016 8:28 AM, "Adrian Gropper" <agropper at healthurl.com> wrote:
> Debbie, you are not following my model. My model has no prior consent, no
> consent policy representation in FHIR or any other way, and no consent
> receipts. My model is purely based on the JASON model where the resource,
> and therefore FHIR, are under separate jurisdiction from the authorization
> policies. In my model, the Grantor's policies are never communicated on the
> wire.
>
> Think of this as analogous to never communicating a private key of the
> wire. My model has no shared secrets and policies are secret. The policies
> associated with the FHIR resource are locked up in the UMA Authorization
> Server and never leave. The only thing that leaves the AS is authorization
> tokens.
>
> Therefore, in my model (an instance of the JASON model) there is no prior
> consent because Bob gets his authorization, regardless of whether it's
> one-time or reusable, when he presents to the Authorization Server. (I will
> not use Authorization for Disclosure ever any more. It's to close and
> confusing with Authorization of Disclosure in HIPAA.)
>
> Therefore, as far as the FHIR resource server is concerned, it only needs
> to generate an empty notification each time Bob actually accesses a
> resource and store the AuditEvent in case the Grantor wants to use FHIR to
> get an Accounting of Disclosures at a later time.
>
> Adrian
>
> On Wednesday, May 18, 2016, Debbie Bucci <debbucci at gmail.com> wrote:
>
>> Authorization for disclosure. Adrian if I follow you... Alice grants Dr
>> Bob access her data (receipt generated here). Dr Bob later accesses data
>> for the first time. Resource [authorization ??] server logs the
>> disclosure event and optionally pushes a message via a subscription to
>> alert Alice that her data was accessed. At some time later Alice could
>> query for both her receipts and disclosures to verify she granted access
>> and it was Bob who accessed her data. Seems to me these may be core to
>> use case in a US context but peripheral to the profiles for its unclear
>> if there would need to be any scopes or resources sets to define to support
>> it. Defining the content of the subscription message,disclosure or
>> receipt probably out of scope.
>> On May 17, 2016 10:55 PM, "Adrian Gropper" <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> 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/
>>>
>>>
>
> --
>
> 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/20160518/d8d5b7ad/attachment-0001.html>
More information about the Openid-specs-heart
mailing list