[Openid-specs-heart] Resource/Scope Proposal #2
John Moehrke
johnmoehrke at gmail.com
Wed Aug 17 13:55:49 UTC 2016
>
> didn't realize this was only to Nancy.-- so reflecting to the list.
>
> Hi Nancy,
>
> I suggest this - multi-generation plan - approach simply because I know
> that the vectors through the healthcare-privacy space are close to
> infinite. I think we should pick the battles we win, one at a time. Getting
> a UMA system in place for healthcare would be a huge improvement. Even if
> it had next to no flexibility in scopes. The concept of "User Managed
> Access" is so powerful to enable a patient to allow others (human or
> computer) to access their data and thus improve their life. We are
> deadlocked on details that can be improved later. By writing down the items
> we are deferring, we create a backlog to pull from in future iterations. I
> recognize however that privacy advocates (I count myself one) have heard
> this multi-generation approach before and they have scars to show that only
> the first generation ever gets accomplished. I sympathize, and say to them
> that this is even more proof that the first generation should be
> under-powered. I will repeat, getting UMA in place is very powerful, even
> with just Read/Write as scope. We have alot of trust and infrastructure
> issues with just this. I don't want to stop there, hopefully this is clear
> by my email an blog posts. However I am frustrated at the stalemate we have
> wrapped around something that is not the most important improvement
> overall. (Note this i also why SMART scopes are so simplistic, as use of
> OAuth is more important than the scopes we will invent in the coming decade)
>
> 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 6: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
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160817/ebedbd39/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/20160817/ebedbd39/attachment-0001.gif>
More information about the Openid-specs-heart
mailing list