dont merge patients with conflicting patient IDs (like dcm4chee2x)

[Clédio Moreira Paiva]

Hello, i have a storage that has non-unique patient IDs.

I need to ensure that the dcm4chee are not merging patient names, even if i send two studies with the same patient id (but different names).

Im using:

dcm4chee-arc-psql:5.22.1-secure-ui - dockerized version with docker-compose on linux

I got two solutions here on forum:

https://groups.google.com/g/dcm4che/c/iQNIi8_Gdg0/m/pX51cdNbAQAJ

Here, Vrinda says:  You don't need to configure Nullify Issuer of Patient ID, Issuer of Patient ID and Issuer of Patient ID Format fields! Just set Merge Attribute field to IssuerOfPatientID={PatientName,hash}-{PatientBirthDate}

But here, Gunter instructed to use nullify and issuer of patient id format fields, and there is no mention of merge attributes:

https://groups.google.com/g/dcm4che/c/hVsMG4_xK4s/m/yLyGfqlaBAAJ

and Gunter posted a screenshot with a sample:

https://10089983123044078017.googlegroups.com/attach/45325e0850d3f/unify-pid.png?part=0.1&view=1&vt=ANaJVrHwme-zv68W5Em9PPe1_vDB5zXqREBQCj4qWbdG4C2eirJFARCj-_bm9EaI_1B4pPnDDUGYl3w2lyEIQVv8D7KLJoJYs1M7iM5u99SrnLKm_sf4984

Accept Conflicting Patient ID - must be set to yes ?

Aparently there are two approachs to solve the merge problem... im a little bit confused, wich is the correct solution for the patient merge of legacy storages?

(on dcm4chee2x, i dont have this problem, apparently it dont merge conflicting patIDs)

[Vrinda Nayak]

In DCM4CHEE archive v5.x patient identifiers are considered for uniqueness of patient records - and not patient names - also as required as per IHE / DICOM / HL7.

Merge Attributes was added in Archive Attribute Coercion much later than the post in which Gunter answered to use Nullify Issuer of Patient ID and Issuer of Patient ID Format.

If you configure attribute coercion rule to ensure patient identifier uniqueness, there is no need to configure Accept Conflicting Patient ID. Without attribute coercions and only configuring Accept Conflicting Patient ID as YES will not overwrite patient names, but studies of different patients are associated with one patient record!

With current archive version, you may choose to configure fields :

either Merge Attributes : Configuring this field for eg. as IssuerOfPatientID={PatientBirthDate}-{PatientName,hash} ensures that Issuer of Patient ID whether present or missing in the incoming objects shall always be overwritten with the value derived from patient's birth date and hash value of patient name

or Nullify Issuer of Patient ID, (optional Issuer of Patient ID) and Issuer of Patient ID Format / Supplement from Device : These fields may be configured for cases where user knows that incoming objects contains some values for Issuer of Patient ID and/or Issuer of Patient ID Qualifiers Sequence but does not trust those values, hence chooses to nullify (always or based on matching / not matching conditions) and either supplements from a different device or applies format specified in Issuer of Patient ID Format field.

  - If Nullify Issuer of Patient ID is configured as MATCHING / NOT_MATCHING : Issuer of Patient ID in coercion rule must be configured as well, wherein the values of Issuer of Patient ID and Issuer of Patient ID Qualifiers Sequence in incoming objects are checked for against the value configured in this field

  - Once Issuer of Patient ID and Issuer of Patient ID Qualifiers Sequence is nullified in incoming objects, you can choose to apply Issuer of Patient ID and Issuer of Patient ID Qualifiers Sequence from a different device using configured Supplement from  Device field or by specifying a specific format to be derived from some attributes in Issuer of Patient ID Format field as for eg. {PatientBirthDate}-{PatientName,hash}

[Clédio Moreira Paiva]

Thank you for your explanation Vrinda, it was very illustrative.

I tried to use the solution using the merge attribute: IssuerOfPatientID={PatientName,hash}-{PatientBirthDate} and it worked great with the new incoming studies since the date that i've set this attribute coercion rule.

But i'm still having problems with patients received before setting the coercion rule.

Lets suppose i received a study with patient "TOM" and patient ID "100", before setting the coercion rule. So this patient dont have "issuer of patient id" his issuer is blank.

The problem is that, before setting the attribute coercion rule, we dont had a RIS yet. So the radiology technicians filled the patient id with a random number "100", he do not is the real owner of this patient id number.

 

But now, we have a RIS, and the patient "GARY" that is a real owner of patient id "100" make a new recent study.

i Noticed that dcm4chee do not create a new patient called GARY with issuer "{PatientName,hash}-{PatientBirthDate}" as expected.

Instead of it, dcm4chee took "TOM" as owner of the new study, and gave to "TOM" the issuer with "{PatientName,hash}-{PatientBirthDate}" , using "GARY" attributes ! the hash was made with "GARY's" Name, and the "GARY's" birthdate ! 

So, should it really work this way?

Maybe i can workaround this dropping the entire dcm4chee database, create a fresh one, set attribute coercion rule, and reimport all studies from storage directory ? so this way, all studies, will have a issuer attribute (import using this how-to https://github.com/dcm4che/dcm4chee-arc-light/wiki/Import-Instances-on-Storage)

But this workaround will take long time, and will be very risky...

Its very simple to reproduce this problem, is just setup a fresh dcm4chee container with no attribute coercion rule, then send a study to dcm4chee, that have, for example id "100". As expected this study will have blank issuer.

now set attribute coercion rule with Merge Attribute field to IssuerOfPatientID={PatientName,hash}-{PatientBirthDate} , and send a new study with another name, but with the same patient id "100"  .

You will notice that the new patient is not created, and the old patient will receive issuer with name-hash+birthdate of the new patient.

[Vrinda Nayak]

As I mentioned before, patient identifiers are considered unique in the archive and also as required as per the standards. If first patient record was created with ID as 100 and without any issuer, on subsequent receive of studies if attributes contain same patient ID and also an issuer, the previous patient ID record in DB is enhanced with the issuer information from newly received studies. If you have ambiguous patient identifier records before you configured the attribute coercion rule, you may choose to supplement such patient identifiers using Supplement Issuer of Patient ID service. Alternatively, if it is just this one record, you may choose to temporarily disable the HL7 Track Changed Patient ID configuration and update pateint using UI by adding a desired Issuer of Patient ID to that patient record.

[Clédio Moreira Paiva]

Thank you Vrinda, you make it even more clear now !

Excuse me to extend this thread, but, im new on it..

Early in this thread you say: "If you configure attribute coercion rule to ensure patient identifier uniqueness, there is no need to configure Accept Conflicting Patient ID."  So, having in mind that a really want to make sure that two patient will never be merged because of conflicting IDs,  as long as i have  attribute coercion rule  configured,  the Accept Conflicting Patient ID set to YES, NO or "-" is indifferent ? will have the same result ?

I have many records without issuer, so i will use the Supplement Issuer of Patient ID service.

Can you give me a sample of a final command that supplement all patients with blank issuer, with the issuer {PatientName,hash}-{PatientBirthDate} format ? (or maybe this is not so simple as i'm thinking...)

it will be something like this ? curl -X 'POST' 'http://test-ng:8080/dcm4chee-arc/aets/DCM4CHEE/rs/patients/issuer/%7BPatientName%2Chash%7D-%7BPatientBirthDate%7D?fuzzymatching=false&test=false'

[Vrinda Nayak]

Using the service without any query parameters should be sufficient. See attached screenshots (before / after using supplement service)

curl -vX POST 'http://localhost:8080/dcm4chee-arc/aets/DCM4CHEE/rs/patients/issuer/%7BPatientName%2Chash%7D-%7BPatientBirthDate%7D'
*   Trying 127.0.0.1:8080...
* Connected to localhost (127.0.0.1) port 8080 (#0)
> POST /dcm4chee-arc/aets/DCM4CHEE/rs/patients/issuer/%7BPatientName%2Chash%7D-%7BPatientBirthDate%7D HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.74.0
> Accept: */*
>  
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Connection: keep-alive
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Headers: origin, content-type, accept, authorization
< Access-Control-Allow-Credentials: true
< Transfer-Encoding: chunked
< Content-Type: application/octet-stream
< Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS, HEAD
< Date: Wed, 25 Aug 2021 11:41:55 GMT
<  
* Connection #0 to host localhost left intact
{"pids":["ALGO00003^^^A2100E2B-19140527","P-00000001^^^95FB6349-19530102","SMS530102^^^95FB6349-19530102","ALGO00001^^^6347B1A7-19000101"]}

[Clédio Moreira Paiva]

Vrinda, thank you again...

I just have one more doubt..

Early in this thread you say: "If you configure attribute coercion rule to ensure patient identifier uniqueness, there is no need to configure Accept Conflicting Patient ID." 

So, having in mind that a really want to make sure that two patient will never be merged because of conflicting IDs,  as long as i have  attribute coercion rule  configured,  the Accept Conflicting Patient ID set to MERGE, YES, NO  or "-" is indifferent ? will have the same result ? (i made tests with all "Accept Conflicting Patient ID" options and they seem to give the same result)

if they apparently gave the same behavior,  Whats the difference between the behavior of the yes, no, merge ?

Thank you !

[Vrinda Nayak]

You can see the difference between the 3 settings of AcceptConflictingPatientID configuration when you don't have any attribute coercion configured.

Example : Assuming two patients Tom and Gary have same PatientID (= P12345) and no issuer and studies for patient Tom are already received by the archive first.

- MERGED (default) : Indicates that objects with a Patient ID which differs from Patient ID in previous received objects of study are accepted, only if the Patient ID in incoming objects refers to an already merged patient. eg. On storing studies of Patient Gary (patient Gary merged previously with patient Tom for eg. using HL7 ADT^A40 patient merge msg) to the archive -> they are associated effectively with patient Tom

- YES : Indicates that objects with a Patient ID which differs from Patient ID in previous received objects of study are accepted, even if the Patient ID in incoming objects does not refer to any merged patient.  eg. On storing studies of Patient Gary to the archive, they get associated with patient Tom

- No : Indicates that objects with a Patient ID which differs from Patient ID in previous received objects of study are rejected. eg. Storing Objects of Patient Gary are rejected with status A778H - Patient ID in incoming object does not match with that of patient associated with study.

[Clédio Moreira Paiva]

Vrinda, thanks for being kind and for share your knowledge !

[Todd Jensen]

Hi,

If I use "IssuerOfPatientID={PatientBirthDate}-{PatientName,hash} ", what is the hash method used on the PatientName? 

Todd Jensen, PhD

Jensen Informatics LLC