<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Cambria;
panose-1:2 4 5 3 5 4 6 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Cambria",serif;
color:#44546A;
font-weight:normal;
font-style:normal;
text-decoration:none none;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria",serif;color:#44546A">To address Adrian’s initial question, the principal goal is to start simple with two FHIR based systems (assuming they are compatible) and how the key components interact
with each other at a process, system and profile level (not necessarily all at once). My thought is that this would provide a base understanding that we can build on either by expanding on with additional use cases or can be applied to other postposed used
cases, whichever the group decides. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria",serif;color:#44546A"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria",serif;color:#44546A">As with any use case, it describes a user workflow from the user’s perspective, which we can use as a tool to discuss how and what under lying processes, systems and
profiles operate and the discussion on Monday was starting to do just that. For example, following up from our conversation, the initial step “Alice has an account from her PHR and then has an account from her new PCP”. This context has provided us with
some good discussion and questions, one of which Justin elaborates on in a different thread:<o:p></o:p></span></p>
<p class="MsoNormal" style="text-indent:.5in"><span style="font-size:14.0pt;font-family:"Cambria",serif;color:#44546A">What are the “Certification Levels”, if any that would measure the validity of the PHR proofing and credentialing of Alice?<o:p></o:p></span></p>
<p class="MsoNormal" style="text-indent:.5in"><span style="font-size:14.0pt;font-family:"Cambria",serif;color:#44546A">How does Alice present these?<o:p></o:p></span></p>
<p class="MsoNormal" style="text-indent:.5in"><span style="font-size:14.0pt;font-family:"Cambria",serif;color:#44546A">Can another source (in the case the PCP) escalate them to a higher level?<o:p></o:p></span></p>
<p class="MsoNormal" style="text-indent:.5in"><span style="font-size:14.0pt;font-family:"Cambria",serif;color:#44546A">How can these be used for SSO?<o:p></o:p></span></p>
<p class="MsoNormal" style="text-indent:.5in"><span style="font-size:14.0pt;font-family:"Cambria",serif;color:#44546A"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria",serif;color:#44546A">Bill<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria",serif;color:#44546A"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria",serif;color:#44546A"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Openid-specs-heart [mailto:openid-specs-heart-bounces@lists.openid.net]
<b>On Behalf Of </b>Adrian Gropper<br>
<b>Sent:</b> Monday, May 11, 2015 7:50 PM<br>
<b>To:</b> Debbie Bucci<br>
<b>Cc:</b> openid-specs-heart@lists.openid.net<br>
<b>Subject:</b> Re: [Openid-specs-heart] HEART 2015-05-11 rough meeting notes<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">I'm not sure how many common understandings we will end up with. I do think it would be helpful for folks that propose a use case to make clear their primary goal in proposing that particular use case. Doing
so, enables all of us to design based on modern technology rather than paving the cow path of paper and parochial business practices.<o:p></o:p></p>
</div>
<p class="MsoNormal">Adrian<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Mon, May 11, 2015 at 6:56 PM, Debbie Bucci <<a href="mailto:debbucci@gmail.com" target="_blank">debbucci@gmail.com</a>> wrote:<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<p class="MsoNormal">If we do not have a common understanding - how do we know when we are conflating the issues? I found it helpful to walk stepwise through the use case and understand the complexities. If we have bucket to sort them into - great.
<br>
There are a lot different parts/issue to consider within each component - which was primarily registration today
<br>
<br>
Does solving the patient portal = <span style="font-size:11.0pt;font-family:"Calibri",sans-serif">
Alice’s PHR (or PCP portal or vendor health app) can be her single point of truth via the use of FHIR APIs ? </span>
<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Mon, May 11, 2015 at 6:12 PM, Justin Richer <<a href="mailto:jricher@mit.edu" target="_blank">jricher@mit.edu</a>> wrote:<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal">I’m with Adrian in terms of decomposing the problem into its components. There was a lot of conflation of authentication, authorization, trust, assurance, and different actors in the discussion today. If we don’t keep the parts clearly-defined
we’ll never make progress.<span style="color:#888888"><o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="color:#888888"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#888888"> — Justin<o:p></o:p></span></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On May 11, 2015, at 5:52 PM, Adrian Gropper <<a href="mailto:agropper@healthurl.com" target="_blank">agropper@healthurl.com</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">I interpreted the principal goal of Bill's Use Case to be a desire to solve the multiple portals problem. I'm aware of parents of seriously ill children that have as many as 11 separate portals to deal with.<o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt">Is this the principal goal of this conversation? If so, then we can begin to decompose the goal of solving the multiple portals problem into registration, authorization and authentication components for the
various actors. If there's another goal, please make it clear.<o:p></o:p></p>
</div>
<p class="MsoNormal">Adrian<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Mon, May 11, 2015 at 5:07 PM, Debbie Bucci <<a href="mailto:debbucci@gmail.com" target="_blank">debbucci@gmail.com</a>> wrote:<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">All <o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt">Great idea from Justin to post now and great discussion ... If other post - I will try to merge before the weekend for next week.<br>
<br>
<o:p></o:p></p>
<p style="margin-left:.75in">1.<span style="font-size:7.0pt"> </span>Alice calls the practice and schedules her initial appointment.<o:p></o:p></p>
<p style="margin-left:1.0in">A.<span style="font-size:7.0pt"> </span>The Scheduler does not find an existing account for Alice and creates a new account.<o:p></o:p></p>
<p style="margin-left:1.2in"><span style="font-size:7.0pt">
</span>i.<span style="font-size:7.0pt"> </span>Local account – Alice may not know<o:p></o:p></p>
<p style="margin-left:1.2in"><span style="font-size:7.0pt">
</span>ii.<span style="font-size:7.0pt"> </span>Could bind an external account/identity to it – binding ceremony<o:p></o:p></p>
<p style="margin-left:1.2in"><span style="font-size:7.0pt">
</span>iii.<span style="font-size:7.0pt"> </span>Object at database/table – that point to Alice OIDC + Public key or other stuff<o:p></o:p></p>
<p style="margin-left:1.0in">B.<span style="font-size:7.0pt"> </span>The Scheduler creates an appointment with the PCP Alice has selected.<o:p></o:p></p>
<p style="margin-left:.75in">2.<span style="font-size:7.0pt"> </span>Alice arrives at the practice and registers with the front desk.<o:p></o:p></p>
<p style="margin-left:1.0in">A.<span style="font-size:7.0pt"> </span>Alice provides the Registrar with her driver’s license and insure card(s).
<o:p></o:p></p>
<p style="margin-left:1.2in"><span style="font-size:7.0pt">
</span>i.<span style="font-size:7.0pt"> </span> – id proofing process<o:p></o:p></p>
<p style="margin-left:1.2in"><span style="font-size:7.0pt">
</span>ii.<span style="font-size:7.0pt"> </span>online eligibility checking – what is covered? payment<o:p></o:p></p>
<p style="margin-left:1.2in"><span style="font-size:7.0pt">
</span>iii.<span style="font-size:7.0pt"> </span>collect and scan – but how about verification ?
<o:p></o:p></p>
<p style="margin-left:1.0in">B.<span style="font-size:7.0pt"> </span>The Registrar scan the cards and updates Alice’s account.<o:p></o:p></p>
<p style="margin-left:1.2in"><span style="font-size:7.0pt">
</span>i.<span style="font-size:7.0pt"> </span>Id proofing<o:p></o:p></p>
<p style="margin-left:1.2in"><span style="font-size:7.0pt">
</span>ii.<span style="font-size:7.0pt"> </span>Can this ID process be re-used “known to the practice?” How can we represent that within the protocols?
<o:p></o:p></p>
<p style="margin-left:1.2in"><span style="font-size:7.0pt">
</span>iii.<span style="font-size:7.0pt"> </span>FITS into vectors of trust in IETF work<o:p></o:p></p>
<p style="margin-left:1.4in">1.1.1.2.B.iii.1.<span style="font-size:7.0pt">
</span>Verify holder of claims/document with identity– high level of confidence<o:p></o:p></p>
<p style="margin-left:1.4in">1.1.1.2.B.iii.2.<span style="font-size:7.0pt">
</span>Onboarding ceremony can bind and verify separately<o:p></o:p></p>
<p style="margin-left:1.4in">1.1.1.2.B.iii.3.<span style="font-size:7.0pt">
</span>Quick photograph and imbed into record for evidence of practice. <o:p></o:p></p>
<p style="margin-left:1.2in"><span style="font-size:7.0pt">
</span>iv.<span style="font-size:7.0pt"> </span>How does the profiles represent the level of trusts – two levels of proofing - trust elevation -
<o:p></o:p></p>
<p style="margin-left:1.4in">1.1.1.2.B.iv.1.<span style="font-size:7.0pt">
</span>(bill concerns) Login to phr - portals will create login account – Alice has a choice – PCP or PHR - potential to use multiple accounts with different levels of trust – how does the levels of trust get described across relying parties/resource servers
(?) How do we know Alice is Alice?<o:p></o:p></p>
<p style="margin-left:1.4in">1.1.1.2.B.iv.2.<span style="font-size:7.0pt">
</span>Alice should have the choice to use whatever. Identity to bind external accounts with local accounts is powerful<o:p></o:p></p>
<p style="margin-left:1.4in">1.1.1.2.B.iv.3.<span style="font-size:7.0pt">
</span>When alice goes to specialist – why would alice need an additional proofing? Specialist can always do their own binding process.
<o:p></o:p></p>
<p style="margin-left:1.4in">1.1.1.2.B.iv.4.<span style="font-size:7.0pt">
</span>Who is the system of record – not bound in OAUTH world. Alice could prove in multi- ways.<o:p></o:p></p>
<p style="margin-left:1.4in">1.1.1.2.B.iv.5.<span style="font-size:7.0pt">
</span>FHIR Referral message – between provider – I am referring to alice –I know here as 1234 – she used cred (issuer/subject) – if you trust me - let her in – save binding ceremony. Who’s to trust bits of information –
<o:p></o:p></p>
<p style="margin-left:1.4in">1.1.1.2.B.iv.6.<span style="font-size:7.0pt">
</span>If FHIR API increases patient engagement going forward …once Alice has set up credential –next system –if level of trust – should be able to transfer /share information.<o:p></o:p></p>
<p style="margin-left:1.2in"><span style="font-size:7.0pt">
</span>v.<span style="font-size:7.0pt"> </span>More info – vectors of trust and binding … take advantage of capabilities that did not exist in paper world
<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
_______________________________________________<br>
Openid-specs-heart mailing list<br>
<a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank">Openid-specs-heart@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<br>
-- <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal">Adrian Gropper MD<span style="font-size:7.5pt"><br>
</span><span style="font-size:10.0pt">Ensure Health Information Privacy. Support Patient Privacy Rights.<br>
<a href="http://patientprivacyrights.org/donate-2/" target="_blank">http://patientprivacyrights.org/donate-2/</a><u><span style="color:blue">
</span></u></span><span style="font-size:11.0pt"><o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
<p class="MsoNormal">_______________________________________________<br>
Openid-specs-heart mailing list<br>
<a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank">Openid-specs-heart@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><o:p></o:p></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<br>
-- <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal">Adrian Gropper MD<span style="font-size:7.5pt"><br>
</span><span style="font-size:10.0pt">Ensure Health Information Privacy. Support Patient Privacy Rights.<br>
<a href="http://patientprivacyrights.org/donate-2/" target="_blank">http://patientprivacyrights.org/donate-2/</a><u><span style="color:blue">
</span></u></span><span style="font-size:11.0pt"><o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
</body>
</html>