[Openid-specs-heart] Resources vs Resource sets

[Adrian Gropper]

Dearest Debbie, (or is it Debbie Dearest?)

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, digi.me is a startup that just raised
money including a major insurance company. The founder describes their
business as:

“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
https://techcrunch.com/2016/06/30/digi-me-bags-6-1m-to-put-users-in-the-driving-seat-for-sharing-personal-data/


Most of all, please read this recent report by your very office:
https://www.healthit.gov/buzz-blog/privacy-and-security-of-ehrs/examining-oversight-privacy-security-health-data-collected-entities-not-regulated-hipaa/
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.


Finally, and also relevant, please note the HEART charter says: *"Support
independent authorization services and identity providers, to be chosen by
people who may build, run, or outsource these services."* (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.


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.


Adrian

On Sun, Jul 31, 2016 at 11:05 AM, Debbie Bucci <debbucci at gmail.com> wrote:

> Wow  - what a lively discussion.   Overall impressions thoughts:
>
> Scope of HEART - Consumer -Patient Mediated exchange (read and write -
> push/pull):
>
>    - Provider [in US called covered entity] to consumer [patient] 3rd
>    party app
>    - Consumer [patient] to Provider or Donation for research or even
>    another 3rd party app
>    - others
>    - 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
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> Patient demographics
>
> Allergies
>
> Problems & Health concerns (Conditions)
>
>  Smoking Status
>
> Care Team and/or Practitioner
>
> Medications
>
> Immunizations
>
> 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.
>
> Hope to see many of you on the call tomorrow.
>
> Deb
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160731/e1f86159/attachment.html>