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.

Adrian: 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.

Justin: 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.

Adrian: 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.