<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]--><![if !supportAnnotations]>
<style id="dynCom" type="text/css"><!-- --></style>
<script language="JavaScript"><!--
function msoCommentShow(anchor_id, com_id)
{
if(msoBrowserCheck())
{
c = document.all(com_id);
a = document.all(anchor_id);
if (null != c && null == c.length && null != a && null == a.length)
{
var cw = c.offsetWidth;
var ch = c.offsetHeight;
var aw = a.offsetWidth;
var ah = a.offsetHeight;
var x = a.offsetLeft;
var y = a.offsetTop;
var el = a;
while (el.tagName != "BODY")
{
el = el.offsetParent;
x = x + el.offsetLeft;
y = y + el.offsetTop;
}
var bw = document.body.clientWidth;
var bh = document.body.clientHeight;
var bsl = document.body.scrollLeft;
var bst = document.body.scrollTop;
if (x + cw + ah / 2 > bw + bsl && x + aw - ah / 2 - cw >= bsl )
{ c.style.left = x + aw - ah / 2 - cw; }
else
{ c.style.left = x + ah / 2; }
if (y + ch + ah / 2 > bh + bst && y + ah / 2 - ch >= bst )
{ c.style.top = y + ah / 2 - ch; }
else
{ c.style.top = y + ah / 2; }
c.style.visibility = "visible";
} } }
function msoCommentHide(com_id)
{
if(msoBrowserCheck())
{
c = document.all(com_id);
if (null != c && null == c.length)
{
c.style.visibility = "hidden";
c.style.left = -1000;
c.style.top = -1000;
} }
}
function msoBrowserCheck()
{
ms = navigator.appVersion.indexOf("MSIE");
vers = navigator.appVersion.substring(ms + 5, ms + 6);
ie4 = (ms > 0) && (parseInt(vers) >= 4);
return ie4;
}
if (msoBrowserCheck())
{
document.styleSheets.dynCom.addRule(".msocomanchor","background: infobackground");
document.styleSheets.dynCom.addRule(".msocomoff","display: none");
document.styleSheets.dynCom.addRule(".msocomtxt","visibility: hidden");
document.styleSheets.dynCom.addRule(".msocomtxt","position: absolute");
document.styleSheets.dynCom.addRule(".msocomtxt","top: -1000");
document.styleSheets.dynCom.addRule(".msocomtxt","left: -1000");
document.styleSheets.dynCom.addRule(".msocomtxt","width: 33%");
document.styleSheets.dynCom.addRule(".msocomtxt","background: infobackground");
document.styleSheets.dynCom.addRule(".msocomtxt","color: infotext");
document.styleSheets.dynCom.addRule(".msocomtxt","border-top: 1pt solid threedlightshadow");
document.styleSheets.dynCom.addRule(".msocomtxt","border-right: 2pt solid threedshadow");
document.styleSheets.dynCom.addRule(".msocomtxt","border-bottom: 2pt solid threedshadow");
document.styleSheets.dynCom.addRule(".msocomtxt","border-left: 1pt solid threedlightshadow");
document.styleSheets.dynCom.addRule(".msocomtxt","padding: 3pt 3pt 3pt 3pt");
document.styleSheets.dynCom.addRule(".msocomtxt","z-index: 100");
}
// --></script>
<![endif]><style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@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: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";}
p.MsoCommentText, li.MsoCommentText, div.MsoCommentText
{mso-style-priority:99;
mso-style-link:"Comment Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Times New Roman","serif";}
span.MsoCommentReference
{mso-style-priority:99;}
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";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.CommentTextChar
{mso-style-name:"Comment Text Char";
mso-style-priority:99;
mso-style-link:"Comment Text";
font-family:"Times New Roman","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;}
/* List Definitions */
@list l0
{mso-list-id:955671623;
mso-list-type:hybrid;
mso-list-template-ids:-1878989098 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
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]--></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'>Good.<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'>Before I jump into responding to your summary I think it would be helpful to unpack the statement you make about the other important aspect of HIPAA that is relevant.<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'>Below, where you say:<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=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='font-family:Symbol'><span style='mso-list:Ignore'>·<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]>“when a HIPAA Covered Entity (e.g. typical EHR) has an electronic means for sharing data available, it MUST offer that method to the patient as well. This means that if FHIR is used for sharing data under TPO, regardless of what the NPP say or don't say, Alice has a HIPAA right to request her data on FHIR.”<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I think this is in the right vein but is imprecise and if we are going to make any progress we have to be more precise – if those on this thread are having a hard time parsing what is said we can be sure external stakeholders think we are talking gibberish.</span><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'>This ascertain “When a HIPAA Covered Entity (CE) has an electronic means of sharing data it must offer that method to the patient as well.” is a reasonable sound bite but I think since some of the folks that are part of this work group are relatively healthcare neophytes and it would be valuable to unpack that a bit because there are two qualifiers under HIPAA for covered entities..<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'>The two qualifiers that apply from HIPAA are “readily producible” and the notion that the discloser is not required to do anything that would expose their system to additional risk. We shouldn’t gloss over these pre-conditions because I think it will only result in heart-ache and disappointment for those who set their expectations on the notion that ‘if they can do it with providers they should be able to do it with consumers’. I agree that this is the intuitive expectation but there is enough wiggle room in the preconditions to pass a container ship through and if we are serious about making progress we need to figure out how to address or constrain the qualifiers IMHO.<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'>If our work doesn’t address what it means for a consumer facing disclosure to be readily producible in a way that does not expose the RS to new security risks we will be creating a false expectation on the part of the families that are depending on us to get this right – so for me I feel we have a responsibility to speak to it.<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'>Adrian – I am not trying to say that you meant to side step these qualifiers in any way – but I think it is important for us to document them somewhere as part of the preconditions that need to be true before we create inaccurate expectations. Like the policy related issues that Oliver was bringing to the table yesterday – I think it is important for a technical only solution to point out these “policy” constraints so that we don’t fool ourselves into thinking we solved the problem of patient access without actually solving anything.<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'>This is the way that I simplify it so that I can keep it straight. I welcome everyones feedback.<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'>I believe that in the real world the API’s that will be exposed to extra-enterprise users (other providers, consumers and the apps that either give authority to act on their behalf) are going to be striated by the type of user accessing them. I believe this is true because the applicable law differs based on whether the API is being used by a Covered Entity or a Patient or by Joe’s Credit Worthiness algorythm or what have you. I may have an API that I expose that allows a provider to use an API that provides all the clincal data I have for a patient based on a partial match search criteria. Because I know that theprovider is also covered by HIPAA and should have a policy about what they do when they see PHI for someone they shouldn’t I may feel that the risk is tenable (this is what RLS based HIE relies on in some ways). I can’t expose this same API to a patient\consumer because I have an obligation to prevent non-professionals from inadvertently (allegedly) seeing the data of others. <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'>I am not trying to be a nay-sayer – I just think it is important that we don’t gloss over these facts of life before we have documented them and – as John M. said earlier last week clearly delineated what is in scope and what is out.<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'>Before an API that exposes FHIR Resources (and possibly resource sets or scopes of same such as ‘Immunization’) to a consumer they need to have some reason to believe that the remote system accessing the API has a right to see the PHI of the subject of the PHI that is being disclosed.<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'>In the Direct world we rely on the face-to-face encounter of the consumer and the Provider to associate consumer’s Direct Address with the right medical records held by the Provider. For the API task force we made reference to the use of the patient portal and its authentication of the remote user (conditioned on there being an encounter between the Family Caregiver or Patient first) to allow access to the appropriate PHI for the person who authenticated into the portal. There is still some <b>magic</b> that we assume exist that allows the consumer’s chosen Client to receive a token from the EMR before we even start talking about the rest of the workflow and perhaps that is a gap we can address but I don’t know if anyone has gottent to the point of actually doing this yet – does anyone know? Does SMART or the Argonauts have a solution for this already or are we all relying on the same magic to occur?<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'>I think it is at this point – after the consumer has authenticated into the Patient Portal of the EMR – that you could realistically start to talk about binding a consumers chosen AS to the data held by a CE. Just like we have proposed for allowing a user to supply their Direct Address I assume that a widget on the portal could be provided that allowed the patient to navigate to the URL for their chosen AS – is that true? Let me assume that this is how the RS can find out what the consumer’s prefered AS is for the sake of getting my head around this. There may be equivalents that emerge in the future but I think this is probably the shortest path to getting things off the ground and running in the current eco-system. (If a user doesn’t provide a preferred AS the Provider would be expected to comply with applicable law and where law allows them to decide their local policy decisions).<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'>At least for me I have to picture a realistic path to getting to your bulleted list below before I can respond in line as follows…<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 style='margin-left:.5in'>a) <a style='mso-comment-reference:AS_1;mso-comment-date:20160803T1033'>All resources </a><span class=MsoCommentReference><span style='font-size:8.0pt'><![if !supportAnnotations]><a class=msocomanchor id="_anchor_1" onmouseover="msoCommentShow('_anchor_1','_com_1')" onmouseout="msoCommentHide('_com_1')" href="#_msocom_1" language=JavaScript name="_msoanchor_1">[AS1]</a><![endif]> </span></span>available as FHIR resources MUST also be provided for registration with a HEART resource server even if the RS decides to bypass the AS or override the AS authorization. <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in'> a1) The HIPAA CE can choose to notify the patient as to whether they bypass or override in the NPP <a style='mso-comment-reference:AS_2;mso-comment-date:20160803T1033'>but it makes only a slight difference</a><span class=MsoCommentReference><span style='font-size:8.0pt'><![if !supportAnnotations]><a class=msocomanchor id="_anchor_2" onmouseover="msoCommentShow('_anchor_2','_com_2')" onmouseout="msoCommentHide('_com_2')" href="#_msocom_2" language=JavaScript name="_msoanchor_2">[AS2]</a><![endif]> </span></span>.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in'>b) HIPAA has a data minimization requirement for some transactions that don't strictly require patient authorization so HEART MAY want to consider how data minimization would be handled using scopes in the cases where an RS is using a HEART AS for all sharing. <br> b1) <a style='mso-comment-reference:AS_3;mso-comment-date:20160803T1033'>In theory, a HIPAA CE could register two paths to the patient's resources with two separate HEART ASs. One AS would bypass the patient-specified AS for Clients that were not subject to patient authorization. The other AS would be specified by the patient. Maybe this is the kind of thing Justin has in mind when he talks of an RS buying an AS from a separate vendor.</a><span class=MsoCommentReference><span style='font-size:8.0pt'><![if !supportAnnotations]><a class=msocomanchor id="_anchor_3" onmouseover="msoCommentShow('_anchor_3','_com_3')" onmouseout="msoCommentHide('_com_3')" href="#_msocom_3" language=JavaScript name="_msoanchor_3">[AS3]</a><![endif]> </span></span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in'>c) Any resource server, HIPAA covered or not, MAY choose to register sets of resources in order to improve the user experience at the AS. These resources may or may not all be specified by FHIR. These bundling and definition of these resource sets may be done by HEART or by standards organizations like the HL7 DAF. (Debbie says that HEART must use only accepted standards so it seems to me that HEART getting <a style='mso-comment-reference:AS_4;mso-comment-date:20160803T1033'>into the resource bundling business is a bit of a slippery slope</a><span class=MsoCommentReference><span style='font-size:8.0pt'><![if !supportAnnotations]><a class=msocomanchor id="_anchor_4" onmouseover="msoCommentShow('_anchor_4','_com_4')" onmouseout="msoCommentHide('_com_4')" href="#_msocom_4" language=JavaScript name="_msoanchor_4">[AS4]</a><![endif]> </span></span><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I may be wasting my breath but I am concerned that the real nay-sayers in the eco-system are well supported when they say what we are talking about is unintelligible to them.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I could be completely off base and all of these assumptions are documented and I need to do more homework but I am feeling beat up trying to assert that there is some there there when doubters ask me about HEART.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>If I am alone I will remove myself from the list serve and you guys can continue in peace without me.<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@01D1ED6C.0C26B810" alt="cid:image001.jpg@01D10761.5BE2FE00"></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"'> agropper@gmail.com [mailto:agropper@gmail.com] <b>On Behalf Of </b>Adrian Gropper<br><b>Sent:</b> Wednesday, August 3, 2016 9:35 AM<br><b>To:</b> Aaron Seib, NATE<br><b>Cc:</b> Maxwell, Jeremy (OS/OCPO); 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'>Aaron,<o:p></o:p></p></div><p class=MsoNormal style='margin-bottom:12.0pt'>I think you are accurately describing HIPAA and that should allow us to re-center this thread on the core subject of Alice's resources. <o:p></o:p></p></div><p class=MsoNormal style='margin-bottom:12.0pt'>The key point for this thread is that HEART needs to enable patient-directed exchange for the full set of FHIR resources with other subsets as options. The reasons for this include the fact that some providers will choose to differentiate themselves by giving the patient a voice in sharing for Treatment, Payment, and Operations even though HIPAA does not force them to do so.<o:p></o:p></p></div><div><p class=MsoNormal>The other important aspect of HIPAA that has not been discussed yet is that when a HIPAA Covered Entity (e.g. typical EHR) has an electronic means for sharing data available, it MUST offer that method to the patient as well. This means that if FHIR is used for sharing data under TPO, regardless of what the NPP say or don't say, Alice has a HIPAA right to request her data on FHIR.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal style='margin-bottom:12.0pt'>Here's my summary of the discussion AND HIPAA as far as HEART is concerned:<o:p></o:p></p></div><p class=MsoNormal>a) All resources available as FHIR resources MUST also be provided for registration with a HEART resource server even if the RS decides to bypass the AS or override the AS authorization. <o:p></o:p></p></div><p class=MsoNormal style='margin-bottom:12.0pt'> a1) The HIPAA CE can choose to notify the patient as to whether they bypass or override in the NPP but it makes only a slight difference.<o:p></o:p></p></div><div><p class=MsoNormal style='margin-bottom:12.0pt'>b) HIPAA has a data minimization requirement for some transactions that don't strictly require patient authorization so HEART MAY want to consider how data minimization would be handled using scopes in the cases where an RS is using a HEART AS for all sharing. <br> b1) In theory, a HIPAA CE could register two paths to the patient's resources with two separate HEART ASs. One AS would bypass the patient-specified AS for Clients that were not subject to patient authorization. The other AS would be specified by the patient. Maybe this is the kind of thing Justin has in mind when he talks of an RS buying an AS from a separate vendor.<o:p></o:p></p></div><div><p class=MsoNormal style='margin-bottom:12.0pt'>c) Any resource server, HIPAA covered or not, MAY choose to register sets of resources in order to improve the user experience at the AS. These resources may or may not all be specified by FHIR. These bundling and definition of these resource sets may be done by HEART or by standards organizations like the HL7 DAF. (Debbie says that HEART must use only accepted standards so it seems to me that HEART getting into the resource bundling business is a bit of a slippery slope.)<o:p></o:p></p></div><div><p class=MsoNormal>A MUST and two MAYs. Can we move on to discussing scopes in this context now?<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Adrian<o:p></o:p></p></div><div><div><div><div><p class=MsoNormal><o:p> </o:p></p></div></div></div></div></div><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On Wed, Aug 3, 2016 at 7:48 AM, Aaron Seib, NATE <<a href="mailto:aaron.seib@nate-trust.org" target="_blank">aaron.seib@nate-trust.org</a>> wrote:<o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Regardless of how it makes me feel – my question earlier is how do we actually address it.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I think the NPP is one way for providers to convey that they will or won’t acknowledge what your Privacy Preferences are – indicated via a AS.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Does anyone disagree with that? </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>There are providers that will argue that they have an ethical responsibility to share with other doctors that may treat you.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>My question comes down to – is a provider obligated to share for Treatment purposes or is it just that they are permitted to despite a patient like Adrian’s preferences.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Anyone have an authoritative answer?</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Aaron Seib, CEO</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>@CaptBlueButton </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> (o) <a href="tel:301-540-2311" target="_blank">301-540-2311</a></span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>(m) <a href="tel:301-326-6843" target="_blank">301-326-6843</a></span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><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 id="_x0000_i1025" src="cid:image001.jpg@01D1ED6C.0C26B810" alt="cid:image001.jpg@01D10761.5BE2FE00"></span></a><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><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="mailto:openid-specs-heart-bounces@lists.openid.net" target="_blank">openid-specs-heart-bounces@lists.openid.net</a>] <b>On Behalf Of </b>Adrian Gropper<br><b>Sent:</b> Tuesday, August 2, 2016 5:27 PM<br><b>To:</b> Maxwell, Jeremy (OS/OCPO)<br><b>Cc:</b> <a href="mailto:openid-specs-heart@lists.openid.net" target="_blank">openid-specs-heart@lists.openid.net</a></span><o:p></o:p></p><div><div><p class=MsoNormal><br><b>Subject:</b> Re: [Openid-specs-heart] Alice's health resource set<o:p></o:p></p></div></div><div><div><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 style='mso-margin-top-alt:auto;margin-bottom:12.0pt'>If an organization wants to be nice to their patients and also reduce the scope of data breaches they would notify patients when their data was shared the way my bank and Apple do when they use my data in a third-party context. We can hope that FHIR and HEART become so much standard practice that every respectful organization adopts the Society for Participatory Medicine motto: "Nothing about me without me." <o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'>The "consent for TPO" you seem to be describing however is just another contract of adhesion that gives no meaningful choice to the patient at all. I, for one, am insulted when presented by such a thing and I've never met any patient that appreciates it.<o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Adrian<o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'> <o:p></o:p></p></div></div></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>On Tue, Aug 2, 2016 at 5:12 PM, Maxwell, Jeremy (OS/OCPO) <<a href="mailto:Jeremy.Maxwell@hhs.gov" target="_blank">Jeremy.Maxwell@hhs.gov</a>> wrote:<o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Not sure I follow. HIPAA does not require consent for TPO—it is a permitted use. An organization may still choose to collect consent for TPO, either because of their own organizational policy or because another law requires it. But this is not “HIPAA TPO consent.” In ONC parlance, we call this “basic choice for TPO” in both our Interoperability Roadmap as well as our Patient Choice Technical Project. Of course others may call this by a different term, but calling it a “HIPAA TPO consent” is imprecise and can perpetuate existing misunderstandings about what HIPAA actually requires.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><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"'> <a href="mailto:agropper@gmail.com" target="_blank">agropper@gmail.com</a> [mailto:<a href="mailto:agropper@gmail.com" target="_blank">agropper@gmail.com</a>] <b>On Behalf Of </b>Adrian Gropper<br><b>Sent:</b> Tuesday, August 02, 2016 5:01 PM<br><b>To:</b> Maxwell, Jeremy (OS/OCPO)<br><b>Cc:</b> Debbie Bucci; <a href="mailto:openid-specs-heart@lists.openid.net" target="_blank">openid-specs-heart@lists.openid.net</a><br><b>Subject:</b> Re: [Openid-specs-heart] Alice's health resource set</span><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 style='mso-margin-top-alt:auto;margin-bottom:12.0pt'>Jeremy, <br><br>Sorry, I should have said HIPAA TPO "consent".<o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'>If access to the FHIR resources does not require Alice's authorization and the RS wants to keep Alice in the dark because HIPAA's accounting of disclosures is seldom implemented as well, then HEART is not involved. I would not call the TPO loophole consent except sarcastically.<o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Adrian<o:p></o:p></p><div><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>On Tue, Aug 2, 2016 at 2:22 PM, Maxwell, Jeremy (OS/OCPO) <<a href="mailto:Jeremy.Maxwell@hhs.gov" target="_blank">Jeremy.Maxwell@hhs.gov</a>> wrote:<o:p></o:p></p><div><div><p><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Also, want to clarify what “typical of HIPAA TPO consent” means? TPO is a permitted use under HIPAA that does not require consent.</span><o:p></o:p></p><p><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p><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="mailto:openid-specs-heart-bounces@lists.openid.net" target="_blank">openid-specs-heart-bounces@lists.openid.net</a>] <b>On Behalf Of </b>Debbie Bucci<br><b>Sent:</b> Tuesday, August 02, 2016 2:17 PM<br><b>To:</b> Adrian Gropper<br><b>Cc:</b> <a href="mailto:openid-specs-heart@lists.openid.net" target="_blank">openid-specs-heart@lists.openid.net</a><br><b>Subject:</b> Re: [Openid-specs-heart] Alice's health resource set</span><o:p></o:p></p><p> <o:p></o:p></p><div><div><p>Lost me again Adrian - <o:p></o:p></p></div><div><div><div><div><p> <o:p></o:p></p></div></div><blockquote style='margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'><div><p>We should also not ignore the Client-to-AS first flow. This is the preferred flow from a privacy engineering perspective. (see other thread with Justin). In the majority of cases of HIE, the Client has a relationship with Alice already (<span style='background:yellow'>this is typical of HIPAA TPO consent</span>) or the Client has found Alice via a "Relationship Locator Service" which is a directory operated by the state or some private entity like CommonWell. When the Client matches with Alice in the RLS, does the RLS return a list of RSs or a pointer to Alice's AS?<o:p></o:p></p></div><div><div><p> <o:p></o:p></p></div></div><div><p>The most privacy-preserving thing would be for RLSs to return pointers to Alice's AS and in the future this is what Alice might insist on if she is still given a choice to opt-in or opt-out of HIE. Alice does have that choice today in the US. In other countries, not-so-much.<o:p></o:p></p></div></blockquote><div><p> <o:p></o:p></p></div><div><p> Are you suggesting the AS is some sort of proxy for all data - I don't think you were saying that. At some point the Client would need a relationship with the RS as well - correct? Is the Client to AS flow a separate spec? Would you please provide the link? Looking at UMA 1.01 - client needs a permission ticket first - that is generated from AS - to RS to client (?)<o:p></o:p></p></div><div><p> <o:p></o:p></p></div><div><div><p> <o:p></o:p></p></div></div><div><p> <o:p></o:p></p></div><div><div><p> <o:p></o:p></p></div></div></div></div></div></div></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><br><br clear=all><br>-- <o:p></o:p></p><div><div><div><div><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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></div></div></div></div></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><br><br clear=all><br>-- <o:p></o:p></p><div><div><div><div><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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></div></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><div style='mso-element:comment-list'><![if !supportAnnotations]><hr class=msocomoff align=left size=1 width="33%"><![endif]><div style='mso-element:comment'><![if !supportAnnotations]><div id="_com_1" class=msocomtxt language=JavaScript onmouseover="msoCommentShow('_anchor_1','_com_1')" onmouseout="msoCommentHide('_com_1')"><![endif]><span style='mso-comment-author:"Aaron Seib"'><![if !supportAnnotations]><a name="_msocom_1"></a><![endif]></span><p class=MsoCommentText><span class=MsoCommentReference><span style='font-size:8.0pt'> <![if !supportAnnotations]><a href="#_msoanchor_1" class=msocomoff>[AS1]</a><![endif]></span></span>This is inaccurate. There may well be FHIR resources that describe the availability of a hospital asset (lets’ say an Operating Room) one day. An API that can access a resource that knows when an OR is in use is very useful to the Enterprise users but there is no reason that this should be shared with a Consumer. <o:p></o:p></p><p class=MsoCommentText><o:p> </o:p></p><p class=MsoCommentText>I think you have to qualify what you are saying here to be All resources that are specific to the consumer’s care – I think HIPAA has a term for it – something like the Common Data Set. <o:p></o:p></p><p class=MsoCommentText><o:p> </o:p></p><p class=MsoCommentText>Being inaccurate here will just degrade the audiences ability to know what we are really saying here.<o:p></o:p></p><p class=MsoCommentText><o:p> </o:p></p><p class=MsoCommentText>The RS would be able to decide if they need to check the AS based on whether or not the resource set had data that was part of the Common Data Set (if they were committed to supporting the patient’s preferences).<o:p></o:p></p><![if !supportAnnotations]></div><![endif]></div><div style='mso-element:comment'><![if !supportAnnotations]><div id="_com_2" class=msocomtxt language=JavaScript onmouseover="msoCommentShow('_anchor_2','_com_2')" onmouseout="msoCommentHide('_com_2')"><![endif]><span style='mso-comment-author:"Aaron Seib"'><![if !supportAnnotations]><a name="_msocom_2"></a><![endif]></span><p class=MsoCommentText><span class=MsoCommentReference><span style='font-size:8.0pt'> <![if !supportAnnotations]><a href="#_msoanchor_2" class=msocomoff>[AS2]</a><![endif]>T</span></span>hese kind of qualitative subjective opinions will only frustrate the audience. It may be slight to you but it may be mission critical so some Foster Parents who need to explain to the state why their ward’s private health information was still shared even though the Judge ordered them to take steps necessary to ensure that it wasn’t.<o:p></o:p></p><![if !supportAnnotations]></div><![endif]></div><div style='mso-element:comment'><![if !supportAnnotations]><div id="_com_3" class=msocomtxt language=JavaScript onmouseover="msoCommentShow('_anchor_3','_com_3')" onmouseout="msoCommentHide('_com_3')"><![endif]><span style='mso-comment-author:"Aaron Seib"'><![if !supportAnnotations]><a name="_msocom_3"></a><![endif]></span><p class=MsoCommentText><span class=MsoCommentReference><span style='font-size:8.0pt'> <![if !supportAnnotations]><a href="#_msoanchor_3" class=msocomoff>[AS3]</a><![endif]></span></span>I think this is a horrible idea. I think there are better ways to handle policy enforcement when the Client isn’t subject to the AS.<o:p></o:p></p><p class=MsoCommentText><o:p> </o:p></p><p class=MsoCommentText>Ken Salyard’s work comes to mind. I think trying to do it this way is possible but it seems like we are treating every Policy Enforcement need like it is a nail. Sometimes a Philips Head is what you should really be using.<o:p></o:p></p><![if !supportAnnotations]></div><![endif]></div><div style='mso-element:comment'><![if !supportAnnotations]><div id="_com_4" class=msocomtxt language=JavaScript onmouseover="msoCommentShow('_anchor_4','_com_4')" onmouseout="msoCommentHide('_com_4')"><![endif]><span style='mso-comment-author:"Aaron Seib"'><![if !supportAnnotations]><a name="_msocom_4"></a><![endif]></span><p class=MsoCommentText><span class=MsoCommentReference><span style='font-size:8.0pt'> <![if !supportAnnotations]><a href="#_msoanchor_4" class=msocomoff>[AS4]</a><![endif]></span></span>I don’t know if this is right or wrong but I do know that I am going insane talking about this in the abstract and even if it is just for discussion purposes – in my opinion - we are on the right track trying to find a reference case like Immunization or the Patient Registration example. The simpler the better in my opinion.<o:p></o:p></p><![if !supportAnnotations]></div><![endif]></div></div></body></html>