[Openid-specs-heart] Resource/Scope Proposal #2

Tue Aug 16 21:15:16 UTC 2016

HEART proposal Example 2

(I apologize in advance for such a long email.  Also, sorry for the delay as
I was away on vacation and catching up.)

Justin proposed that team members propose suggested resources, scopes and
what they mean.  The objective is to suggest positive solutions.  None will
be totally 'correct' but that is OK because together these suggestions can
be combined and adjusted to reach the 'correct' solution.  Based on that, I
will create another stab as an alternative.

1.       First, since HEART is based on FHIR, we should not expect any
changes in FHIR, at least for the 1.0 version.  The resources should be the
FHIR resources.  I am stating this as a discrete point.  I think we all
agree, but I would like to know that we do indeed concur.

2.       In an attempt to simplify, my original list of resources was the
list of FHIR resources that are implemented by the Argonaut group.  Since
this is the set that most of the current servers have implemented, we could
expect them to be supported first. (I have no objection to the list being
the complete list of FHIR resources, if that is preferred by the group.)
This subset list also happens to correspond to the Common Clinical Data set.
(I am suggesting that we start with this limited set in the assumption that
we could implement HEART as soon as it is specified.)

*         Patient demographics (Known as 'patient' per FHIR)

*         Allergies

*         Problems & Health concerns (Conditions)

*         Vital Signs  (Category of Observations)

*         Labs

*         Smoking Status  

*         Care Team  (Some vendors have Care Plan of which Care Team is a
subset.)

*         Medications

*         Immunizations 

*         Goals
---- this next subset of resources could expand on the above list and are a
continuation of the Argonaut implementation list.

*         UDI  (Device)

*         Procedures

*         Plan of Treatment

*         Assessment

3.       The chart below is simply to demonstrate to those less familiar
with FHIR how this might work.  All of these results are per patient.

Common Name

FHIR Resource

Category if applies

Other filter

Patient demographics

Patient

Allergies

AllergyIntolerance

Problems and Health Concerns

Condition

Vital Signs

Observation

Vital-signs

Lab Results

DiagnosticReport

Lab

Smoking Status

Observation

Code=72166-2

Care Team

CarePlan

CareTeam

Medications

MedicationStatement

Medications

MedicationOrder

Immunizations

Immunization

Goals

Goal

UDI

Device

Procedures

Procedure

Plan of Treatment

(Still being defined in re-sprint)

Assessment

(Still being defined in re-sprint)

There are different filters for each resource type.  These should not be
addressed by HEART in terms of having our patient, Alice, provide varying
permissions at that level.

The reasons for limiting the resources to a list like this is because they
are already implemented and tested for many servers and because they are a
great first step.  If we can do this in HEART for starters we will have
achieved a lot!

4.       Terminology:  This group often uses different terminology which
causes confusion.  Eve has suggested several times that we focus on
clarifying terminology and has begun that effort in her use case document.
One term that has bothered me in the past is the term 'Resource Set'.  At
the HL7 conference, Josh clarified this for me.  My current understanding is
that UMA uses 'Resource Set' for the same purpose as FHIR uses 'Resource
Type', or as is often shortened in FHIR as 'Resource'.  So in FHIR, if we
request medications for the patient Alice, we refer to the resource
'Medications', while UMA refers to this as a 'Resource Set' for the patient
Alice.  (The result would be a list of medications for Alice.)  If this
understanding is currently incorrect, can someone please correct it?

5.       Grouping of resources:  Let's assume that we have agreed on the
list of FHIR resources.  I propose that we allow Alice to select which of
the list she desires to share, with the addition of choices 'all' or 'none'.
The requests for the resources by the client would still be made
individually for each resource.  (To me the notion of 'resource set' implied
that we would define a set of individual resources - say by some category.
I would advise against using such a notion as it only complicates and does
not add any benefits.)

6.       Scopes

a.       Read/Write

                                                         i.            In
last week's meeting, Justin referenced the current scope stream:
individual, bulk, read, write.  Since we are specifying HEART, I would
assume this is always what the patient is specifying.  So for HEART, the
scope of 'bulk' is not relevant.  Further we have scopes of Read, Write, or
*.  I suggest that we allow Alice to specify Read, Write, and have the
ability to specify both.  These settings can be set either per resource or
for all resources.

Two points should be noted:

                                                       ii.
Current implementations are supporting 'Read' and do not yet support
'Write'.  We may be fine with starting with just 'Read' for version 1.0.

                                                     iii.            Since
Alice is defining what she is willing to share - wouldn't that be the 'Read'
case?  I can imagine that we will see implementations where Alice controls
her RS and in that case could specify 'Write' permissions.  For the
immediate future, I would be surprised if the EMR would allow Alice to give
permissions to Dr. Bob to write to an EMR.  There may be a case where Alice
can give Dr. Bob permission to write to her PHR.

b.       Dates

                                                               i.      My
understanding from yesterday's conversation was that we do not want to
include dates in the scopes on resources, per HEART.  There are date filters
available for some resources, but that is within the FHIR query
specification, an outside of the HEART spec.

                                                             ii.      Eve
raised the objective of having expiration dates associated with the
permissions granted, but that functionality does not apply to resource date
scopes

                                                           iii.      So
'dates' are not considered as a scope per this discussion.

c.       Confidentiality codes:  I was the culprit that initially raised the
case of Alice not wanting to share her HIV condition, but only sharing her
non-HIV condition.  I believe most of us would like to provide such a
feature in HEART, but since that original discussion I am now of the opinion
that we should NOT include this feature in version 1.0.  

                                                         i.
Confidentiality codes were suggested as a potential solution to this issue.
It has been stated that some additional 'magic' needs to occur to make this
viable.  Since it is not currently supported in current FHIR implementation,
adding this to HEART in version 1.0 could derail the effort.

                                                       ii.
Confidentiality codes are defined in FHIR as tags.

                                                     iii.
Confidentiality codes are not implemented in most of the current servers.
Even if they were, there is not a consistent method to consistently code
values across servers. This could lead to inconsistent results and be worse
that not providing the feature at all.

                                                     iv.            If Alice
desired to not share her 'HIV' condition, we would need to add a scope to
the resource request asking the server to withhold data that matches the
requested confidentiality settings.  This scope is not currently defined in
FHIR and we should not be attempting to change FHIR as part of our HEART 1.0
specification.  

                                                       v.            If I
were running a RS, I certainly would not be willing to send Alice's HIV
condition to the client tagged as confidential and expect the client to not
share it - instead I would want to not send the data at all - thus the
requirement to add a new scope - which we should definitely avoid. 

This document is also added as an attachment.

-Nancy

Nancy Lush          

nancy.lush at lgisoftware.com

Lush Group, Inc

Office: (401) 423-9111

28 Narragansett Ave

PO Box 651

www.lgisoftware.com 

Cell:(401) 965-9347

Jamestown, RI 02835

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160816/314825cc/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 3006 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160816/314825cc/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: HEART proposal Example 2.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 18260 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160816/314825cc/attachment-0001.docx>