Dear Marcel,
We have a strange issue with our DICOM router, based on Conquest 1.5.0b. We use use the (DICOM) PatientID (0010,0020) as the primary patient identifier. Secondary to this, data stored on our main PACS is encoded with the patient’s SSN (BSN), always in the “OtherPatientIDs” sequence, with IssuerOfPatientID=’NLMINBIZA’. Our DICOM router is configured as a caching proxy (VirtualServerFor0) for our main PACS.
# Configuration of the virtual server
CacheVirtualData = 1
OverlapVirtualGet = 0
VirtualServerFor0 = MAINPACS,FIXKODAK,CACHESTUDIES
Every so often we find that we cannot push data to our DICOM router, and the router complains about a
***Refused to enter inconsistent link PatientID into DICOMStudies: PatientID = 'XXXXXXXX' StudyInsta = '2.16.840.1.113883(…)019', Old='YYYYYYYYY', Refused='XXXXXXXX'
where XXXXXXXX is our primary PatientID, and YYYYYYYYY is the patient’s SSN (BSN), which means the DICOM router is telling us that it already has data in its database (Microsoft SQL Server) for the given StudyInstanceUID, but for a patient identified by his SSN instead of his PatientID. Using the Conquest GUI we can navigate to this record (and delete it thus solving the collision), which usually seems to be an RTPLAN object, but the underlying (DICOM) image (.dcm) file seems to be never present. Digging through our history (months, years) of Conquest logfiles we can never find a line in serverstatus.log that reports ‘Written file D:\Dicom\Data\YYYYYYYYY\(……).dcm’, which gives us the idea that we never received any data (-slices, -objects, from the main PACS or any other system in our landscape) that had the patient’s SSN as its primary PatientID. If we use our Conquest to query our main PACS using not the PatientID but the patient’s SSN instead, we also get that patient’s data, but a retrieve command does write lines like ‘Written file D:\Dicom\Data\YYYYYYYYY\(…).dcm’ into our serverstatus.log files, showing somebody retrieved data using the SSN as a PatientID. So, somebody accidentally retrieving data from our main PACS, through our DICOM router, using the SSN as PatientID seems to be unlikely (as we never see this happen in the logfiles).
We are wondering how this conflicting record (the one encoded by the patient’s SSN) can end up in our database. We have done some digging through Conquest’s source code and found the possibly related “VirtualQueryToDb()” function, which can be used to trigger QueryConverter0 and QueryResultConverter0, but we are not sure about the conditions under which possibly this mechanism could save query-results, perhaps containing SSN-information, into our database, setting the stage for a later collision. We have only Import- and ExportConverters, no Query(Result)Converters or anything else.
Could you help us by pointing us into a direction that we could further investigate? We would like to run our DICOM router in a higher debug level to get more internal operational information, but we are hesitant to do so because of its high load.
Kinds regards,
Maarten