Stream: implementers
Topic: Duplicate Patients
Quintonn (Jul 04 2019 at 14:10):
Hi,
I am using HAPI Fhir Server and I'm testing sending FHIR messages to it.
I've sent the same Patient FHIR Resource to the server and it created 2 different Patient resources.
Should it not have detected they are the same patient?
Or are there some settings I have to set?
René Spronk (Jul 04 2019 at 14:18):
In REST, the burden is (mostly) upon the client to ensure it doesn't create duplicates.
HAPI doesn't truly support FHIR messaging unless you wrote your own operation (e.g. $process-message) to define how a message should be processed. If you're posting a FHIR message to the root endpont the server will ignore the fact that it's a message and process it like any other bundle, and it will POST all of the resources contained in the message. If you send the same message twice, it will create all resources twice.
Quintonn (Jul 04 2019 at 14:19):
thank you for that.
And if I do a search on the identifier i should see the same patient twice?
Quintonn (Jul 04 2019 at 14:22):
actuall i can confirm that is indeed the case.
So there is no setting or anything that control this?
Or maybe I can add some java code somewhere?
Kevin Mayfield (Jul 04 2019 at 14:32):
I would suggest writing your own code to handle this. You could do as Rene suggested or create a facade on top of the server that implements your business rules and logic.
I've tended to use the facade pattern as I can change the FHIR server behind it without too much hassle.
Quintonn (Jul 04 2019 at 14:33):
is there any documentation anywhere that can give me some ideas where to start?
Quintonn (Jul 04 2019 at 14:41):
Using If-None-Exist http header worked. It prevents further duplication
Lloyd McKenzie (Jul 04 2019 at 14:53):
Prevention of duplicates is a business rule. The server has to decide what constitutes a duplicate and act to prevent them. For example, is it prohibited for multiple patient records to exist with the same social insurance number? In some systems yes, in others no. Our public test servers don't enforce any business rules so they'll allow duplicates of anything.
Brian Reinhold (Jul 05 2019 at 00:20):
Using If-None-Exist http header worked. It prevents further duplication
@Quintonn I also use the conditional create to prevent data duplication However, that is an expensive transaction for the server. So I create a duplicate detection filter. Since I am only uploading Patient, Device and Observation resources, I can prevent re-uploading the Patient and Device resources by linking the if-none-exist parameter to the logical id in the server's response. When my if-none-exist parameter has a logical id associated with it, I dont re-upload it. For Observations from the same Patient and Device use time stamping to filter. It works quite well and saves bandwidth.
Cooper Thompson (Jul 05 2019 at 20:54):
I'll chime in that for our server implementation of Patient.create, we will always perform a duplicate check before creating. If we find a single high threshold match, we will return that patient as if it were the one you created (i.e. we will "lie" and say we created a new patient for you, when in fact we didn't).
Related to René's comment above about the burden being on the client for preventing duplicates, that can sometimes be true for data within a patient context, but often a client is not permitted to see patients beyond the one they are authorized for, so for Patient specifically, often a client cannot determine if the patient they want to create exists already or not.
Cooper Thompson (Jul 05 2019 at 20:56):
Also, Conditional Create / If-None-Exist may work for some servers, but some servers may want to control the conditions for creating a patient, and not allow clients that control.
René Spronk (Jul 06 2019 at 05:45):
I fully agree that server will need to do some stuff to avoid duplicates, but to me that adds a layer above and beyond "pure REST" (or rather: pure CRUD). You used the wording "the server will 'lie' to you" to indicate that you also consider this behavior (while necessary) not to be entirely in the spirit of REST :-) .. but it'll work just fine. Question will then be how to expose this server behaviour in a FHIR conformance statement or implementation guide.
Kirt Schaper (Jul 09 2019 at 12:53):
Are there any servers which implement the Patient $match operation?
Cooper Thompson (Jul 09 2019 at 16:32):
@René Spronk I agree - this is beyond "pure REST". However I think basically every FHIR interaction we have implemented goes beyond pure REST, since for reads we only return the part of the resource that the requester has access to, and for writes (of all sorts) we will always perform some sort of matching / validation. I think anything other than a toy server has to deviate somewhat from pure REST, otherwise you'd end up with a tangled mess of duplicate data (not just patients, but pretty much any other data type as well).
Richard Ettema (Jul 09 2019 at 17:14):
@Kirt Schaper The AEGIS WildFHIR server supports the Patient $match operation.
FHIR STU3 (v3.0.1): http://wildfhir3.aegis.net/fhir3-0-1
FHIR R4 (v4.0.0): http://wildfhir4.aegis.net/fhir4-0-0
Grahame Grieve (Jul 10 2019 at 22:50):
tx.fhir.org also supports $match (though the algorithm is not overly intelligent)
Last updated: Apr 12 2022 at 19:14 UTC
