[Openid-specs-heart] HEART Meeting notes 2016-05-16
Adrian Gropper
agropper at healthurl.com
Wed May 18 04:05:32 UTC 2016
In 6.14.6.3 "The body of the email may be empty,"
Adrian
On Tuesday, May 17, 2016, Grahame Grieve <grahame at healthintersections.com.au>
wrote:
> I'm not sure what you mean by 'an empty subscription message'
>
> Grahame
>
>
> On Wed, May 18, 2016 at 1:40 PM, Adrian Gropper <agropper at healthurl.com
> <javascript:_e(%7B%7D,'cvml','agropper at healthurl.com');>> wrote:
>
>> And could AuditEvent be triggered by an empty Subscription message?
>>
>> Adrian
>>
>>
>> On Tuesday, May 17, 2016, Grahame Grieve <
>> grahame at healthintersections.com.au
>> <javascript:_e(%7B%7D,'cvml','grahame at healthintersections.com.au');>>
>> wrote:
>>
>>> Right, that would a profile on AuditEvent
>>>
>>> Grahame
>>>
>>>
>>> On Wed, May 18, 2016 at 1:29 PM, Adrian Gropper <agropper at healthurl.com>
>>> wrote:
>>>
>>>> My bad. Accounting of Disclosures it is.
>>>>
>>>> Adrian
>>>>
>>>>
>>>> On Tuesday, May 17, 2016, John Moehrke <johnmoehrke at gmail.com> wrote:
>>>>
>>>>> I have always referred to it as "Accounting of Disclosures". Meaning
>>>>> it is a report that indicates the disclosures that have happened (history).
>>>>> Which is what AuditEvent, and my blog speak to.
>>>>>
>>>>> I would expect an "Accounting FOR Disclosures" to be a record of the
>>>>> potential disclosures that might happen in the future (aka
>>>>> Consent/Authorization). So I was confused given the scope of HEART.
>>>>>
>>>>> John
>>>>>
>>>>> John Moehrke
>>>>> Principal Engineering Architect: Standards - Interoperability,
>>>>> Privacy, and Security
>>>>> CyberPrivacy – Enabling authorized communications while respecting
>>>>> Privacy
>>>>> M +1 920-564-2067
>>>>> JohnMoehrke at gmail.com
>>>>> https://www.linkedin.com/in/johnmoehrke
>>>>> https://healthcaresecprivacy.blogspot.com
>>>>> "Quis custodiet ipsos custodes?" ("Who watches the watchers?")
>>>>>
>>>>> On Tue, May 17, 2016 at 10:13 PM, Adrian Gropper <
>>>>> agropper at healthurl.com> wrote:
>>>>>
>>>>>> 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> 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/
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> -----
>>>>>>> http://www.healthintersections.com.au /
>>>>>>> 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/
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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/
>>>>
>>>>
>>>
>>>
>>> --
>>> -----
>>> http://www.healthintersections.com.au /
>>> 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/
>>
>>
>
>
> --
> -----
> 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/20160518/2f78b4bd/attachment.html>
More information about the Openid-specs-heart
mailing list