<div dir="ltr"><div>Thanks Eve for sending around the various links and for bringing the WEDI <a href="http://www.wedi.org/docs/default-document-library/virtual-clipboard-definition-and-design-document.pdf?sfvrsn=0">document</a> to our attention. It represents a good point of reference for how some of the industry will consider adoption of HEART. I will use the WEDI terminology for this comment.<br><br></div><div>The WEDI document does not mention the reality that there is zero adoption of federated patient identity services in healthcare today. I think HEART needs to consider how to ease the path to broad adoption of OpenID Connect while also staying focused on our charter. I'm not sure how to interpret what WEDI calls "External Security Services" (figure on p13 - b). Presumably it's an OpenID Connect IDP? Since patient identity federations don't exist yet and it's not clear who would govern such a federation, we need to be careful about our IDP assumptions and federations in general.<br><br>The rest of the diagram on p13 is much easier to understand if we treat the Application Services (purple) as just another instance of an External Application Partner (yellow). All four blocks have an Inter-application path (isn't this just FHIR?) and a Security Communication Path (isn't this just OAuth and UMA?).<br><br></div><div>The Mobile App (green) is pretty clear. No matter what, we can assume that we need a mobile secure element under control of a mobile UI. Per the WEDI model, the Mobile App needs to be recognized by the (optional) IDP and what WEDI calls the Application Security Services (orange).<br><br></div><div>The Application Security Services (orange) is the only one containing an Authorization Service so it presumably maps into HEART. Regardless of the fact that WEDI put a gray rectangle around this and the Application Services block, HEART does not benefit from adopting this combination. Doing so is unnecessary and might even violate our charter.<br><br></div><div>We can conclude that WEDI would support an UMA AS as the manager of the Security Communication Path that controls FHIR-standard resource access.<br><br></div><div>First and foremost, IMHO, HEART needs to consider how we can drive adoption of a patient-centered authorization service without forcing all of the External Application Partners, including the Application Services block, to worry about also federating with an IDP. In other words, HEART must be clear whether we are asking the FHIR endpoints (PHR, EHR, Payer, whatever...) to trust the AS regardless of whether an IDP is trusted as well.<br><br></div><div>This post about WEDI might be a separate thread from whatever we mean by virtual clipboard but I put it here first because WEDI's is the only definition of a virtual clipboard that we've seen.<br><br></div><div>Adrian<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 21, 2016 at 5:15 PM, Nancy Lush <span dir="ltr"><<a href="mailto:nlush@lgisoftware.com" target="_blank">nlush@lgisoftware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div link="blue" vlink="purple" lang="EN-US"><div><p class="MsoNormal"><span style="font-family:"Calibri",sans-serif;color:#1f497d">The Argonaut Group has implemented (or will soon complete) the following resources in FHIR:<u></u><u></u></span></p><p><u></u><span style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u>Patient (demographics)<u></u><u></u></p><p><u></u><span style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u>Allergies<u></u><u></u></p><p><u></u><span style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u>Problems & Health concerns (Condition/Problem)<u></u><u></u></p><p><u></u><span style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u>Vital Signs <u></u><u></u></p><p><u></u><span style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u>Labs<u></u><u></u></p><p><u></u><span style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u>Smoking Status <u></u><u></u></p><p><u></u><span style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u>Care Team (Some vendors have Care Plan of which Care Team is a subset.)<u></u><u></u></p><p><u></u><span style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u>Medications<u></u><u></u></p><p><u></u><span style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u>Immunizations <u></u><u></u></p><p><u></u><span style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u>Goals<u></u><u></u></p><p><u></u><span style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u>UDI (Device)<u></u><u></u></p><p><u></u><span style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u>Procedures<u></u><u></u></p><p><u></u><span style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u>Plan of Treatment<u></u><u></u></p><p><u></u><span style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u>Assessment<u></u><u></u></p><p class="MsoNormal"><span style="font-family:"Calibri",sans-serif;color:#1f497d">These pretty much match the Common Clinical Data Set. Why don’t we start with that list? <u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:"Calibri",sans-serif;color:#1f497d">Yes, Eve, it does include labs.<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">The virtual clipboard reference is a bit askew since the virtual clipboard initial pilot seems much smaller in scope. Perhaps it is just me, but I am confused by that reference added in.<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">-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-bounces@lists.openid.net</a>] <b>On Behalf Of </b>Debbie Bucci<br><b>Sent:</b> Thursday, July 21, 2016 12:07 PM<br><b>To:</b> Eve Maler <<a href="mailto:eve.maler@forgerock.com" target="_blank">eve.maler@forgerock.com</a>><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] New thread - What is in a clipboard resource set?<u></u><u></u></span></p><div><div class="h5"><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">On Thu, Jul 21, 2016 at 11:39 AM, Eve Maler <<a href="mailto:eve.maler@forgerock.com" target="_blank">eve.maler@forgerock.com</a>> wrote:<u></u><u></u></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><p class="MsoNormal">Just to level-set, there are three links in the current use case to sources that describe potentially interesting data (though not directly how they map to FHIR, as far as I can see):<u></u><u></u></p><div><ul type="disc"><li class="MsoNormal"><a href="https://bitbucket.org/openid/heart/wiki/Alice_Shares_with_Physicians_and_Others_UMA_FHIR" target="_blank">Use case</a><u></u><u></u></li></ul><ul type="disc"><ul type="circle"><li class="MsoNormal"><a href="https://www.healthit.gov/policy-researchers-implementers/patient-generated-health-data" target="_blank">PGHD</a><u></u><u></u></li><li class="MsoNormal"><a href="https://www.healthit.gov/sites/default/files/commonclinicaldataset_ml_11-4-15.pdf" target="_blank">Common Clinical Data Set</a><u></u><u></u></li><li class="MsoNormal"><a href="https://www.wedi.org/home/virtual-clipboard-to-improve-patient-data-collection" target="_blank">Virtual clipboard</a> (<a href="http://www.wedi.org/docs/default-document-library/virtual-clipboard-definition-and-design-document.pdf?sfvrsn=0" target="_blank">this link</a> is actually more helpful -- I've changed it in the use case)<u></u><u></u></li></ul></ul><div><p class="MsoNormal">And based on one of our telecon conversations, we provided this list right in the use case, where the first item might possibly encompass some of the others by definition:<u></u><u></u></p></div></div><div><div><ol start="1" type="1"><li class="MsoNormal">Virtual clipboard<u></u><u></u></li><li class="MsoNormal">Basic patient profile /Patient)<u></u><u></u></li><li class="MsoNormal">Medication history (/MedicationDispense, /MedicationAdministration)<u></u><u></u></li><li class="MsoNormal">Immunizations (/Immunization.vaccineCode , /Immunization.status)<u></u><u></u></li><li class="MsoNormal">Allergies (/AllergyIntolerance)<u></u><u></u></li><li class="MsoNormal">Problem list /Condition.code, /Condition.status)<u></u><u></u></li><li class="MsoNormal">Labs (/DiagnosticReport.code - LOINC /DiagnosticReport.codedDiagnostics - SNOMED)<u></u><u></u></li><li class="MsoNormal">Basic insurance info? EOB?<u></u><u></u></li><li class="MsoNormal">(what else? Keep it simple) <u></u><u></u></li></ol></div></div></div></blockquote><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">Here was my guess about directions, given that a use-case-based definition of this resource set is meant to encompass baseline information before a first visit.<u></u><u></u></p></div></div></blockquote><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Agree - basic info to start the conversation - vs. a clinical referral for specific illness - that may be a follow-on request. <u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in"><div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">First, we want to keep firmly in our minds that Alice's motivation to share this information at all is as a convenience vs. sharing it in a more onerous, brittle fashion (e.g., having to keep updating her meds list later, spending time printing forms, arriving early to the first appointment...). So we don't "win" if we don't hit that mark.<u></u><u></u></p></div></div></blockquote><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">If we focus on convenience first - then other benefits may follow. <u></u><u></u></p></div><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in"><div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Second, labs and EOBs look like the "odd items out" on that list for a first visit. Am I right? And what's missing? And what's the "FHIR concordance" for all this? Can one actually be done?<u></u><u></u></p></div></div></blockquote><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Agree no labs and EOB but in US basic insurance (payer as noted below) info will be needed. Is emergency contact part of demographics (need to look). How do capture both OTC meds, herbs ect? (some of that may be covered as well) Some information ex: - why are you making the appointment and other things of that nature would be out of scope - or perhaps an extension?<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal"> <u></u><u></u></p></div><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in"><div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Third, there would be some kind of a "matrix of requesting-side appropriateness" for what is to be shared:<u></u><u></u></p></div><div><ul type="disc"><li class="MsoNormal"><b>Payment info:</b> E.g., there's a particular type of insurance infrastructure in the US, but in Canada, it would look different. So the "insurance info" reference in #8 would need to vary or be missing per jurisdiction. <u></u><u></u></li></ul></div></div></blockquote><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><ul type="disc"><li class="MsoNormal"><u></u> <u></u></li><li class="MsoNormal"><b>Provider services:</b> There <i>may</i> be a fundamental mismatch between the nature of health information available and what the provider can even do. When it comes to, say, chiropractic, is there an appropriateness or privacy concern about providing meds/allergy information? It's a complex technical question to imagine leaving this info out per provider type (akin to the segmentation challenges discussed on the recent thread titled "Patient Consent", so perhaps we decide to put it out of scope in favor of time constraints on usage, notifications of what's missing, usage constraints, etc.), but I'm listing this for discussion completeness.<u></u><u></u></li></ul><div><p class="MsoNormal">Finally, I'm assuming that for interoperability and attractiveness of standardization, we'd want to say that (barring the above concerns if solved) if a data item is <i>available</i> in the record, and Alice chooses to share it as part of the "virtual clipboard" resource set context, then it <i>must</i> be included. In technical terms, this would equate to the resource server supporting an API call that extracts out a bunch of potentially disparate data fields and provides them, because it supports the use case (i.e., provides a lot of value). We could separately think about whether extensibility is okay or not in the context of HEART.<u></u><u></u></p></div></div></div></blockquote><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Agree <u></u><u></u></p></div></div></div></div></div></div></div></div><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" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><br>
<br></blockquote></div><br></div>