Attendees:

Debbie Bucci

Michael Chen

Thompson Boyd

Adrian Gropper

Sarah Squire

Justin Richer

Randy Bak

Danny van Leeuwen

David Batchelor

Eve Maler

Nancy Lush

Kenneth Salyards

William Kinsley

John Moehrke

Dale Moberg

Aaron Seib

Kathleen Connor

Glen Marshall

Edmund Jay

Mayank Agarwal

Debbie:

We need at least 37 votes in OIDF. We only have 17. Please vote if you are a member or become a member so you can vote. Being a member of the HEART working group does not make you a member of OIDF.

We will meet next Monday even though it’s a holiday. If you can come, please do.

Adrian:

I’ve been working with Dr. Chen for two years now on a project. I don’t know who is using his EHR already. My only connection with him is around this patient-centered approach we’re doing.

Michael:

I’m a family physician, currently practicing. This project was in response to my frustration with the current options for EHR in terms of cost and user interface. So I made my own. In 2012, I made an effort to share it with others. There were a few clinics that had the model I was looking for. They started using my system. There was also interest internationally. With the developments in UMA and FHIR APIs, it would lead to this idea of the reality where the patient has control of their personal health information.

This demo will show three separate tasks.

First task: Patient invites doctor, doctor uses SSO to connect to patient’s PHR

I’m going to start off acting as the patient. This Nosh instance has a MITREid Connect UMA Server and an EMR. There is already a connection between the pNOSH and the UMA server. The UMA server works as an IdP for pNOSH. It asks for an approval. The patient would authorize. Then the patient sees their dashboard. Here the patient can share their pre-registered resources - these are denominations of what FHIR is using (i.e. allergies, medications, demographics). The patient can then submit an invitation to the provider. Providers can have single-sign on for all patient data, even if patients are using their own individual pNOSH instances through the mdNOSH gateway.

The provider receives an email indicating that one of his patients has invited him to their PNosh and giving him a URL to log in. The provider logs into his mdNOSH account and is directed to the patients pNOSH.

Eve:

What do the UMA policies look like under the hood?

Michael:

There are a series of FHIR endpoints protected by UMA. The UMA server has a web app that the patient can log into. That’s plain MITREid Connect. You can manage policies just as you do normally.

Second task: provider accesses pNOSH patient information from mdNOSH

The provider can add a problem list item from within the patient’s PHR, then log out. Then through UMA and FHIR, the provider can see the problem in mdNOSH and get a link into the patient’s pNOSH. We can access information securely that the patient has given access to.

FHIR has both read and write access, so if the patient chooses to, the information flow can be bi-directional.

Adrian:

What we’re showing here combines the UMA authorization server with the patient’s health record. HIE of one separates these two components. What’s going on here is much closer to HEART’s first use case.

William:

How is the patient credentialed and matched within the provider system?

Michael:

If the provider has given permission to access this patient’s pNOSH, there’s a series of steps hinged upon the provider’s email address. If they were separate, they would have to dynamically register. The common identity is the provider’s email address. Once that connection has been made, that enterprise EMR would have to figure out how to save or generate a refresh token to maintain secure access.

Right now, it is assumed that the provider would have to verify that the patient is the correct patient that they’re connecting to. That part will have to be worked on.

Debbie:

Didn’t the patient authorize the provider?

Eve:

That’s where levels of assurance comes in.

Adrian:

The patient isn’t using a patient portal. If they were, the sequence that results in this linkage starts with the patient logging into the portal at the mdNOSH and then linking their pNOSH. The staff-oriented patient matching that’s happening in these scenarios is exactly what is happening in the medical community now.

Michael:

I’m hoping to find other people to help with this project. It’s hosted on github.

Adrian:

We are splitting off HIE of one from pNOSH. Hopefully better open source communities can be built that way.

Debbie:

It’s good to hear that it was easy to add FHIR.

Michael:

My system is already web-based, so it was easy to add a RESTful API. That part was relatively trivial.