How does dcm4chee decide scans belong together (in the web interface)?

[Joey]

Hello,

How does dcm4chee know when two images belong in the same series or to the same patient? Which tags or part of the dicom format are involved in determining this? 

I have performed many test cases and dcm4chee seems to be just too smart.

In my latest test cases I programmatically change the Patient ID of a scan and then send it to the dcm4chee archive.

The web interface shows me the scan with the new Patient ID as expected.

I then upload another scan of the same patient, but from another series. I don't change the Patient ID, the original one remains.

The web interface then shows me two scans, both under the same Patient Name and Patient ID, while this is correct for the first one, it's wrong for the second.

I had expected dcm4chee to create another row with the same Patient Name and the original Patient ID.

So, I am wondering.. what makes a scan really unique? Why does dcm4chee group them together under the same Patient Name despite the Patient IDs in the scans being different.

Is this only a byproduct of the dcm4chee-web3 interface and ARE they in fact unique already?

I hope I'm being clear..

[fleetwoodfc]

Each instance object received will contain the Patient ID, Study Instance UID, Series Instance UID in the DICOM header. The first instance received is used to create a new patient record (if the patient does not already exist in the DB) and also a new study record with a unique key of Study Instance UID. So the second series received will be added to the study record because its Study Instance UID is a match (the patient info will be coerced). 

[Joey]

Thank you very much for the explanation.

Does this imply that if even one of the UIDs is a database match, dcm4chee will add it to the same study record?

[fleetwoodfc]

Yes because a UID should be globally unique. From DICOM:

"Unique Identifiers (UIDs) provide the capability to uniquely identify a wide variety of items. They guarantee uniqueness across multiple countries, sites, vendors and equipment. Different classes of objects, instance of objects and information entities can be distinguished from one another across the DICOM universe of discourse irrespective of any semantic context."

[Gunter Zeilinger]

That behavior is also required for compliance with IHE Scheduled Workflow: The received objects from the Modalities may contain staled Patient Information, because - in opposite to the Image Manager/Archive - Modalties does not receive HL7 ADT messages - in particular for Patient Update and Merge - originated by the ADT system and forwarded to the Image Manager/Archive by the Department System Scheduler/Order Filler.

--
You received this message because you are subscribed to the Google Groups "dcm4che" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dcm4che+u...@googlegroups.com.
To post to this group, send email to dcm...@googlegroups.com.
Visit this group at https://groups.google.com/group/dcm4che.
For more options, visit https://groups.google.com/d/optout.