Duplicated patient entries, one created by MWL, and another created by archive with attribute coercion rule.

[Clédio Moreira Paiva]

Hello !

Im having problems with duplicated patient entries caused by Modality Worklist.

Im using:

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

I can create new Modality Worklist entries using a HL7 Order with ORM^O01 Message.

But i notice that dcm4chee-arc creates a new patient entry (in patients list) for each of Modality worklist order. (maybe i'm wrong, but i think that dcm4chee2.x did not create new patient entries on each ORM order...)

The RIS system that generate the Modality Worklist, give an static issuer for every patient, so every patient entry created by modality worklist, have the same issuer, for example: issuer: "HOSPITAL".

The problem is that, i use a attribute coercion rule in archive to ensure unique patients. Therefore dcm4chee generates a issuer dynamically, based on hash of name+birthday  (merge attribute: IssuerOfPatientID={PatientName,hash}-{PatientBirthDate})

At the end of this process (create mwl order, execute the study, send to pacs, and store) i've ended up with two patient entries for each study. One patient entry created by mwl with static issuer "hospital", and the second patient entry created by archive with a dynamic issuer defined by attribute coercion rule.

Whats the correct approach to solve this situation ?

• There is a way to avoid MWL to create patient entries ? (because the patient entry will be created again on study reception)

• Or maybe i can force the attribute coercion rule to act over patient issuers created by MWL
  

• Or maybe i can make the RIS itself to create a dynamic issuer with the same attributes {PatientName,hash}-{PatientBirthDate}. This way dcm4chee will not create a new patient entry when it receive the study. To do this i just need to know what kind of hash algorithm is used by dcm4chee to create patient name hash.
  

Thanks !

[Vrinda Nayak]

In the earlier post, you had mentioned only about receive of studies and studies of different patient records with same patient ID getting merged with one another. Hence, the solution stated was to configure an attribute coercion rule.

To correctly execute / implement following flow

> At the end of this process (create mwl order, execute the study, send to pacs, and store) i've ended up with two patient entries for each study. One patient entry created by mwl with static issuer "hospital", and the second patient entry created by archive with a dynamic issuer defined by attribute coercion rule.

- When RIS creates an order with issuer "HOSPITAL" and sends it to archive, the Patient ID should be different for each patient record specified in PID-3. eg. P1^^^HOSPITAL (patient Tom) and P2^^^HOSPITAL (patient Gary)

- Modality should query the worklist as required by RAD-5 Query Worklist transaction and use the patient and order information available in the worklist to populate the object attributes before storing the study to the archive.

- Doing so, you would not need to configure any attribute coercion rule to ensure uniqueness of patient records

[Clédio Moreira Paiva]

Hello,

if I could always trust mwl since the first patient sent to dcm4chee, the attribute coercion rule would not really be needed.

 

But earlier we dont have a RIS, so there are countless patients filled with incorrect patient ids, stored in dcm4chee. (and we cant drop them out)

Keeping attribute coercion rule working with mwl, will prevent the system to merge the new patients with correct patid,  with older patients that exists in the dcm4chee before we start to use a RIS.

lets suppose that dcm4chee have a old patient called "TOM" with incorrect pat id "100", and now that we have a RIS, the real owner of patid "100" make a new study, that came throught the MWL.

If i dont have attribute coercion rule, the real owner of patid 100 will be merged with the old patient "TOM".

But if i keep MWL working with attribute coercion rule, i get the problem related on this topic:

At the end of this process (create mwl order, execute the study, send to pacs, and store) i've ended up with two patient entries for each study. One patient entry created by mwl with static issuer "hospital", and the second patient entry created by    archive with a dynamic issuer defined by attribute coercion rule.

if i could know what kind of hash algorithm is used to create the issuer {PatientName,hash}-{PatientBirthDate}. I will be able to make the RIS to create by itself a dynamic issuer with the same structure of attribute coercion rule.

This way the patient that came throught MWL/RIS will not be created with static issuer "HOSPITAL" anymore. This patient will be created by MWL with the correct  issuer {PatientName,hash}-{PatientBirthDate}.

This way i think that i can prevent duplicated patient entries. And keep MWL and  attribute coercion rule working together.

[Clédio Moreira Paiva]

Sorry for raising this topic, but it would really help me a lot to have this answer. Thank you

[Vrinda Nayak]

If you have patient records in your archive without any issuers associated to them (before there was any RIS in your setup) - for such records, you may use Supplement Issuer of Patient ID service with dynamic pattern for issuer (in path parameter) eg. {PatientName,hash}-[PatientBirthDate}. 

i.e. curl -X POST 'http://localhost:8080/dcm4chee-arc/aets/DCM4CHEE/rs/patients/issuer/{PatientName,hash}-[PatientBirthDate}?PatientID=100'

Once these records are made unique and then RIS sends an order message with same Patient ID as 100 but with issuer HOSPITAL (i.e. in PID-3 as 100^^^HOSPITAL) - the patient records and eventually the studies for these patients won't get merged.

[Clédio Moreira Paiva]

Hello vrinda, sorry if i didnt express myself propertly. But there are reasons that i want to keep MWL and attribute coercion rule working together.

I will try to give another sample. In this hospital i have a mixed environment, there is new modalities that have MWL support like CT, DX (and they are ok working with MWL), but i also have some modalities that dont have support for MWL (Like some Ultrasound modalities, and one old CR from AGFA)

The patient information of US and CR studies still being filled manually. So if i deactivate attribute coercion rule, the US and CR studies will be sent to storage without issuer, and this will make some mess.

Also, i get many typos in this manually filled info, there are many PATIDs filled incorrectly, mainly during 24H emergency. And, In the case of a incorrect filling of PATID, i need to assure that this incorrect filled patient NEVER be merged with other patient.

If a patitent with a typo in manually filled info, be merged with another patient, became a very difficult job to locate this exam for posterior correction, in addition to that, many times, the error is not noticed at the time, only days later.

So my intention is to keep attribute coercion rule to ensure unique issuer for manually filled studies, and also keep MWL working for the new modalities that support it. (like CT and DX).

But if i keep MWL and attribute coercion rule working together, i come into the problem related in this thread. "At the end of this process (create mwl order, execute the study, send to pacs, and store) i've ended up with two patient entries for each study. One patient entry created by mwl with static issuer "hospital", and the second patient entry created by archive with a dynamic issuer defined by attribute coercion rule."

[Gunter Zeilinger]

If I understand you right, you want to coerce incoming patient attributes (including Issuer of Patient ID) with attributes from a matching (by which attribute?) MWL item feeded by HL7v2 Order messages, but if no matching MWL item is found, the Issuer shall be created from hashes of Patient Demographics to preclude to associate the new received Study with a wrong existing Patient record?

[Clédio Moreira Paiva]

Hello, Gunter.

I think that you got it. (in old dcm4chee2x. i think that the patient record is created only when the study was received by dcm4chee. But in dcm4chee-arc5 i noticed that the pacient record is created as soon as the MWL entry is recorded).

I think that, in resume, i want to assure that typos PATIDs never be merged with existing patient records. And i do this following the very illustrative instructions of vrinda in this thread: https://groups.google.com/g/dcm4che/c/7mkvxVgFylg Basically i was instructed to create a attribute coercion rule to prevent merge of typos PATIDs with existing Patient record.

But i also use MWL for some modalities (its a mixed environment some modalities have MWL and some dont). And the patient records created by MWL has a static issuer "HOSPITAL".

So i think that the solution for my scenario is to keep MWL and attribute coercion rule working together.

But if i keep MWL working together with attribute coercion rule, i got two patient records, one with issuer "HOSPITAL" ( created as soon as the MWL entry is recorded ) and another with dynamic issuer, created from hashes of Patient Demographic (created at study reception).

I would like to know the correct solution for this scenario...

[Vrinda Nayak]

For this case, you may create an attribute coercion rule as

dn: cn=mergeMWL-useHash,dicomDeviceName=dcm4chee-arc,cn=Devices,cn=DICOM Configuration,dc=dcm4che,dc=org
objectClass: dcmArchiveAttributeCoercion
cn: mergeMWL-useHash
dcmDIMSE: C_STORE_RQ
dicomTransferRole: SCU
dcmMergeAttribute: IssuerOfPatientID={PatientName,hash}-{PatientBirthDate}
dcmMergeMWLMatchingKey: AccessionNumber
dcmMergeMWLTemplateURI: ${jboss.server.temp.url}/dcm4chee-arc/mwl2series.xsl
dcmProperty: IssuerOfPatientID!=HOSPITAL

This coercion rule gets applied on incoming studies to archive, if it does not contain Issuer of Patient ID attribute or any value for Issuer of Patient ID attribute or if  Issuer of Patient ID attribute has value other than HOSPITAL.

It searches if there are any existing MWL items in DB using AccessionNumber as matching key i.e. value of AccessionNumber in incoming study is used for searching MWL items containing that AccessionNumber. If present, MWL attributes are used to fill out some study / series attributes and patient attributes. If no MWL is found, Issuer of Patient ID is generated from hash of Patient Name and Patient Birth Date.

If you're sure that some modalities do query for worklist and populate the study attributes from worklist before sending the study to archive, you may add an extra property to the coercion rule to skip it for some modalities for optimization purposes (This avoids MWL DB queries to search for worklist again by the archive if modality anyway uses it beforehand). Eg. dcmProperty: Modality!=CT|DX.

[Clédio Moreira Paiva]

Hello Vrinda,

I'm sorry but I'm new to dcm4chee-arc. How can i insert this rule ? i think that is not by the UI. There is a way to insert it using linux cmd ?

I would just like to propose a suggestion to reduce the complexity, if my own RIS generated the issuer dynamically, using the hash of the name + date of birth, wouldn't it be less complex? this would be very simple for me, I would just need to know the algorithm used for this hash.

[Vrinda Nayak]

An issuer is normally hospital specific. If you generate issuer for each patient record, the concept of issuer is literally lost. If RIS is making use of an issuer (some static value used hospital wide as HOSPITAL), would recommend to keep it.

Attribute Coercions using archive are workarounds when other systems in a workflow are unable to do the right steps due to whichever reason.

You may add attribute coercion rule using archive UI by going to Configuration page - Device tab. Select dcm4chee-arc device. Go to Extensions - Device Extension - Archive Device Extension - Child Objects. In Child Objects, search for Attribute Coercion and add one with the configs specified in the last post.

[Clédio Moreira Paiva]

Thanks for explanation about the concept of issuer, now i can understand.

One important Question: This Attribute Coercion Rule must Replace the rule that i'm using before ? ( the rule you showed me in this post  https://groups.google.com/g/dcm4che/c/7mkvxVgFylg)

I tried to fill the Attribute coercion rule using the UI, and i dont find where to fill the following options:

dn: cn=mergeMWL-useHash,dicomDeviceName=dcm4chee-arc,cn=Devices,cn=DICOM Configuration,dc=dcm4che,dc=org
objectClass: dcmArchiveAttributeCoercion
cn: mergeMWL-useHash

dcmProperty: IssuerOfPatientID!=HOSPITAL

I was only able to fill in the following options:

dcmDIMSE: C_STORE_RQ
dicomTransferRole: SCU
dcmMergeAttribute: IssuerOfPatientID={PatientName,hash}-{PatientBirthDate}
dcmMergeMWLMatchingKey: AccessionNumber
dcmMergeMWLTemplateURI: ${jboss.server.temp.url}/dcm4chee-arc/mwl2series.xsl

I attached a screenshot of my screen. 

Em terça-feira, 7 de setembro de 2021 às 14:41:25 UTC-3, Clédio Moreira Paiva escreveu:

Thanks for explanation about the concept of issuer, now i can understand.

One important Question: This Attribute Coercion Rule must Replace the rule that i'm using before ? ( the rule you showed me in this post  https://groups.google.com/g/dcm4che/c/7mkvxVgFylg)

I tried to fill the Attribute coercion rule using the UI, and i dont find where to fill the following options:

dn: cn=mergeMWL-useHash,dicomDeviceName=dcm4chee-arc,cn=Devices,cn=DICOM Configuration,dc=dcm4che,dc=org
objectClass: dcmArchiveAttributeCoercion
cn: mergeMWL-useHash

dcmProperty: IssuerOfPatientID!=HOSPITAL

I was only able to fill in the following options:

dcmDIMSE: C_STORE_RQ
dicomTransferRole: SCU
dcmMergeAttribute: IssuerOfPatientID={PatientName,hash}-{PatientBirthDate}
dcmMergeMWLMatchingKey: AccessionNumber
dcmMergeMWLTemplateURI: ${jboss.server.temp.url}/dcm4chee-arc/mwl2series.xsl

I attached a screenshot of my screen. 

[Vrinda Nayak]

cn: mergeMWL-useHash :  Use the value in Name field. Rename the value as required, it's just an identifier for the coercion rule which denotes what the attribute coercion is supposed to do

dcmProperty: IssuerOfPatientID!=HOSPITAL : Add  IssuerOfPatientID!=HOSPITAL in Conditions field. Modality !=CT|DX may also be added as an additional condition (as you previously mentioned that these modalities are able to query worklists and use its attributes before storing the study)

I don't see where I have specified any attribute coercion rule in https://groups.google.com/g/dcm4che/c/7mkvxVgFylg post. Also, the discussions in that post was limited to the storage of objects without any issuer case. There was no mention of worklists. Anyway, I had explained the meaning of some fields in attribute coercion rule, so if you already have one configured, you may just update the same rule but with fields / values specified in this post as this coercion rule caters to both merging from MWL if present, else generating value for issuer from patient's attributes - rule is only applied if the specified conditions match.

[Clédio Moreira Paiva]

Thanks Vrinda, your explanation was perfect.
I make some tests and it seems to work ! Problem solved, thanks!

[Eduardo Lima]

Hi Vrinda, I'm trying to formulate an hl7 message to send to dcm4chee worklist. From the messages I was able to formulate when I sent a new message from the same patient with a new exam, DCM4CHEE reports that it is an ambiguous entry accusing the following error "Caused by: org.dcm4chex.archive.exceptions.NonUniquePatientException: Patient[id=248673, issuer=null, name=EDUARDO SILVA LIMA^null^null^null] ambiguous". Could you help me? See if could it be some wrong field or some field in the message I forgot to fill in? or even send a MWL message with the right patterns? the one I'm using is this one:

MSH|^~\&|||||||ORM^O01^ORM_O01|||2.5

PID||248673|248673|248673|EDUARDO SILVA LIMA||19951129|M|||||||||||||||||||

PV1||U||||||DR TESTE|

ORC|NW||9999||SC||||||||||||||

OBR|||9999|^^^^RM CRANIO||||||||||||||9999|11|||||MR|||||||||| 

Em quarta-feira, 8 de setembro de 2021 às 05:50:06 UTC-3, vrinda...@j4care.com escreveu:

[Vrinda Nayak]

- Caused by: org.dcm4chex.archive.exceptions.NonUniquePatientException: Patient[id=248673, issuer=null, name=EDUARDO SILVA LIMA^null^null^null] ambiguous

I've never worked on dcm4chee archive v2. However, you may check if your DB already contains patient ID record with 248673 with(-out) issuer? If it is the same patient record for which this order message should be sent, ensure that your PID-3 (unique patient identifier consisting also of issuer information) follows HL7 CX data type.