Attending:

Debbie Bucci

Thompson Boyd

Michael Magrath

Glen Marshall

Sarah Squire

Kenneth Salyards

Adrian Gropper

Jin Web

Justin Richer

John Moehrke

Tom Sullivan

Jim Kragh

Dale Moberg

Edmund Jay

Hope Morgan

Events in UMA, FHIR, and HEART http://lists.openid.net/pipermail/openid-specs-heart/Week-of-Mon-20151102/000568.html

Sarah/Debbie:

The next step is to look at what an event receipt structure would look like in a HEART context.

Glen:

The HL7 is currently working on consent as a FHIR resource. Glen will be a part of that working group.

Debbie:

What’s happening at ietf?

Justin:

People from a bunch of different standards groups are working to figure out if there’s an abstraction context for identity events that we can pull out. RISC is looking at compromised account events. Other folks are just looking at how to tell relying parties that a user logged out. And HEART is looking at consent events. The list is here: https://www.ietf.org/mailman/listinfo/id-event

Adrian’s workflow diagram discussion

workflow diagram http://www.websequencediagrams.com/?lz=dGl0bGUgQmFzZWxpbmUgSEVBUlQgU2VxdWVuY2UgRGlhZ3JhbQoKcGFydGljaXBhbnQgIkFsaWNlIHJlc291cmNlXG5vd25lciAoUk8pIiBhcyBSTwAhDk5QRQAiC3NlcnYAKQVTACcHUwBOD2dlbnQgYXV0aG9yaXphdGlvbgArCkEALgdBACYPQm9iIGNsaWVudFxuYXBwIChDAIEFBkMAFRJyZXF1ZXN0aW5nXG5wYXJ0eSAoUnFQAIEzB3FQCm5vdGUgb3ZlciBSTywgUlMsIEFTLCBDLAAYBU5QRSA9IE5vbi1QZXJzb24gRW50aXR5IC8gVGhpcyBpcyB0aGUgSW5kaXZpZHVhbC10by0ABAogRGVzaWduIFBhdHRlcm4KZW5kIG5vdGUKCgpSTy0-UlM6IDEgLSBQcmVzZW50cyBJbiAAYQYKUlMtPlJPOiAyIC0gR2V0cyBDcmVkZW50aWFsADIJMyAtIFNpZ24gSW4gdG8gTlBFIFBvcnRhbAA1CTQgLSBEaXNwbGF5ABoFUk9JIEZvcm0AdQk1IC0gU3BlY2lmeSBBdXRoJ3ogUwCCcAoAgRwJNiAtIFRleHQgUgCDfAcgRGVzY3JpcHRpb24AgUYFQVM6IDcAgQIOAINSBgCBCwcAgUwFQVM6IDggLSBGSElSADUWQQCBcAc5AEwlMTAgLSBDb25maXJtAIE6BQCEOAkgUG9saWNpZXMATAZTOiAxMQAiClxuAIE_CVJlZ2lzdHIAhHEFAIEbCTEyAFIGc2VudCBSZWNlaXB0CgCEExUKIEVuZCBvZiBVTUEgUGhhc2UgMQCDWwsAhFALAIRJDiBScVAgZGlzY292ZXIAhD4GAIZWCCB2aWEgbWVzc2FnZSBvciBkaXJlY3RvcnkgcXVlcnkAhDkLQwCEOwczIC0gUgCFXwYAgxgJClJxUACCHgc0AIRWDENsYWltc1xuZS5nLiBib2JAbWVkaWNhbHNvY2lldHkub3JnAIJ_BnFQOiAxNQCEahQAUAk2AINhD1MAags3IC0gTWF5IG5lZWQgdG8AgmEHZXIgQwCHMAUAg2QFQzogMTgAglcTQwCDVwc5AIFOCnMAg1EOADcIMjAgLSBHcmFuABARAIJgGwCDIREyAIcOCiAAgk0IMjEgLSBBY2Nlc3MAhSEOAIVACTIyABwGb3VudGluZyBmb3IgRGlzY2xvc3VyAINfHQCEIhEzAIgNDAo&s=mscgen

google document https://docs.google.com/document/d/1RchwNe8ddxnEzQihtivdUl9y-qfryjevyUEtGcnQ-eA/edit

Adrian:

When you read through this, you’ll notice the actors, and you’ll notice that this maps well to something called “agency law.”

John:

When you say “profile without new legal review, new federations, new registries, or patient-matching issues,” are you making an assertion that those are out of scope? Or that it solves these.

Adrian:

I’m saying that it solves these.

Let me quickly run through the UMA phases. I’m making the assumption that Alice presents in person and she has a local ID. She gets a credential. Now the hospital has added an html version of their existing ROI form. Because Alice is logged in, this release of information form can be prepopulated with her name, date of birth, and patient ID. It then asks Alice for an authorization server. We are assuming that Alice already has an authorization server. If she doesn’t have an authorization server, there’s a link to “get one here.” That allows her to download an authorization server from a trusted source. The assumption is that these authorization servers are personal. They don’t represent an organization. I invented this thing saying allow the hospital to authenticate the requesting party.

Tom:

Why did you say that the release expiration date doesn’t apply to healthcare?

Adrian:

Because it’s generic. It applies to more fields than healthcare. I’m trying to be careful not to introduce profiles prematurely.

Tom Sullivan:

You said the hospital might provide authentication to the doctor? I assume the doctor’s staff would be able to do that?

Adrian:

Once Alice says she trusts her hospital as an identity provider, that’s all we need to know. How the hospital authenticates their doctors does not apply. She is trusting the IdP - in this case, an NPE.

I invented this dance that submits this HTML form created by the hospital to this generic authorization server and allows Alice on this screen from Alice’s AS to choose “no sensitive information” and “expires today” and “allow the hospital to be the IdP”

The hospital is able to provide warnings - black box type warnings - when someone wants to register an app or an AS as a patient under the patients’ right of access. The hospital should not ban them from doing that, but can provide black box warnings.

Then we have a consent receipt going to a notice endpoint of Alice’s authorization server.

Justin:

How we deliver receipts is currently being discussed by the id-events ietf discussion group. This whole idea of a notice endpoint does not exist yet, but it’s something people are starting to talk about.

Adrian:

Now we get to “patient resource discovery, patient matching, and patient activity surveillance.” This is something that does not exist today. It sort of “out of scope magic.” ADT event is an HL7 standard for notification whenever a patient shows up or leaves a hospital. We want to capture them at the health information exchange and allow other doctors and service providers to be notified. Doctors want to know who else is going to treat the patient.

Tom Boyd:

This is really important. We call it “leakage.” It can hurt you in terms of trying to make a profit. If patients are starting to leave your system, you can bring them back in your system. It’s a way to control costs.

Adrian:

Phase 2 is where the real health information exchange happens. At this point, Bob comes to the hospital and says “give me Alice’s stuff.” UMA tells Bob where Alice’s AS is, allows Bob to authenticate, either directly or through a federation. Justin can tell us whether that’s correct.

Justin:

The claims presentation may not necessarily be an authentication event, but that’s certainly the most common use case, so it’s fine to say that.

Adrian:

Now we have the opportunity for Bob to register a client. The hospital doesn’t see this transaction, so they are in a “safe harbor” legally. This dynamic registration is optional. It should involve “black box warnings.’ Alice has the ultimate responsibility to accept clients who are knocking at the door.

Justin:

It’s really important to capture that UX around the “black box warning” - explaining to Alice that she’s about to do something that’s entirely her responsibility - is going to be vitally important.

Adrian:

Now we have another example of a consent receipt. This one is for the benefit of Bob. It parallels the receipt that was for the benefit of Alice. It allows Bob to have a record of the transaction with Alice’s authorization server. Then Bob’s client gets the resource. Then we have a third consent receipt that I would call “accounting for disclosure.” This protects the hospital to provide this notice endpoint. Right now breaches and snooping occur and it takes months or a whistleblower for the hospital to notice something has gone wrong. However, if you provide notice to the individual that a transaction has happened, the hospital’s risk is greatly reduced.

Glen:

When a patient receives a notice, how do we know that they have been notified and accept the implicit responsibility in that notice. If there’s a cause for action, we need to know how to prove that notice was sufficient.

Adrian:

In agency law, notice is always used together with “good faith.” All we can do is provide the endpoints and some guidance. In the end, it’s about good faith.

Dale:

I have a couple business questions. This is based on experience with HIEs. Normally, the person who is getting access to healthcare information has a heathcare relationship to Alice. Does Alice’s permission form establish that relationship?

Adrian:

We need to talk more about who manages consent. We need to deal with the consent management issue. Consent management as a business and a liability, can be enabled by this.

Dale:

There’s a lot of resistance in the business world. The people running the exchanges view the information as owned by the patient. They feel like they are a stakeholder in this because of liability. I hear a lot of concerns about whether they have a trail of the alleged physician party. How does that work in this system? How do I know that the person’s entitlement to view information is up to snuff so that HIPAA liability is met?

Adrian:

The sooner we get through the use case, the sooner we can bring in the HIEs. I really think that HEART needs to first do the baseline scenario, and then that will clarify how we do research and HIE.

Debbie:

You’ve done a lot of work here. We’ve done three use cases. Are you suggesting a fourth?

Adrian:

I suggest that this document becomes the first profile that we create.

Debbie:

I would hope that there’s one profile that gets voted on that can be layered against all four use cases to see if it works.

Adrian:

I agree. But I don’t want to consider this a fourth use cases. I want to consider this a first profile.

Debbie:

This is a use case, not a profile.

Sarah:

What does the word profile mean to you?

Adrian:

It means that two systems can interoperate. This is what we’ve defined to allow systems to interoperate.