<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Yes, as far as I can tell we agree on this point. Contrary to popular belief, I’m not here *just* to disagree with everyone. :)<div class=""><br class=""></div><div class=""> — Justin</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 2, 2016, at 10:33 AM, Moehrke, John (GE Healthcare) <<a href="mailto:John.Moehrke@med.ge.com" class="">John.Moehrke@med.ge.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><meta name="Generator" content="Microsoft Word 14 (filtered medium)" class=""><style class=""><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 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";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.hoenzb
{mso-style-name:hoenzb;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1784836710;
mso-list-template-ids:-189992080;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1
{mso-list-id:2042169212;
mso-list-template-ids:-1547904202;}
@list l1:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></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]--><div lang="EN-US" link="blue" vlink="purple" class=""><div class="WordSection1"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D" class="">Yes, that is my point. I think we agree. right?<o:p class=""></o:p></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D" class=""> </span></p><div class=""><div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in" class=""><p class="MsoNormal"><b class=""><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"" class="">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"" class=""> Justin Richer [<a href="mailto:jricher@mit.edu" class="">mailto:jricher@mit.edu</a>] <br class=""><b class="">Sent:</b> Tuesday, February 02, 2016 8:44 AM<br class=""><b class="">To:</b> Moehrke, John (GE Healthcare)<br class=""><b class="">Cc:</b> Eve Maler; Adrian Gropper; <a href="mailto:openid-specs-heart@lists.openid.net" class="">openid-specs-heart@lists.openid.net</a><br class=""><b class="">Subject:</b> Re: [Openid-specs-heart] CHIME Launches $1M Challenge to Solve Patient ID Problem<o:p class=""></o:p></span></p></div></div><p class="MsoNormal"><o:p class=""> </o:p></p><p class="MsoNormal">Identity confirmation and binding are key, here. You cannot trust the identity attributes of a general IdP from the outside and use those to match an internal record. That’s utterly ludicrous, I think we can all easily agree on that. What you *can* do, though, is have a process whereby you are both reasonably sure that the person you’re talking to is the subject of a specific medical record and that that same person can prove control over a specific external IdP account. Thus the federated identity is bound to the medical identity. <o:p class=""></o:p></p><div class=""><p class="MsoNormal"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal">It gets a little more interesting when the identity attributes of a specific IdP can be trusted to some extent. Do you want to trust those attributes alone for lookup into a records system? Most likely not. But they can help with the onboarding process. <o:p class=""></o:p></p><div class=""><p class="MsoNormal"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal">We’re not the only ones looking to do this kind of situational binding, either. I’ve got another client who’s very interested in combining the attributes of a digital identity from a trusted IdP with in-person verification in order to build a highly assured transactional identity. <o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal"> — Justin<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><o:p class=""> </o:p></p><div class=""><blockquote style="margin-top:5.0pt;margin-bottom:5.0pt" class=""><div class=""><p class="MsoNormal">On Feb 2, 2016, at 8:21 AM, Moehrke, John (GE Healthcare) <<a href="mailto:John.Moehrke@med.ge.com" class="">John.Moehrke@med.ge.com</a>> wrote:<o:p class=""></o:p></p></div><p class="MsoNormal"><o:p class=""> </o:p></p><div class=""><div class=""><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D" class="">+1. Thanks Eve. I too worry that we must also keep the bad-guys OUT! Medical Identity Fraud is huge.</span><o:p class=""></o:p></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D" class=""> </span><o:p class=""></o:p></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D" class="">The current practice is ‘in person proofing’… as the first encounter with the patient is as a … patient… Now many patients are not at their ‘best’ when they first appear, so the understanding of their identity evolves over the first hours and days and weeks. Thus in healthcare practice we often know the patient by many identifiers that we have either merged or linked. And there are cases where a merged or linked patient needs to be unmerged or unlinked. Very messy business. Ultimately the patient gets billed for the services they have received, and the identity gets confirmation that they paid, thus stronger. This is just a discussion of the patient id, not the patient as a user.</span><o:p class=""></o:p></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D" class=""> </span><o:p class=""></o:p></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D" class="">The patient as a User usually starts with this in-person relationship. Most often the healthcare organization uses the identity they know, and the billing address to send them postal-mail (covered by strong fraud laws). This kickstarts an online confirmation workflow that binds the human patient identity to a user identity. Unfortunately this often is by way of a hospital managed user account, and not an internet friendly OAuth identity. </span><o:p class=""></o:p></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D" class=""> </span><o:p class=""></o:p></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D" class="">There are increasing cases where an internet friendly OAuth identity is used. However these (Facebook, Google, etc) are very low assurance identities, as anyone can claim to be anyone. To use these in healthcare we elevate the LoA using the above described online confirmation workflow so that the result is an identity that the patient wants to use, elevated to a higher assurance level through the healthcare driven identity confirmation workflow.</span><o:p class=""></o:p></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D" class=""> </span><o:p class=""></o:p></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D" class="">John</span><o:p class=""></o:p></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D" class=""> </span><o:p class=""></o:p></p><p class="MsoNormal"><b class=""><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"" class="">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"" class=""> Openid-specs-heart [<a href="mailto:openid-specs-heart-bounces@lists.openid.net" class="">mailto:openid-specs-heart-bounces@lists.openid.net</a>] <b class="">On Behalf Of </b>Eve Maler<br class=""><b class="">Sent:</b> Tuesday, February 02, 2016 12:35 AM<br class=""><b class="">To:</b> Adrian Gropper<br class=""><b class="">Cc:</b> <a href="mailto:openid-specs-heart@lists.openid.net" class="">openid-specs-heart@lists.openid.net</a><br class=""><b class="">Subject:</b> Re: [Openid-specs-heart] CHIME Launches $1M Challenge to Solve Patient ID Problem</span><o:p class=""></o:p></p><p class="MsoNormal"> <o:p class=""></o:p></p><div class=""><p class="MsoNormal">(This will have to be my last response on this subject, unless we can stay out of the realm of "unprofilable philosophy".)<o:p class=""></o:p></p><div class=""><p class="MsoNormal"> <o:p class=""></o:p></p></div><div class=""><p class="MsoNormal">Whether "healthcare is a human right" or not, mitigating risk is still a challenge I thought we mutually agreed is important to solve; otherwise we wouldn't be trying to solve things like the "Adrian clause" in the UMA spec. Therefore, it can't be true that "assurance" is conceptually irrelevant because its very purpose is to mitigate risk by "establishing confidence in user identities electronically presented to an information system" (quoting from NIST Special Publication 800-63-2, called the Electronic Authentication Guideline). The purpose of this spec is emphatically <i class="">not</i> exclusive to credit or financial use cases. <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_Identity-5Fverification-5Fservice&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=S2lF8wqaFBGRf-NBpz_IZjcqA-AI_kAV9hkCLmZvL2Q&s=tq5n9wHm3N_2ZKRB_NuXwqKW_QZIPAr5g6rkq5ARJnk&e=" class="">Identity verification</a> that is applied when someone registers with any high-enough-value service (could be an EHR portal or an employer portal or something else, such as regulated online gambling) often <i class="">use</i> financial and governmental documents, because they are useful for binding real-world people to pre-recorded identities.<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"> <o:p class=""></o:p></p></div><div class=""><p class="MsoNormal">If we're in the realm of pure sovereignty and inalienable human rights vs. "icky financial stuff", then I see that as incompatible with asking questions about governance. But if we're being realistic in trying to stop fraud and abuse by health identity thieves and trying to solve other security and privacy scenarios that are in our remit, then we must concern ourselves with "assurance" and risk mitigation using appropriate identity verification and authentication tools and governance processes.<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"> <o:p class=""></o:p></p></div><div class=""><div class=""><p class="MsoNormal">I would love to know what the current standards are for becoming "known to a practice", btw.<o:p class=""></o:p></p></div></div></div><div class=""><p class="MsoNormal"><br clear="all" class=""><o:p class=""></o:p></p><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b class="">Eve Maler<br class=""></b>ForgeRock Office of the CTO | VP Innovation & Emerging Technology<br class="">Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl<br class="">New <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__www.forgerock.com&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=S2lF8wqaFBGRf-NBpz_IZjcqA-AI_kAV9hkCLmZvL2Q&s=O83u6syn25hZ8H2CSds0Whb6VXG2pXHU4ilMDQNZGCY&e=" target="_blank" class="">ForgeRock Identity Platform</a> with <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__www.forgerock.com_platform_user-2Dmanaged-2Daccess_&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=S2lF8wqaFBGRf-NBpz_IZjcqA-AI_kAV9hkCLmZvL2Q&s=6J_QBRDTvCsC7nKUk_a4s3hvDB3ZjxshEYhajEG8ixI&e=" target="_blank" class="">UMA support</a> and an <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__forgerock.org_openuma_&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=S2lF8wqaFBGRf-NBpz_IZjcqA-AI_kAV9hkCLmZvL2Q&s=hIe4D_M5GXf99DyZ7l9APbwGplAQWE-DyH6sPqFX4UA&e=" target="_blank" class="">OpenUMA community</a>!<o:p class=""></o:p></p></div></div></div></div></div></div></div><p class="MsoNormal"> <o:p class=""></o:p></p><div class=""><p class="MsoNormal">On Mon, Feb 1, 2016 at 7:12 PM, Adrian Gropper <<a href="mailto:agropper@healthurl.com" target="_blank" class="">agropper@healthurl.com</a>> wrote:<o:p class=""></o:p></p><p class="MsoNormal">I take Vectors of Trust for granted. LOA is irrelevant in the patient ID discussion. Healthcare is not like credit, healthcare is a human right whereas cheaper credit is a privilege. I truly don't understand where our workgroup or Congress are thinking human sovereignty ends. <o:p class=""></o:p></p><div class=""><p class="MsoNormal"> <o:p class=""></o:p></p></div><div class=""><p class="MsoNormal">If anyone believes that HEART, and consequently FHIR, can assume a floor on human sovereignty in access and control of our personal information (including searchable identifiers, choice of notification end points, right to anonymous or pseudonymous service, institutional limits on a licensed physician's authority, right to be forgotten) then let's start a list of these limits on privacy here, below.<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"> <o:p class=""></o:p></p></div><div class=""><p class="MsoNormal">Keep in mind, that for every item we choose to add to the list we will be called on to suggest an appropriate governance mechanism. Are we going to rewrite HIPAA or just hope for appropriate interpretations?<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"> <o:p class=""></o:p></p></div><p class="MsoNormal"><UL><o:p class=""></o:p></p><div class=""><p class="MsoNormal"> <o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><span style="color:#888888" class="">Adrian</span><o:p class=""></o:p></p></div><div class=""><div class=""><div class=""><p class="MsoNormal"><br class="">On Monday, February 1, 2016, Eve Maler <<a href="mailto:eve.maler@forgerock.com" class="">eve.maler@forgerock.com</a>> wrote:<o:p class=""></o:p></p><div class=""><p class="MsoNormal">Below, with less pertinent stuff elided:<o:p class=""></o:p></p><div class=""><p class="MsoNormal"><br clear="all" class=""><o:p class=""></o:p></p><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b class="">Eve Maler<br class=""></b>ForgeRock Office of the CTO | VP Innovation & Emerging Technology<br class="">Cell <a href="tel:%2B1%20425.345.6756" target="_blank" class="">+1 425.345.6756</a> | Skype: xmlgrrl | Twitter: @xmlgrrl<br class="">New <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__www.forgerock.com&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=S2lF8wqaFBGRf-NBpz_IZjcqA-AI_kAV9hkCLmZvL2Q&s=O83u6syn25hZ8H2CSds0Whb6VXG2pXHU4ilMDQNZGCY&e=" target="_blank" class="">ForgeRock Identity Platform</a> with <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__www.forgerock.com_platform_user-2Dmanaged-2Daccess_&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=S2lF8wqaFBGRf-NBpz_IZjcqA-AI_kAV9hkCLmZvL2Q&s=6J_QBRDTvCsC7nKUk_a4s3hvDB3ZjxshEYhajEG8ixI&e=" target="_blank" class="">UMA support</a> and an <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__forgerock.org_openuma_&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=S2lF8wqaFBGRf-NBpz_IZjcqA-AI_kAV9hkCLmZvL2Q&s=hIe4D_M5GXf99DyZ7l9APbwGplAQWE-DyH6sPqFX4UA&e=" target="_blank" class="">OpenUMA community</a>!<o:p class=""></o:p></p></div></div></div></div></div></div></div><p class="MsoNormal"> <o:p class=""></o:p></p><div class=""><p class="MsoNormal">On Sat, Jan 30, 2016 at 3:01 PM, Adrian Gropper <<a href="mailto:agropper@healthurl.com" class="">agropper@healthurl.com</a>> wrote:<o:p class=""></o:p></p><div class=""><div class=""><div class=""><p class="MsoNormal">You've lost me again. My 1 - 5 sequence had nothing to do with the strength of authentication for either the RO at the RS, the RO at the AS, or the RqP anywhere. LOA is important, and it comes into play in many places, but I don't understand how it impacts the chain between Resource Registration with an AS at one end and a successful FHIR transfer from the RS to the Client at the other.<o:p class=""></o:p></p></div></div></div><div class=""><p class="MsoNormal"> <o:p class=""></o:p></p></div><div class=""><p class="MsoNormal">I didn't mention "Resource Registration"; I mentioned "onboarding/registering patients". I couldn't remember what words the WG agreed to use for when a patient first shows up at a practice vs. a service; in fact, now that I look at our <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1IvbdWerdvMuA1dQ-2DKQvVKqIBrAas7FoenNVUtgpqYrw_edit-3Fusp-3Dsharing&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=S2lF8wqaFBGRf-NBpz_IZjcqA-AI_kAV9hkCLmZvL2Q&s=sKhVjDy15DJ_SZn-4CLI3q8__K5nPvrwg--TQJOkwXg&e=" target="_blank" class="">first use case</a>, it seems we've taken out some explanatory terminology definition stuff that we used to have in there, and also mixed up our usage in a spot or two, but "registration" is supposed to be reserved for a practice and "onboarding" is supposed to for a service (such as an EHR portal). So: what I meant was "patient identity verification methods when onboarding patients to a service".<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"> <o:p class=""></o:p></p></div><div class=""><p class="MsoNormal">(In the case of actually providing many healthcare services, whether in person or something like telehealth, I wonder: is actual patient pseudonymity really practical? There's a physical body involved.)<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"> <o:p class=""></o:p></p></div><div class=""><p class="MsoNormal">Your #1-#5 process is interesting if you're considering treating biometrics as a body's "persistent username", but, at this point, fairly theoretical vs. how identity is verified today given that financial and governmental documentation is heavily relied on and biometric markers tend not to be, and your list speaks only of the "front-loaded" part, not the routine usage of any credentials. That latter part is where authentication comes in, and also where cross-service assurance leakage (e.g. UMA RS/AS, and client/RqP trust elevation) can potentially happen. LOA definitionally includes routine usage, not just credential creation.<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"> <o:p class=""></o:p></p></div><div class=""><p class="MsoNormal">Doctor IDs do matter too if they are in the position of accessing the patient's data as a requesting party.<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"> <o:p class=""></o:p></p></div><div class=""><p class="MsoNormal">(For those perhaps less technically inclined, here's a very old blog post of mine discussing <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.xmlgrrl.com_blog_2009_12_31_how-2Dto-2Drest-2Dassured_&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=S2lF8wqaFBGRf-NBpz_IZjcqA-AI_kAV9hkCLmZvL2Q&s=CoSrlDdhT-OFe_s-qifJWC8L2oPrHSeL-CAy4uoLVfQ&e=" target="_blank" class="">Levels of Assurance</a> that may be of interest. And heres the very latest version of the canonical <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__nvlpubs.nist.gov_nistpubs_SpecialPublications_NIST.SP.800-2D63-2D2.pdf&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=S2lF8wqaFBGRf-NBpz_IZjcqA-AI_kAV9hkCLmZvL2Q&s=rtswsoIIqXRiR-sp8r6R4T0C2m1Lje8bSn2V0QTCrBE&e=" target="_blank" class="">LOA specification</a>.)<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"> <o:p class=""></o:p></p></div><div class=""><p class="MsoNormal">Trying to net out some conclusions that are relentlessly practical for HEART purposes:<o:p class=""></o:p></p></div><div class=""><ul type="disc" class=""><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo3">Without further profiling, "raw" UMA doesn't require that Alice use the same identifier or the same authentication strength at both, say, a PHR resource server and an IRB authorization server.<o:p class=""></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo3">The formal LOA standard defines an LOA 1-4 scale that is very rigid, and doesn't allow for pseudonymity once you enter into the levels with any good authentication strength.<o:p class=""></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo3">If we wanted that for any use cases, we'd have to get creative (e.g., looking at Justin's "Vectors of Trust" standards work) to split the difference and get some of both.<o:p class=""></o:p></li></ul></div><blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt" class=""><div class=""><div class=""><div class=""><p class="MsoNormal"> <o:p class=""></o:p></p></div><p class="MsoNormal" style="margin-bottom:12.0pt">Please be more explicit. I know that the standards around authentication events is important and that federating IdPs and LOA may play a role for the doctors and nurses as RqPs but LOA is much less important for the patient authentication. Once again, this thread is about patient ID in the patient matching for FHIR sense. It is not directly about the doctor's ID, or is it?<o:p class=""></o:p></p></div><p class="MsoNormal"><span style="color:#888888" class="">Adrian</span><o:p class=""></o:p></p></div><div class=""><div class=""><div class=""><p class="MsoNormal"> <o:p class=""></o:p></p><div class=""><p class="MsoNormal">On Sat, Jan 30, 2016 at 4:59 PM, Eve Maler <<a href="mailto:eve.maler@forgerock.com" class="">eve.maler@forgerock.com</a>> wrote:<o:p class=""></o:p></p><div class=""><p class="MsoNormal">(Removing wg-uma from this thread as not pertinent -- and anyway, I don't use my same email address/identifier for that list... :-)<o:p class=""></o:p></p><div class=""><p class="MsoNormal"> <o:p class=""></o:p></p></div><div class=""><p class="MsoNormal">Are biometrics going to become common as a standard as a patient identity verification method when onboarding/registering patients anytime soon and, further, for ongoing authentication once the patient is in the system? Both are needed for high assurance. Just yesterday, I happened to tweet this from a doctor's office...<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"> <o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_xmlgrrl_status_693220654611496960&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=S2lF8wqaFBGRf-NBpz_IZjcqA-AI_kAV9hkCLmZvL2Q&s=lpTLJBujwW6KiWmD4jWA9LAP3w3fiOPSXL1g2NcPWTc&e=" target="_blank" class="">https://twitter.com/xmlgrrl/status/693220654611496960</a><o:p class=""></o:p></p></div><div class=""><p class="MsoNormal">"OH at doctor’s office: Nurse to doctor: “Hey, I need your password again.” Why constrained delegated access needs to be easier than *that*."<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"> <o:p class=""></o:p></p></div><div class=""><p class="MsoNormal">(and actually, it was an MA, not a nurse)<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"> <o:p class=""></o:p></p></div><div class=""><p class="MsoNormal">And as I noted previously, biometrics are not the be-all/end-all of authentication, and while certain (not all) biometrics have interesting properties for uniquely <i class="">identifying</i> a person in the real world, many of them can also be faked by bad guys, and really should be paired with a second factor. It has been observed that "they make a better username than a password".<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"> <o:p class=""></o:p></p></div><div class=""><p class="MsoNormal">As long as various authentication methods are considered equivalently strong, this is where it could be useful to demand that "some individual" simply be able to prove they can log in to some client/RS at strength X and also to the authorization server at equivalent strength X, where it's only necessary for one side to have successfully patient-matched, and where there's a requirement for some magic patient ID to be correlatable/passed between systems if necessary to satisfy regulatory compliance issues.<o:p class=""></o:p></p></div></div><div class=""><p class="MsoNormal"><br clear="all" class=""><o:p class=""></o:p></p><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b class="">Eve Maler<br class=""></b>ForgeRock Office of the CTO | VP Innovation & Emerging Technology<br class="">Cell <a href="tel:%2B1%20425.345.6756" target="_blank" class="">+1 425.345.6756</a> | Skype: xmlgrrl | Twitter: @xmlgrrl<br class="">New <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__www.forgerock.com&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=S2lF8wqaFBGRf-NBpz_IZjcqA-AI_kAV9hkCLmZvL2Q&s=O83u6syn25hZ8H2CSds0Whb6VXG2pXHU4ilMDQNZGCY&e=" target="_blank" class="">ForgeRock Identity Platform</a> with <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__www.forgerock.com_platform_user-2Dmanaged-2Daccess_&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=S2lF8wqaFBGRf-NBpz_IZjcqA-AI_kAV9hkCLmZvL2Q&s=6J_QBRDTvCsC7nKUk_a4s3hvDB3ZjxshEYhajEG8ixI&e=" target="_blank" class="">UMA support</a> and an <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__forgerock.org_openuma_&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=S2lF8wqaFBGRf-NBpz_IZjcqA-AI_kAV9hkCLmZvL2Q&s=hIe4D_M5GXf99DyZ7l9APbwGplAQWE-DyH6sPqFX4UA&e=" target="_blank" class="">OpenUMA community</a>!<o:p class=""></o:p></p></div></div></div></div></div></div></div><p class="MsoNormal"> <o:p class=""></o:p></p><div class=""><div class=""><div class=""><p class="MsoNormal">On Sat, Jan 30, 2016 at 1:29 PM, Adrian Gropper <<a href="mailto:agropper@healthurl.com" class="">agropper@healthurl.com</a>> wrote:<o:p class=""></o:p></p><p class="MsoNormal">We're back on track with "<span style="font-size:10.0pt" class="">Authentication strength/LOA and pairing mechanics could be a matter for HEART profiling."</span><o:p class=""></o:p></p><div class=""><p class="MsoNormal"> <o:p class=""></o:p></p></div><div class=""><p class="MsoNormal">The issue becomes, what is the chain of events that drives patient ID in the sense of enabling a patient-level FHIR client to access a patient-level FHIR resource?<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"> <o:p class=""></o:p></p></div><div class=""><p class="MsoNormal">1 - Although it's not the only way to build this chain, I start with "known to the practice" in the sense that a specific person's biometric can be associated with a specific primary key in either the FHIR client or FHIR resource server. There is no matching yet and the biometric, be it a photo or iris scan, is neither verified nor is it used for matching across the link.<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"> <o:p class=""></o:p></p></div><div class=""><p class="MsoNormal">2 - The patient provides an identifier to the Client FHIR endpoint that can eventually result in a match at the FHIR resource server. A persona. Depending on jurisdictional and business issues, this identifier may not be subject to any verification at all, verification to ensure correct spelling such as an email confirmation, or verification against a federated authority such as the state DMV. <o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"> <o:p class=""></o:p></p></div><div class=""><p class="MsoNormal">3 - The persona identifier provided to the FHIR Client can be designed in all sorts of different ways. <o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"> a - It could be globally unique and anonymous like a Bitcoin address. <o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"> b - It could be globally unique and easily remembered like an email address or mobile number<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"> c - It could be globally unique and subject to a federation's jurisdiction like a driver's license number<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"> <o:p class=""></o:p></p></div><div class=""><p class="MsoNormal">4 - All of a, b, or c are then subject to discovery mechanics and standards such as blockchain, WebFinger or lookup in Surescripts or the state HIE. This eventually turns into an identifier that is unique to the FHIR resource server for that matching patient persona.<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"> <o:p class=""></o:p></p></div><div class=""><p class="MsoNormal">5 - The FHIR client presents to the FHIR resource server with a patient context and requests access. Hilarity and maybe more UMA ensues.<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"> <o:p class=""></o:p></p></div><div class=""><p class="MsoNormal">Somewhere between 1 and 5 we have patient and requesting party authentications, AS and client registrations, and these touch UMA and HEART more or less directly. I prefer to think of the patient's persona and her UMA AS URI being a unified and key link in his chain of events. <o:p class=""></o:p></p></div><div class=""><div class=""><div class=""><p class="MsoNormal"> <o:p class=""></o:p></p></div><div class=""><p class="MsoNormal">Adrian<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal"> <o:p class=""></o:p></p></div></div></div></div></div></div></div></div></div></div></div></blockquote></div></div></div></div><p class="MsoNormal" style="margin-bottom:12.0pt"> <o:p class=""></o:p></p></div></div><div class=""><div class=""><p class="MsoNormal">-- <o:p class=""></o:p></p><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><p class="MsoNormal"> <o:p class=""></o:p></p><div class=""><p class="MsoNormal">Adrian Gropper MD<br class=""><br class=""><span style="font-family:"Arial","sans-serif";color:#1F497D" class="">PROTECT YOUR FUTURE - RESTORE Health Privacy!<br class="">HELP us fight for the right to control personal health data.<br class="">DONATE: <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.org_donate-2D2_&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=S2lF8wqaFBGRf-NBpz_IZjcqA-AI_kAV9hkCLmZvL2Q&s=yMZuD-j3QlyHjmgLtLHZTFAnbhfyJp0gsqfpl7mBtg4&e=" target="_blank" class=""><span style="color:#0563C1" class="">http://patientprivacyrights.org/donate-2/</span></a></span> <o:p class=""></o:p></p></div></div></div></div></div></div></div><p class="MsoNormal"> <o:p class=""></o:p></p></div></div></div><p class="MsoNormal"> <o:p class=""></o:p></p></div></div><p class="MsoNormal">_______________________________________________<br class="">Openid-specs-heart mailing list<br class=""><a href="mailto:Openid-specs-heart@lists.openid.net" class="">Openid-specs-heart@lists.openid.net</a><br class=""><a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" class="">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><o:p class=""></o:p></p></div></blockquote></div><p class="MsoNormal"><o:p class=""> </o:p></p></div></div></div></div></div></blockquote></div><br class=""></div></body></html>