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

Wed Aug 10 18:57:02 UTC 2016

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-
> bounces 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160810/1d44ada3/attachment-0001.html>