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

[Debbie Bucci]

On Thu, Jul 21, 2016 at 11:39 AM, Eve Maler <eve.maler at forgerock.com> wrote:

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

Agree - basic info to start the conversation - vs. a clinical referral for
specific illness  - that may be a follow-on request.


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

If we focus on convenience first  - then other benefits may follow.

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

Agree no labs and EOB but in US basic insurance (payer as noted below) info
will  be needed.   Is emergency contact part of demographics (need to
look).   How do capture both OTC meds, herbs ect?  (some of that may be
covered as well)   Some information ex: - why are you making the
appointment and other things of that nature would be out of scope - or
perhaps an extension?



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

Agree
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160721/94c34ee2/attachment.html>