<div dir="ltr"><div><font size="2">Dearest Debbie, (or is it Debbie Dearest?)<br><br></font></div><font size="2">You are very wrong about 5 more years of authorization servers as business associates. Apple Health (Kit, Research, and now HL7 CCDA) are an example where "Apple will not see your data." is the privacy policy and BA status is irrelevant. It's not just Apple, <a href="http://digi.me" target="_blank">digi.me</a> is a startup that just raised money including a major insurance company. The founder describes their business as: <br></font><p style="line-height:1.38;margin-top:0pt;margin-bottom:0pt" dir="ltr"><font size="2"><span style="font-family:arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">“the key thing for Digi.me is that we don’t see, touch, nor hold any data ever; it’s all only held by the individual”. You can read more about them </span><a style="text-decoration:none" href="https://techcrunch.com/2016/06/30/digi-me-bags-6-1m-to-put-users-in-the-driving-seat-for-sharing-personal-data/" target="_blank"><span style="font-family:arial;color:rgb(17,85,204);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:underline;vertical-align:baseline">https://techcrunch.com/2016/06/30/digi-me-bags-6-1m-to-put-users-in-the-driving-seat-for-sharing-personal-data/</span></a></font></p><p style="line-height:1.38;margin-top:0pt;margin-bottom:0pt" dir="ltr"><font size="2"><br></font></p><p style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><font size="2">Most of all, please read this recent report by your very office: <a href="https://www.healthit.gov/buzz-blog/privacy-and-security-of-ehrs/examining-oversight-privacy-security-health-data-collected-entities-not-regulated-hipaa/">https://www.healthit.gov/buzz-blog/privacy-and-security-of-ehrs/examining-oversight-privacy-security-health-data-collected-entities-not-regulated-hipaa/</a> and then ask Karen, Jocelyn, and Lucia whether HHS has any solutions in mind to what this report describes - other than hopefully HEART. Does HHS really believe that extending BA regulations to authorization servers will solve the issues in the report? Maybe they do, in which case we're headed for a EU GDPR alternative to HIPAA with the authorization servers as "data controllers" and a very different regulatory domain. I love that a person from HHS is co-chairing HEART so let's make the most of it even as we wait for HHS to decide on a strategy to deal with the report's findings.<br></font></p><p style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><font size="2"><br></font></p><p style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><font size="2">Finally, and also relevant, please note the HEART charter says: <i>"Support independent authorization services and identity providers, to be
chosen by people who may build, run, or outsource these services."</i> (I hate consumer - it implies that patients have a realistic choice in seeking care from a doctor, ER, or hospital and that we're consuming something that takes away from others - we're people.) Your opinion about the 5-year timeline just doesn't matter.</font></p><p style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><font size="2"><br></font></p><p style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><font size="2">The degree to which HEART chooses to profile particular subsets of FHIR has nothing to do with whether a person chooses to outsource his / her authorization server. It simply has to do with the person's user experience in setting policies that HIPAA-covered-entities and FTC-covered-entities and 42-CFR-covered-entities as resource servers will need to follow. In some cases, the resource servers will voluntarily take advantage of the FHIR standard while in others it will not apply at all. </font><br></p><p style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><br></p><p style="line-height:1.38;margin-top:0pt;margin-bottom:0pt">Adrian<br></p></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jul 31, 2016 at 11:05 AM, Debbie Bucci <span dir="ltr"><<a href="mailto:debbucci@gmail.com" target="_blank">debbucci@gmail.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><div>Wow - what a lively discussion. Overall impressions thoughts:<br><br></div>Scope of HEART - Consumer -Patient Mediated exchange (read and write - push/pull):<br></div><ul><li>Provider [in US called covered entity] to consumer [patient] 3rd party app <br></li><li>Consumer [patient] to Provider or Donation for research or even another 3rd party app </li><li>others</li><li>Profiles (3 core profiles) defined would extend used for mash-ups - Use multiple APIs. The 2 FHIR profiles serve as the exemplar for other APIs<br></li></ul><p>FHIR is an international standards - that we all agree is the vehicle to
exchange CLINICAL data. If 3rd party apps want to play they will need
to understand FHIR API rules/resources/structures etc. <br></p><p>A full time 7x24 primary care giver with an extensive care team- would push back on the notion that payment information is irrelevant when it comes to decisions to be made about care and treatment. Aggregation of Claims and clinical data has been identified as as need for many efforts. I see it as a potential value add to consumers. There are not many claims resources a the moment so out of scope for the UMA 1.0 FHIR Resource profile.<br></p><p>The confidentiality codes were not created in a vacuum - they are derived from an ISO standard. Covered Entities will have their own methods in how they segregate their data to meet requirements. I would hope a term of art such as "very sensitive" data would have some meaning or reference for all services - whether health related or commercial. Tagging aside - the acceptance of confidentiality code as a scope that a consumer can respond to seems like good baby step in the right direction. <br></p><p>I personally believe individual AS owned by consumer - and not
associated with some kind of entity - whether commercial or health
related - will not be a reality (generally accepted -trusted(?)) within the next 5
years. Centralized AS [ACO and HIE] may find value in providing consumer based services. Those UMA AS would (i think) be considered business associates - yet how the covered entity manages their burden - out of scope for HEART discussions. Other commercial ventures - Personal Data Stores .... many do appear to have business models that rely upon providing service value add for both providers and insurance companies - may be business associates for but in general - lets assume 3rd party app. <br></p><p>Suggesting a subset of Nancy's initial list and would like to skip Eve's first suggestion to just choose a resource ( because there will be many) and suggest we move directly to defining a resource set with a focus on the virtual clipboard /patient intake and expand from there. Ultimately the RS will create their own but would like to see (if permitted) an example or 3 in the profile to react to. <br></p><span class=""><p><span style="color:rgb(31,78,121)">Patient demographics</span></p><p><span style="color:rgb(31,78,121)">Allergies</span></p><p><span style="font-family:symbol;color:rgb(31,78,121)"><span><span style="font:7pt "times new roman""></span></span></span><span style="color:rgb(31,78,121)">Problems & Health concerns (Conditions)</span></p></span><p><span style="font-family:symbol;color:rgb(31,78,121)"><span><span style="font:7pt "times new roman""> </span></span></span><span style="color:rgb(31,78,121)">Smoking Status </span></p><p><span style="font-family:symbol;color:rgb(31,78,121)"><span><span style="font:7pt "times new roman""></span></span></span><span style="color:rgb(31,78,121)">Care Team and/or Practitioner </span><br></p><p><span style="font-family:symbol;color:rgb(31,78,121)"><span><span style="font:7pt "times new roman""></span></span></span><span style="color:rgb(31,78,121)">Medications</span></p><p><span style="font-family:symbol;color:rgb(31,78,121)"><span><span style="font:7pt "times new roman""></span></span></span><span style="color:rgb(31,78,121)">Immunizations </span></p><span style="color:rgb(31,78,121)"></span><p>My assumption is that we are defining resource set types, scopes, and claims-gathering flows. There has been some talk about both UMA and UMA+ or UMA 2016 - If this cannot be done with UMA 1.0 - lets clarify that point sooner than later.</p><p>Hope to see many of you on the call tomorrow.</p><p>Deb<br></p><p><br></p></div><div><br><br><br></div></div>
</blockquote></div><br></div>