<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 14 (filtered medium)"><!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@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.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.EmailStyle17
        {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-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:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I am missing something.  <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>FHIR is a layer of abstraction from the actual way the data is stored by the RS.  A resource set is a view of that abstraction layer.  I am not sure I see a burden if it is done correctly.  That has been one of the reported benefits of using FHIR – the ability to get only the data you need for the use case your consumer wants to solve.  The notion of minimum necessary.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>What am I missing.  Either I was sold on hype that hasn’t materialized yet or I don’t understand the question.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Toward the end you say that HEART can certainly profile subsets of FHIR.  Are you just indicating a preference to have the views being created by the HEART side of the equation?  Doesn’t that extinguish the minimum necessary benefits that FHIR could support?  <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Aaron Seib, CEO<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>@CaptBlueButton <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> (o) 301-540-2311<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>(m) 301-326-6843<o:p></o:p></span></p><p class=MsoNormal><a href="nate-trust.org"><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;text-decoration:none'><img border=0 width=205 height=48 id="Picture_x0020_1" src="cid:image001.jpg@01D1ECB5.164129A0"></span></a><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><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:openid-specs-heart-bounces@lists.openid.net] <b>On Behalf Of </b>Adrian Gropper<br><b>Sent:</b> Tuesday, August 02, 2016 11:47 AM<br><b>To:</b> Debbie Bucci<br><b>Cc:</b> openid-specs-heart@lists.openid.net<br><b>Subject:</b> Re: [Openid-specs-heart] Alice's health resource set<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><div><div><div><div><div><div><div><p class=MsoNormal style='margin-bottom:12.0pt'>Debbie,<o:p></o:p></p></div><p class=MsoNormal style='margin-bottom:12.0pt'>It's very important for both HEART and the UMA folks to be clear about this. <o:p></o:p></p></div><p class=MsoNormal style='margin-bottom:12.0pt'>I don't want either UMA or HEART to create any "burden" on the RS unless there's a clear problem we're fixing. Sticking as close to FHIR as possible seems to be a way that we can avoid an extra burden on the RS. It places the burden of capturing and interpreting Alice's policies entirely on the authorization server. The RS could make Alice's AS job much easier by supporting Confidentiality Codes and other metadata as part of the scope process but that would certainly be an added burden on the RS and should be optional.<o:p></o:p></p></div><p class=MsoNormal style='margin-bottom:12.0pt'>Introducing a HEART profile for some particular resource set that is not just plain FHIR seems to me to be a clear burden to the RS. Now they will have two overlapping standards to coordinate: FHIR and HEART, both talking about resources. Interoperability will also suffer because the rule is "be strict in what you offer and liberal in what you accept". A health RS strictly has to offer FHIR for all sorts of reasons including apps like SMART and participation in vendor networks like CommonWell, and directed exchange for the Precision Medicine Initiative.<o:p></o:p></p></div><p class=MsoNormal style='margin-bottom:12.0pt'>For the other side of interoperability, the HEART RS must be liberal in what kinds of AS it accepts in order to make patient-directed exchange with HIPAA, non-HIPAA, 42CFR, Things, decision support, and all other clients willing to play by FHIR rules interoperable.<o:p></o:p></p></div><p class=MsoNormal style='margin-bottom:12.0pt'>From the AS perspective, HEART can certainly profile subsets of FHIR, DAF, OpenID Connect, WebFinger, and other standards in order to improve the user experience but these would be optional to any particular RS and would not limit interoperability. <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 Tue, Aug 2, 2016 at 10:52 AM, Debbie Bucci <<a href="mailto:debbucci@gmail.com" target="_blank">debbucci@gmail.com</a>> wrote:<o:p></o:p></p><div><div><p class=MsoNormal>Resource Set  - what purpose it might serve. <o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Mind you - I don't know the thinking behind the UMA spec - but In the federated authentication environment when you are dealing with hundreds if not thousands for partners, a methods to group claims together has evolved to help ease the burden on the backend  for those having to configure release policies for each and every partner.   The ability for a RS to define resource sets that makes sense for their business - may have a similar effect.<o:p></o:p></p></div><div><div><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><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><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">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><p class=MsoNormal><br><br clear=all><br>-- <o:p></o:p></p><div><div><div><div><div><div><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>Adrian Gropper MD<br><br><span style='font-family:"Arial","sans-serif";color:#1F497D'>PROTECT YOUR FUTURE - RESTORE Health Privacy!<br>HELP us fight for the right to control personal health data.<br>DONATE: <a href="http://patientprivacyrights.org/donate-2/" target="_blank"><span style='color:#0563C1'>http://patientprivacyrights.org/donate-2/</span></a></span> <o:p></o:p></p></div></div></div></div></div></div></div></div></div></div></body></html>