Stream: Security and Privacy
Topic: Consent Service
James Agnew (Jun 11 2019 at 13:55):
At the San Antonio WGM tooling meeting (I hope I'm getting the timeline right..) @Grahame Grieve proposed a generic user-implementable API that would allow a developer to implement a consent service on top of a FHIR repository. The motivation was to create a fairly low-level API that is flexible and powerful enough that it could be used by developers to implement anyone's notion of consent. I.e. it makes on assumptions on how a Consent resource (or consent directives more generally) should be interpreted, but provides the infrastructure so that someone could write that interpretation in code and have it enforced by the server.
In case it's of interest, at DevDays today I'm going to touch briefly on a new proof-of-concept implementation of this that is being added to HAPI FHIR.
This is the user visible API that implementers would have to implement:
https://github.com/jamesagnew/hapi-fhir/blob/ja_consent_svc/hapi-fhir-server/src/main/java/ca/uhn/fhir/rest/server/interceptor/consent/IConsentService.java
The rest of the user API (but not hapi's internal implementation of the API) lives in here: https://github.com/jamesagnew/hapi-fhir/tree/ja_consent_svc/hapi-fhir-server/src/main/java/ca/uhn/fhir/rest/server/interceptor/consent
This is very much a work in progress, but it does work. I have testing consent service implementations that block specific user access, do data masking, create audit records, etc.
I'm hoping to spur some feedback on the API, shortcomings, suggestions, etc.
Josh Mandel (Jun 11 2019 at 14:18):
Session details https://www.devdays.com/us/schedule/#event-234 -- 10:30a in St Helen's
David Pyke (Jun 11 2019 at 14:56):
Can I get a copy of the presentation?
James Agnew (Jun 11 2019 at 15:33):
Sure thing, will post afterward. The consent stuff is literally only 4 slides, but hey. :)
Grahame Grieve (Jun 11 2019 at 15:35):
I have a few discovered things to extend the API with. Will get back to it
Josh Mandel (Jun 11 2019 at 16:53):
Does
thePreResourceAccessDetails.setDontReturnResourceAtIndex(i);
mean that fewer than _count resources (maybe even zero) would get returned, or is there logic somewhere to go fetch more results from the db as individual search results are redacted from the response bundle? @James Agnew
Josh Mandel (Jun 11 2019 at 16:55):
Also, I was expecting to see something about Consent resources in this interface, but I guess this is at a different level of abstraction (and any given interceptor might look up some Consent resources to define its policy... or not).
Grahame Grieve (Jun 11 2019 at 18:39):
yes the consent resources are implicit in this interface - one assumes that implementations track and load consent resources as appropriate
James Agnew (Jun 11 2019 at 21:22):
@Josh Mandel re. count: that is a fun topic. One of the differences between my API and the one Grahame proposed is that i've split the concept of "seeResource" into two concepts, roughly called "canSeeResource" and "aboutToSeeResource".
The former is a simple boolean question, and the idea is that it happens before pages are calculated. The idea there is that if you ask for _count=10, you should get a page of 10 back unless you've exhausted all possible resources. This probably has a measurable negative impact on performance, but also means that it's possible to block resources without the user being able to detect whether any data was blocked.
James Agnew (Jun 11 2019 at 21:23):
And yeah, the assumption I'm making is that if Consent resources are a part of your consent infrastructure (and they probably are), you load them in the first method.
James Agnew (Jun 11 2019 at 21:39):
Oh, and @David Pyke, here are the slides: https://docs.google.com/presentation/d/1rp7g7n3OXvjoU4qmMhEWEFW-3Csag-gdh4g16y139So
John Moehrke (Jun 12 2019 at 12:49):
Nicely done. I look forward to deeper details to be understood.
Last updated: Apr 12 2022 at 19:14 UTC
