[Openid-specs-heart] Notification in HEART and/or UMA

[Aaron Seib, NATE]

Adrian,

 

This is a very useful description of the HEART work: “HEART is all about giving everyone a choice of authorization server in the FHIR context.”

 

I think it would be a great way to start a presentation about HEART that would provide a better understanding of what the project is about.

 

Before we move onto the rest of the thread here – which I think is just as important to understanding what is being proposed - can we deconstruct the meaning of two components of this sentence?

 

·         What does it mean to ‘give everyone a choice of authorization server’?

·         What does it mean to do so ‘in the FHIR Context’?

 

Next, I thought that this statement was very useful:  ‘When she (Alice) engages with a FHIR service provider as a patient Alice provides three pieces of information:

·         an identity

·         a notification address

·         a resource registration address

I want to make sure I understand what you mean when you later describe a potentially ideal solution as ‘Alice to provide an identity that automagically links to her Notification and Authorization addresses.”

If I am reading it correctly – I think you are asking if an email address supplied by Alice would be sufficient for the identity – I just want to make sure I understand the question.  If I am keeping up there would be some way that Alice associates this email address with her choice of Authorization server (that a FHIR based resource server could use to resolve her privacy preferences) and incidentally be where the FHIR based Resource Server would send notifications about the disclosures it made based on her privacy preferences found in the Authorization Server of her choice in association with the email address she chooses.

Thank you – this would be the kind of detail that I think we could share with a folks like NATE’s members et al.

 

Aaron

 

 

Aaron Seib, CEO

@CaptBlueButton 

 (o) 301-540-2311

(m) 301-326-6843

cid:image001.jpg at 01D10761.5BE2FE00

 

From: Openid-specs-heart [mailto:openid-specs-heart-bounces at lists.openid.net] On Behalf Of Adrian Gropper
Sent: Saturday, July 30, 2016 1:47 PM
To: openid-specs-heart at lists.openid.net
Cc: Dixie Baker
Subject: [Openid-specs-heart] Notification in HEART and/or UMA

 

A new thread to consider Danny's very important reminder of how HEART will deal with Notification. 

>From Alice's perspective, when she engages with a FHIR service provider as a patient Alice provides three pieces of information:

- an identity

- a notification address

- a resource registration address

That's a lot to ask. We're all used to providing an email address as an identity and a notification endpoint. We're also used to the typical OAuth authorization screen that sometimes appears after we use a federated identity such as Gmail. What we're not used-to, yet, is being given a choice of OAuth authorization server the same way we have a choice of notification address. HEART is all about giving everyone a choice of authorization server in the FHIR context. It's the essence of being patient-centered and why the HEART charter says: "build, buy, or outsource" the AS.

The ideal situation IMHO would be for Alice to provide an identity that automagically links to her Notification and Authorization addresses. If that identity is an email address, then we have a simple, voluntary, and well-established way to explain HEART and to bootstrap the rest of the patient registration or consent to health information exchange process. Is there any realistic alternative to email? 

It's not clear at this time whether UMA will add a Notification endpoint to the UMA spec. If it does, then HEART can just use that. If it doesn't then HEART will need to deal with Notification some other way. Either way, HEART will need to explain to FHIR resource servers how they are expected to bootstrap discovery of Alice's authorization server and, incidentally, her Notification address.

Adrian


 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160731/98a75f9e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 3142 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160731/98a75f9e/attachment.jpg>