<div dir="ltr">Great, thanks, folks. As I noted, the four resource instances in my slide were just SWAGs, and to be basically ignored as examples. Your lists are more accurate. If we take Adrian's suggestion, and assume that Alice should simply be able to share resource instances sort of like the VA resource types he lists for now, then I think I've got a big part of an answer as to the "technical gap" between what Alice would experience and what clients (acting on behalf of providers, at least) would want to access and query. Clients acting on behalf of people such as spouses and other caregivers might have other sorts of queries they'd want to make...</div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">
<p><b>Eve Maler<br></b>ForgeRock Office of the CTO | VP Innovation & Emerging Technology<br>Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl</p></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Thu, Nov 3, 2016 at 7:13 PM, Adrian Gropper <span dir="ltr"><<a href="mailto:agropper@healthurl.com" target="_blank">agropper@healthurl.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>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.<br><br></div>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 src="cid:ii_1582d191d6adaeed" alt="Inline image 1" width="488" height="275"><br><br></div>Adrian<br></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Thu, Nov 3, 2016 at 9:37 PM, Nancy Lush <span dir="ltr"><<a href="mailto:nlush@lgisoftware.com" target="_blank">nlush@lgisoftware.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div link="blue" vlink="purple" lang="EN-US"><div class="m_4502280005233828030m_-289878913207204553WordSection1"><p class="MsoNormal"><span style="font-family:"Calibri",sans-serif;color:#1f497d">Hi Eve,<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><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.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal">I will provide feedback on the 2<sup>nd</sup> of your two slides, as that seems to be the most recent version.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">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.)<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Feedback on your slides:<u></u><u></u></p><p class="m_4502280005233828030m_-289878913207204553MsoListParagraphCxSpFirst"><u></u><span style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u>From the physician perspective (Please, physicians on the list please feel free to provide your perspective.)<u></u><u></u></p><p class="m_4502280005233828030m_-289878913207204553MsoListParagraphCxSpMiddle" style="margin-left:1.0in"><u></u><span style="font-family:"Courier New""><span>o<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u>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.)<u></u><u></u></p><p class="m_4502280005233828030m_-289878913207204553MsoListParagraphCxSpMiddle" style="margin-left:1.5in"><u></u><span style="font-family:Wingdings"><span>§<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u>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.<u></u><u></u></p><p class="m_4502280005233828030m_-289878913207204553MsoListParagraphCxSpMiddle" style="margin-left:1.0in"><u></u><span style="font-family:"Courier New""><span>o<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u>Blood Glucose/lab results<u></u><u></u></p><p class="m_4502280005233828030m_-289878913207204553MsoListParagraphCxSpMiddle" style="margin-left:1.5in"><u></u><span style="font-family:Wingdings"><span>§<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u>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.<u></u><u></u></p><p class="m_4502280005233828030m_-289878913207204553MsoListParagraphCxSpMiddle" style="margin-left:1.5in"><u></u><span style="font-family:Wingdings"><span>§<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u>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.<u></u><u></u></p><p class="m_4502280005233828030m_-289878913207204553MsoListParagraphCxSpMiddle" style="margin-left:2.0in"><u></u><span style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u>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.<u></u><u></u></p><p class="m_4502280005233828030m_-289878913207204553MsoListParagraphCxSpMiddle" style="margin-left:1.0in"><u></u><span style="font-family:"Courier New""><span>o<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u>Appointment data since some point in time.<u></u><u></u></p><p class="m_4502280005233828030m_-289878913207204553MsoListParagraphCxSpMiddle" style="margin-left:1.5in"><u></u><span style="font-family:Wingdings"><span>§<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u>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?<u></u><u></u></p><p class="m_4502280005233828030m_-289878913207204553MsoListParagraphCxSpMiddle" style="margin-left:1.0in"><u></u><span style="font-family:"Courier New""><span>o<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u>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.<u></u><u></u></p><p class="m_4502280005233828030m_-289878913207204553MsoListParagraphCxSpMiddle"><u></u><span style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u>From the patient objective.<u></u><u></u></p><p class="m_4502280005233828030m_-289878913207204553MsoListParagraphCxSpMiddle" style="margin-left:1.0in"><u></u><span style="font-family:"Courier New""><span>o<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u>Medication List – Yes, the patient would want to see their list of medications and that is meaningful to the patient.<u></u><u></u></p><p class="m_4502280005233828030m_-289878913207204553MsoListParagraphCxSpMiddle" style="margin-left:1.0in"><u></u><span style="font-family:"Courier New""><span>o<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u>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.<u></u><u></u></p><p class="m_4502280005233828030m_-289878913207204553MsoListParagraphCxSpMiddle" style="margin-left:1.0in"><u></u><span style="font-family:"Courier New""><span>o<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u>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.<u></u><u></u></p><p class="m_4502280005233828030m_-289878913207204553MsoListParagraphCxSpLast" style="margin-left:1.0in"><u></u><span style="font-family:"Courier New""><span>o<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u>Four-strain flu vaccine. I believe the patient can meet this requirement by viewing their current immunization list.<u></u><u></u></p><p class="MsoNormal">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.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">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.<u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">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. <u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">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.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">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.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">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. <u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">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.)<u></u><u></u></p><p class="m_4502280005233828030m_-289878913207204553MsoListParagraphCxSpFirst"><u></u><span>1.<span style="font:7.0pt "Times New Roman""> </span></span><u></u>All (None – that would be an absence of an authorization.)<u></u><u></u></p><p class="m_4502280005233828030m_-289878913207204553MsoListParagraphCxSpMiddle" style="margin-left:1.0in"><u></u><span>a.<span style="font:7.0pt "Times New Roman""> </span></span><u></u>This would imply all resources supported by this RS without limitations<u></u><u></u></p><p class="m_4502280005233828030m_-289878913207204553MsoListParagraphCxSpMiddle"><u></u><span>2.<span style="font:7.0pt "Times New Roman""> </span></span><u></u>Selected Resources by Resource type<u></u><u></u></p><p class="m_4502280005233828030m_-289878913207204553MsoListParagraphCxSpMiddle" style="margin-left:1.0in"><u></u><span>a.<span style="font:7.0pt "Times New Roman""> </span></span><u></u>This could include specific resource types<u></u><u></u></p><p class="m_4502280005233828030m_-289878913207204553MsoListParagraphCxSpMiddle" style="margin-left:1.0in"><u></u><span>b.<span style="font:7.0pt "Times New Roman""> </span></span><u></u>It might also allow all resource type Except indicated Resource types<u></u><u></u></p><p class="m_4502280005233828030m_-289878913207204553MsoListParagraphCxSpMiddle"><u></u><span>3.<span style="font:7.0pt "Times New Roman""> </span></span><u></u>Share by sensitive data indication<u></u><u></u></p><p class="m_4502280005233828030m_-289878913207204553MsoListParagraphCxSpMiddle" style="margin-left:1.0in"><u></u><span>a.<span style="font:7.0pt "Times New Roman""> </span></span><u></u>This may be an option to either<u></u><u></u></p><p class="m_4502280005233828030m_-289878913207204553MsoListParagraphCxSpMiddle" style="margin-left:1.5in"><u></u><span><span style="font:7.0pt "Times New Roman""> <wbr> <wbr> </span>i.<span style="font:7.0pt "Times New Roman""> </span></span><u></u>Exclude all sensitive data<u></u><u></u></p><p class="m_4502280005233828030m_-289878913207204553MsoListParagraphCxSpMiddle" style="margin-left:1.5in"><u></u><span><span style="font:7.0pt "Times New Roman""> <wbr> </span>ii.<span style="font:7.0pt "Times New Roman""> </span></span><u></u>Exclude specific kinds of sensitive data as defined in our sensitive data tagging.<u></u><u></u></p><p class="m_4502280005233828030m_-289878913207204553MsoListParagraphCxSpMiddle" style="margin-left:1.0in"><u></u><span>b.<span style="font:7.0pt "Times New Roman""> </span></span><u></u>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. <u></u><u></u></p><p class="m_4502280005233828030m_-289878913207204553MsoListParagraphCxSpLast" style="margin-left:1.0in"><u></u><span>c.<span style="font:7.0pt "Times New Roman""> </span></span><u></u>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.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><span style="font-family:"Calibri",sans-serif;color:#1f497d">-Nancy<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></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"> Openid-specs-heart [mailto:<a href="mailto:openid-specs-heart-bounces@lists.openid.net" target="_blank">openid-specs-heart-bou<wbr>nces@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.openi<wbr>d.net</a><span><br><b>Subject:</b> [Openid-specs-heart] V2 of Profiling UMA for FHIR slides<u></u><u></u></span></span></p><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">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.<u></u><u></u></p><div><div class="m_4502280005233828030h5"><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">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!<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">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"><u></u><u></u></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" value="+14253456756" 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><u></u><u></u></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><br></div></div>______________________________<wbr>_________________<br>
Openid-specs-heart mailing list<br>
<a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank">Openid-specs-heart@lists.openi<wbr>d.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" rel="noreferrer" target="_blank">http://lists.openid.net/mailma<wbr>n/listinfo/openid-specs-heart</a><br>
<br></blockquote></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><br>-- <br><div class="m_4502280005233828030gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br><div dir="ltr">Adrian Gropper MD<span style="font-size:11pt"></span><br><br><span style="font-family:"Arial",sans-serif;color:#1f497d">PROTECT YOUR FUTURE - RESTORE Health Privacy!</span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>HELP us fight for the right to control personal health data.</span><span style="font-family:"Arial",sans-serif;color:#1f497d"></span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>DONATE:
<a href="http://patientprivacyrights.org/donate-2/" target="_blank"><span style="color:#0563c1">http://patientprivacyrights.<wbr>org/donate-2/</span></a></span><span style="color:#1f497d"></span>
</div></div></div></div></div></div></div></div>
</font></span></div>
</blockquote></div><br></div>