Stream: implementers
Topic: Logical ID changes
Rob Resendez (Dec 11 2020 at 17:34):
I'm in a bit of a pickle where I've learned that some of our logical ids, references haven't been fully consistent. The problem stems from the fact that we have some surrogate keys in our system that fundamentally resolve to the same resource... so these might be the same underlying resource:
Patient/x
Patient/x-2
But there's a discrepancy in our code that builds the resource entity -- it will always use the "preferred id"... say Patient/x. The problem is exasperated where resources that reference Patient use the "preferred id". For example:
Observation?patient=x-2
This resource bundle here would fetch the same content as ?patient=x, and all of the patient refs wouldn't match the input parameter and would instead be pointing to patient/x
This is a bug, really... I'd really like for there to be no hint of the surrogate "x-2"; At this time I'm seeking some advice on a good strategy for resolving this. It's tricky because the spec states
Once assigned by the server, the id is never changed
Anyone ever experienced some problem where you felt you had to fix/change logical ids? I guess you may have to leave the "bad" resources out there indefinitely
Lloyd McKenzie (Dec 11 2020 at 18:46):
You can remove existing resources, though you should only do that if you're confident it's not going to break any of your communication partners. Alternative is to mark those records as inactive and add a link to them that points to the correct patient record.
René Spronk (Dec 12 2020 at 08:53):
Where does the spec say that if one searches for Patient/x, and the server responds with Patient/y, that this would be an error? Sometimes that's a very desirable feature, e.g. if Patient resources have been merged (e.g. if x has been merged into y).
Last updated: Apr 12 2022 at 19:14 UTC
