<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'>In line below..<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:image002.jpg@01D1472F.E9567F10"></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> Monday, January 04, 2016 6:26 PM<br><b>To:</b> Aaron Seib<br><b>Cc:</b> openid-specs-heart@lists.openid.net<br><b>Subject:</b> Re: [Openid-specs-heart] Sum it up<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'>Yes.<o:p></o:p></p></div><p class=MsoNormal style='margin-bottom:12.0pt'>My point was not just about data blocking but also about governance of Authorization Servers. I made several points:<o:p></o:p></p></div><p class=MsoNormal style='margin-bottom:12.0pt'>1 - Federal laws place constraints on Authorization Servers that are not directly controlled by one patient<span style='color:#1F497D'> (Another way to put this might be to say that the Federal laws were written with the intent of protecting the patient who otherwise didn’t have a way of communicating their preferences – this approach resulted in a per force conservative set of laws that have had the unintended consequence that we are experiencing today - where patients may want to have their information shared but those who are regulated feeling like they are liable for something if they don’t follow the letter of the law)</span>. Therefore, many consent management problems can be solved by simply allowing patients that care to specify and control their own Authorization Server<span style='color:#1F497D'> (Yes! This is what I have been saying but I wouldn’t have used the misnomer consent nor referenced a specific technology like Authorization servers)</span>. This is easily handled by UMA and OAuth as long as the (FHIR) Resource pertains to just one patient. It's obviously impossible for bulk or other Resources that pertain to more than one patient. I believe this consent management problem was the essence of the use-case you raised and that the HEART profiles can easily solve it.<span style='color:#1F497D'> Which brings us back to the debate in December. Was that ever finalized? I think there are or at least may be intra-enterprise use cases where the Consumer’s AS is not involved and the Regulated entity could leverage a Bulk Permission Type. I am thinking about the facility where the EMR has both specially protected data and other PHI. For some of the internal users you may allow not them to access specially protected data but you have some internal users (from the behavioral health unit) that may be authorized to access the specially protected data to. But as I think about the charter I am not so sure this case is in scope of HEART given no consumer is involved? is that accurate?</span><o:p></o:p></p></div><p class=MsoNormal style='margin-bottom:12.0pt'>2 - HEART, UMA, and OAuth do not need to concern themselves with "other" Authorization Servers operated by the Hospital. These are internal to the institution. Since the institution also has the patient's data, the institution always has the last word on its release. The Hospital can always bypass the HEART Authorization Server and can always transfer information by other means. For all HEART, UMA, and OAuth purposes a Resource has only one Authorization Server.<span style='color:#1F497D'> By God – I think I am still in agreement with you. You are essentially answer the question I had when I finished reading the last sentence, right?</span><o:p></o:p></p></div><p class=MsoNormal style='margin-bottom:12.0pt'>3 - It's very important that HEART not constrain what John called the "ethics" of health information blocking such as 72 hour delays for data sharing<span style='color:#1F497D'> (can anyone provide a reference for this topic? I am not getting it from the fragments shared so far – there is an ethical argument to not disclose for three days? We will serve no wine before its time?)</span>. Policies regarding this kind of block are beyond our purview<span style='color:#1F497D'> (you can all share your inputs with the API TF of course!)</span>. What HEART profiles need to do is to allow the Hospital to verify attributes of the Requesting Party if they are inclined to do such verification<span style='color:#1F497D'> (I don’t follow – do you mean if they are inclined to do so before the 72 hours? </span>. That way, Alice's Authorization Server can say: Send One Data Object to Bob and Bob claims he's a Licensed Practitioner in MA. The Hospital would have the option of either verifying that Bob is a licensed MD or not (the 72 hour block is nor required by law<span style='color:#1F497D'>???</span>). If they chose to impose the block, the Hospital would need to make a good faith effort to determine Bob's license status. I think this kind of "trust elevation" may be out of band for UMA, but I'm not sure.<o:p></o:p></p></div><p class=MsoNormal>So to summarize, HEART needs to (1) allow patients to specify a personal AS to avoid blocks on sensitive information, (2) focus on resources that pertain to a single patient to allow (1), and (3) enable direct transfer of resources to Requesting Parties that are able to provide verified attributes to the Resource Server to avoid blocking for "ethical" reasons when such blocking would be unwarranted.<o:p></o:p></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'>I am in agreement up to topic #3 – probably need to get a better understanding.<o:p></o:p></span></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal>Adrian<o:p></o:p></p><div><div><div><div><p class=MsoNormal style='margin-bottom:12.0pt'><o:p> </o:p></p></div></div></div></div></div><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On Mon, Jan 4, 2016 at 5:26 PM, Aaron Seib <<a href="mailto:aaron.seib@23eleven.net" target="_blank">aaron.seib@23eleven.net</a>> wrote:<o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Adrian,<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>You had a specific point that I wanted t make sure I could refine and restate accurately.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>I wish I had a handle on the jargon used but maybe you can help me get there.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'>There is a Data Provider. For illustrative purposes let’s say a Hospital (I am learning that in some scenarios the Consumer is a Data Provider where the data is PGHD so I am learning). <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'>Let’s keep it simple and say that there is One Data Object that this Data Provider wants to make sharing decisions about but there are two Authorization Servers one of which is controlled by the Consumer and the other is not.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'>For arguments sake let’s say that the AS controlled by Alice is has been configured to properly convey that it is her preference that whenever Hospital is going to make a disclosure to another Provider for Treatment purposes that the Hospital share One Data Object.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'>Let’s say that the Hospital also operates an AS that it uses to make disclosure decisions. It is based on a Law that says “Thou shall not disclose One Data Object without consumer consent”.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Is the bottom line that if the Hospital does not disclose One Data Object to another Provider in accordance with the consumers wishes that they are in fact knowingly participating in information blocking if they know that the Consumer has an AS of their own?<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Aaron Seib<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Principal, 2311<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>(o) <a href="tel:301-540-2311" target="_blank">301-540-2311</a><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>(m) <a href="tel:301-326-6843" target="_blank">301-326-6843</a><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div></div></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 class=MsoNormal align=center style='text-align:center'><hr size=1 width="100%" noshade style='color:#A0A0A0' align=center></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>No virus found in this message.<br>Checked by AVG - <a href="http://www.avg.com">www.avg.com</a><br>Version: 2016.0.7294 / Virus Database: 4489/11319 - Release Date: 01/04/16<o:p></o:p></p></div></body></html>