[Openid-specs-heart] Draft HEART Meeting Notes 2016-01-25

Adrian Gropper agropper at healthurl.com
Tue Jan 26 16:06:30 UTC 2016


I'm not sure what a call for consensus is or who is allowed to initiate it
but it seems that BlueButton on FHIR is a good and simple and very real
thing to build consensus around.

Adrian

On Tue, Jan 26, 2016 at 10:31 AM, Justin Richer <jricher at mit.edu> wrote:

> As an order of process (and the chairs can correct me if I'm wrong), there
> was no call for consensus made nor can consensus be adequately judged given
> the conversation that took place.
>
> Adrian, please be careful of using the word "consensus" in the context of
> standards body working groups as it has a very specific meaning that I
> don't believe you're intending to invoke here.
>
>  -- Justin
>
>
> On 1/26/2016 8:40 AM, Adrian Gropper wrote:
>
> Thank you Sarah for a wonderful summary of an interesting call.
>
> It seems that we have a consensus to look into how BlueButton on FHIR can
> inform HEART.
>
> Can we assume:
> 1 - that HIPAA requires the protection design for BlueButton on FHIR to
> enable access by a patient-designated third-party's client.
>
> 2 - that the client can be anything, including built-from-source and
> community-supported, as long as it implements the FHIR standard.
>
> 3 - that the client cannot be required to pay money or otherwise register
> itself as an institution beyond being trusted by the specific patient's
> authorization server.
>
> 4 - that the specific patient's authorization server may decide to use a
> standards-based identity provider as a source of trust for requesting
> parties and their clients.
>
> 5 - the RqP's IdP might be separate from CMS (the RS) and it's only up to
> the individual patient to configure her AS accordingly.
>
> 6 - HEART profiles will support this transaction in a manner acceptable to
> the FHA and CMS.
>
> I've cc'd Mark and hope for comment and clarification from folks familiar
> with the HL7, FHA, ONC, UMA issues relative to the sequence above.
>
> Adrian
>
>
>
> On Mon, Jan 25, 2016 at 5:15 PM, Sarah Squire <sarah at engageidentity.com>
> wrote:
>
>> Attendees:
>>
>> Debbie Bucci
>>
>> Danny van Leeuwen
>>
>> Sarah Squire
>>
>> Justin Richer
>>
>> Adrian Gropper
>>
>> Eve Maler
>>
>> Josh Mandel
>>
>> Thomas Sullivan
>>
>> Jin Wen
>>
>> Kathleen Connor
>>
>> Edmund Jay
>>
>> Thompson Boyd
>>
>> Eve’s API Task Force Testimony
>>
>> Eve will be testifying tomorrow:
>> <https://www.healthit.gov/facas/calendar/2016/01/26/api-task-force-virtual-hearing>
>> https://www.healthit.gov/facas/calendar/2016/01/26/api-task-force-virtual-hearing
>>
>> Her written contribution is here:
>> <https://www.healthit.gov/facas/sites/faca/files/APITF_Testimony_EveMaler_2016-01-26.docx>
>> https://www.healthit.gov/facas/sites/faca/files/APITF_Testimony_EveMaler_2016-01-26.docx
>>
>> There’s tension around accessibility vs. security. APIs are more properly
>> called communication protocols, and they require access control for many
>> different reasons. You can’t charge for an API if you can’t control access.
>> It might be interesting to talk about data tagging. You want to catch the
>> provenance of the data before it is created. One way to do that is to tag
>> the device that’s generating the data. It’s kind of like an identity
>> attribute for a device. tagging the data when it’s static is too late.
>>
>> There are several motivations for standardizing API semantics: squeeze
>> out complexity, join data, get better vetting, give more buy vs build
>> choice.
>>
>> Adrian’s API Task Force Testimony
>>
>> Adrian will be testifying on Thursday:
>>
>>
>> <https://www.healthit.gov/facas/calendar/2016/01/28/api-task-force-virtual-hearing>
>> https://www.healthit.gov/facas/calendar/2016/01/28/api-task-force-virtual-hearing
>>
>> His written contribution was sent to the list.
>>
>> BlueButton on FHIR is Medicare’s pilot with Mark Scrimshire at the helm.
>> It’s taking a copy of the medicare claims database. The issue of access
>> management has already been dealth with and in production. What is being
>> piloted is how to translate that into FHIR. It’s patient-level, read-only.
>>
>> Justin:
>>
>> what do you mean by “encryption design of UMA, HEART, and FHIR”? What are
>> the security gaps you’re talking about?
>>
>> Adrian:
>>
>> I just mean the flows. We’re pretty clear on the scalability issues
>> around them. Going from that clarity to UMA in this API economy is not at
>> all clear. It’s all new. This is the same thing we’ve been talking about on
>> the list. So where does that leave us?
>>
>> Justin:
>>
>> HEART isn’t an encryption solution, so let’s keep building it the way
>> we’ve been building it.
>>
>> Jin:
>>
>> I agree with Justin. Encryption has a specific meaning technically.
>>
>> Adrian:
>>
>> Okay, I’m talking about protection, not encryption. So, what does this
>> tell us about FHIR?
>>
>> Justin:
>>
>> Access and choice are fundamental tenants that need to be enabled, which
>> is the goal of the HEART working group?
>>
>> Adrian:
>>
>> Can we use the HIPAA definitions of choice for HEART?
>>
>> Kathleen:
>>
>> I’ve been looking at the OCR guidance. I’m using it for the
>> patient-choice project. I think it’s valuable. It spells things out
>> clearly.
>>
>> Adrian:
>>
>> There’s a specification for allowing third party access without the
>> patient having to see or decrypt the data going from the resource server to
>> the client. The piece of guidance that’s missing is an interpretation on
>> the part of OCR is that if the patient provides a public key in person to
>> the resource server whether that is considered to be equivalent to the
>> patient providing a USB fob or an email address.
>>
>> Kathleen:
>>
>> Yeah, but FHA has a workgroup that has all the agencies involved in this
>> questions. Other agencies have higher requirements than are required in
>> HIPAA. They are working on the ability of the patient to wave
>> responsibility.
>>
>> Adrian:
>>
>> Yes, but that’s institution-to-institution access. Is that the same FHIR
>> as institution-to-patient access?
>>
>> Justin:
>>
>> It’s the same FHIR, but it’s not the same part of FHIR, and it works
>> differently.
>>
>> Kathleen:
>>
>> Wouldn’t the policies be different? In terms of certificates, and levels
>> of assurance and content?
>>
>> Adrian:
>>
>> Right, and once we have a consensus on that, HEART becomes an exercise in
>> protection design. I don’t know if UMA 1.0.1 has a gap with respect to this
>> or not. With respect to MITREid Connect, I’ve been lead to believe that the
>> AS cannot be decoupled from the resource server in the current version, so
>> the AS cannot be made independent.
>>
>> Justin:
>>
>> That is incorrect. You can decouple the AS from the RS from the
>> requesting party from the IdP. All of those can be in separate security
>> domains. What doesn’t work is trying to do a webfinger lookup on a server
>> that’s not hosted on the same domain.
>>
>> Adrian:
>>
>> I think we can work through this. I’m not sure who else is using MITREid
>> Connect in healthcare.
>>
>> Justin:
>>
>> Everyone who is using SMART.
>>
>> Adrian:
>>
>> Has anyone separated an RS from an AS?
>>
>> Josh:
>>
>> We haven’t tried to do that. It hasn’t been a system requirement as yet.
>>
>> Justin:
>>
>> SMART is only an OAuth/OIDC server. UMA was put in to support the Privacy
>> on FHIR work last year. It is still a very bare and focused implementation.
>>
>> Debbie:
>>
>> Can MITREid Connect support federated IdPs? Can you webfinger to the
>> multiple IdPs?
>>
>> Justin:
>>
>> It IS an IdP, and it’s meant to be a federated IdP. You can webfinger
>> into it if you set it up on the domain correctly. HealthAuth.org works for
>> a webfinger lookup of <Alice at HealthAuth.org>Alice at HealthAuth.org.
>>
>> Adrian:
>>
>> It sounds like my developer and I are the only people who are trying to
>> do a separated AS from IdP.
>>
>> Debbie:
>>
>> Are you trying to stand up an AS that accepts multiple IdPs?
>>
>> Justin:
>>
>> Are you talking about logging in as the requesting party or the resource
>> owner?
>>
>> Adrian:
>>
>> The requesting party
>>
>> Sarah:
>>
>> These capabilities are in scope for the HEART specification. This might
>> be a more appropriate subject for the UMA list and UMA call.
>>
>> Adrian:
>>
>> Well, I’d like to do it in BlueButton on FHIR.
>>
>> Sarah;
>>
>> Well, you’re doing something no one has ever done before, so I’m not sure
>> anyone can help you. UMA is a technical specification for a communications
>> protocol. You can put whatever features you want into your software. The
>> standards community isn’t obliged to help you do that.
>>
>> Debbie:
>>
>> The CMS BlueButton on FHIR needs to outline what they’re doing and what
>> standards they’re supporting.
>>
>> Justin:
>>
>> Take some time if you can to call into the API Task Force meeting
>> tomorrow.
>>
>> Josh:
>>
>> I’m on the committee for this hearing, so please send me any questions.
>> The hearing probably won’t take all five hours.
>>
>> Justin:
>> The security profiles are coming up for a vote very soon. Please read
>> through them.
>> Sarah Squire
>> Engage Identity
>> <http://engageidentity.com/>http://engageidentity.com
>>
>> _______________________________________________
>> 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/
>
>
> _______________________________________________
> Openid-specs-heart mailing listOpenid-specs-heart at lists.openid.nethttp://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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160126/8bdf09e1/attachment-0001.html>


More information about the Openid-specs-heart mailing list