Stream: implementers
Topic: Conventions around "entered-in-error"
Brian Forbis (Dec 14 2020 at 17:59):
I have a little bit of confusion around the usage of "entered-in-error". Is "entered-in-error" a convention that all FHIR resources will/should support to represent a "soft-deleted" record? It seems that most (but strangely, not all) resources have some sort of status attribute that can be set to "entered-in-error". From a general framework perspective, I would think a consistent representation of "soft-deleted" should be adhered to.
Does anyone have insight into why there are resources that don't support this status (or resources that don't have a status attribute at all)?
Lloyd McKenzie (Dec 14 2020 at 18:03):
All resources are required to have entered-in-error or receive a waiver. Some resources (Parameters, OperationOutcome, etc.) aren't generally persisted and there isn't a use-case for it
Brian Forbis (Dec 14 2020 at 18:14):
Ok, I think that makes sense for non-persistable resources. So it seems like an alternative to "entered-in-error" might be the use of "active". Are there guidelines for when "active" is used instead of "status".
Lloyd McKenzie (Dec 14 2020 at 18:46):
If you've got a state machine that is essentially a boolean, then we allow just 'active'.
Brian Forbis (Dec 14 2020 at 20:17):
Ok, another tangential question regarding soft-deleted: Have implementers generally redacted resources that are returned in search bundles that are in "entered-in-error" status? I have seen this referenced in this conversation here, however I have not seen it referenced much outside of that one conversation. Would the proper way to implement that involve returning the resource with a "REDACTED" meta field in the bundle, but allowing for a full non-redacted read on that resource using the READ interaction for legitimate uses of that soft-deleted resource?
Grahame Grieve (Dec 14 2020 at 20:27):
I don
Grahame Grieve (Dec 14 2020 at 20:27):
I don't recall ever having discussion about this.
Michele Mottini (Dec 14 2020 at 21:18):
No, resource that are entered-in-error MUST be returned by searches, otherwise downstream systems would not be able to fix their copies (if they retain copies)
Brian Forbis (Dec 14 2020 at 21:29):
I wasn't referring to removing the entries entirely from the search, that conversation I linked goes into great detail into why that is a bad idea.. There was a comment in that thread about returning a REDACTED resource, as the attributes aside from "id" and "status" may no longer be relevant or pose patient safety risks to return.
Michele Mottini (Dec 14 2020 at 22:31):
Oh got it, sorry I misunderstood
Last updated: Apr 12 2022 at 19:14 UTC
