<div dir="ltr"><div><div><div><div><div><div><div>A new thread to consider Danny's very important reminder of how HEART will deal with Notification. <br><br>From Alice's perspective, when she engages with a FHIR service provider as a patient Alice provides three pieces of information:<br></div>- an identity<br></div>- a notification address<br></div>- a resource registration address<br><br></div>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.<br><br></div>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? <br><br></div>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.<br><br></div>Adrian<br><div><div><div><div><div><br> <br></div></div></div></div></div></div>