Stream: implementers
Topic: handling "moved" resources
Aaron Moronez (Mar 11 2021 at 21:23):
Our software has the ability to "merge" patient records. For example, say two records exist (patient-5 and patient-10) and they both refer to the same "real" person (Bob Smith, who happened to visit two different locations in your large hospital system but for reasons unknown his existing record was not found when visiting the second location). Our software allows you to merge all patient data onto one record and deactivate the other (i.e. all data for Bob Smith on record patient-5 would be moved to record patient-10, record patient-5 would be deactivated, and the patient-10 would be the ongoing source of truth for Bob Smith). Let's say a request is then later made for patient-5 via FHIR. Does FHIR support the concept of a redirect, or even an HTTP 301 type response that points to where a resource now lives (if it moved)? It's not quite appropriate to simply throw a 404, since, although patient-5 has been deleted/deactivated, the data the user actually cared about retrieving really just lives elsewhere. I haven't been able to find much guidance about this use case. Suggestions?
Lloyd McKenzie (Mar 11 2021 at 21:35):
This is what we have in the spec: https://build.fhir.org/patient.html#merge
In short - no standard behavior, at least not yet. You can use Patient.link as part of the merge process. However, what happens to references and queries is currently up to individual implementers to decide
Michael Lawley (Mar 11 2021 at 21:58):
And practically, I agree 301 would likely be more useful than 404. Event though not listed explicitly here https://www.hl7.org/fhir/http.html (table at bottom of page), at least allowed per the text below the page.
Aaron Moronez (Mar 12 2021 at 14:23):
@Lloyd McKenzie Patient.link would seem like a possibility, but in this case, the patient-5 record is also deleted/deactivated. You wouldn't actually be able to retrieve patient-5 in order to see the link to get to patient-10.
@Michael Lawley Yea, since 301 isn't explicitly referenced, we were hesitant to use it. We were considering using a 410, since the merged record is deleted/activated, and putting the new location in the OperationOutcome.issue.expression returned with that error (and documenting that use case for our users).
Aaron Moronez (Mar 12 2021 at 14:37):
@Michael Lawley We could also plow forward with using a proper 301 and also document that workflow so our users know to grab the new resource location from the 301 response header (and we'd probably throw it somewhere in the OperationOutcome as well).
Lloyd McKenzie (Mar 12 2021 at 14:43):
Rather than 'deleting' you could mark Patient.active as 'false' - meaning it won't show up in searches for active patients, but will still manifest as a linked Patient.
Last updated: Apr 12 2022 at 19:14 UTC
