Wiki

Clone wiki

HEART / 2016-03-07

Attendees:

Debbie Bucci

Adrian Gropper

Thompson Boyd

Sarah Squire

Glen Marshall

Scott Shorter

Tom Sullivan

Dale Moberg

Eve Maler

Nancy Lush

Alex Horowitz

Justin Richer

Jin Wen

William Kinsley

Kathleen Connor

Edmund Jay

Aaron Seib

Debbie: Let’s start with conference updates.

Justin: There were a handful of meetings at HIMSS. There was a HEART/SMART meeting where Justin and Josh presented the two projects and explained why we have the two different efforts and how they work. It is the hope of both projects to be compatible. We went over the technical differences between the two specs. There was interest in providing input for HEART’s semantic profiles, particularly from Grahame. Tuesday night we had an informal HEART meetup. Some old folks, some new folks. There were two meetings about CMS’s POET effort. It’s something that Josh, Alan, Sarah, and Justin have been working on to figure out how to meet CMS’s goals. The main idea with POET is that it’s trying to make sense of client accountability. HEART’s position is to allow dynamic registration and allow software statements to allow for higher levels of trust. We explained that to CMS, and there seemed to be buy-in that they may take that path going forward.

Adrian: I went to the big Argonaut meeting that was keynoted by Karen. This was a series of meetings with people from CMS there as well. The meeting was mostly about the major EHR vendors as well as large early-adopter healthcare provider institutions. This was an interesting meeting because it was focused on a patient-centered use case. My impression is that HEART needs to focus on Argonaut if we want to stay in touch with what’s going on. When I brought up HEART, people sort of poo-pooed it. People think that OAuth and FHIR will do whatever they need for Argonaut.

Justin: Can you clarify what you mean when you say that people want OAuth and FHIR but not HEART?

Adrian: Josh has not yet agreed that HEART is a component of SMART. In private, he says nice things about HEART and UMA, but it has never come up in public.

Thom: Adrian is correct. I don’t hear UMA or HEART mentioned very much.

Adrian: I had a long conversation with Josh about whitelisting and dynamic registration policy. We need to get clear about whether we’re whitelisting clients, ASs, neither, or both. I listed the issues as I see them in the email.

Glen: Can you clarify what you mean by whitelisting and how it relates to HEART?

Adrian: We are talking about dynamic registration and software statements.

Glen: I’m hearing why we shouldn’t, but I don’t know what it is we shouldn’t do.

Eve: Whitelisting and blacklisting are something you can do in a system to secure them. Software statements are a packet of metadata that you can use to dynamically register at runtime with a higher level of trust.

Glen: Is this addressed in our use cases for HEART?

Justin: The idea with a software statement is that it’s a trust anchor. An authorization server inside a trust community will point to some sort of registry where developers can go and get a software statement. The software statement happens out of band, but the registration between the client and AS happens dynamically.

Glen: But where in our use cases do we have a need for this?

Debbie: We haven’t wanted to go this deep into the technology for the use cases yet. We haven’t discussed it yet. We decided to let preregistration be out of scope.

Kathleen: HL7 Security Labeling Service describes dynamic trust information being exchanged at run time as access control decision information.

Justin: The current security specs say that dynamic registration is required, but we need to discuss that more.

Debbie: ONC has some funding opportunities coming up regarding FHIR. Eve, can you tell us about RSA?

Eve: There weren’t HEART-specific meetups at RSA. We did talk about some of the challenges of going from paper to digital records. There were a lot of discussions about healthcare at the conference. It looks like security folks are getting interested in that space.

Debbie: Justin, can you explain a little bit about Mike Jones’ concerns about implementations supporting different efforts?

Justin: Sarah and I had some discussions about this. We’d like to propose some differentiation. If we have a HEART-compliant IdP, it’s only protecting the UserInfo API, so a lot of the requirements of HEART don’t apply, because you’re not protecting HEART resources. You’re not fulfilling that role in the ecosystem. We also need to specify that an AS can service HEART clients and non-HEART clients. HEART requirements only need to apply when HEART transactions are taking place.

Eve: I had a conversation with Mike Jones. He was remarking on this, and it’s something that the OpenID specs had to go through as well. So what you’ve described sounds like a good exercise.

Adrian: What does this have to do with an interoperability logo?

Justin: These proposals haven’t been captured in the spec yet. I can start that discussion on the list. We are looking at interoperability testing that will also inform these.

Glen: Having seen that kind of certification against a test suite, I would like us to be part of the HL7 FHIR connectathon. It gives a stronger cache than testing against an independent test suite.

Adrian: When I say logo, I mean that when something is labeled HEART, a consumer can expect it to be interoperable.

Justin: What you are talking about is a formal certification to enforce compliance with the mark.

Adrian: Not necessarily. What I’m describing is something closer to the HIMSS pledge, something that would be similar to what OpenID Foundation does as a self-assessment listing service. That’s what we’re trying to do in IDESG.

Debbie: Scott Shorter joined the group last week and is interested in working on terminology and glossary.

Scott: I have created a wiki page with terms from the HEART work. It’s always a challenging task to come up with terms that satisfy multiple people.

Adrian: Is this meant to be a collaborative project?

Debbie: Yes, we need to move it to where other people can edit it, but yes, it is intended to be collaborative. This is a HEART deliverable.

Justin: As long as it’s a tool of the working group and not an output of the working group, that’s fine.

Debbie: I’m hoping it can be a reference. I just wanted to make sure we have it out there. We will take a first swipe. We will put it somewhere where everyone can contribute.

Adrian: We are having side conversations about terminology.

Scott: The specs themselves do have terminology sections, so at the very least, these can be a recommendation to the author from the working group.

Eve: We could point to these from the use cases instead of copying definitions. I did put a lot of work into the nuance of definitions in the use cases. So maybe we could use those in the glossary.

Scott: It also might be helpful to cross-reference and show where in the use cases each term appears.

Debbie: We’re going to keep working on this for a while and then we’ll move it. I’ve been looking forward to the semantic profiles, and I’m trying to figure out what the semantic profiles look like.

Eve: I sent an email about semantic profiling titled “Ad hoc get-togethers to work on elements of UMA "semantic" profiling”

Debbie: What if we start with our three use cases in concert? Maybe that would help us make assumptions around resource sets and scopes. I will try to do a layout similar to what I’ve been seeing.

Eve: I will try to make an UMA-flavored version of the first use case.

Updated