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

Adrian Gropper agropper at healthurl.com
Tue Jan 26 13:40:18 UTC 2016


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
>
> Her written contribution is here:
> 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
>
> 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.
>
> 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
>
> _______________________________________________
> 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160126/c05679a6/attachment.html>


More information about the Openid-specs-heart mailing list