<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><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><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>