<div dir="ltr"><div>Let me try to clarify a number of things said in today's call and put them in the context of Alice and Bob's user experience and Justin's concern regarding privacy engineering.<br><br></div>The baseline user experience should be: <br><ol><li><b>Alice has to remember only one thing</b>: Her voluntary globally unique pseudonym. I suggest we use an email address as the reference point.</li><li><b>Dr. Bob gets everything he needs,</b> Alice's policies permitting, by simply entering Alice's pseudonym into his client.</li><li><b>Resource Server (the source of Alice's attributes, a PHR or EHR) allows Alice to specify her Authorization Server</b> (This is what I can't convince the HL7-FHIR folks to consider).</li><li><b>An Interop Label </b>defined by a neutral entity, (e.g.: PPR) encourages Alice's AS, Dr. Bob's Client, and the Resource Server to make it easy for Alice by promising interoperability with web services that separately self-assert that Label. The label definition may include a suggested set of policies that Alice might use by default, scope, and IdP options.</li></ol><p>The rest is easy. <br></p><ol><li>Alice opens an account with an AS that installs the Interop Label by default and makes itself discoverable via her chosen globally unique pseudonym. Alice can accept the defaults mindlessly if she really trusts the Interop Label source and AS. She can always modify her policies at a later time. <br></li><li>Alice supplies her pseudonym to the Resource Server. The rest is handled automagically by UMA / HEART.</li><li>Alice supplies her pseudonym to Dr. Bob. The rest is handled automamagically by UMA / HEART.</li><li>Alice receives notification whenever the Resource Server authorizes release of her attributes. After a while, Alice goes to her AS and turns those notifications into a monthly digest, similar to the statement she gets from her bank.</li></ol><p>For extra credit:<br></p><p>Here's a list of 10 things Halamka would like to see per his blog post today: <a href="http://thehealthcareblog.com/blog/2016/06/13/fud-part-ii-the-return-of-fear-uncertainty-and-doubt/">http://thehealthcareblog.com/blog/2016/06/13/fud-part-ii-the-return-of-fear-uncertainty-and-doubt/</a></p><p>(my comments in (parenthesis))<br></p><p>*A master patient identifier for the country (easy if resource servers would accept a voluntary unique pseudonym)<br>
*A provider directory for the country <br>
*A consent registry/record locator service for the country (easy if resource servers would accept a patient-specified UMA AS)<br>
*A customer relationship management platform that supports care management <br>
*A groupware communication tool for healthcare<br>
*A set of security solutions that makes two factor authentication/endpoint encryption easier (easy if resource servers actually allowed patients and doctors to use OpenID Connect)<br>
*A mobile platform for patient/family engagement that provides usability and high value transactions to the consumer (easy if instead of multiple portals, the focus of engagement was delegated through a patient-specified AS)<br>
*A telehealth/telemedicine platform that supports documentation/billing in the cloud<br>
*An interoperability platform that leverages cloud technologies to 
seamlessly provide clinicians with the information they need when their 
need it (easy if we have a model where an inteorperability label actually means something the way WiFi or Bluetooth do)<br>
*An analytics platform that notifies/alerts clinicians when something 
needs to be done – providing wisdom, not just a flood of data. (easy if the interoperability label specifies AS notification at the level of the Enter key in associated resource server. FHIR can do this. My proposed interoperability label is "Independent Decision Support at the Point of Care" (iDSpoc) indicating that not only are the patient and physician able to specify their respective authorization servers but that the EHR issues a notification to that AS whenever an order is entered or other significant change is made.</p><p>My concern is that FHIR, including SMART on FHIR, have not allowed the most obvious user experience use-case into the spec. The result will be the FUD that Halamka discusses and another three or five years of information blocking.</p><p>Adrian<br></p><p><br></p><p><br></p><p> -- <br></p><div><div><div><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br><div dir="ltr">Adrian Gropper MD<span style="font-size:11pt"></span><br><br><span style="font-family:"Arial",sans-serif;color:rgb(31,73,125)">PROTECT YOUR FUTURE - RESTORE Health Privacy!</span><span style="font-family:"Arial",sans-serif;color:rgb(31,73,125)"><br>HELP us fight for the right to control personal health data.</span><span style="font-family:"Arial",sans-serif;color:rgb(31,73,125)"></span><span style="font-family:"Arial",sans-serif;color:rgb(31,73,125)"><br>DONATE:
<a href="http://patientprivacyrights.org/donate-2/" target="_blank"><span style="color:rgb(5,99,193)">http://patientprivacyrights.org/donate-2/</span></a></span><span style="color:rgb(31,73,125)"></span>
</div></div></div></div></div></div></div></div>
</div></div></div></div></div>