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

Grahame Grieve grahame at healthintersections.com.au
Wed May 18 04:25:51 UTC 2016 

ok. sure, that could trigger an AuditEvent. It does on my server, though I
think I could improve the quality of information that goes with that

btw, you can test all this stuff on
http://fhir2.healthintersections.com.au/open

Grahame


On Wed, May 18, 2016 at 2:05 PM, Adrian Gropper <agropper at healthurl.com>
wrote:

> 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>
>> wrote:
>>
>>> And could AuditEvent be triggered by an empty Subscription message?
>>>
>>> Adrian
>>>
>>>
>>> On Tuesday, May 17, 2016, Grahame Grieve <
>>> 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 / +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
/ +61 411 867 065
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160518/2e126e7d/attachment-0001.html>

More information about the Openid-specs-heart mailing list