Posts by mukoya

Understood.

Thank you.

Hi Marcel.

We have a situation where a hospital has signed up for reporting services from a reporting company.

The arrangement is such that only a certain number of studies should be sent per day for remote reporting.

When routing via Conquest, is there a way we can configure it to send only the first so many studies and ignore the rest?

Regards.

Mukoya.

Hi Marcel,

Your suggestion worked!

We used the first example.

Thank you again.

Thank you.

I will try this.

Regards.

Hi,

There are instances when a DICOM tag has multiple distinct components under the same parent tag, e.g., the 008,008 tag (see attached).

How do I represent one of the parts in a converter?

For example, in the attached image, I would like to replace the phrase "GENERATED_2D" with a different value; let's just say "RIGHT". How would I compose the import converter to replace this phrase while leaving other components in the tag intact?

Thank you.

My Apologies, Marcel

It appears we did not collect sufficient info before contacting you. We made several assumptions.

It looks like there were 3 distinct studies, and some images between the studies conflicted.

In the image attached, I have masked PID, Name, and DOB, which were the same in all 3.

We will identify a pair of conflicting files from two of the studies and then interrogate further. I will then update you.

We have not seen a similar error again on this or other PostgreSQL installations so far.

Thank you.

We have done further tests, and looks like someone changed the study details on modality before resending.

So, the error does not occur when the exact same study is re-sent to Conquest. This is a good thing.

The error seems to occur when a duplicate SOP Instance UID is received with study/series details that do not match those of the old similar SOP Instance.

So, it is a different, less serious problem than what we initially thought. Resending failed studies is not an issue unless the user changes the study details before resending.

4/12/2025 6:19:28 PM [RADWEB] *** ERROR: duplicate key value violates unique constraint "dicomimages_pkey" DETAIL: Key (sopinstanc)=(1.2.156.112536.3.560.11000010138.1519099378125.131) already exists.

4/12/2025 6:19:28 PM [RADWEB] ***Failed PGSQLExec : INSERT INTO DICOMImages (SOPInstanc, SOPClassUI, ImageNumbe, EchoNumber, AcqDate, AcqTime, ReceivingC, SamplesPer, PhotoMetri, QRows, QColumns, BitsStored, ImageType, ImagePat, SeriesInst, AccessTime, ObjectFile, DeviceName) VALUES ('1.2.156.112536.3.560.11000010138.1519099378125.131', '1.2.840.10008.5.1.4.1.1.4', '4', '1', '20250411', '095211', 'L_BODY', '1', 'MONOCHROME2', '512', '512', '12', E'DERIVED\\PRIMARY\\OTHER\\PK', 'NAKR-850694', '1.2.156.112536.3.560.11000010138.1519099147953.35', 1744471136, E'Images\\20250411\\NAKR-850694\\0\\40155\\1.2.156.112536.3.560.11000010138.1519099378125.131.dcm', 'MAG0')

4/12/2025 6:19:28 PM [RADWEB] Query On Image

4/12/2025 6:19:28 PM [RADWEB] Issue Query on Columns: DICOMImages.SOPInstanc, DICOMSeries.SeriesInst, DICOMStudies.PatientID, DICOMStudies.StudyInsta

4/12/2025 6:19:28 PM [RADWEB] Values: DICOMStudies.PatientID = E'NAKR-850694' and DICOMSeries.StudyInsta = DICOMStudies.StudyInsta and DICOMImages.SeriesInst = DICOMSeries.SeriesInst

4/12/2025 6:19:28 PM [RADWEB] Tables: DICOMImages, DICOMSeries, DICOMStudies

4/12/2025 6:19:28 PM [RADWEB] Query Distinct Tables: DICOMImages, DICOMSeries, DICOMStudies

4/12/2025 6:19:28 PM [RADWEB] Columns : DICOMImages.SOPInstanc, DICOMSeries.SeriesInst, DICOMStudies.PatientID, DICOMStudies.StudyInsta

4/12/2025 6:19:28 PM [RADWEB] Where : DICOMStudies.PatientID = E'NAKR-850694' and DICOMSeries.StudyInsta = DICOMStudies.StudyInsta and DICOMImages.SeriesInst = DICOMSeries.SeriesInst

4/12/2025 6:19:28 PM [RADWEB] Records = 0

4/12/2025 6:19:28 PM [RADWEB] RemoveFiles 0 images

4/12/2025 6:19:28 PM [RADWEB] Add to Table: DICOMImages

4/12/2025 6:19:28 PM [RADWEB] Columns: SOPInstanc, SOPClassUI, ImageNumbe, EchoNumber, AcqDate, AcqTime, ReceivingC, SamplesPer, PhotoMetri, QRows, QColumns, BitsStored, ImageType, ImagePat, SeriesInst, AccessTime, ObjectFile, DeviceName

4/12/2025 6:19:28 PM [RADWEB] Values: '1.2.156.112536.3.560.11000010138.1519099139859.119', '1.2.840.10008.5.1.4.1.1.4', '1', '1', '20250411', '094755', 'L_BODY', '1', 'MONOCHROME2', '512', '512', '12', E'DERIVED\\PRIMARY\\OTHER\\PK', 'NAKR-850694', '1.2.156.112536.3.560.11000010138.1519098871343.34', 1744471136, E'Images\\20250411\\NAKR-850694\\0\\40154\\1.2.156.112536.3.560.11000010138.1519099139859.119.dcm', 'MAG0'

4/12/2025 6:19:28 PM [RADWEB] *** ERROR: duplicate key value violates unique constraint "dicomimages_pkey" DETAIL: Key (sopinstanc)=(1.2.156.112536.3.560.11000010138.1519099139859.119) already exists.

4/12/2025 6:19:28 PM [RADWEB] ***Failed PGSQLExec : INSERT INTO DICOMImages (SOPInstanc, SOPClassUI, ImageNumbe, EchoNumber, AcqDate, AcqTime, ReceivingC, SamplesPer, PhotoMetri, QRows, QColumns, BitsStored, ImageType, ImagePat, SeriesInst, AccessTime, ObjectFile, DeviceName) VALUES ('1.2.156.112536.3.560.11000010138.1519099139859.119', '1.2.840.10008.5.1.4.1.1.4', '1', '1', '20250411', '094755', 'L_BODY', '1', 'MONOCHROME2', '512', '512', '12', E'DERIVED\\PRIMARY\\OTHER\\PK', 'NAKR-850694', '1.2.156.112536.3.560.11000010138.1519098871343.34', 1744471136, E'Images\\20250411\\NAKR-850694\\0\\40154\\1.2.156.112536.3.560.11000010138.1519099139859.119.dcm', 'MAG0')

4/12/2025 6:19:28 PM [RADWEB] Query Tables: DICOMImages

4/12/2025 6:19:28 PM [RADWEB] Columns : ObjectFile, DeviceName

4/12/2025 6:19:28 PM [RADWEB] Where : SOPInstanc = '1.2.156.112536.3.560.11000010138.1519099140640.120' AND ImagePat = 'NAKR-850694'

4/12/2025 6:19:28 PM [RADWEB] Order : (null)

4/12/2025 6:19:28 PM [RADWEB] FreeStore Left 161220 on D:\

4/12/2025 6:19:28 PM [RADWEB] Add to Table: DICOMImages

4/12/2025 6:19:28 PM [RADWEB] 0000,0002 18 UI AffectedSOPClassUID "1.2.840.10008.1.1"

4/12/2025 6:19:28 PM [RADWEB] 0000,0100 2 US CommandField 48

4/12/2025 6:19:28 PM [RADWEB] Query On Image

4/12/2025 6:19:28 PM [RADWEB] Issue Query on Columns: DICOMImages.SOPInstanc, DICOMSeries.SeriesInst, DICOMStudies.PatientID, DICOMStudies.StudyInsta

4/12/2025 6:19:28 PM [RADWEB] Values: DICOMStudies.PatientID = E'NAKR-850694' and DICOMSeries.StudyInsta = DICOMStudies.StudyInsta and DICOMImages.SeriesInst = DICOMSeries.SeriesInst

4/12/2025 6:19:28 PM [RADWEB] RemoveFiles 0 images

4/12/2025 6:19:28 PM [RADWEB] Add to Table: DICOMImages

4/12/2025 6:19:28 PM [RADWEB] *** ERROR: duplicate key value violates unique constraint "dicomimages_pkey" DETAIL: Key (sopinstanc)=(1.2.156.112536.3.560.11000010138.1519099140640.120) already exists.

4/12/2025 6:19:28 PM [RADWEB] 0000,0002 18 UI AffectedSOPClassUID "1.2.840.10008.1.1"

4/12/2025 6:19:28 PM [RADWEB] 0000,0100 2 US CommandField 48

4/12/2025 6:19:28 PM [RADWEB] 0000,0110 2 US MessageID 1

4/12/2025 6:19:28 PM [RADWEB] Query On Image

4/12/2025 6:19:28 PM [RADWEB] Issue Query on Columns: DICOMImages.SOPInstanc, DICOMSeries.SeriesInst, DICOMStudies.PatientID, DICOMStudies.StudyInsta

4/12/2025 6:19:28 PM [RADWEB] Values: DICOMStudies.PatientID = E'NAKR-850694' and DICOMSeries.StudyInsta = DICOMStudies.StudyInsta and DICOMImages.SeriesInst = DICOMSeries.SeriesInst

4/12/2025 6:19:28 PM [RADWEB] Records = 0

4/12/2025 6:19:28 PM [RADWEB] RemoveFiles 0 images

4/12/2025 6:19:28 PM [RADWEB] Add to Table: DICOMImages

4/12/2025 6:19:28 PM [RADWEB] Columns: SOPInstanc, SOPClassUI, ImageNumbe, EchoNumber, AcqDate, AcqTime, ReceivingC, SamplesPer, PhotoMetri, QRows, QColumns, BitsStored, ImageType, ImagePat, SeriesInst, AccessTime, ObjectFile, DeviceName

4/12/2025 6:19:28 PM [RADWEB] Values: '1.2.156.112536.3.560.11000010138.1519099141437.121', '1.2.840.10008.5.1.4.1.1.4', '3', '1', '20250411', '094755', 'L_BODY', '1', 'MONOCHROME2', '512', '512', '12', E'DERIVED\\PRIMARY\\OTHER\\PK', 'NAKR-850694', '1.2.156.112536.3.560.11000010138.1519098871343.34', 1744471136, E'Images\\20250411\\NAKR-850694\\0\\40154\\1.2.156.112536.3.560.11000010138.1519099141437.121.dcm', 'MAG0'

4/12/2025 6:19:28 PM [RADWEB] 0000,0002 18 UI AffectedSOPClassUID "1.2.840.10008.1.1"

4/12/2025 6:19:28 PM [RADWEB] 0000,0100 2 US CommandField 48

4/12/2025 6:19:28 PM [RADWEB] 0000,0110 2 US MessageID 1

4/12/2025 6:19:28 PM [RADWEB] 0000,0800 2 US DataSetType 257

4/12/2025 6:19:28 PM [RADWEB] 0002,0010 17 UI TransferSyntaxUID "1.2.840.10008.1.2"

4/12/2025 6:19:28 PM [RADWEB] 9999,0400 26 LO ConquestConsoleComma "deletepatient:NAKR-850694"

4/12/2025 6:19:28 PM [RADWEB] Deleting patient: NAKR-850694

4/12/2025 6:19:28 PM [RADWEB] Query On Image

4/12/2025 6:19:28 PM [RADWEB] Issue Query on Columns: DICOMImages.SOPInstanc, DICOMSeries.SeriesInst, DICOMStudies.PatientID, DICOMStudies.StudyInsta

4/12/2025 6:19:28 PM [RADWEB] Values: DICOMStudies.PatientID = E'NAKR-850694' and DICOMSeries.StudyInsta = DICOMStudies.StudyInsta and DICOMImages.SeriesInst = DICOMSeries.SeriesInst

4/12/2025 6:19:28 PM [RADWEB] Tables: DICOMImages, DICOMSeries, DICOMStudies

4/12/2025 6:19:28 PM [RADWEB] Query Distinct Tables: DICOMImages, DICOMSeries, DICOMStudies

4/12/2025 6:19:28 PM [RADWEB] Columns : DICOMImages.SOPInstanc, DICOMSeries.SeriesInst, DICOMStudies.PatientID, DICOMStudies.StudyInsta

4/12/2025 6:19:28 PM [RADWEB] Where : DICOMStudies.PatientID = E'NAKR-850694' and DICOMSeries.StudyInsta = DICOMStudies.StudyInsta and DICOMImages.SeriesInst = DICOMSeries.SeriesInst

4/12/2025 6:19:28 PM [RADWEB] Order : (null)

4/12/2025 6:19:28 PM [RADWEB] Records = 0

4/12/2025 6:19:28 PM [RADWEB] RemoveFiles 0 images

4/12/2025 6:19:28 PM [RADWEB] Add to Table: DICOMImages

4/12/2025 6:19:28 PM [RADWEB] Columns: SOPInstanc, SOPClassUI, ImageNumbe, EchoNumber, AcqDate, AcqTime, ReceivingC, SamplesPer, PhotoMetri, QRows, QColumns, BitsStored, ImageType, ImagePat, SeriesInst, AccessTime, ObjectFile, DeviceName

4/12/2025 6:19:28 PM [RADWEB] Values: '1.2.156.112536.3.560.11000010138.1519099142218.122', '1.2.840.10008.5.1.4.1.1.4', '4', '1', '20250411', '094755', 'L_BODY', '1', 'MONOCHROME2', '512', '512', '12', E'DERIVED\\PRIMARY\\OTHER\\PK', 'NAKR-850694', '1.2.156.112536.3.560.11000010138.1519098871343.34', 1744471136, E'Images\\20250411\\NAKR-850694\\0\\40154\\1.2.156.112536.3.560.11000010138.1519099142218.122.dcm', 'MAG0'

4/12/2025 6:19:28 PM [RADWEB] *** ERROR: duplicate key value violates unique constraint "dicomimages_pkey" DETAIL: Key (sopinstanc)=(1.2.156.112536.3.560.11000010138.1519099142218.122) already exists.

4/12/2025 6:19:28 PM [RADWEB] ***Failed PGSQLExec : INSERT INTO DICOMImages (SOPInstanc, SOPClassUI, ImageNumbe, EchoNumber, AcqDate, AcqTime, ReceivingC, SamplesPer, PhotoMetri, QRows, QColumns, BitsStored, ImageType, ImagePat, SeriesInst, AccessTime, ObjectFile,

Noted.

Yes, it's not a critical feature... Nice to have.

Thank you.

Hi Marcel,

Conquest, in our setup, seems to zip logs (and other important files) daily and store them in the log folder. BTW, this is really helpful!

However, it looks like these log folders can grow quite large for a busy center.

Is there a way Conquest can automatically delete the oldest zipped log files, say after a month?

Thank you.

Looks like Conquest with Postgres behaves differently from Conquest with SQLite.

In SQLite, sending a duplicate SOP instance to Conquest does not cause any conflicts in the db. However, in Postgres, the duplicate SOP is rejected.

Here is an actual scenario that led to the attached error log messages.

We are using Conquest as a router.

Conquest forwards images over the internet, which (internet) can be unstable.

So, almost always, Conquest will receive images from modality faster than it can send.

Some files have been received into Conquest but are still in the queue for sending.

If Conquest shuts down, e.g., in this case I think it was due to a power outage, the forward queue in memory will be lost.

When the PC powers back on, there are some files that are in the Conquest database but did not reach the destination server where Conquest was to send them.

When the user notices this discrepancy, they resend the study from the modality to try to complete the image number on the destination PACS.

However, this is not possible because the images are rejected and therefore does not update the destination PACS unless the old study is deleted from db so that new one can be sent.

Conquest log:

20250411 11:06:16 ***Error saving to SQL: Images\20250403\NAKR-000111(N)\S-202504037085\4\1.2.156.14702.1.1003.64.2.20250403113829982576.dcm

20250411 11:06:16 *** ERROR: duplicate key value violates unique constraint "dicomimages_pkey"

DETAIL: Key (sopinstanc)=(1.2.156.14702.1.1003.64.2.20250403113829982576) already exists.

Postgres log:

2025-04-11 10:50:14 EAT STATEMENT: INSERT INTO DICOMImages (SOPInstanc, SOPClassUI, ImageNumbe, ImageDate, ImageTime, AcqDate, AcqTime, AcqNumber, SliceLocat, SamplesPer, PhotoMetri, QRows, QColumns, BitsStored, ImageType, ImagePat, SeriesInst, AccessTime, ObjectFile, DeviceName) VALUES ('1.2.156.14702.1.1003.64.2.20250403113832744734', '1.2.840.10008.5.1.4.1.1.2', '113', '20250403', '113832.000', '20250403', '113649.173', '4', '757.900024414063', '1', 'MONOCHROME2', '512', '512', '16', E'ORIGINAL\\PRIMARY\\AXIAL\\HELICAL', '963191(N)', '1.2.156.14702.1.1003.64.1.202504031131414741082585856828', 1744357792, E'Images\\20250403\\963191(N)\\S-202504037085\\4\\1.2.156.14702.1.1003.64.2.20250403113832744734.dcm', 'MAG0')

2025-04-11 10:50:14 EAT ERROR: duplicate key value violates unique constraint "dicomimages_pkey"

2025-04-11 10:50:14 EAT DETAIL: Key (sopinstanc)=(1.2.156.14702.1.1003.64.2.20250403113832744734) already exists.

Is there a trick we can employ to convince Postgres to behave like SQLite in this respect?

Thank you.

Thank you for your answer.

This retry helps a lot.

Actually, I believe the retry duration (probably less than 30 seconds in total) is rather short. I have not personally observed or tested this, but I believe that Postgres may take significantly longer when repairing a large database. I would have put it at 30 minutes to 1 hour total retry duration, e.g every 30 seconds 60 times. You may consider this in future.

Great!!!

Thank you Marcel.

Checking.

What is the expected behavior? Are there any settings maybe in the INI file we should create/adjust?

Thank you Marcel for your response.

This is acknowledged.

We will try figure out something, and if not possible, just use Conquest the way it is. Users can always manually resend studies if necessary.

Noted.

Thank you.

I will try the stopgap measure you have indicated for now.

We are also changing our installations to use dicom send to Conquest instead of import from folder.

Thank you.

Thank you Marcel, for your response.

Just to clarify, do you mean that:

1. There something we can do to make it retry? If so, kindly give me a pointer.

2. You could make changes to code on your end to make it retry?.. If so, thank you. We will wait for the changes.

Regards.

Conquest seems to be doing well with Postgres.

However, there is a curious error I have seen a couple of times.

When the computer restarts (sometimes after a power outage), Postgres may take a few seconds to be available.

It seems like Conquest just checks about 3 times within 1-2 seconds and gives up.

When Postgres becomes available, Conquest does not know or try to find out.

In the two scenarios in which I have encountered this issue, Conquest was set to automatically import from a watched folder. Images just remain in the watched folder even when Postgres is back online.

Restarting postgres does not make any difference.

Everything works OK again after Conquest restart.

I also noted that in Conquest's "frozen" state, although it does not process items in watched folders, it processes images sent via C-move over the network. It is like an incoming DICOM association prompts it to recheck Postgres. However, even after receiving such images via DICOM network, it does not remember to process items in the watched folder unless Conquest itself is restarted.

Attached below is a side-by-side comparison of Conquest and Postres logs. Please take note of the time stamps.

Is there a way to set Conquest so that it checks for DB availability for longer or any other way to address this issue?

Thank you Marcel!

Hi Marcel,

When forwarding images, unless there is forwarding failure, it appears that the queued items are kept in RAM.

If there is a power outage, the queue is lost, leading to partial studies on the receiving server, unless the study is resent all over again from the source.

One could keep QueueSize option in dicom.ini low, say 5, but this can cause errors when forwarding via a slow network. It means that Conquest will slow down receiving of images to keep those in memory, pending sending at only 5.

One solution to this could be to keep this queue in a file on disk. This would make a big difference. When Conquest restarts (e.g., after a power outage), it checks the file and continues from where it left off.

Have you ever considered such an option, or do you have another trick to address this issue?

Thank you.

Hi Marcel,

My apologies; I think I might have overreacted when I noticed one error with Postgres, having had quite some trouble with MySQL.

The Postgres error appears to have been an isolated incident.

I have run Postgres on 5 fairly busy servers (including the one that had the error) for two days with no more errors.

So far, it appears that Postgres is not affected, and this is good enough for us; we will just forget about Mysql for now.

In case of any more errors that we are unable to fix, we will let you know.

Thank you.