[Openid-specs-heart] HEART Scope Design Proposal #1

Thu Aug 11 02:57:52 UTC 2016

Adrian

2. Consent.period

John

On Aug 10, 2016 5:00 PM, "Adrian Gropper" <agropper at healthurl.com> wrote:

> Thank you John for pointing us to a specific document so that we can
> figure out how the UMA AS and UMA scopes might interact with the HL7 work.
> Looking at the spec I can ask a few specific (sic) questions which I have
> numbered below:
>
> (1) To Ken's question, the NYP ROI Authorization Form is at
> https://dl.dropboxusercontent.com/u/8909568/NYP%20authorization.pdf Is it
> fair to say that the FHIR Consent resource http://hl7-fhir.github.io/
> consent.html is designed to capture the content of the executed NYP ROI
> Form in a legally accountable way, regardless of how actual sharing will be
> enforced?
>
> (2) I don't see any particular way to express date ranges in the Consent
> spec. Maybe this is to be handled through extensions. If the purpose of
> standardizing the Consent resource is interoperability, then it seems to me
> that a lot of profiling will need to be done and it's not clear who will do
> that profiling. I believe HL7 FHIR has an 80% rule. Does the Consent spec
> require profiling to reach the 80% level? (Being able to encode the NYP ROI
> Form would meet the 80% threshold for me.) If profiling is needed to reach
> 80%, who will do that profiling?
>
> (3) The Privacy Consent Directive http://hl7-fhir.github.io/
> consent.html#6.4.1.1 introduces the term Substitute Decision Maker which
> is not mentioned anywhere else in the document. Could the UMA AS be the
> Substitute Decision Maker this section is referencing? If so, then point us
> to a spec for Substitute Decision Maker and we will make progress on the
> relationship between FHIR and HEART.
>
> I agree with John that (c) Both is the preferred solution. (b) has nothing
> to do with UMA and HEART. (a) is unrealistic, impractical, and undesirable
> because it assumes a massive bureaucracy that protects all the institutions
> and all of the patients in all circumstances. This kind of bureaucracy has
> been elusive (see the UK NHS care.data news for an example of trying to do
> this in a single national system) and review the history of NHIN for the US
> equivalent. Option (c) is already supported by the UMA spec because it
> allows the UMA resource server to impose whatever jurisdictional and
> business rules it chooses regardless of what the UMA AS authorization token
> and associated scopes may say.
>
> John is clear on the user experience aspects of the discussion. Whether an
> UMA AS chooses to implement FHIR Consent in order to improve the user
> experience may not be relevant to the HEART scope discussion. Authorization
> Servers can compete on their user experience without harming
> interoperability for FHIR endpoints labeled HEART. The interoperability
> rule (be liberal in what you accept and strict in what you send out)
> applies.
>
> (4) The sine-qua-non for interoperability is that any Client labeled HEART
> and any Server labeled HEART must work together under any UMA standard AS.
> Some UMA AS will be FHIR-aware and others will not. Does anyone interpret
> the HEART charter as implying that the AS is somehow healthcare specific?
>
> As for John's suggestion that we get UMA in the FHIRe door first before we
> deal with improvements, let's revisit the date or page range issue as part
> of the relationship between UMA and FHIR as orthogonal standards that we
> are all in favor of after we make some progress on questions (1) to (4).
>
> Adrian
>
>
>
>
>
>
>
> On Wed, Aug 10, 2016 at 4:35 PM, John Moehrke <johnmoehrke at gmail.com>
> wrote:
>
>> Adrian,
>>
>> A Consent Directive is one of the formal terms used for results of a
>> Privacy Consent act/ceremony. Lots of terms for the same thing. There is
>> nothing new being spoken about here. Note these are defined on the FHIR
>> Consent Resource page
>>   http://hl7-fhir.github.io/consent.html
>>
>> In FHIR ballot about to start (STU3) the concept is managed by the FHIR
>> Consent Resource, rather than a profile on contract. This was done to
>> simplify and focus. ANYONE who is an HL7 member, make sure you signup for
>> the ballot NOW. Outsiders can also participate.
>>   www.hl7.org/ctl.cfm?action=ballots.home&ballot_cycle_id=541
>>
>> The FHIR Consent Resource is only a mechanism for capturing the consent
>> meaning. It is not a mechanism for decision making or enforcement. It is
>> also not a mechanism for interacting with the patient (UI).  The FHIR
>> Consent resource is just a resource. It is not a service. It is not an
>> operational environment. It is not an application. Something else would be
>> the method of intervention upon requests for data about a subject, deciding
>> if it is authorized, and enforcing it.
>>
>> Where UMA is a method of making decisions and enforcement. UMA leaves the
>> capturing of the rules that it enforces as an implementation detail of the
>> AS. Nore does UMA define a static format for the rules.
>>
>> Thus one could:
>> a) Use UMA alone, leaving up to UI of the UMA AS to capture the rules,
>> persist the consent experience, etc... This means that UMA AS is used to
>> protect all accesses to protected data about the subject.
>> b) Use FHIR Consent to capture the results of the consent ceremony; and
>> all data holding servers would look to the FHIR Consent rules when they
>> themselves decide if a request for data is authorized.
>> c) Use FHIR Consent to capture the results of the consent ceremony; and
>> use UMA to make data request authorization decisions.
>>
>> So, you could use one, or the other, or both. There is no need for us to
>> constrain one or the other. But we should be aware of all. Clearly the best
>> combination from a standards perspective is (c); but it is also the most
>> complex UMA AS.
>>
>> Neither of these is dependent on Scopes. Scopes are an optimization
>> factor. The better aligned Scopes are to the consent rules, the fewer UMA
>> authorization decisions need to be made. If Scopes align well, then one
>> decision authorizing a broader scope value can be re-used in many different
>> transactions by an application against a resource sever. If the scopes
>> don't align well, then authorization decisions need to be on a request by
>> request basis. This is just an optimization. It does not inhibit the rules
>> that the UMA can enforce. I believe I am right, so if I am wrong I hope
>> someone from OAuth/UMA community can illuminate my mistake.
>>
>> This is why I recommend we just pick some scopes for now. Similar to what
>> SMART did, they just picked something that was easy to pick.  The real
>> magic that we are enabling is to have UMA involved, and thus getting "User"
>> "Managed" "Access" (Aka Patient Centric Authorizations). Once we get UMA in
>> this position, the UMA AS can be improved.
>>
>> 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 Wed, Aug 10, 2016 at 1:57 PM, Adrian Gropper <agropper at healthurl.com>
>> wrote:
>>
>>> What is a consent directive?
>>>
>>> What is the relationship of whatever it is to FHIR or any other standard
>>> data model?
>>>
>>> How does a consent directive interact with OAuth, UMA or OpenID Connect?
>>>
>>> Do you have an example of how a consent directive maps into, replaces,
>>> or changes the NYP ROI authorization form?
>>>
>>> Thanks,
>>>
>>> Adrian
>>>
>>>
>>>
>>> On Wed, Aug 10, 2016 at 2:49 PM, Salyards, Kenneth (SAMHSA/OPPI) <
>>> Kenneth.Salyards at samhsa.hhs.gov> wrote:
>>>
>>>> Fine grained authorization should be dealt with using a patients’
>>>> consent directive. FHIR DSTU2 supports consent directive as part of the
>>>> contract resource. In DSTU3, as I understand the consent directive will not
>>>> be part of contract. This can work seamlessly within the UMA resource
>>>> server construct. Ken
>>>>
>>>>
>>>>
>>>> *From:* Openid-specs-heart [mailto:openid-specs-heart-bou
>>>> nces at lists.openid.net] *On Behalf Of *Vivek Biswas
>>>> *Sent:* Wednesday, August 10, 2016 1:50 PM
>>>> *To:* Adrian Gropper; openid-specs-heart at lists.openid.net
>>>> *Cc:* Josh Mandel; Grahame Grieve
>>>>
>>>> *Subject:* Re: [Openid-specs-heart] HEART Scope Design Proposal #1
>>>>
>>>>
>>>>
>>>> Hi Adrian,
>>>>
>>>>
>>>>
>>>> The scopes are meant to do coarse-grained authorization and not fine
>>>> grained authorization.
>>>>
>>>>
>>>>
>>>> And hence, this one of the reason why scopes are static string.
>>>>
>>>>
>>>>
>>>> If one want to perform fine grained authorization, then its based on
>>>> lot of contextual information like you mention, date-range, geo-location,
>>>> etc....
>>>>
>>>>
>>>>
>>>> The contextual information can reside in the Request Payload, in
>>>> database, within the access token (if JWT) etc. All these contextual
>>>> information associated with the request can be trusted only if the access
>>>> token is valid.
>>>>
>>>>
>>>>
>>>> There can be a policy associated with context which can help us to
>>>> decide if the request should be authorized or not.
>>>>
>>>>
>>>>
>>>> So, scopes can help you do first level of coarse grain authorization
>>>> which will yield you an access token. Once an access token is valid, grab
>>>> the contextual information from the payload, header, access token etc. Find
>>>> a policy associated with the contextual object and than perform fine level
>>>> authorization based on the policy.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Regards
>>>>
>>>> Vivek Biswas, CISSP
>>>>
>>>> Consulting Member @Oracle
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------
>>>>
>>>> *From:* Adrian Gropper <agropper at healthurl.com>
>>>> *To:* "openid-specs-heart at lists.openid.net" <
>>>> openid-specs-heart at lists.openid.net>
>>>> *Cc:* Justin Richer <jricher at mit.edu>; Vivek Biswas <
>>>> vivek_biswas at yahoo.com>; Josh Mandel <jmandel at gmail.com>; Grahame
>>>> Grieve <grahame at healthintersections.com.au>
>>>> *Sent:* Tuesday, August 9, 2016 12:57 PM
>>>> *Subject:* Re: [Openid-specs-heart] HEART Scope Design Proposal #1
>>>>
>>>>
>>>>
>>>> There are many reasons why we need to find a way:
>>>>
>>>>    1. I have never seen a release of information form that did not
>>>>    have a date range. Has anyone? If we say HEART can't do that we're calling
>>>>    into question the legitimacy of HEART.
>>>>    2. We have a lot of experience with 75-page CCDAs with the current
>>>>    standards. Many patients have huge health records and it is
>>>>    resource-intensive to get 74-pages of information you already had in order
>>>>    to find the change from the last encounter. The cost is not just on the
>>>>    sender but on the recipient as well. This is probably the top complaint of
>>>>    the current interop methods in my medical society.
>>>>    3. I don't think the HEART charter set a particular limit on how
>>>>    much of FHIR we would manage. It's not in our charter to treat effective
>>>>    provider-to-provider exchange as out-of-scope. Once we say that HEART will
>>>>    not support the full patient-level feature set of FHIR, where do we draw
>>>>    the line?
>>>>    4. UMA is not OAuth. The goals of the two standards are very
>>>>    different. UMA and HEART are patient-centered. If we restrict HEART to a
>>>>    small fraction of the longitudinal health records or patient-centered
>>>>    health rerecords transactions (because most of the traffic stays in the
>>>>    batch or institution-to-institution domain) then where do we host the
>>>>    discussion on a future for patient-centered records?
>>>>    5. There is no logical reason for HEART to not support date ranges
>>>>    once FHIR has that capability. In some jurisdictions, this would be seen as
>>>>    reducing patient's right of access and subject to legal challenge.
>>>>
>>>> I've added Josh and Grahame to this thread. Let's try and find the
>>>> solution to this problem even if it involves changing UMA, FHIR or both.
>>>>
>>>> Adrian
>>>>
>>>>
>>>>
>>>> On Tue, Aug 9, 2016 at 12:31 PM, Vivek Biswas <vivek_biswas at yahoo.com>
>>>> wrote:
>>>>
>>>> I agree with Justin, that scopes are static string vs scope string be
>>>> parameterized. Most of the OAuth server support static string.
>>>>
>>>>
>>>>
>>>> It will get challenging to implement a profile which requires dynamic
>>>> string which in turn will hamper the adoption of HEART.
>>>>
>>>>
>>>>
>>>> We are trying to add contextual information into the scope which are
>>>> not what scopes are intended for.
>>>>
>>>>
>>>> Regards
>>>>
>>>> Vivek Biswas, CISSP
>>>>
>>>> Consulting member @Oracle
>>>>
>>>>
>>>> On Aug 9, 2016, at 9:17 AM, Justin Richer <jricher at mit.edu> wrote:
>>>>
>>>> A problem I can see with this is that the “date” field in particular
>>>> moves this from something that’s expressible as a table of known strings
>>>> (like in the appendix of the current spec) to something that’s dynamically
>>>> parameterized with a potentially infinite set of values. This is a problem
>>>> in practice as many OAuth implementations treat all scopes as static
>>>> strings, and will do things like limit set set of scopes a client is
>>>> allowed to ask for based on a set of registered strings. That’s not
>>>> possible with a field like “date” anymore, since the value is filled in at
>>>> runtime. We tried to have parameterized scopes in BB+ (and even implemented
>>>> it) but it was generally thought to be too complicated, and required
>>>> special tooling at the authorizations server.
>>>>
>>>>
>>>>
>>>> If at all possible, I’d like HEART scopes to not require such special
>>>> processing and support at the AS.
>>>>
>>>>
>>>>
>>>>  — Justin
>>>>
>>>>
>>>>
>>>> On Aug 8, 2016, at 9:08 PM, Adrian Gropper <agropper at healthurl.com>
>>>> wrote:
>>>>
>>>>
>>>>
>>>> Scope Design Proposal #1 aims to support a typical ROI authorization
>>>> <https://dl.dropboxusercontent.com/u/8909568/NYP%20authorization.pdf>.
>>>>
>>>> The structure of SDP1 is: patient/date
>>>> <http://hl7.org/fhir/search.html#date>/confidentialitycl ass
>>>> <http://hl7-fhir.github.io/v3/ConfidentialityClassification/vs.html>/
>>>> resource <http://hl7.org/fhir/resourcelist.html>/edit
>>>>
>>>>
>>>> The logic is as follows:
>>>>
>>>>    - /patient because this applies to only one patient at a time. The
>>>>    patient ID is local to the resource server.
>>>>    - /date <http://hl7.org/fhir/search.html#date> is defined by FHIR
>>>>    and can be a range. Putting it at the highest level in the hierarchy (if a
>>>>    scope hierarchy is useful) allows for efficiency in clients requesting
>>>>    updates and reduces the cost to the resource server
>>>>    - /confidentialityclass
>>>>    <http://hl7-fhir.github.io/v3/ConfidentialityClassification/vs.html>
>>>>    filters for resources at or below the specified value. Resources that do
>>>>    not have a confidentiality class are considered N - Normal. It is up to the
>>>>    resource server to provide jurisdictictionally appropriate policies and
>>>>    user interfaces for setting confidentiality class other than N on
>>>>    particular resources.
>>>>    - /resource <http://hl7.org/fhir/resourcelist.html> is any resource
>>>>    listed in the particular version of the FHIR specification
>>>>    - /edit is "read", "write", "any" operation by the client on the
>>>>    resource
>>>>
>>>> A client might request a scope for immunizations for patient 23 as:
>>>>
>>>> [ "date=le2016-8-8","conclass=N" , "resource=Immunization", "edit=read" ]
>>>>
>>>> on a resource registered as: [base]/Patient/23/ with a reference to HEART scopes SDP1
>>>> that would tell both the AS and anyone else that dereferenced HEART/SDP1 that the RS would
>>>> process specific scope strings for date, confidentialityclass, resource, and edit as described above.
>>>>
>>>> The AS would be free to present SDP1 to the RO any way that it chose.
>>>>
>>>> A resource server like NYP that wanted to offer registration for sensitive data like Mental Health Treatment
>>>> would register another resource: [base]/Patient/23/ MentalHealthTx with whatever scopes it offered.
>>>> These additional resources would not be specified by HEART.
>>>>
>>>> Any particular RS could choose to support Confidentiality Class, additional resources, neither, or both.
>>>>
>>>> It would be up to the AS to combine HEART SDP1 resources and additional resources and scopes offered by the RS into whatever policy setting experience it wanted.
>>>>
>>>> With this scheme, an AS might offer Alice a policy setting for
>>>> Observation = R - Restricted even on a resource server that did not support
>>>> confidentiality class. This would cause all client requests for
>>>> Observations to fail because the RS would be forced to treat unlabeled
>>>> resources as N and the authorization tokens for observations were R. The RS
>>>> could:
>>>> (a) ignore this problem and treat it as an AS bug,
>>>> (b) implement confidentiality classification, or
>>>> (c) offer additional resources and scopes so that the AS could tell
>>>> Alice that Observations did not include those related to mental health in
>>>> the hope that Alice would set Observation = N and deal with mental health
>>>> as a separate part of her policy.
>>>>
>>>> I believe that, to a first approximation, SDP1 would capture the
>>>> functionality of most sharing use-cases without forcing the RS to do
>>>> anything more than it is jurisdictionally already required to do.
>>>>
>>>> Adrian
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>>
>>>>
>>>> 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/
>>>> <http://patientprivacyrights.org/donate-2/>
>>>>
>>>> ______________________________ _________________
>>>> Openid-specs-heart mailing list
>>>> Openid-specs-heart at lists. openid.net
>>>> <Openid-specs-heart at lists.openid.net>
>>>> http://lists.openid.net/ mailman/listinfo/openid-specs- heart
>>>> <http://lists.openid.net/mailman/listinfo/openid-specs-heart>
>>>>
>>>>
>>>>
>>>> ______________________________ _________________
>>>> Openid-specs-heart mailing list
>>>> Openid-specs-heart at lists. openid.net
>>>> <Openid-specs-heart at lists.openid.net>
>>>> http://lists.openid.net/ mailman/listinfo/openid-specs- heart
>>>> <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/
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> 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
>>>
>>>
>>
>
>
> --
>
> 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/20160810/19d5e41e/attachment.html>