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

Adrian Gropper agropper at healthurl.com
Tue Aug 9 01:08:02 UTC 2016


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>/confidentialityclass
<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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160808/addcccb1/attachment.html>


More information about the Openid-specs-heart mailing list