Stream: implementers
Topic: Masked Extension for privacy restricted record
Duncan Miller (Aug 07 2016 at 19:38):
Hi - I was hoping someone could advise whether we need to use the masked extension, to denote (every) missing required element of a resource, that has been redacted when we also specify the redacted security tag (privacy restricted resource being returned).
We are presuming it is to make the resource machine readable, but had it questioned as the extension is repeated many times.
Grahame Grieve (Aug 07 2016 at 21:12):
the circumstances in which it is appropriate to mark an element as removed for security reasons are very narrow . Most security asd removal requires you not to mark that the information has been removed.
Grahame Grieve (Aug 07 2016 at 21:13):
as far as FHIR is concerned, you don't need to us the mased extension at all. It's your local requirements that drive whether you should use it or not
Lloyd McKenzie (Aug 07 2016 at 22:08):
Typically that extension is used when there's a need to explicitly declare to the recipient that information has been removed because there's an ability for them to go through a process to get access and they need to know that the information has been suppressed in order to go through the process. But it's a tricky thing because sharing that data exists may be sufficient to infer at least some information.
Duncan Miller (Aug 08 2016 at 00:56):
Thanks for both of your quick replies!!!
John Moehrke (Aug 08 2016 at 14:42):
I have not seen this "masked extension" where is it? This extension was not added with the cooperation of or awareness of CBCC or Security WG. I am worried that it needs to be properly cast with explanation of the potential privacy breach it would present.
Grahame Grieve (Aug 08 2016 at 22:01):
I am assuming that this was a reference to the ISO 21090 nullFlavor extension, with value = MSK
Lloyd McKenzie (Aug 08 2016 at 22:35):
The v3 code certainly has those caveats as part of the definition.
John Moehrke (Aug 09 2016 at 14:30):
so this is a pattern for using nullFlavors in FHIR to expose on an element by element basis that the reason it is null is because it has been masked? Can nullFlavors be used like that on ALL element types in FHIR?
John Moehrke (Aug 09 2016 at 14:34):
The only concept that has been discussed is to apply a security-tag to a RESOURCE that has been modified due to Privacy or Security reasons. This is applied at the Resource level, not at each element. To apply at the element level might be useful; but we need to warn our implememntors that doing so at the element level is more 'risk' than doing it at the resource level; yet doing it anywhere does have risk and should only be used when the risk of exposing that data has been masked is acceptable given the security/privacy context of the transaction. It is possible this is the same at the element level. I mostly want to get details written for our readership.
Grahame Grieve (Aug 09 2016 at 23:24):
presumably you think that the definition of the MSK code is inadequate?
John Moehrke (Aug 10 2016 at 14:15):
The definition of MSK is likely good. What I think is not obvious is that the use of the code presents a Privacy Risk that might not be obvious. Thus I don't know if updating the definition of MSK is the best approach, but putting the 'privacy consideration' into the vocabulary might be the only way .
Grahame Grieve (Aug 10 2016 at 20:16):
"Note: using this null flavor does provide information that may be a breach of confidentiality, even though no detail data is provided" - seems clear to me
John Moehrke (Aug 11 2016 at 13:49):
I don't see that text on http://hl7-fhir.github.io/extension-iso21090-nullflavor.html. I agree that it would be sufficient and clear.
Grahame Grieve (Aug 11 2016 at 23:15):
it's here: http://hl7-fhir.github.io/v3/NullFlavor/vs.html where the meaning of MSK is defiend
John Moehrke (Aug 12 2016 at 14:58):
thanks
Last updated: Apr 12 2022 at 19:14 UTC
