[Openid-specs-heart] Resources vs Resource sets

[Debbie Bucci]

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/b990f07c/attachment.html>