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

Justin Richer jricher at mit.edu
Tue Jan 26 15:31:02 UTC 2016


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 <mailto: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 <mailto: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
>     <mailto: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 list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160126/7ff4282f/attachment.html>


More information about the Openid-specs-heart mailing list