[Openid-specs-heart] Draft HEART Meeting Notes 2016-02-08

Sarah Squire sarah at engageidentity.com
Mon Feb 8 22:54:58 UTC 2016


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.

Sarah Squire
Engage Identity
http://engageidentity.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160208/218d259a/attachment-0001.html>


More information about the Openid-specs-heart mailing list