Stream: implementers
Topic: data-absent-reason extension or valueSet
Yunwei Wang (Jul 24 2019 at 20:07):
I am trying to figure out if Condition.code is absent, should I use the extension or code from valueSet?
Eric Haas (Jul 24 2019 at 22:25):
My general guidance is written here. @Lloyd McKenzie better agree because I reluctantly :-) followed his somewhat sage advice...
Eric Haas (Jul 24 2019 at 22:26):
http://build.fhir.org/ig/argonautproject/R4/branches/master/general-guidance.html#missing-data
Eric Haas (Jul 24 2019 at 22:28):
... stilll hashing out whether to use unsupported or unknown. I have some follow up work with our implementers
Lloyd McKenzie (Jul 24 2019 at 22:42):
Use code from value set if one applies (including 'unknown' or 'other' if part of the valueset). In general, if you're using dataAbsent reason, it should be because the absent reason is relevant to the receiver. If you're just doing it to satisfy a mandatory, it means the profile is broken and the element shouldn't be mandatory.
Eric Haas (Jul 25 2019 at 02:19):
or the spec is broken. I have a list.
Lloyd McKenzie (Jul 25 2019 at 02:25):
@Eric Haas - not understanding?
Yunwei Wang (Jul 27 2019 at 00:45):
What I want to do is replace the real value in Condition.code with data absent reason when this is a "sensitive" condition and the requester does not present additional patient consent. I assume this is a correct usage of this value set? @Lloyd McKenzie @Eric Haas
Eric Haas (Jul 29 2019 at 19:33):
with DAR = masked but I don't see this approach described in the Security Section @John Moehrke what is the recommended approach here?
Eric Haas (Jul 29 2019 at 19:34):
security tag + DAR extensions ?
Lloyd McKenzie (Jul 29 2019 at 23:39):
Typically if you're going to suppress the Condition.code, you probably want to suppress the entire instance - and might not even want the receiver to know the Condition exists.
Yunwei Wang (Jul 30 2019 at 01:59):
@Lloyd McKenzie I do want the client knows that this Condition is suppress due to missing certain consent and would be available when require consent is present.
The use case we are discussing is that some US state has more strict privacy regulation than other state. So when hospital A in state A requesting patient clinical data from hospital B in state B, hospital B may not be able to send all medical data due to addition requirement from state B. And we do want hospital A know that some conditions are masked due to lack of consent.
So another question is that should I mask only the Condition.code with DAR code or the whole Condition with DAR extension. Now I think maybe I should mask the whole Condition except Condition.id
Grahame Grieve (Jul 30 2019 at 02:00):
yes, id, status, and meta.security of masked
Yunwei Wang (Jul 30 2019 at 02:10):
@Grahame Grieve If I use DAR extension, do I still need to populate all required fields such Condition.subject?
Grahame Grieve (Jul 30 2019 at 02:10):
yes
Grahame Grieve (Jul 30 2019 at 02:10):
I meant to write subject
Eric Haas (Jul 30 2019 at 03:25):
OK this seems like clear guidance and this is not documented in the security section as described here. Is there another place I should look?
Saul Kravitz (Sep 18 2020 at 21:12):
Is there a write up of how/when to use DAR? Do I need to define every spot where a DAR could conceivably be used in an IG?
Lloyd McKenzie (Sep 18 2020 at 22:28):
Different IGs take different conventions. Unless there are constraints or wording that say otherwise, then DAR - and any other standard or local extension can appear on any element so long as the context in the extension definition allows it. In practice, encountering a DAR on a mandatory element is likely to be surprising and break a lot of systems. So - if you want systems to be able to handle a DAR (or some other extension) in a particular location gracefully, it's good practice to either explicitly mention it in the profile or at least give textual guidance highlighting the IG's expectations.
Last updated: Apr 12 2022 at 19:14 UTC
