Stream: Orders and Observation WG
Topic: Best approach for 'masked'
Lloyd McKenzie (Mar 31 2022 at 17:27):
For a number of observations, the set of 'absent reasons' (other, refused to answer, not applicable, etc.) is incorporated as part of the valueset for the Observation.valueCodeableConcept - as is best practice. However, there certain null flavors such as 'masked' that will never be the actual value for the element - when doing data capture "masked" is not something that makes sense. So we don't want to include that 'absent reason' as part of the ValueSet for the Observation.value. The question is: is it appropriate to send the 'masked' absent reason in Observation.dataAbsentReason and wipe the value, or should we wipe the value and replace it with the DAR extension?
My leaning is to say that what goes in Observation.dataAbsentReason should be what was originally captured, whereas if you're redacting data , that you always use the DAR extension - because there are a variety of things that you might redact (author, subject, timeframe, etc.)
Opinions? Is it appropriate to add a recommendation/best practice to the spec for something like this?
John Moehrke (Mar 31 2022 at 17:31):
note that masked is just one algorithm for de-identifying data... but I don't think that is your use-case... right?
John Moehrke (Mar 31 2022 at 17:33):
We did look at Observation, and it is the subject of the De-Identification section -- http://build.fhir.org/secpriv-module.html#deId
John Moehrke (Mar 31 2022 at 17:34):
YES, more would be good. glad to help
Hans Buitendijk (Mar 31 2022 at 17:39):
@Lloyd McKenzie : I'm concerned that also the DAR extension would get confusing whether it represents the actual record absent reason or the masking process reason if there is still other data being sent on the resource. So shouldn't it be a more specific masking focused extension? Adding a DAR extension where a DAR attribute is already present would get confusing as well as to the purpose.
Lloyd McKenzie (Mar 31 2022 at 18:16):
You wouldn't have a DAR extension on 'value' if there hadn't been a value. I guess in theory you could have a DAR extension on Observation.dataAbsentReason if you were suppressing something like "refused to answer".
Lloyd McKenzie (Mar 31 2022 at 18:17):
(And understood that 'Masked' is only one style of redaction. If you're actually yanking the elements and not making explicit what you yanked, then there's no question of where to put the flag, so I'm not worrying about that aspect.)
Hans Buitendijk (Mar 31 2022 at 23:51):
So if DAR is on Observation directly you would you use of the general purpose masking and if on a specific attribute and it is o.k. to know there was something there but redacted you would use it on that attribute. My concern is that regular process DARs are different than redaction DARs. Similar to having a status on the record or a status (one or more) on the content.
Lloyd McKenzie (Apr 01 2022 at 02:15):
I don't think it would make sense for a 'source' Observation to ever have an Observation.dataAbsentReason of 'masked'. If you had an Observation with a DAR of "refused to answer" and for some reason wanted to mask that DAR, then you would send the DAR with a DAR extension in it that said 'masked'.
John Moehrke (Apr 01 2022 at 11:12):
that seems like a policy choice. Not unreasonable place for a policy to end up... I will quote a Canadian: "If you choose not to decide you still have made a choice."
Last updated: Apr 12 2022 at 19:14 UTC
