[Openid-specs-heart] V2 of Profiling UMA for FHIR slides

Fri Nov 4 02:13:08 UTC 2016

Below is the list of resources offered by the VA.

I think we could engage FHIR experts to help HEART document the gaps
between the VA list the current FHIR specs. Or not.

I'm not in favor of HEART doing anything in the first version to profile
FHIR beyond this gap analysis. Further profiling around FHIR is an exercise
in user-experience design that's not a core HEART capability or it's a job
for the HL7 folks who are responsible for the gaps in the first place.

That said, HL7 or some other group, might decide to standardize
"sensitivity codes" and other metadata instead of changing the resource
semantics. HEART is not configured to do sensitivity code design or any
other metadata enhancements to an API standard. We can consider that
sensitivity codes will be added in the future and, if they are, the VA
Selected Data chooser will be changed accordingly.

[image: Inline image 1]

Adrian

On Thu, Nov 3, 2016 at 9:37 PM, Nancy Lush <nlush at lgisoftware.com> wrote:

> Hi Eve,
>
>
>
> I will apologize in advance for the length of this reply.  I have also
> included it as a word document in case anyone finds that easier to read
> then an email thread.
>
>
>
> I will provide feedback on the 2nd of your two slides, as that seems to
> be the most recent version.
>
>
>
> From the overview perspective, I suggest that we start our focus on
> providing a standard that will work for known use cases.  Whatever we
> define, the innovators will innovate, and new use cases will arise.  We
> should not be trying to control that.  Suggested use cases at the end of
> this feedback.  (Since I started writing this, Adrian has suggested use
> case. I support those.)
>
>
>
> Feedback on your slides:
>
> ·         From the physician perspective (Please, physicians on the list
> please feel free to provide your perspective.)
>
> o   Medications – A physician is very unlikely to query whether Alice is
> taking Medication A.  Instead, he or she asks to see Alice’s medication
> list.  Then they know all the medications she is taking.  (It is normally
> important for them to have the complete list.)
>
> §  You raised another point on the call – how to handle over the counter
> and supplements.  Often, if they are recorded at all at the EMR they are
> recorded in the med list.  While I agree, there should be a place for these
> in the medical record, that is out of scope for this task.
>
> o   Blood Glucose/lab results
>
> §  This is a tricky topic because FHIR has grouped several categories in
> the observation resource type.  I would love to see those separated but do
> not know if that is an option with our HEART spec.
>
> §  Let’s assume for the purpose of this conversation that we are looking
> at the medical data set of lab results.  It may be that the doctor is
> interested in Alice’s blood glucose reading over time.  But we can also
> leave this to the client app to address that specific functionality.
>
> ·         As an example, in our FHIR prototype app, we display lab
> results by lab date.  When the user drills down to the most recent lab
> results, they may notice that Alice’s blood glucose is out of normal
> range.  They click that and get a graph of this blood glucose reading over
> time.  That is a feature delivered by an app.  We don’t need to have Alice
> specifying any different policy around this feature or the physician doing
> any special requests.  It is just an intuitive drill down on available data.
>
> o   Appointment data since some point in time.
>
> §  I am not sure why a physician may be looking at this.  They would have
> it in their own EMR.  Would they need to go to another data source to
> determine this information?
>
> o   Entire Vaccine History.  Yes, you have this correct – the physician
> is interested in their entire vaccine history.  They certainly would not
> want to limit it by date range since that could eliminate key data.
>
> ·         From the patient objective.
>
> o   Medication List – Yes, the patient would want to see their list of
> medications and that is meaningful to the patient.
>
> o   Blood Glucose readings for a specific week – A client app could
> derive this information form either lab results or records coming from a
> personal device.  Refer to use cases below.
>
> o   Appointments.  Yes, a patient would want to get a list of upcoming
> appointments.  There has not been as much work with this resource in
> current FHIR implementations that I am aware of.  Largely, it seems that
> more patients have access to this information and it is not ‘Clinical
> Data’.  But certainly this resource is important in the patient’s care
> management.
>
> o   Four-strain flu vaccine.  I believe the patient can meet this
> requirement by viewing their current immunization list.
>
> I began to list Use Cases, but Adrian has already listed known common use
> cases.  I agree with these, with the exception of perhaps the last case
> that might require more explanation.
>
>
>
> The point for HEART at this stage is that we can move this process along
> significantly by identifying a few known use cases and addressing the whole
> process to support these.  Will we have all use cases?  No.  We need to let
> our innovators innovate – they will define many use cases we have not
> considered and that should be encouraged.  Our current known sources of
> information include EMRs, HIEs and PHRs.  But we have another round of
> details with IoT and other sources.  I don’t know which institutions are
> implementing the device resource and if that needs to be refined, but we
> will discover this as folks begin to use these features.  We certainly will
> have instances of RSs that exchange fitbit data, scale data, and blood
> glucose readings as examples.
>
>
>
> My guess is that eventually Alice may be asked to select which resources
> she will share, with whom, from each of the RSs that contain her data.
> From that perspective, we should allow each RS to define the resource sets
> they support, along with a ‘User-friendly’ description that would be
> provided to the user. It would include an API definition.  As RSs engage,
> we should have groups working to certify so that client apps can expect the
> same response for a given resource type across RSs.  Past that, we should
> let it sort itself out.
>
>
>
> So we could say we support ‘these 8 resource types’, or 17 or whatever.
> But the industry will be able to identify more to be included in the mix.
>
>
>
> If we can start with a reasonable first resource type list and a
> reasonable list of example use case, then we will have empowered our
> innovators.
>
>
>
> Back to your power point slide, Let’s assume that there is an RS that
> contains data collected from a series of devices Alice uses to manage her
> diabetes.  Let’s assume one of those is Blood Glucose readings.  The RS
> resource set may be different than the observation lab results data set.
> In fact, that may come in as a device resource per the FHIR API.  So for
> that case the ‘Blood Glucose readings since a defined date’ would be of
> interest to both the clinician and the patient.  And in fact it might be
> nice if the client app charted that data or provided some other insightful
> presentation to both Alice and the clinician.
>
>
>
> One last point:  My current thinking is that Alice should be provided the
> ability to define scopes in at least three mutually exclusive areas.
> (Others may have other thoughts.)
>
> 1.       All (None – that would be an absence of an authorization.)
>
> a.       This would imply all resources supported by this RS without
> limitations
>
> 2.       Selected Resources by Resource type
>
> a.       This could include specific resource types
>
> b.       It might also allow all resource type Except indicated Resource
> types
>
> 3.       Share by sensitive data indication
>
> a.       This may be an option to either
>
>                                                                i.      Exclude
> all sensitive data
>
>                                                              ii.      Exclude
> specific kinds of sensitive data as defined in our sensitive data tagging.
>
> b.       As have been both pointed out and argued by this group, this
> feature requires certain magic to be defined and resolved.  There are
> groups working on sorting out the details of this.  I recommend we not get
> bogged down by this detail at this time and continue on with the remaining
> options (1 & 2 above) for now.  We should just know that this is coming.
>
> c.       Ken has argued that providing Alice the ability to manage access
> by data sensitivity is more meaningful than limiting by FHIR resource
> type.  I think that using Resource Type for a first pass will provide
> benefit and that they are close to what patients will understand if we use
> a limited set. (Ex:  Medication list, problem list, list of allergies,
> patient demographics, vital signs, etc.)  Eventually, once we can support
> sensitivity data, that may replace the resource set type option as Alice’s
> preferred method.
>
>
>
> -Nancy
>
>
>
> *From:* Openid-specs-heart [mailto:openid-specs-heart-
> bounces at lists.openid.net] *On Behalf Of *Eve Maler
> *Sent:* Tuesday, November 01, 2016 12:00 PM
> *To:* openid-specs-heart at lists.openid.net
> *Subject:* [Openid-specs-heart] V2 of Profiling UMA for FHIR slides
>
>
>
> As discussed on the call, the exercise is to figure out *Alice's
> motivation for sharing* the various data sets (FHIR resources in scope)
> vs. *the provider's motivation for wanting access* to them.
>
>
>
> The ones listed on the slides aren't necessarily the ones Nancy et al.
> listed on the call/in email, so please don't take the slides versions as
> gospel!
>
>
>
> Please identify the specific use cases/scenarios you have in mind. By
> drilling down on this, we can get an idea of the interplay among the FHIR
> API design, the UMA resource set boundaries and scopes as Alice may want to
> experience them, and the API calls as the provider's client applications
> may want/need to make them. I believe this will have a big impact on how we
> can/will profile.
>
>
> *Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging
> Technology
> Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
> *The ForgeRock Identity Summit* is coming to
> <http://summits.forgerock.com/> *Paris in November!*
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>

-- 

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE: http://patientprivacyrights.org/donate-2/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20161103/2139fc16/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MyHealtheVet Resources.png
Type: image/png
Size: 108856 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20161103/2139fc16/attachment-0001.png>