Stream: Security and Privacy
Topic: FHIR-Security and Privacy Overview Mon Q3
Michael Donnelly (Jan 14 2019 at 15:35):
The FHIR Agenda for Q3 lists "FHIR-Security and Privacy Overview (@John Moehrke )." Is this an overview of recent changes and what we're doing this week, a high level overview for people who've never been in this space before, or something else?
John Moehrke (Jan 14 2019 at 15:37):
It is not a tutorial, it is an update to the active workgroup membership on what has changed recently that they may not have followed.
John Moehrke (Jan 14 2019 at 15:41):
There have been tutorials, but they are not well attended. So there is a need to get a bunch of people interested to drive for a tutorial.
Michael Donnelly (Jan 14 2019 at 16:22):
Cool, thanks.
Grahame Grieve (Jan 17 2019 at 15:26):
@Ewout Kramer @James Agnew :
interface ConsentEngine {
// initialises the engine, and provides it with a FHIR API Access to a data store
// that includes patient consent statements. The engine is trusted to access the
// store as part of the system
void initialise(FHIRClient client) throws [Exceptions];
// notify the engine that a new resource has been added to the store
// called immediately after the transaction to commit the resource
// completes (may be in a different thread). The engine can use this
// to help maintain it's internal cache
void seeResource(FHIRResource resource);
// call this when any operation is started. return true if the
// request should be processed. call this *before* user authorization
// has been checked
//
// if the operation is not appropriate, fill out the response, and
// return false
ConsentOperationEngine startOperation(Request request, FHIRClient client);
}
enum ConsentOperationStatus {
reject, // the requested operation cannot proceed, and an operation outcome suitable for the user is available
proceed, // the requested operation is allowed to proceed, but the engine will review each resource before sending to the client
authorised // the engine has nothing to say about the operation (same as proceed, but the host application need not consult the engine - can use more efficient counting/caching methods)
}
interface ConsentOperationEngine {
// find out the status of the operation
ConsentOperationStatus status();
// if the operation is rejected, the details to return to the client as an explanation (may be explicit or not)
OperationOutcome outcome();
// check whether to add the resource to the response going out to the client.
// result = null: don't send the resource to the client.
// result != null: send the resource to the client.
// the routine may modify the resource to prepare it for sending to the client
Resource addResource(Resource resource);
// adds consent related information to the audit record for the operation
void addToAudit(AuditEvent event);
// called when the operation processing is terminated to allow
// the consent engine to recover resources etc.
void close();
}
Rick Geimer (Jan 17 2019 at 15:44):
@Sean McIlvenna as well (see above)
Grahame Grieve (Mar 29 2019 at 05:42):
on this subject: I've been playing around with my implementation, and I've discovered that it misses something that 's pretty hard. Imagine that you have this query:
Get {base]/Observation?patient=12345&context.class=IMP
(get all observations associated with an inpatient episode)
Now imagine that the patient has consented to share all encounters for the period where the encounter unit is not type=PSYCH. And there's an encounter in there with that type for patient 12345. Should the observations from the encounter be returned as part of the query?
Jose Costa Teixeira (Mar 29 2019 at 05:54):
Not always, i hope. I had this case where depending who asks, the result may not show all events. Our use case was not an inpatient (it was a nurse that was being followed in psych ward) and we wanted to "hide" those consultations and related medications. Medication was a bit more tricky but consultations was clear - this should not be shown.
John Moehrke (Mar 29 2019 at 12:56):
Grahame, if the organization agrees to that kind of a policy, then they must have the technology to enforce that kind of a policy. This is why the complexity of policy tends to be far less comprehensive than Privacy advocates want. As once a policy is accepted, it must be enforced without exception. Proving a negative is very hard.
John Moehrke (Mar 29 2019 at 12:59):
Your specific case is one that the security/privacy committees would indicate is best handled with security labeling. Those Observations would be tagged, and thus the result (none with this tag) would be returned. Which brings up the point Jose is making, that with some things (especially drugs) it is not clear why the drug was prescribed, so one tends to need to tag drugs based on all possible uses of that drug. Which brings up safety cases, these safety cases are often handled by role/persona elevated privileges to safety algorithms (cds-hooks) like drug-drug interaction checking.
Lloyd McKenzie (Mar 29 2019 at 14:42):
The other way of dealing with it is by compartments. If you find the restricted encounters, you could then constrain out anything that's in their compartments.
John Moehrke (Mar 29 2019 at 15:18):
using security tags is a form of compartment... (everything that has ETH is in the ETH compartment, etc...)
Lloyd McKenzie (Mar 29 2019 at 15:50):
Security tags and compartments are completely separate technical mechanisms. You could have a tagging service that was compartment driven - but that would mean that if an encounter got updated to change its type, the tagging service would then go through (on all accessible servers) and change the tags associated with everything in the encounter compartment.
John Moehrke (Mar 29 2019 at 17:39):
No, please look at the Healthcare Security/Privacy Classification system, which is the vocabulary used in the meta.security element. It indicates "compartment". I expressed that this is not identical but related to RESTful use of 'compartment'.. http://build.fhir.org/security-labels.html#hcs
Lloyd McKenzie (Mar 29 2019 at 17:43):
Ick. Why would you use a word that FHIR ascribes a specific meaning to and give it a different meaning?
John Moehrke (Mar 29 2019 at 17:49):
because Security used the word well before REST was a concept...
John Moehrke (Mar 29 2019 at 17:50):
it isn't dramatically different in concept... but technically implementation is different. However as a meta.security use, it is clear. And as meta.security use, it is very flexible to any specific organizations needs.
John Moehrke (Mar 29 2019 at 17:52):
The military uses this often, as a way to tag data to specific secret projects. Think about the various military code words... those are compartments.. within that compartment there are also various levels of 'sensitivity' and also various levels of 'confidentiality'... just like we have modeled. We modeled it after 'standards'.
Grahame Grieve (Mar 29 2019 at 19:15):
Your specific case is one that the security/privacy committees would indicate is best handled with security labeling
security labeling is a useful input to the problem, but wouldn't begin to handle the actual case in my question
Grahame Grieve (Mar 29 2019 at 19:17):
Not always, i hope
Not ever, I expect. If you don't consent to share information about that encounter, you don't consent to share information about the things in the encounter. It's less obvious to me about observation linked to condition where there's no agreement to share the condition.
John Moehrke (Mar 29 2019 at 19:32):
I think this depends on the language of the policy. Was the language about start->stop time? Was the language about the encounter? Was the language about the class of sensitivity? Each of these is possible.
John Moehrke (Mar 29 2019 at 19:33):
which is unfortunately the complexity of policy. everytime we try to get a handle on this complexity, someone introduces another vector.
Jose Costa Teixeira (Mar 29 2019 at 19:41):
(I assume we are talking about really consent, not permission to share the data, which may be broader than consent).
I would expect the decision on whether to share or not would depend on some set of rules. I don't think we can find all those rules, but they should be a few types of rules and implementers can have their own recipes.
Jose Costa Teixeira (Mar 29 2019 at 19:47):
if patient does not consent on condition, all derived information which would require a reason to share, is not consented.
If it gets shared or not, it depends on a "calculation" which will consider consent among other things.
John Moehrke (Mar 29 2019 at 19:59):
YES @Jose Costa Teixeira That is the scope of the "Consent" resource
Jose Costa Teixeira (Mar 29 2019 at 20:27):
I meant the scope of the question, not the scope of the resource (perhaps i missed the context). The question was "should information be returned", so i just wanted to check that "consent" is one of the variables.
Jose Costa Teixeira (Apr 14 2019 at 09:06):
Would we consider a standard mechanism to express what can be shared in which conditions? Just an idea inspired by other thread, not sure if sensible or misplaced: a GraphDefinition of sorts to say "Here is what you can share (under these conditions...):
Jose Costa Teixeira (Apr 14 2019 at 09:07):
and then we put the graphQL or the paths to the linked elements, with the constraints we need.
John Moehrke (Apr 15 2019 at 14:21):
I have too been wondering if GraphQL would work better than the rule encoding we have in Consent today... but need an expert to give it a try and present some examples.
Last updated: Apr 12 2022 at 19:14 UTC
