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

Adrian Gropper agropper at healthurl.com
Wed May 18 02:55:52 UTC 2016


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
> <javascript:_e(%7B%7D,'cvml','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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160517/984fb424/attachment.html>


More information about the Openid-specs-heart mailing list