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

Fri Nov 4 01:37:52 UTC 2016

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!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20161103/89c9d177/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: EveFeedbacktoUMAProfileResourceTypes.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 17049 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20161103/89c9d177/attachment.docx>