Wiki

Clone wiki

HEART / 2016-06-13

Attending:

Debbie Bucci

Cait Ryan

Glen Marshall

Nancy Lush

Sarah Squire

Thompson Boyd

Justin Richer

Scott Shorter

Adrian Gropper

Celestin Bitjonck

Eve Maler

Edmund Jay

Josh Mandel

Walter Kirk

Dale Moberg

Julie Maas

Discussion:

Debbie: Do we need more discussion on the feedback from the implementer’s drafts?

Justin: We don’t need to discuss anything, we just need to do the work we already discussed. If anyone wants to suggest spec-grade text, that would be helpful. You can post text to the list, post it inside an issue, or you can make a pull request.

Adrian: Can we talk about what HL7 is doing?

Glen: There is an effort in HL7 to round out the consent resource in FHIR. There’s also a FHIR security effort. Those are both going to ballot. Participation does not require membership.

Debbie: Are they talking about OAuth scopes in the workgroups in HL7?

Glen: No, they are dealing with the conjunction between audit and provenance.

Debbie: The next thing is the UMA semantic profile. Eve, how can we help with that?

Eve: There’s a lot of choice and flexibility in the FHIR API, so what we want to profile is really up to us. In the use case, sharing scenario one, step one, we’re using the metaphor of sharing within google docs. We need to talk about the details of the share approach.

Adrian: This is a good time to talk about consent. FHIR refused to let Alice specify anything regarding consent except a notification endpoint.

Josh: I don’t think it’s fair to characterize it that way. We have asked for specific proposals from you, and FHIR isn’t defining consent workflows.

Eve: I haven’t yet said what Alice is controlling in terms of extent of access.

Debbie: In the case where Alice has a PHR and she wants to share her data with an EHR, her PHR would be the server? And the EHR would be the client?

Eve: Yes. Bob’s EHR would have client credentials and get an AAT.

Adrian: There should be something that shields Alice’s policies from FHIR entities.

Glen: That doesn’t have anything to do with what we’re doing here. Also keep in mind that FHIR is an international standard, so US policies are not going to dominate.

Debbie: If the EHR knows Alice’s app and they’re both talking FHIR, they would both have conformance statements about what endpoints they support?

Adrian: Is it our assumption that Alice doesn’t have to be on the wire for this to happen? If Dr. Bob can satisfy Alice’s policies?

Eve: Yes, that’s correct. UMA has configuration data at a well known place.

Adrian: What we’re describing is an ideal. When most people talk about this, they use the term HIE. Once the consent has been executed, when Dr. Bob asks for the information, Alice doesn’t have to be there.

Eve: Yes, that’s correct.

Adrian: I urge you to join the FHIR consent calls so that this is represented.

Eve: If you think that I can help, I’m happy to join.

So, in the access approval approach, we need to somehow sew together Alice’s account at the EHR to her PHR.

Adrian: So would Alice only have to remember a pseudonym like an email address for that to work?

Eve: It could. We could standardize the type of data so that would work.

Sarah: Any implementer certainly could use that user experience, but we’re not specifying it as part of the profile.

Justin: And there’s a privacy component to this, if someone can find out where Alice’s medical record lives, even if they can’t get access to it, just from Alice’s email address, that’s a bad pattern in terms of privacy and security.

Debbie: Do we need more discussion on the feedback from the implementer’s drafts?

Justin: We don’t need to discuss anything, we just need to do the work we already discussed. If anyone wants to suggest spec-grade text, that would be helpful. You can post text to the list, post it inside an issue, or you can make a pull request.

Adrian: Can we talk about what HL7 is doing?

Glen: There is an effort in HL7 to round out the consent resource in FHIR. There’s also a FHIR security effort. Those are both going to ballot. Participation does not require membership.

Debbie: Are they talking about OAuth scopes in the workgroups in HL7?

Glen: No, they are dealing with the conjunction between audit and provenance.

Debbie: The next thing is the UMA semantic profile. Eve, how can we help with that?

Eve: There’s a lot of choice and flexibility in the FHIR API, so what we want to profile is really up to us. In the use case, sharing scenario one, step one, we’re using the metaphor of sharing within google docs. We need to talk about the details of the share approach.

Adrian: This is a good time to talk about consent. FHIR refused to let Alice specify anything regarding consent except a notification endpoint.

Josh: I don’t think it’s fair to characterize it that way. We have asked for specific proposals from you, and FHIR isn’t defining consent workflows.

Eve: I haven’t yet said what Alice is controlling in terms of extent of access.

Debbie: In the case where Alice has a PHR and she wants to share her data with an EHR, her PHR would be the server? And the EHR would be the client?

Eve: Yes. Bob’s EHR would have client credentials and get an AAT.

Adrian: There should be something that shields Alice’s policies from FHIR entities.

Glen: That doesn’t have anything to do with what we’re doing here. Also keep in mind that FHIR is an international standard, so US policies are not going to dominate.

Debbie: If the EHR knows Alice’s app and they’re both talking FHIR, they would both have conformance statements about what endpoints they support?

Adrian: Is it our assumption that Alice doesn’t have to be on the wire for this to happen? If Dr. Bob can satisfy Alice’s policies?

Eve: Yes, that’s correct. UMA has configuration data at a well known place.

Adrian: What we’re describing is an ideal. When most people talk about this, they use the term HIE. Once the consent has been executed, when Dr. Bob asks for the information, Alice doesn’t have to be there.

Eve: Yes, that’s correct.

Adrian: I urge you to join the FHIR consent calls so that this is represented.

Eve: If you think that I can help, I’m happy to join.

So, in the access approval approach, we need to somehow sew together Alice’s account at the EHR to her PHR.

Adrian: So would Alice only have to remember a pseudonym like an email address for that to work?

Eve: It could. We could standardize the type of data so that would work.

Sarah: Any implementer certainly could use that user experience, but we’re not specifying it as part of the profile.

Justin: And there’s a privacy component to this, if someone can find out where Alice’s medical record lives, even if they can’t get access to it, just from Alice’s email address, that’s a bad pattern in terms of privacy and security.

Updated