Seems like a very smart way to transfer large amounts of DICOM data to me.
Marcel
Seems like a very smart way to transfer large amounts of DICOM data to me.
Marcel
Not yet,
objects larger than 500 MB partially crash the server. On the list for the next release, but mey be very hard to fix other than that the object is totally rejected. A 64 bit version would help here....
Marcel
Hi,
I think Syngo declines such a move. You can try to enter multiple patient IDs separated by just a comma (,) into the patient ID box. Best use a text editor to make the list.
Marcel
There may be an issue with a - dash in the patientID. Which version are you running? Does this occur for all patients?
Marcel
Hi,
This is intended behavior: it only sends a command to the server and sending the command succeeds. I will see if I can add your wished behavior.
Marcel
Try dgate --debuglevel:4 and see what query is executed. That might solve the mystery.
Marcel
For the manual: dgate -?
I ran the commands on a windows/linux machine where they worked. By the way, the server (dgate -v) needs to run (in the background) for dgate -- commands to work.
Marcel
Hi,
the calledAE issue is probably a bug where the spaces are not correctly handled. As for reading in the new dicom.ini, kill and restart server should do the job. However, once a DICOM image is recieved a filename is generated and stored in the database - that will be reused for the same object. Only deleting the image/series/study/patient will force generation of a new filename.
Marcel
Hi,
The date format in DICOM images must be YYYYMMDD. Any other format will not be correctly handled (as you have shown) and lead to a rejected database insert when the resulting string is too long (more than 8 chars).
The too long date string should have been truncated by our server and give a warning message. That this does not happen is a known bug.
Marcel
Hi, some command line tools exist but they are not so well documented nor user friendly.
Try:
dgate "--studyfinder:conquestsrv1|t|%s %s %s"
where t is a part of name or patient ID.
Or:
dgate "--query:dicomstudies|PatientID||%s"
Marcel
Does the crash occur when the object is dropped onto conquest? If so, a copy of the offending would be appreciated to see if I need to fix something.
Marcel
Hi,
They can be on the same machine but need to be set up on different ports: not both 104.
Marcel
Hi,
conquest accepts Hl& files (via drag and drop or a batch file) to fill its own worklist database. That can be queries through DICOM. I am not aware of a DICOM option to forward or recieve modality worklist entries (they can only be queried). So, it is not clear how your pacs loads its modality worklist table. I guess conquest cannot help there.
Marcel
Wow,
thats appreciated!
Marcel
Not yet, is on the list for the release.
Marcel
Hi,
Exportconverter "forward patient to XXXX" in 1.4.13beta would do the job. However, it would forward all studies to the viewing client when one is recieved. Your specific option is not there. Also note a bug in 1.4.13beta causing a high CPU load during the 10 minute timeout when using this option. So it is ok to test but please wait until release for production use.
Marcel
Try "forward study to XXXX" in 1.4.13beta. However, note that there is a bug causing high CPU load while it waits for the timeout of 10 mins. For real use you have to wait for a release version.
Marcel
Hi,
try:
between "7", "20"; defer; forward to TEP_ESOFT
The defer message should then repeat until 20 hours.
Marcel
Can you specify way how you would like to see finer control through dicom.ini? By the way, part of the bogging down is due to the bug in the 1o minutes delay.
Marcel
Can you query VITREA from conquest or store from CONQUEST into VITREA?
Marcel