Dgate.exe is 11/28/07
Leszek
Posts by ljaszcza
-
-
My current statement in Dicom.ini is:
ExportConverter0 = forward patient age -600+0 modality %m to FAIRLIGHT5
No change in what happens though. When I run a patient with multiple studies in the last year, Conquest says:
[FAIRLIGHT] Exportconverter0.0: queued forward pat - (CR of WTF790) to FAIRLIGHT5
and only forwards the current examination.
-
A CT with 261 images/ 5 series came in. Conquest forwarded 18038 images. I did cut the ForwardDelay = 6, is this the problem? Or, is this behavior due to the ForwardAssociationLevel = image setting? Should it be "study"? The sending CT is a Toshiba Aquillion 4 slice.
Thanks, Leszek -
hmm,
The error is associated with the date filter.
If I say "forward patient to Fairlight5", it works, sends everything for the patinet.
If I say " forward patient modality m% to Fairlight5", it only forwards the current examination for the patient.
If I say "forward patient now -360 to Fairlight5", I get the "remote DICOM error" I mentioned above.
If I say "forward patient age -360 to Fairlight5", It incorrectly forwards just the current study rather than the last 360 days. It correctly says: [FAIRLIGHT] Exportconverter0.0: queued forward pat - (20070106-20080101 of WTF790) to FAIRLIGHT5 but only delivers the current examination rather than everything for the specified date range.
I tried "forward study" instead of "forward patient" with the same behavior.Am I doing something wrong?
Thanks, Leszek
-
Note: this post concerns an unreleased version.
Hi Marcel,
I am trying to get Conquest 13a to forward studies from the last 360 days, matched by modality, when forwarding patients. Here is how I set up my dicom ini. Converter0 is the one in question.ForwardAssociationLevel = image
ForwardAssociationCloseDelay = 5
ForwardAssociationRefreshDelay = 3600
ForwardAssociationRelease = 0ExportConverters = 3
ExportConverter0 = forward study modality %m now -360 to FAIRLIGHT5
ExportConverter1 = forward to RisviewjhHere is what I get:
[FAIRLIGHT] Exportconverter0.0: queued forward stu - (20070006-20080006 of WTF790) to FAIRLIGHT5
[FAIRLIGHT] [recompress]: recompressed with mode = j2 (strip=0)
[FAIRLIGHT] Written file: F:\fairdicom\WTF790\1.22.333.4444.55555.20080101123946.1.1_0001_000002_1199210706002f.dcm
[FAIRLIGHT] UPACS THREAD 0: ENDED AT: Tue Jan 01 17:01:01 2008
[FAIRLIGHT] UPACS THREAD 0: TOTAL RUNNING TIME: 2 SECONDS
[FAIRLIGHT] Mirror copy: \\n5200\usbhdd\fairdicom\WTF790\1.22.333.4444.55555.20080101123946.1.1_0001_000002_1199210706002f.dcm
[FAIRLIGHT] [recompress]: recompressed with mode = un (strip=1)
[FAIRLIGHT] ExportConverter1.0: forward F:\fairdicom\WTF790\1.22.333.4444.55555.20080101123946.1.1_0001_000002_1199210706002f.dcm to Risviewjh
[FAIRLIGHT] [recompress]: recompressed with mode = un (strip=1)
[FAIRLIGHT]
[FAIRLIGHT] UPACS THREAD 1: STARTED AT: Tue Jan 01 17:01:07 2008
[FAIRLIGHT] Calling Application Title : "FAIRLIGHT "
[FAIRLIGHT] Called Application Title : "FAIRLIGHT "
[FAIRLIGHT] Application Context : "1.2.840.10008.3.1.1.1"
[FAIRLIGHT] Presentation Context 0 "1.2.840.10008.5.1.4.1.2.1.2"
[FAIRLIGHT] C-Move Destination: "FAIRLIGHT5 "
[FAIRLIGHT] C-Move (PatientRoot)
[FAIRLIGHT] ***preretrieve/forward xxx to: remote DICOM error
[FAIRLIGHT] UPACS THREAD 1: ENDED AT: Tue Jan 01 17:01:07 2008
[FAIRLIGHT] UPACS THREAD 1: TOTAL RUNNING TIME: 0 SECONDSI don't know where the remote dicom error is coming from. If I just specify Forward to Fairlight5, it works. What am I missing?
Thanks,
Leszek -
Ok. There is a ~355meg file in printer_files. The __checklarestmalloc: yields
[FAIRLIGHT] Server command sent using DGATE -- option
[FAIRLIGHT] Largest malloc = 730 MBI guess I should set up a noncompressed instance of conquest and route that machine to it.
I wonder why this problem never arose before. The machine has 2gb physical memory.
Leszek
-
hmm, I rebooted the logiq e and got the following message from conquest during the logiq e boot.
[FAIRLIGHT] UPACS THREAD 1: STARTED AT: Fri Nov 30 08:13:40 2007
[FAIRLIGHT] Calling Application Title : "FAIRGEUS2 "
[FAIRLIGHT] Called Application Title : "FAIRLIGHT "
[FAIRLIGHT] Application Context : "1.2.840.10008.3.1.1.1"
[FAIRLIGHT] Presentation Context 0 "1.2.840.10008.5.1.4.1.1.7"
[FAIRLIGHT] Presentation Context 1 "1.2.840.10008.5.1.4.1.1.6.1"
[FAIRLIGHT] Presentation Context 2 "1.2.840.10008.5.1.4.1.1.3.1"
[FAIRLIGHT] Presentation Context 3 "1.2.840.10008.5.1.4.1.1.6"
[FAIRLIGHT] Presentation Context 4 "1.2.840.10008.5.1.4.1.1.3"
[FAIRLIGHT] *** Association rejected: you may need to add the listed presentation context as sop to dgatesop.lst
[FAIRLIGHT] UPACS THREAD 1: ENDED AT: Fri Nov 30 08:18:40 2007
[FAIRLIGHT] UPACS THREAD 1: TOTAL RUNNING TIME: 300 SECONDSAll these SOP are correct for multiframe US storage and present in my dgatesop.lst (I opened the list and confirmed). Why the rejection? Is this related to the previous error?
To clarify, I rebooted the GE US after the conquest failure of the previous post. The US pauses for a long time at boot and I see the above error in conquest...Leszek
Leszek
-
I am trying to send a US cardiac study with a couple of lengthy cine sequences. I believe that the longest is about 200meg in size. I get the following error sequence followed by a "dead server restart", debug level 4. The machine is a GE Logiq e, about 6 months old.
[FAIRLIGHT] UPACS THREAD 74: STARTED AT: Fri Nov 30 08:05:58 2007
[FAIRLIGHT] A-ASSOCIATE-RQ Packet Dump
[FAIRLIGHT] Calling Application Title : "FAIRGEUS2 "
[FAIRLIGHT] Called Application Title : "FAIRLIGHT "
[FAIRLIGHT] Application Context : "1.2.840.10008.3.1.1.1"
[FAIRLIGHT] Number of Proposed Presentation Contexts: 5
[FAIRLIGHT] Presentation Context 0 "1.2.840.10008.5.1.4.1.1.7"
[FAIRLIGHT] Presentation Context 1 "1.2.840.10008.5.1.4.1.1.6.1"
[FAIRLIGHT] Presentation Context 2 "1.2.840.10008.5.1.4.1.1.3.1"
[FAIRLIGHT] Presentation Context 3 "1.2.840.10008.5.1.4.1.1.6"
[FAIRLIGHT] Presentation Context 4 "1.2.840.10008.5.1.4.1.1.3"
[FAIRLIGHT] Server Command := 0001
[FAIRLIGHT] Message ID := 002e
[FAIRLIGHT] 0000,0002 28 UI AffectedSOPClassUID "1.2.840.10008.5.1.4.1.1.3.1"
[FAIRLIGHT] 0000,0100 2 US CommandField 1
[FAIRLIGHT] 0000,0110 2 US MessageID 46
[FAIRLIGHT] 0000,0700 2 US Priority 0
[FAIRLIGHT] 0000,0800 2 US DataSetType 0
[FAIRLIGHT] 0000,1000 50 UI AffectedSOPInstanceU "1.2.840.113619.2.224.3420688.1194391281.0.386.512"
[FAIRLIGHT] 0002,0010 19 UI TransferSyntaxUID "1.2.840.10008.1.2.1"
[FAIRLIGHT] Written file: F:\fairdicom\36174\1.2.840.113619.2.224.3420688.1194391281.0.385_0001_000001_11962778131081.dcm
[FAIRLIGHT] UPACS THREAD 71: ENDED AT: Fri Nov 30 08:08:33 2007
[FAIRLIGHT] UPACS THREAD 71: TOTAL RUNNING TIME: 591 SECONDS
[FAIRLIGHT] ExportConverter0.0: forward F:\fairdicom\36174\1.2.840.113619.2.224.3420688.1194391281.0.385_0001_000001_11962778131081.dcm to FAIRLIGHT5
[FAIRLIGHT] Mirror copy: \\n5200\usbhdd\fairdicom\36174\1.2.840.113619.2.224.3420688.1194391281.0.385_0001_000001_11962778131081.dcm
[FAIRLIGHT] [DecompressImage]: internal decompressor does not support color jpeg, using external decompressor
[FAIRLIGHT] 0000,0002 18 UI AffectedSOPClassUID "1.2.840.10008.1.1"
[FAIRLIGHT] 0000,0100 2 US CommandField 48
[FAIRLIGHT] 0000,0110 2 US MessageID 7
[FAIRLIGHT] 0000,0800 2 US DataSetType 257
[FAIRLIGHT] 9999,0400 6 UN "silent"
[FAIRLIGHT] 0000,0002 18 UI AffectedSOPClassUID "1.2.840.10008.1.1"
[FAIRLIGHT] 0000,0100 2 US CommandField 48
[FAIRLIGHT] 0000,0110 2 US MessageID 7
[FAIRLIGHT] 0000,0800 2 US DataSetType 257
[FAIRLIGHT] 9999,0400 6 UN "silent"
[FAIRLIGHT] ***VR:ReAlloc out of memory allocating 355622400 bytes
[FAIRLIGHT] ***A fatal error occurred (out of memory) - closing serverIt seems like the external decompressor is running out of memory? Allocate 355gigs of memory, ha ha. Any idea on what is happening here and how to fix it? Actually the first longest cine seems to make it to conquest, the second and subsequent images are not present. Conquest reports the first cine sequence is present at 118 meg. The second image in the series is just a single color doppler image.
This machine has been sending a variety of studies including echocardiograms for months now without any problem sending. I wonder if one of the sequences is not corrupted. But, the error seems to occur during decompression for verification so I guess it must be a decompressor failure, right?Thanks,
Leszek -
Yes, that syntax is good.
Define patient/study/series is necessary I think.
The compressed clause is a good idea.
The modality clause is necessary.
I agree, the date seems easiest to implement (and most useful) as age relative to the study, probably as +/-days.Thanks,
Leszek -
Well,
Time and modality is the most useful. The forward patient feature is almost unusable for me because of critical care patients. A clinic sends an single image portable chest and forward patient send 100s of images of old CT angiograms, etc. This is a constant problem during the work day, the workstation is slowed down by acceptance of 100s of not useful images.
A filter is really needed to make this feature work.
1. Modality. We should be able to limit by modality. ie, a CR pulls up old CR studies, CT old CT studies.
2. Time. Either limit by time or old exam. So, limit by t-365 days for old examinations or x old studies.
3. Body part matching would be nice but not necessary.
4. Allowing the user to specify patient matching criteria. So; match by ID and/or last name and/or birthdate. Again, this would be a nice but not necessary feature. I have patients who go to multiple institutions and so have a clinic ID, hospital ID, perhaps a second clinic ID. Matching by LAST NAME (AND) BIRTH DATE rather than just PATIENT ID is nice.Anyhow, I have not programmed for years but will peer at the code to see if I can help. This request is a lot of work.
The first two points (time and modality matching) are really needed to make the forward patient feature work. The others are icing on the cake.
Thanks,
LJJ -
Is there a way to limit the "patient forward"? That is to say, limit forwarding by same modality or body part?
ie, if a Chest CR comes in forward patient's chest CR exams?
I did not see a way to do this from the manual instructions.Thanks, LJJ
-
Marcel, what is happening here?
[FAIRLIGHT] ***[CompressJPEGImage]: Error on load after: dcmcjpeg +el +un +sr F:\fairdicom\printer_files\1.2.826.0.1.3680043.2.135.732936.34336296.6.1193697443.625.46.dcm out.dcm)
[FAIRLIGHT] Added file: F:\fairdicom\SHC32732\1.3.12.2.1107.5.2.2.9934.20050112082909000002_0002_000138_11930002311285.v2
[FAIRLIGHT] Mirror copy: \\N5200\usbhdd\FAIRDICOM\SHC32732\1.3.12.2.1107.5.2.2.9934.20050112082909000002_0002_000138_11930002311285.v2
[FAIRLIGHT] 0000,0002 18 UI AffectedSOPClassUID "1.2.840.10008.1.1"
[FAIRLIGHT] 0000,0100 2 US CommandField 48
[FAIRLIGHT] 0000,0110 2 US MessageID 7
[FAIRLIGHT] 0000,0800 2 US DataSetType 257
[FAIRLIGHT] 9999,0400 88 UN "addimagefile:F:\\temp2\\1.2.826.0.1.3680043.2.135.732936.34336296.6.1193000231.890.74.dcm"Is the system leaving files in the printer_files secondary to a jpeg error? I have conquest set to jpeg lossless storage on Mag0.
Thanks,
Leszek -
Well, I just made a new data directory, pointed conquest to it and drop/dragged the old one and things seem to be going ok. The printer_files directory is being used correctly.
Initially, my data directory was "Fairlight conquest" with a space. That seems to cause difficulties occasionally, so the new data directory is without a space in the name... I wonder if that was part of the problem?
Anyhow, things seem to be ok now. No buildup of files in the printer_files directory and I am mirroring to a NAS drive succesfully.
Good deal.
Thanks for a great product, LJJ -
hmm.
All dicom files.
I am trying to regen the database and clean it up via drag and drop, the printer_files directory immediately starts filling up with duplicates ( at least I think they are duplicates).
I think this may be a permission problem but cannot pin it down yet. I did change dgate logon as local administrator rather than system account to fix the write to mirror problem. Could this be the problem? I did confirm that the directory has proper permissions for local administrator to write to the Printer_files directory. No change in the duplicates appearing.
I am using XP sp2. Conquest latest beta version.This is unusual. I run three conquest servers on this machine, all mysql native. Two share a single database and file directory, the third has it's own database and different directory. All three are otherwise set up similarly. MySql native, mirror drive, log in service as local administrator. The problem is seen in my larger shared database, not the smaller solo database.
So, now I can't even regen my database because printer_files quickly grows to gigantic (double) size.
Anyone have this problem too? Or able to replicate it?
Thanks, LJJ -
My main conquest storage directory (mysql setup) has 240,000 files, 60 gigs. I have never used the print function. What is happening? Are these deletable?
Thanks, LJJ -
I forgot to specify that I have the service log in under the administrator account rather than "local service" in the service preferences menu. It does not seem to work if the service is run under "local service". Permissions problem I suppose.
-
I have some insight on the write to NAS problem. The issue stems from Microsoft's improper handling of mapped drives. In short, a service is unable to write to a mapped drive unless a service running a local account maps the drive.
A workaround is to use the machine path rather than the mapped drive name.
So, in my dicom.ini, setting mirror to x: where x: is my mapped drive errors out. But, setting mirror to \\machine name\path works fine.
Phew, now a have a easier way of setting up offsite backup.
Hope this helps someone,
LJJ -
Sorry Lambert,
We don't "see" you as often as Marcel. Thanks to you too for the hard work and for allowing us to share.
LJJ -
Likewise here,
Marcel,
Thank you for the wonderful job on Conquest. It is a great help to small/rural health care and imaging centers. Well done. Please keep us users up to date if there is anything we can help with.L.J.Jaszczak MD
-
Well, I think three levels of granularity would be useful to forward comparison studies.
1) specify match by modality. This is most important. If Conquest forwards a CR, we should be able to limit it to forwarding old CRs only.
2) specify number of old studies to forward or limit by time. Less important but useful. For example, if more than 5 old CR examinations are present, only forward the most recent 5 examinations. Or only forward examinations within 3 years of current examination.
3) Specify patient match by name (and/or) Patient ID (and/or) birth date for old film retrieval. This is less important but useful when patients have misspelled or alternate (jim^jones for example) name presentations or clinic/hospital IDs. So you could specify a strict name and ID match for old examination retrieval or a loose name or ID match. Or even a ((name and birth date) or (ID and birth date)) statement.