I left the server running on Wednesday and was off yesterday, so this morning I have checked, and unfortunately I am still getting the same result with the new version. Just to confirm, the version I am now running is DGATE (1.4.16, build Wed Dec 14 18:05:11 2011, bits 32) as reported with a '-v' on startup.
I guess you are going to need an example in order to trouble shoot further? If so, I'll try and de-identify an example and pass it through the server.
Magic - thanks Gerald. I think that install is on 1.4.16beta. And my searching fu obviously isn't up to scratch!
Update: I thought I could get around the issue by simply passing the path of the SR in the default storage folder, but this doesn't work because the image isn't written there until after the 'system' command returns.
Therefore I really need to get 'save to' working in order to progress without resorting to scripts that monitor contents of folders...
Hi
I am using conquest primarily for dose audit collection. I have added the SOP for XRayRadiationDoseSRStorage and with no import arguments the structured reports are saved to the default location and I can extract all the dosimetry data using a python routine.
However, my preferred approach (aligned with what I have done for 'reading/ocr' the CT protocol images) is to 'save to' as an import argument, before running the analysis on the saved copy which subsequently deletes the image. The conquest version of the image is destroyed at the end of the import argument. Thus no patient data is stored on the server for more than a few minutes.
The problem is that the copy of the Dose SR that is made when using 'save to' only has the standard header data, none of the structured report section. The version that is saved to the default location is the whole thing.
Is this a feature or a bug? Can I change the behaviour?
Thanks in advance for you help!
Kind regards
Ed
Thanks Marcel.
It is good to know what the limitations are, rather than just guessing till it breaks!
I'm not sure I understand you, or maybe I haven't explained mysself very well.
The advantage of my setup is that the dose information gets extracted from the clinical image and written to file, then the image and associated data is deleted from conquest. This has two advantages:
1/ the server doesn't need to be very big as it only has the images for a very short time, and
2/ there are less information governance issues as the clinical information isn't being stored.
The disadvantage would be that I am storing data in csv file, which are nice and accessible, but not really where data should live!
I have thought about using the conquest database, but I don't think it would support keeping the dose data without any patient IDs. Even if you anonymised on import, I haven't worked out if you can delete the image but keep the text data. Any ideas if this is possible?
The other alternative I am thinking of is as I have it now, but instead of writing to csv, pass the variables to a script that then inserts them into a new database.
Any suggestions welcome!
True, but the beauty of this method is that no patient identifiable information gets stored for any time on the server.
An alternative would be to anonymise on import, but I have no use for the images.
Hi
I am trying to set up a method of recording patient dosimetry information by extracting information from DICOM headers. My basic setup is to use an ImportConverter to write the header information out to a file, then destroy the file. However, if there are more than 40 tags, it seems to ignore that ImportConverter - it doesn't write anything out and the serverstatus log just records the next ImportConverter, destroy. If I use exactly 40 tags, it writes them out but changes the export file name to something along the lines of doseauj<D8><D7><D4><C9>^N<A9>It<D6><C6>ˠ<E4>Kʫ<CB><E4>^Z<<E4>5iq<E9><AE>S\<8F><AF>>Ѯy<F4><A6>o#<E1>79<C2>\<A9>m<9E><A4><A5><D1>i)<D1>h<9A>b<9A><E8>^^俺?1<B6><84><93> A`6d֛<97>1Q<97><B1>Pg§{<E9><B2><E5><D8><E6>J<AF>ɷO?<D5><CE><D7>M^M<D4><FA>4^2UT.<E1>I.<FC><CE><CF>m<D9>n|<EE>d (it was doseaudit.csv)
Any ideas? Is there a limitation, or is this just a bug?
I am using the current version from the website, on Linux.
Desired converter:
ImportConverter0 = append "%V0008,0060,%V0018,1000,%V0018,700A,%V0008,0070,%V0008,0080,%V0008,1010,%V0008,1090,%V0008,0068,%V0008,0023,%V0008,0033,%V0020,000D,%V0020,000E,%V0020,0010,%V0020,0011,%V0020,0052,%V0010,0030,%V0010,0040,%V0010,1010,%V0018,0015,%V0018,1030,%V0018,5101,%V0020,0020,%V0020,0062,%V0018,1110,%V0018,1111,%V0018,1114,%V0040,0306,%V0018,1147,%V0018,1149,%V0018,11A0,%V0018,11A2,%V0018,1191,%V0018,1160,%V0018,7050,%V0018,1166,%V0018,1190,%V0018,0060,%V0018,1150,%V0018,1151,%V0018,1152,%V0018,1153,%V0018,1405,%V0040,0302,%V0040,0310,%V0040,0316,%V0040,0318,%V0018,6000,%V0018,7060,%V0018,7062,%V0018,7064%n" to doseaudit.csv18,1153 makes it do the funny file name, beyond that it ignores the line. I have tried switching 18,1153 for 18,1405, but the same thing happens.
I had the same issue with the posters above, using Ubuntu 10.04.1 AMD64, following the instructions in the linux manual.
I then went back and did a sudo make install for both the jpeg-6c and jasper directories, then did sudo sh maklinux, and it seems to have worked. Well, I now have a compiled dgate - I haven't tested it yet!
I hope that helps some one else!
Hello
Is logging of conquest as a service possible?
We have an application for conquest which would involve importing and exporting images between two trusts. It would be very useful to be able to identify which patients/images had been moved.
This would enable us to have some level of audit trail, so when a mistake has to be corrected on one of our images, we can take a look to see if it has been forwarded on to the other hospital.
Kind regards,
Ed
Thanks Marcel
So I guess that I can't use the calledAE in the filename for now then - please mark it as a bug for next release!
Kind regards,
Ed
Each CT slice is 512kB, or half a meg.
The average size of a study will depend on the type of study, the thickness and interval of the slices that are stored, the number of recon jobs that are stored etc etc.
As an example though, Thorax Abdo Pelvis scans can easily end up with 1000 images in, which would take about 500MB storage space uncompressed.
I hope this is of some help.
Ed
Hi
It appears that if you use %callingae in the FileNameSyntax, the full 16 characters are written into the filename. If there are fewer characters in the AE Title, then ConQuest uses the extra spaces reports that it has
QuoteWritten file: C:\dicomserver\data\MG\RPYC_PHYIM02 \physics^gridfactor\study845\s2492-i4-000e.dcm
for example - notice the gap between IM02 and \physics
However, the files beneath the AE Title folder are never written, and that folder does not have the extra spaces.
My syntax is as follows:
Also, I am not clear as to how to get ConQuest to take notice of an edited dicom.ini. The only way I could do it in the end was to uninstall the NT service, close the service, make sure my changes were in dicom.ini, reboot the machine, and then restart ConQuest. Anything less and my changes were ignored!
I did try various combinations of kill and restart the server, verify database, re-initialize database etc, but presumably didn't get the particular sequence one must use! Any hints? The manual just says that you shouldn't need to edit it 
I am using v 1.4.12c
Thanks,
Ed
Thanks Marcel - that is excellent news.
Glad to see the forum has been resurrected as well!
I have had a quick try with adding a kVp field, and it works fine.
I have one question though - in the dicom.sql file, it specifies the format as
However, it seems most of the SQL-Types are set to SQL_C_CHAR (except the date fields), and most of the DICOM-Types are set to DT_STR or DT_UINT.
I would have expected a few more types to be used for the SQL, and for the DICOM-Types to correspond to the Value Representations in the DICOM Dictionary (3.6). Are the types simplified for a reason? Do I need to worry about them?
Thanks once again for your help. Conquest looks like it is going to be very useful.
Ed
Hi
I have just installed conquest to hopefully replace the wonderful KPACS I have been using for the last couple of years.
I use my DICOM store to keep all the images that are generated whilst doing medical physics QA of diagnostic radiology scanners of various types.
My question is whether it is possible for the database tables to be configured for more/different tags than the usual patient centric ones.
For example, I would like to be able to query the database conquest creates for CT images from June 2007 from scanner x where the kV was 120 and the slice thickness 2.5 mm.
I wouldn't need to be able to do the query from Conquest - I am planning on using some other software to query the database before performing automated QA on the data. However, I would want conquest to act as the DICOM store and create the tables in the database in the first place.
Is there any chance? Or is this something that is deeply hard-coded into the system?
Many thanks for what seems to be an excellent system so far!
Ed McDonagh
Thanks Andreas and Yves
I did as suggested, and I recieved no error messages, and the database did regenerate properly. Perfect 
Thanks again.
Hi Andreas
I am getting the same error on regeneration, and I'm obviously using a different version to Bushranger (0.9.8(.1?) - now I have managed to download it!)
Any ideas what it might be?
It gives the warning about the server directory, then allows you to start the regeneration. Then the regeneration window disappears, and it is impossible to close the local settings window, or the main K-PACS window, although it is still responsive in that it allows you to press 'Cancel' or 'Save settings' - it just doesn't do anything!
Thanks. Ed
Hi
I might be going mad here, but the version of K-PACS I have downloaded appears to be version 0.9.7!
It is exactly the same size as 0.9.7, and when I install and upgrade, the software tells me it is 0.9.7.
Thanks,
Ed
Doh! Yes of course. I just haven't needed to go there for some time!
Thanks again.
Ed