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

Wed Aug 17 13:54:20 UTC 2016

Adrian,

This is exactly why the HL7 Security WG and CBCC WG (privacy) have pushed
so hard to keep the Access Control layer out of the FHIR specification.
Access Control needs to be independently developed and managed from the
data-model; it needs to leverage -access control- infrastructure
improvements from the greater IT world; and it needs to be dynamic
(policy). This is why we (hl7 privacy and security experts) have pushed for
pointing at HEART, and resisted any tight linkage within the FHIR
specification. I will note that this is getting harder as leadership in
some regions want a single source for a complete system; they don't
appreciate the layered approach.

John

John Moehrke
Principal Engineering Architect: Standards - Interoperability, Privacy, and
Security
CyberPrivacy – Enabling authorized communications while respecting Privacy
M +1 920-564-2067
JohnMoehrke at gmail.com
https://www.linkedin.com/in/johnmoehrke
https://healthcaresecprivacy.blogspot.com
"Quis custodiet ipsos custodes?" ("Who watches the watchers?")

On Tue, Aug 16, 2016 at 9:16 PM, Adrian Gropper <agropper at healthurl.com>
wrote:

> Proposal #2 highlights the central issue for HEART: Will patient-directed
> exchange be a second-class or accessory approach to interoperability based
> on FHIR?
>
> FHIR itself is neither patient-directed or not. It's a global
> specification for how to access a person's health data. The authorization
> layer on top of FHIR is what determines the role of patients relative to
> EHR vendors and institutions, the meaning of patient-directed exchange, and
> the ability for innovation in healthcare.
>
> Right now, EHR vendors are the unchallenged gatekeepers of practice
> innovation. Proposal #2 makes this clear again and again by highlighting
> the role of EHR vendors, not physicians or even hospitals, as the critical
> concern for the scope of HEART. At one point, the proposal admits that it
> might not even support our PHR use-case.
>
> From another perspective on the relationship between HEART and FHIR, we
> must recognize that FHIR is primarily designed to access records via a
> query mechanism rather than "static" resource URIs. The consequence of
> HEART ignoring this design fundamental cannot be overstated. Excluding
> query support from HEART ensures second-class status for patient-directed
> exchange and makes HEART potentially useless for longitudinal patient
> records that combine clinical, environmental, and social data for a
> particular patient.
>
> How many of us would consent to providing scope of access to our
> environmental and social exposures without control over the range of dates,
> location, or other constraints on search? The combination of clinical,
> environmental, and social data is essential to achieve the full potential
> of both research and clinical decision support. Is HEART a vision where EHR
> vendors and hospital networks control our personal environmental and social
> data as well as our clinical?
>
> Let's take a simple example of some service providing decision support, in
> the form of a second opinion. Will the patient be able to decide the scope
> of data to be considered for that second opinion or will the opinion be
> filtered through the process and interests of the EHR vendor and hospital?
> What is the meaning of second opinion and informed consent if HEART accepts
> that limitation?  Is HEART promoting practice innovation and investment in
> innovative services if these services cannot get first-class access to the
> patient's entire FHIR interface under patient direction?
>
> HEART that cannot support the major mode of access to FHIR puts patients,
> families, and innovators at the mercy of a handful of EHR vendors. We have
> deep experience on how that turns out.
>
> Adrian
>
>
> On Tue, Aug 16, 2016 at 7:15 PM, Nancy Lush <nlush at lgisoftware.com> wrote:
>
>> Interesting.  I had not thought about that third case.
>>
>>
>>
>> So when you say ‘I don't think we should try to put this kind of thing
>> in a scope; yet’ – Should this team define cases that we would like to
>> solve, but which will not be solved in a version 1?
>>
>>
>>
>> -Nancy
>>
>>
>>
>> *From:* John Moehrke [mailto:johnmoehrke at gmail.com]
>> *Sent:* Tuesday, August 16, 2016 7:03 PM
>> *To:* Nancy Lush <nlush at lgisoftware.com>
>> *Cc:* HEART List <openid-specs-heart at lists.openid.net>
>> *Subject:* Re: [Openid-specs-heart] Resource/Scope Proposal #2
>>
>>
>>
>> I want to clear up what seems to have gotten confused.
>>
>>
>>
>> There are a few places where date-ranges are needed.
>>
>> 1. How long is this authorization statement valid ---  This is a
>> not-before, not-after. This is typically short-term specific to an
>> authorization decision. OAuth includes this in the token
>>
>> 2. How long is this policy statement valid -- when I give rules to the
>> UMA AS, how long do I want this to last. This is around the authorization
>> rules. For example, I am authorizing doctor Bob to have access to my data
>> for 24 months. This is commonly seen as an expiration of a consent. This is
>> what the period element in the FHIR consent is for. UMA might have internal
>> values for this, but no need to expose this. Clearly (1) would need to be
>> shorter than (2) when the deadlines approach.
>>
>> 3. The period for which a rule applies. For example I authorize access to
>> my data, except NOT the data created during 1998. Or I authorize access to
>> Joe any data that was created during 1998.
>>
>>
>>
>> It is this third one that gets involved in a scope discussion. I don't
>> think we should try to put this kind of thing in a scope; yet. It is
>> however likely the top priority vector for rules. Often times a patient
>> knows a timeframe that they wish the world to forget.
>>
>>
>>
>> John
>>
>>
>> John Moehrke
>> Principal Engineering Architect: Standards - Interoperability, Privacy,
>> and Security
>> CyberPrivacy – Enabling authorized communications while respecting Privacy
>> M +1 920-564-2067
>> JohnMoehrke at gmail.com
>> https://www.linkedin.com/in/johnmoehrke
>> https://healthcaresecprivacy.blogspot.com
>> "Quis custodiet ipsos custodes?" ("Who watches the watchers?")
>>
>>
>>
>> On Tue, Aug 16, 2016 at 4:15 PM, Nancy Lush <nlush at lgisoftware.com>
>> wrote:
>>
>> 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
>>
>>
>>
>> [image: LGI_logo_small]
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Openid-specs-heart mailing list
>> Openid-specs-heart at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>>
>>
>>
>> _______________________________________________
>> 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/
>
> _______________________________________________
> 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/20160817/19d14ca7/attachment.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/20160817/19d14ca7/attachment.gif>