[Openid-specs-heart] New thread - What is in a clipboard resource set?

[Eve Maler]

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

   - Use case
   <https://bitbucket.org/openid/heart/wiki/Alice_Shares_with_Physicians_and_Others_UMA_FHIR>
      - PGHD
      <https://www.healthit.gov/policy-researchers-implementers/patient-generated-health-data>
      - Common Clinical Data Set
      <https://www.healthit.gov/sites/default/files/commonclinicaldataset_ml_11-4-15.pdf>
      - Virtual clipboard
      <https://www.wedi.org/home/virtual-clipboard-to-improve-patient-data-collection>
      (this link
      <http://www.wedi.org/docs/default-document-library/virtual-clipboard-definition-and-design-document.pdf?sfvrsn=0>
      is actually more helpful -- I've changed it in the use case)

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:

   1. Virtual clipboard
   2. Basic patient profile /Patient)
   3. Medication history (/MedicationDispense, /MedicationAdministration)
   4. Immunizations (/Immunization.vaccineCode , /Immunization.status)
   5. Allergies (/AllergyIntolerance)
   6. Problem list /Condition.code, /Condition.status)
   7. Labs (/DiagnosticReport.code - LOINC
   /DiagnosticReport.codedDiagnostics - SNOMED)
   8. Basic insurance info? EOB?
   9. (what else? Keep it simple)

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.

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.

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?

Third, there would be some kind of a "matrix of requesting-side
appropriateness" for what is to be shared:

   - *Payment info:* 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.
   - *Provider services:* There *may* 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.

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 *available* in the record, and Alice chooses to
share it as part of the "virtual clipboard" resource set context, then it
*must* 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.


*Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging Technology
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
*ForgeRock Summits and UnSummits* are coming to
<http://summits.forgerock.com/> *Sydney, London, and Paris!*

On Tue, Jul 19, 2016 at 4:51 AM, Debbie Bucci <debbucci at gmail.com> wrote:

> Now that we agree the RPT is essentially an suthorization to release ...
> changing thread to focus on resource set.
>
> >>Can you elaborate a little on what you're thinking in terms of defining
> a resource set? I imagine that the "clipboard" resource set would vary
> quite a bit based on the provider and their specialty. Are you suggesting
> that we attempt to define a universal set of fields that everyone would
> need as a baseline?
>
> Really need someone that knows FHIR in great detail to weigh in but ....
>
> it seems to me that there are general classes to authorize (meds allergies
> etc) that could generally be placed in the resource set to allow specific
> implementations to gather the info needed within those classes throttled by
> the classification code.
>
> I was going to look at a few examples but as I recall - with exceptions to
> specialty specific questions much of the paper form are the exact same
> questions from provider to provider
>
> >>Or are you thinking that we should just acknowledge the existence of
> something called a clipboard resource set, and let implementors decide for
> themselves what that means?
>
> Believe there needs to be some consistency but ack need for extensions
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160721/aa07c233/attachment.html>