A part of me wishes we would separate out the resource labeling while potentially keeping it in scope. How far could we get by defining just one really non-controversial resource like Alice's allergies? Or one really useful resource like Alice's insurance coverage? Sooner or later, we may need to deal with replacing the current role of CCD-A as a transition of care document and more.<div><br></div><div>In the long run, the health standard groups like HL7 are going to need market drivers or regulations to do most of the resource mapping. I don't see this as a current priority for HEART.</div><div><br></div><div>Adrian<br><br>On Tuesday, July 7, 2015, Eve Maler <<a href="mailto:eve.maler@forgerock.com">eve.maler@forgerock.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Commenting on one of Aaron's bulleted items:<div><br></div><div>Profiling "a standard way to label assets managed by the RS" is one of the tasks I was contemplating to be potentially in scope for our semantic UMA profile. This is because it is possible for resource set descriptions (these are things that an UMA RS registers at an AS, to put resources under protection) to include resource types. As I understand it, the FHIR API conveys data structures that reflect quite a lot of HL7 standardization work already done, which amounts to "resource typing".</div><div><br></div><div>While a lot of companies with proprietary APIs might not want to standardize their resource assets, there's a lot of power in standardized resource labeling in open ecosystems like the one we're working on. For starters, there's a <a href="https://docs.kantarainitiative.org/uma/rec-oauth-resource-reg-v1_0.html#rfc.section.4" target="_blank">security consideration</a> that is mitigated by the use of "well-known and standardized" description elements. (See this <a href="https://github.com/xmlgrrl/UMA-Specifications/issues/151" target="_blank">UMA issue</a> for some background.) For another example, standard types could drive automated policy workflows in interesting ways.</div></div><div class="gmail_extra"><br clear="all"><div><div><div dir="ltr"><div><div dir="ltr">
<p><b>Eve Maler<br></b>ForgeRock Office of the CTO | VP Innovation & Emerging Technology<br>Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl<br>Join our <a href="http://forgerock.org/openuma/" target="_blank">ForgeRock.org OpenUMA</a> community!</p></div></div></div></div></div>
<br><div class="gmail_quote">On Tue, Jul 7, 2015 at 2:56 PM, Aaron Seib <span dir="ltr"><<a href="javascript:_e(%7B%7D,'cvml','aaron.seib@nate-trust.org');" target="_blank">aaron.seib@nate-trust.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Thanks for starting this new thread.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I am not expert in this space (yet) but let me see if I can repeat back what I think you are proposing. <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Are you suggesting that for Resource Server (RS) be able to accept a standard profile authorization assertion (based on the UMA profile) from a standard (UMA-based) Authorization Server (AS)? <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I maybe out of date but I seem to remember reading that the UMA profile states that the Authorization Policy service capabilities (as required to implement an AS) are out of scope for the UMA profile - as are the specific policies for how you label assets (network, applications, data) managed by the RS with access tokens that are registered with and managed by the AS. <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">To echo back your language is your suggestion that </span><span style="font-size:14.0pt;font-family:"Cambria","serif";background:yellow">it</span><span style="font-size:14.0pt;font-family:"Cambria","serif""> ^would^ <span style="background:yellow">be simpler to have consistent patterns (libraries) implemented</span></span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> that would address what the UMA profile has intentionally said is out of scope? I.e., <u></u><u></u></span></p><p><u></u><span style="font-size:11.0pt;font-family:Symbol;color:#1f497d"><span>·<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">addressing the need for a standard way to label assets managed by the RS; and (?) <u></u><u></u></span></p><p><u></u><span style="font-size:11.0pt;font-family:Symbol;color:#1f497d"><span>·<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">a standard way to represent the inputs to an Authorization Policy Service<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">In my mind this would allow us to not only solve the simple cases but also enable us to develop libraries that represent the applicable policy of a given Federal Reg or libraries of applicable state law that could be re-used by everyone. It might also enable the different associations to provide recommended policies to be adopted by their members and plugged into the solution following a period of local policy tweaking by a given institution or Agency.<u></u><u></u></span></p><p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Am I getting this right?</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Aaron Seib, CEO<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">@CaptBlueButton <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> (o) <a href="tel:301-540-2311" value="+13015402311" target="_blank">301-540-2311</a><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">(m) <a href="tel:301-326-6843" value="+13013266843" target="_blank">301-326-6843</a><u></u><u></u></span></p><p class="MsoNormal"><a href="http://nate-trust.org" target="_blank"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d;text-decoration:none"><img border="0" width="205" height="48" src="cid:image001.jpg@01D0B8DE.515108A0"></span></a><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u><u></u></span></p></div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><div><div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in"><p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Openid-specs-heart [mailto:<a href="javascript:_e(%7B%7D,'cvml','openid-specs-heart-bounces@lists.openid.net');" target="_blank">openid-specs-heart-bounces@lists.openid.net</a>] <b>On Behalf Of </b>Kinsley, William<br><b>Sent:</b> Monday, July 06, 2015 8:45 PM<br><b>To:</b> <a href="javascript:_e(%7B%7D,'cvml','openid-specs-heart@lists.openid.net');" target="_blank">openid-specs-heart@lists.openid.net</a><br><b>Subject:</b> [Openid-specs-heart] Flip the question of “Vanilla" OAuth vs. UMA<u></u><u></u></span></p></div></div><div><div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria","serif"">I am starting a new thread … I think we need to flip the question of “Vanilla" OAuth vs. UMA”. I feel confident that we are going to discover use cases that cannot be supported by “Vanilla” OAuth or would be greatly simplified by using UMA. <u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria","serif""> <u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria","serif"">Maybe the real question to ask is: Are there any augments (use case, technology restriction, cost, etc.) that justifies NOT using (requiring) UMA?<u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria","serif""> <u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria","serif"">From a interoperability, quality, security and development perspective, would it be simpler to have consistent patterns (libraries) implemented that are more likely to be “drop-in compatible” without source changes. While the standard itself would be considered rigid, it would be flexible by the use and implementation of the UMA profiles. <u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria","serif""> <u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria","serif"">The caveat here is the resource server (RS) would need to be able to accept/process a UMA profile without developing custom code to interpret it. Would this require resource servers to adhere to a standard set of UMA profiles or a defined UMA profile taxonomy that could describe the healthcare consent models (if one exists)?<u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""> </span><span style="font-size:14.0pt;font-family:"Cambria","serif""><u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria","serif"">Bill<u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""> </span><span style="font-size:14.0pt;font-family:"Cambria","serif""><u></u><u></u></span></p></div><div style="margin-top:6.7pt;margin-bottom:6.7pt"><p class="MsoNormal"><span style="font-family:"Arial","sans-serif""> </span><span style="font-size:14.0pt;font-family:"Cambria","serif""><u></u><u></u></span></p></div><table border="0" cellspacing="3" cellpadding="0" width="1117" style="width:670.45pt;margin-left:5.4pt"><tbody><tr style="height:26.25pt"><td style="padding:.75pt .75pt .75pt .75pt;height:26.25pt"><p class="MsoNormal" align="right" style="margin-right:0in;margin-bottom:6.7pt;margin-left:0in;text-align:right"><span style="font-family:"Arial","sans-serif""> </span><u></u><u></u></p></td><td style="padding:.75pt .75pt .75pt .75pt;height:26.25pt"><p class="MsoNormal" align="right" style="margin-right:0in;margin-bottom:6.7pt;margin-left:0in;text-align:right"><span style="font-family:"Arial","sans-serif""><img border="0" width="181" height="50"></span><u></u><u></u></p></td></tr></tbody></table><p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria","serif""><u></u> <u></u></span></p><table border="0" cellspacing="3" cellpadding="0" width="1117" style="width:670.45pt;margin-left:5.4pt"><tbody><tr><td style="padding:.75pt 9.85pt .75pt 9.85pt"></td></tr></tbody></table><p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria","serif""><u></u> <u></u></span></p><table border="0" cellspacing="3" cellpadding="0" width="1117" style="width:670.45pt;margin-left:5.4pt"><tbody><tr><td style="padding:.75pt .75pt .75pt .75pt"><p class="MsoNormal" style="margin-right:0in;margin-bottom:6.7pt;margin-left:0in"><b><span style="font-size:10.0pt;font-family:"Calibri","sans-serif"">William Kinsley<br></span></b><span style="font-size:10.0pt;font-family:"Calibri","sans-serif"">Enterprise Architect, Ambulatory<u></u><u></u></span></p><div><p class="MsoNormal" style="margin-right:0in;margin-bottom:6.7pt;margin-left:0in"><b><span style="font-size:10.0pt;font-family:"Calibri","sans-serif"">NEXTGEN HEALTHCARE<br></span></b><span style="font-size:10.0pt;font-family:"Calibri","sans-serif"">Solutions for: Ambulatory, Inpatient and Community Connectivity<br>795 Horsham Road, Horsham, PA 19044<br><a href="tel:%28215%29%20657-7010%20x21128" value="+12156577010" target="_blank">(215) 657-7010 x21128</a> [o] <br><a href="javascript:_e(%7B%7D,'cvml','BKinsley@nextgen.com');" target="_blank">BKinsley@nextgen.com</a><u></u><u></u></span></p></div></td><td style="padding:.75pt .75pt .75pt .75pt"><p class="MsoNormal" style="margin-right:0in;margin-bottom:6.7pt;margin-left:0in"><span style="font-family:"Arial","sans-serif";color:blue"><a href="http://www.oneugm.com" target="_blank"><span style="text-decoration:none"><img border="0" width="248" height="92"></span></a></span><u></u><u></u></p></td></tr></tbody></table><div style="margin-top:6.7pt;margin-bottom:6.7pt"><p class="MsoNormal"><span style="font-family:"Arial","sans-serif""> </span><span style="font-size:14.0pt;font-family:"Cambria","serif""><u></u><u></u></span></p></div><table border="0" cellspacing="3" cellpadding="0" width="813" style="width:487.5pt;margin-left:5.4pt"><tbody><tr><td style="padding:.75pt .75pt .75pt .75pt"><p class="MsoNormal" style="margin-right:0in;margin-bottom:6.7pt;margin-left:0in"><b><i><span style="font-size:10.0pt;font-family:"Calibri","sans-serif";color:#e46c0a">Be ready for MU and ICD-10 in 2015. Start your EHR version 5.8 and KBM version 8.3 upgrade today. Get the resources you need at </span></i></b><span style="font-size:10.0pt;font-family:"Calibri","sans-serif";color:#e46c0a"><a href="http://www.nextgen.com/upgradecentral" target="_blank"><b><i><span style="color:#007cb9">www.nextgen.com/upgradecentral</span></i></b></a></span><u></u><u></u></p></td></tr></tbody></table><div style="margin-top:6.7pt;margin-bottom:6.7pt"><p class="MsoNormal"><span style="font-family:"Arial","sans-serif""> </span><span style="font-size:14.0pt;font-family:"Cambria","serif""><u></u><u></u></span></p></div><table border="0" cellspacing="3" cellpadding="0" width="820" style="width:492.0pt;margin-left:5.4pt"><tbody><tr><td style="padding:.75pt .75pt .75pt .75pt"><p class="MsoNormal" style="margin-right:0in;margin-bottom:6.7pt;margin-left:0in"><span style="font-size:6.0pt;font-family:"Arial","sans-serif"">This message, and any documents attached hereto, may contain confidential or proprietary information intended only for the use of the addressee(s) named above or may contain information that is legally privileged. If you are not the intended addressee, or the person responsible for delivering it to the intended addressee, you are hereby notified that reading, disseminating, distributing or copying this message is strictly prohibited. If you have received this message by mistake, please immediately notify us by replying to the message and delete the original message and any copies immediately thereafter. Thank you for your cooperation.</span><u></u><u></u></p></td></tr></tbody></table><div style="margin-top:6.7pt;margin-bottom:6.7pt"><p class="MsoNormal"><span style="font-family:"Arial","sans-serif""> </span><span style="font-size:14.0pt;font-family:"Cambria","serif""><u></u><u></u></span></p></div><div style="margin-top:6.7pt;margin-bottom:6.7pt"><p class="MsoNormal"><span style="font-family:"Arial","sans-serif""> </span><span style="font-size:14.0pt;font-family:"Cambria","serif""><u></u><u></u></span></p></div></div></div></div></div><br>_______________________________________________<br>
Openid-specs-heart mailing list<br>
<a href="javascript:_e(%7B%7D,'cvml','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" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><br>
<br></blockquote></div><br></div>
<br>_______________________________________________<br>
Openid-specs-heart mailing list<br>
<a href="javascript:;" onclick="_e(event, 'cvml', 'Openid-specs-heart@lists.openid.net')">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><br>
<br></blockquote></div><br><br>-- <br><div dir="ltr">Adrian Gropper MD<span style="font-size:11pt"></span><font size="1"><br><font size="2">Ensure Health Information Privacy. Support Patient Privacy Rights.<br></font></font><span style="font-size:11pt"><font size="1"></font></span><font size="2"><a href="http://patientprivacyrights.org/donate-2/" target="_blank"><font color="blue"><u>http://patientprivacyrights.org/donate-2/</u></font></a><font color="blue"><u> </u></font></font><span style="font-size:11pt"></span><span style="font-size:11pt"></span><span style="font-size:11pt"><font size="1"> <br></font><div></div></span><br></div><br>