DICOM data with the same StudyInstanceUID gets imported into different patients.

Google Groups archive
1

This is an issue related to my previous question. Here are the steps to reproduce:

  1. Two DICOM files with these differences (see attachment)

File 1: File 2:

PatientID: 987654321

PatientName: A A

PatientBirthDate: 19560101 19560101

PatientSex: M M

StudyInstanceUID: 1234.1.1.2.1 1234.1.1.2.1

SeriesInstanceUID: 1234.1.1.2.1.1 9.8.7.6

SOPInstanceUID: 1234.1.1.2.1.1.1 9.8.7.6.1

  1. Use an Orthanc server with no current patients (simpler to see problem)

  2. Send the DICOM files to the Orthanc server: “storescu --call ORTHANC 192.168.1.65 4242 CT* -v”

4.The result is two patient records – each with a copy of a study instance record of the same StudyInstanceUID.

I don’t believe the DICOM standard says anywhere that the PatientID tag uniquely determines a patient on planet earth. But I believe it does say that a StudyInstanceUID should only belong to one patient. The two DICOM entities above have the same StudyInstanceUID and should therefore be assigned to the same patient record.

Both this issue an the previous issue I believe are related to the DicomInstanceHasher algorithm. Is there any way to alter the behavior of this class from a plugin? Or is it possible to alter the behavior of this class based on configuration switches.

Thanks in advance for your consideration of this issue.

Stacy Loesch.

OrthancBugReport.2.7z (1.19 KB)

2

Hi Stacy,

Indeed, the PatientID is not a unique identifier for the patient like the StudyInstanceUID is for the study.

However, it seems to me that the standard says that both the Patient and Study Modules shall be identical in each instance of a study which is not the case in your sample data. What is the PatientID of this patient ? null or 987654321 ? Why would we trust file1 more than file2.

No, the way the DicomHasher works is not configurable (and not accessible through the plugin SDK).

Only recommendation I have is to sanitize your data before pushing them to Orthanc.

Best regards,

Alain.

3

It doesn’t make sens to have a StudyUID with different PatientID.

PatientID is not a unique key as studyUID, but is has to rely on something consistant, so if your patientID are inconstant you can count on it …

4

Thanks for the responses.

I think it’s probably best to end the discussion on this issue here. Any more comments somebody wants to make here it’s probably best to add them to the discussion on “Only PatientID tag is used…”.

Stacy.