Stream: implementers
Topic: Search - Bundle contents when resources are not visible
Jose Costa Teixeira (Aug 09 2021 at 17:12):
Supposing a Patient has been taking paracetamol and disulfiram, but the disulfiram record is tagged as "not for disclosure";
When we query for Patient medications, if the disulfiram is not disclosed, what are the best practices? Should the Bundle contain 1 or 2 entries? Is there interest in saying "total=2", or we really hide from the user that there may be more information?
Lloyd McKenzie (Aug 09 2021 at 17:22):
It really depends on policy. Is there a "break the glass" capability where a provider can get access to the hidden record if they go through a particular process/seek patient consent? If there's action they could take, then any time there's a circumstance where there might be information not revealed (based on access privileges), there should be a warning in the search response. E.g. "These search results only contain records that do not have access restrictions. To access 'restricted' information (if any), record patient consent or invoke emergency break-the-glass procedures." The search count should represent the records actually available and navigable to - otherwise the client software will get confused.
Jose Costa Teixeira (Aug 09 2021 at 17:23):
Presuming there is a break-thee-glass, is there any standard way to say "other records may exist"?
Lloyd McKenzie (Aug 09 2021 at 17:35):
'warning' OperationOutcome in the search-set Bundle is the best way.
John Moehrke (Aug 09 2021 at 18:24):
@Jose Costa Teixeira No there is not an agreed way to do this.
John Moehrke (Aug 09 2021 at 18:26):
First, note that there is no good reason to tell a user that they are receiving less than total data, unless there is some policy that indicates that the user is allowed to know this. Many (most) users will not be allowed to know that they are receiving less than full data. The users that might, are clinicians with privilege to elevate their active privilege (e.g. break-glass). It is only this subset of users that there is any legitimate reason to tell them that there is more data available.
John Moehrke (Aug 09 2021 at 18:29):
Second, there are plenty of stories that when a clinician, who was not authorized to invoke break-glass, was told that they were not seeing everything, these users would obsess on this lack of information and fail to properly review the information they were given. Thus these sites had explicitly turned OFF this, and therefore would never tell a user that was not authorized to break-glass when they were not being given everything.
John Moehrke (Aug 09 2021 at 18:31):
Third, it is unusual for clinicians to be restricted from seeing safety critical information. I have seen discussed that drug/allergy/intolerance interactions would never be blinded... This gets to Lloyds point about policy... any policy that would enable a blinding to a treating clinician had better have the rules clearly stated when that data being blinded would have a safety impact.
Jose Costa Teixeira (Aug 09 2021 at 18:32):
Ok, assuming that such policy would exist (some users see the warning, some users don't see the warning)
I wanted to see if there is / should be a standard way to tell those privileged users "there may be more than this", because this would drive behaviour, and the trigger for that behaviour should be somewhat known/standardized, right?
John Moehrke (Aug 09 2021 at 18:32):
Fourth, often policy has a different category for clinician with a legitimate treatment relationship, vs all other clinicians. Where the first group is never blinded. Any patient concern with someone that might be in this first group is enough to eliminate them completely.
John Moehrke (Aug 09 2021 at 18:33):
YES, I think there should be a defined method
John Moehrke (Aug 09 2021 at 18:33):
but there is not one yet
John Moehrke (Aug 09 2021 at 18:33):
i don't know of a leading potential.
Jose Costa Teixeira (Aug 09 2021 at 18:34):
Hence the use case disulfiram - everyone wants to see all the medication of a patient, but a drug that is used to treat alcoholism problems may pose such challenges.
John Moehrke (Aug 09 2021 at 18:35):
bundle.meta.security -- tag REDACTED
John Moehrke (Aug 09 2021 at 18:36):
Jose Costa Teixeira said:
Hence the use case disulfiram - everyone wants to see all the medication of a patient, but a drug that is used to treat alcoholism problems may pose such challenges.
I agree.. hence why this is not a policy that HL7 should state... And why I caution anyone that wants to blind this data to also address the safety concerns with the privacy concerns, and address it relevant to treating clinicians
John Moehrke (Aug 09 2021 at 18:38):
but.. Your concuding point is something I can agree with.... Given that there is some policy that would apply to a treatment case with a clinician user... and that policy allows the clinician user to be told that there is data being blinded... and that clinician does have break-glass capability... then HOW would the results of the search indicate less than full data was returned
John Moehrke (Aug 09 2021 at 18:39):
thus.. NOT a non-treatment case, NOT a non-clinical user, NOT a clinical user without break-glass authorization.
John Moehrke (Aug 09 2021 at 18:40):
I gravitate towards using bundle.meta.security... I am not confident that REDACTED is the best code, there likely needs to be one defined that does not yet exist.
John Moehrke (Aug 09 2021 at 18:42):
@Mohammad Jafari do you have a pattern you used?
John Moehrke (Aug 09 2021 at 18:55):
Here is my proposal in 2015 https://healthcaresecprivacy.blogspot.com/2015/12/break-glass-on-fhir-solution.html
John Moehrke (Aug 09 2021 at 18:55):
the break-glass section in the FHIR core http://build.fhir.org/security-labels.html#break-the-glass
has an example operationOutcome
John Moehrke (Aug 09 2021 at 18:57):
which gets to the point.... that to have standardized return code, will directly lead to a need for a standardized break-glass.
John Moehrke (Aug 09 2021 at 18:58):
I am not against it, but am not going to dictate alone except in my blog. Meaning, I welcome discussion and consensus solution development.
Mohammad Jafari (Aug 18 2021 at 17:09):
There was no use-case for me where the user had to be informed of the redaction after the redaction takes place --note that informing the recipient of the very fact that there has been a redaction can compromise privacy because it can be indicative that the record includes certain sensitive conditions.
However, in an old pilot of a security labeling system we implemented, we used the masked null flavour as a code to indicated some information has been removed for privacy reasons.
In Pauldron Hearth, I simply remove the total attribute from the Bundle since it's optional. Note that since pauldron hearth is a proxy, it can only see the HTTP response and doesn't have any way to know the total number of resources to be returned if there are more than one page of results in the bundle.
In the of multi-page results, there is still the risk of inference since a result page with redactions will have fewer resources than a normal page (since servers usually return pages of the same size when paginating)
Last updated: Apr 12 2022 at 19:14 UTC
