Stream: implementers
Topic: Modifier Extension
Tushar Nair (Apr 03 2020 at 21:40):
Hello,
I am trying to capture a scenario in FHIR where we have to identify and flag some information which mihgt be erroneous. Example - A female patient with a test for prostate. In such a case I was thinking of using the option of 'Modifier Extension' to enrich the incoming resource and persist it accordingly. Is it the correct approach?
Thanks !
Jean Duteau (Apr 03 2020 at 21:46):
you would add a modifierExtension to the resource that you received? that would be a no-no. a) the sender would expect to get back the same thing he sent in if he subsequently requested it; b) modifierExtension says that you are modifying the interpretation of the resource. If you wanted to do this, I could see you adding a tag in the Resource.meta.
But even then I'm not sure I agree with that. See what others have to say...
Grahame Grieve (Apr 03 2020 at 23:11):
I think it makes a big difference whether you are the primary holder of the record, or a secondary consumer. Request for correction is a topic over on #patient empowerment
Lloyd McKenzie (Apr 03 2020 at 23:58):
"might be erroneous" isn't a modifier. Known to be erroneous is usually a status (and status is a modifier specifically because it allows 'entered-in-error'). I would go with a regular extension if you're just updating your own record. If you're asking someone to fix a record you believe is wrong, that would be Task.
Tushar Nair (Apr 04 2020 at 00:37):
Lloyd McKenzie said:
"might be erroneous" isn't a modifier. Known to be erroneous is usually a status (and status is a modifier specifically because it allows 'entered-in-error'). I would go with a regular extension if you're just updating your own record. If you're asking someone to fix a record you believe is wrong, that would be Task.
@Lloyd McKenzie , We are not the owner, we are consuming the resource in our server. In such a scenario- can we store the resource as received as versionid=1 and the source in the meta shall be whatever we received originally. Then we can edit the resource where we use 'entered-in-error' value in the status, versionId-2, source in meta can be marked as 'Our System' instead of what we had in versionId-1. Does that make sense?
Lloyd McKenzie (Apr 04 2020 at 02:39):
You can. In fact, you can choose to make the transformation before you persist anything - there's no requirement to store data "as received", though in some data sharing models, clients will get peeved if you don't. Is your intention to say definitively "this is definitely an error" or "this might be an error"? "status=entered-in-error" is appropriate for the former, but not the latter. In your example, a prostate exam against a patient with a gender=F is not necessarily an error - there are lots of clinical/social circumstances where that could be completely accurate, so presumably what you'd want is a flag to say 'suspect' and have a human verify if/when they get the chance.
Tushar Nair (Apr 06 2020 at 16:17):
Lloyd McKenzie said:
You can. In fact, you can choose to make the transformation before you persist anything - there's no requirement to store data "as received", though in some data sharing models, clients will get peeved if you don't. Is your intention to say definitively "this is definitely an error" or "this might be an error"? "status=entered-in-error" is appropriate for the former, but not the latter. In your example, a prostate exam against a patient with a gender=F is not necessarily an error - there are lots of clinical/social circumstances where that could be completely accurate, so presumably what you'd want is a flag to say 'suspect' and have a human verify if/when they get the chance.
Thank you so much @Lloyd McKenzie , this really helps.
Robert McClure (Apr 07 2020 at 16:07):
As the lead of the Gender Harmoney project, I am compelled to comment on your example use case where a gender/sex and test mismatch can likely occur because of the lousy way system current capture the complexity of sex and gender identity. Dragons lie here and some patients with a "sex" of F may indeed need prostate exams.
Janaka Peiris (Aug 11 2020 at 15:55):
My question is very basic about ModifierExtensions. Can someone give a practical example on how to use it ? I went through FHIR documentation, and didn't get a clear picture on differences between normal Extensions and ModifierExtensions.
I came across this, when going through StructureDefinition XMLs created from Forge tool (v24.2 for R4) there was a ModifierExtension added in all cases whenever extensions were present. This scenario I have asked separately from Firely. (I'm not sure if this is due to a way we had created profiles or an error.) Thanks !
René Spronk (Aug 11 2020 at 17:10):
As the name already indicates, ModifierExtensions modify the meaning of the resource (the standard 80% data elements as contained in the core spec). My favorite example, which we use in the Firely FHIR training courses, is the anti-prescription. If the anti-prescription ModifierExtension is present, the meaning of a MedicationRequest resource (a prescription) is turned on its head: DO NEVER prescribe medication X. That's quite different from "Prescribe medication X". Hence the statement that ModifierExtensions cant ever be ignored, if there is an unknown one in a resource (and one has to check if there's one!) then you need some error handling to deal with it.
There are only a few implementations in production use that use ModifierExtension. You really have to know what you're doing. Dragons beware.
Janaka Peiris (Aug 11 2020 at 19:42):
Thanks @René Spronk this explains it clearly.
Last updated: Apr 12 2022 at 19:14 UTC
