<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 15 (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: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;}
/* 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.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
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.m-289878913207204553msolistparagraph, li.m-289878913207204553msolistparagraph, div.m-289878913207204553msolistparagraph
{mso-style-name:m_-289878913207204553msolistparagraph;
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;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;
font-weight:normal;
font-style:normal;}
.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-family:"Calibri",sans-serif;color:#1F497D'>Hi Adrian,<o:p></o:p></span></p><p class=MsoNormal><span style='font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-family:"Calibri",sans-serif;color:#1F497D'>Just to be clear. I agree we should not be proposing any FHIR changes. It is simply helpful to be able to refer to them in the HEART profiles. <o:p></o:p></span></p><p class=MsoNormal><span style='font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-family:"Calibri",sans-serif;color:#1F497D'>The beginning of my response is feedback on the slide Eve presented. You have listed initial use cases, so that is addressed, unless others wish to expand.<o:p></o:p></span></p><p class=MsoNormal><span style='font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-family:"Calibri",sans-serif;color:#1F497D'>While protecting sensitive data is something Alice may wish do to, particularly in certain populations, we should address it in more detail in the future, not right now. Let’s get the non-sensitive data use cases defined first.<o:p></o:p></span></p><p class=MsoNormal><span style='font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-family:"Calibri",sans-serif;color:#1F497D'>-Nancy<o:p></o:p></span></p><p class=MsoNormal><span style='font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>From:</span></b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> agropper@gmail.com [mailto:agropper@gmail.com] <b>On Behalf Of </b>Adrian Gropper<br><b>Sent:</b> Thursday, November 03, 2016 10:13 PM<br><b>To:</b> Nancy Lush <nlush@lgisoftware.com><br><b>Cc:</b> Eve Maler <eve.maler@forgerock.com>; openid-specs-heart@lists.openid.net<br><b>Subject:</b> Re: [Openid-specs-heart] V2 of Profiling UMA for FHIR slides<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><div><div><div><p class=MsoNormal style='margin-bottom:12.0pt'>Below is the list of resources offered by the VA. <br><br>I think we could engage FHIR experts to help HEART document the gaps between the VA list the current FHIR specs. Or not.<br><br>I'm not in favor of HEART doing anything in the first version to profile FHIR beyond this gap analysis. Further profiling around FHIR is an exercise in user-experience design that's not a core HEART capability or it's a job for the HL7 folks who are responsible for the gaps in the first place.<o:p></o:p></p></div><p class=MsoNormal style='margin-bottom:12.0pt'>That said, HL7 or some other group, might decide to standardize "sensitivity codes" and other metadata instead of changing the resource semantics. HEART is not configured to do sensitivity code design or any other metadata enhancements to an API standard. We can consider that sensitivity codes will be added in the future and, if they are, the VA Selected Data chooser will be changed accordingly. <br><br><br><img width=488 height=275 style='width:5.0833in;height:2.8645in' id="_x0000_i1025" src="cid:image002.jpg@01D23678.0D4BC2D0" alt="Inline image 1"><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 Thu, Nov 3, 2016 at 9:37 PM, Nancy Lush <<a href="mailto:nlush@lgisoftware.com" target="_blank">nlush@lgisoftware.com</a>> wrote:<o:p></o:p></p><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><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-family:"Calibri",sans-serif;color:#1F497D'>Hi Eve,</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='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-family:"Calibri",sans-serif;color:#1F497D'>I will apologize in advance for the length of this reply. I have also included it as a word document in case anyone finds that easier to read then an email thread.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='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'>I will provide feedback on the 2<sup>nd</sup> of your two slides, as that seems to be the most recent version.<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'>From the overview perspective, I suggest that we start our focus on providing a standard that will work for known use cases. Whatever we define, the innovators will innovate, and new use cases will arise. We should not be trying to control that. Suggested use cases at the end of this feedback. (Since I started writing this, Adrian has suggested use case. I support those.)<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'>Feedback on your slides:<o:p></o:p></p><p class=m-289878913207204553msolistparagraph><span style='font-family:Symbol'>·</span><span style='font-size:7.0pt'> </span>From the physician perspective (Please, physicians on the list please feel free to provide your perspective.)<o:p></o:p></p><p class=m-289878913207204553msolistparagraph style='margin-left:1.0in'><span style='font-family:"Courier New"'>o</span><span style='font-size:7.0pt'> </span>Medications – A physician is very unlikely to query whether Alice is taking Medication A. Instead, he or she asks to see Alice’s medication list. Then they know all the medications she is taking. (It is normally important for them to have the complete list.)<o:p></o:p></p><p class=m-289878913207204553msolistparagraph style='margin-left:1.5in'><span style='font-family:Wingdings'>§</span><span style='font-size:7.0pt'> </span>You raised another point on the call – how to handle over the counter and supplements. Often, if they are recorded at all at the EMR they are recorded in the med list. While I agree, there should be a place for these in the medical record, that is out of scope for this task.<o:p></o:p></p><p class=m-289878913207204553msolistparagraph style='margin-left:1.0in'><span style='font-family:"Courier New"'>o</span><span style='font-size:7.0pt'> </span>Blood Glucose/lab results<o:p></o:p></p><p class=m-289878913207204553msolistparagraph style='margin-left:1.5in'><span style='font-family:Wingdings'>§</span><span style='font-size:7.0pt'> </span>This is a tricky topic because FHIR has grouped several categories in the observation resource type. I would love to see those separated but do not know if that is an option with our HEART spec.<o:p></o:p></p><p class=m-289878913207204553msolistparagraph style='margin-left:1.5in'><span style='font-family:Wingdings'>§</span><span style='font-size:7.0pt'> </span>Let’s assume for the purpose of this conversation that we are looking at the medical data set of lab results. It may be that the doctor is interested in Alice’s blood glucose reading over time. But we can also leave this to the client app to address that specific functionality.<o:p></o:p></p><p class=m-289878913207204553msolistparagraph style='margin-left:2.0in'><span style='font-family:Symbol'>·</span><span style='font-size:7.0pt'> </span>As an example, in our FHIR prototype app, we display lab results by lab date. When the user drills down to the most recent lab results, they may notice that Alice’s blood glucose is out of normal range. They click that and get a graph of this blood glucose reading over time. That is a feature delivered by an app. We don’t need to have Alice specifying any different policy around this feature or the physician doing any special requests. It is just an intuitive drill down on available data.<o:p></o:p></p><p class=m-289878913207204553msolistparagraph style='margin-left:1.0in'><span style='font-family:"Courier New"'>o</span><span style='font-size:7.0pt'> </span>Appointment data since some point in time.<o:p></o:p></p><p class=m-289878913207204553msolistparagraph style='margin-left:1.5in'><span style='font-family:Wingdings'>§</span><span style='font-size:7.0pt'> </span>I am not sure why a physician may be looking at this. They would have it in their own EMR. Would they need to go to another data source to determine this information?<o:p></o:p></p><p class=m-289878913207204553msolistparagraph style='margin-left:1.0in'><span style='font-family:"Courier New"'>o</span><span style='font-size:7.0pt'> </span>Entire Vaccine History. Yes, you have this correct – the physician is interested in their entire vaccine history. They certainly would not want to limit it by date range since that could eliminate key data.<o:p></o:p></p><p class=m-289878913207204553msolistparagraph><span style='font-family:Symbol'>·</span><span style='font-size:7.0pt'> </span>From the patient objective.<o:p></o:p></p><p class=m-289878913207204553msolistparagraph style='margin-left:1.0in'><span style='font-family:"Courier New"'>o</span><span style='font-size:7.0pt'> </span>Medication List – Yes, the patient would want to see their list of medications and that is meaningful to the patient.<o:p></o:p></p><p class=m-289878913207204553msolistparagraph style='margin-left:1.0in'><span style='font-family:"Courier New"'>o</span><span style='font-size:7.0pt'> </span>Blood Glucose readings for a specific week – A client app could derive this information form either lab results or records coming from a personal device. Refer to use cases below.<o:p></o:p></p><p class=m-289878913207204553msolistparagraph style='margin-left:1.0in'><span style='font-family:"Courier New"'>o</span><span style='font-size:7.0pt'> </span>Appointments. Yes, a patient would want to get a list of upcoming appointments. There has not been as much work with this resource in current FHIR implementations that I am aware of. Largely, it seems that more patients have access to this information and it is not ‘Clinical Data’. But certainly this resource is important in the patient’s care management.<o:p></o:p></p><p class=m-289878913207204553msolistparagraph style='margin-left:1.0in'><span style='font-family:"Courier New"'>o</span><span style='font-size:7.0pt'> </span>Four-strain flu vaccine. I believe the patient can meet this requirement by viewing their current immunization list.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>I began to list Use Cases, but Adrian has already listed known common use cases. I agree with these, with the exception of perhaps the last case that might require more explanation.<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'>The point for HEART at this stage is that we can move this process along significantly by identifying a few known use cases and addressing the whole process to support these. Will we have all use cases? No. We need to let our innovators innovate – they will define many use cases we have not considered and that should be encouraged. Our current known sources of information include EMRs, HIEs and PHRs. But we have another round of details with IoT and other sources. I don’t know which institutions are implementing the device resource and if that needs to be refined, but we will discover this as folks begin to use these features. We certainly will have instances of RSs that exchange fitbit data, scale data, and blood glucose readings as examples.<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'>My guess is that eventually Alice may be asked to select which resources she will share, with whom, from each of the RSs that contain her data. From that perspective, we should allow each RS to define the resource sets they support, along with a ‘User-friendly’ description that would be provided to the user. It would include an API definition. As RSs engage, we should have groups working to certify so that client apps can expect the same response for a given resource type across RSs. Past that, we should let it sort itself out. <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'>So we could say we support ‘these 8 resource types’, or 17 or whatever. But the industry will be able to identify more to be included in the mix.<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'>If we can start with a reasonable first resource type list and a reasonable list of example use case, then we will have empowered our innovators.<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'>Back to your power point slide, Let’s assume that there is an RS that contains data collected from a series of devices Alice uses to manage her diabetes. Let’s assume one of those is Blood Glucose readings. The RS resource set may be different than the observation lab results data set. In fact, that may come in as a device resource per the FHIR API. So for that case the ‘Blood Glucose readings since a defined date’ would be of interest to both the clinician and the patient. And in fact it might be nice if the client app charted that data or provided some other insightful presentation to both Alice and the clinician. <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'>One last point: My current thinking is that Alice should be provided the ability to define scopes in at least three mutually exclusive areas. (Others may have other thoughts.)<o:p></o:p></p><p class=m-289878913207204553msolistparagraph>1.<span style='font-size:7.0pt'> </span>All (None – that would be an absence of an authorization.)<o:p></o:p></p><p class=m-289878913207204553msolistparagraph style='margin-left:1.0in'>a.<span style='font-size:7.0pt'> </span>This would imply all resources supported by this RS without limitations<o:p></o:p></p><p class=m-289878913207204553msolistparagraph>2.<span style='font-size:7.0pt'> </span>Selected Resources by Resource type<o:p></o:p></p><p class=m-289878913207204553msolistparagraph style='margin-left:1.0in'>a.<span style='font-size:7.0pt'> </span>This could include specific resource types<o:p></o:p></p><p class=m-289878913207204553msolistparagraph style='margin-left:1.0in'>b.<span style='font-size:7.0pt'> </span>It might also allow all resource type Except indicated Resource types<o:p></o:p></p><p class=m-289878913207204553msolistparagraph>3.<span style='font-size:7.0pt'> </span>Share by sensitive data indication<o:p></o:p></p><p class=m-289878913207204553msolistparagraph style='margin-left:1.0in'>a.<span style='font-size:7.0pt'> </span>This may be an option to either<o:p></o:p></p><p class=m-289878913207204553msolistparagraph style='margin-left:1.5in'><span style='font-size:7.0pt'> </span>i.<span style='font-size:7.0pt'> </span>Exclude all sensitive data<o:p></o:p></p><p class=m-289878913207204553msolistparagraph style='margin-left:1.5in'><span style='font-size:7.0pt'> </span>ii.<span style='font-size:7.0pt'> </span>Exclude specific kinds of sensitive data as defined in our sensitive data tagging.<o:p></o:p></p><p class=m-289878913207204553msolistparagraph style='margin-left:1.0in'>b.<span style='font-size:7.0pt'> </span>As have been both pointed out and argued by this group, this feature requires certain magic to be defined and resolved. There are groups working on sorting out the details of this. I recommend we not get bogged down by this detail at this time and continue on with the remaining options (1 & 2 above) for now. We should just know that this is coming. <o:p></o:p></p><p class=m-289878913207204553msolistparagraph style='margin-left:1.0in'>c.<span style='font-size:7.0pt'> </span>Ken has argued that providing Alice the ability to manage access by data sensitivity is more meaningful than limiting by FHIR resource type. I think that using Resource Type for a first pass will provide benefit and that they are close to what patients will understand if we use a limited set. (Ex: Medication list, problem list, list of allergies, patient demographics, vital signs, etc.) Eventually, once we can support sensitivity data, that may replace the resource set type option as Alice’s preferred method.<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'><span style='font-family:"Calibri",sans-serif;color:#1F497D'>-Nancy</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='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:11.0pt;font-family:"Calibri",sans-serif'>From:</span></b><span style='font-size:11.0pt;font-family:"Calibri",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>Eve Maler<br><b>Sent:</b> Tuesday, November 01, 2016 12:00 PM<br><b>To:</b> <a href="mailto:openid-specs-heart@lists.openid.net" target="_blank">openid-specs-heart@lists.openid.net</a><br><b>Subject:</b> [Openid-specs-heart] V2 of Profiling UMA for FHIR slides</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><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>As discussed on the call, the exercise is to figure out <i>Alice's motivation for sharing</i> the various data sets (FHIR resources in scope) vs. <i>the provider's motivation for wanting access</i> to them.<o:p></o:p></p><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>The ones listed on the slides aren't necessarily the ones Nancy et al. listed on the call/in email, so please don't take the slides versions as gospel!<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Please identify the specific use cases/scenarios you have in mind. By drilling down on this, we can get an idea of the interplay among the FHIR API design, the UMA resource set boundaries and scopes as Alice may want to experience them, and the API calls as the provider's client applications may want/need to make them. I believe this will have a big impact on how we can/will profile.<br clear=all><o:p></o:p></p><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><p><b>Eve Maler<br></b>ForgeRock Office of the CTO | VP Innovation & Emerging Technology<br>Cell <a href="tel:%2B1%20425.345.6756" target="_blank">+1 425.345.6756</a> | Skype: xmlgrrl | Twitter: @xmlgrrl<br><b>The ForgeRock Identity Summit</b> <a href="http://summits.forgerock.com/" target="_blank">is coming to</a> <b>Paris in November!</b><o:p></o:p></p></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></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></blockquote></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>