retrieve by study level

  • We use iq-view and query by study level. when used with most pacs systems, it will then retrieve only the study queried for. when using conquest dicom, it will send by patient level. we need it to send as we query, either by patient level or study level. what happens now is if there are more studies with that patient, it will send all the studies instead of just the study we queryed and asked for. how can this by done?


    thanks


    pat stacey

  • Marcel, it is not a "problem". It is how it is designed I thought.


    I have two places where I use Conquest Dicom. One is a hospital (Sister's) and the other a medical group (BMG). I have 7 radiologist that query and retrieve using iQ-View. When they query, it is usually with a modality filter (for their specialty) and by a date. They will get a result back showing what they want. When they then retrieve, EVERYTHING that is in that folder (wich is in the data folder and each folder is identified by patient ID number and corresponds with the patient ID on the query) comes over, not just the study the are marking to retrieve.


    What happens on the institution side is that they send all their images automaticallly to our Conquest Dicom. For example:


    Tom Jones had an MRI done on 1-5-09. That MRI is sent to our server under the patient ID. It is put in a folder that corresponds with that ID number in the data folder in Conquest.


    If Tom Jones also had a CT done on 12-21-08, it is already in that folder on the server, so the end results is that the MRI and CT are in the same folder on the server.


    Now Tom Jones also had 4 CR's done in the past year. Those are also in the same folder in the data directory.


    Dr. Bob queries out to our server (using iQ-View) using the patient ID. He gets back that there are 6 studies done on Tom Jones (no filter on the query). He then marks the ones that he wants to retrieve. Let us say he wants the MRI. He marks ONLY the MRI. In return, he gets ALL the studies since Conquest is responding at a patient level instead of a study level. Since the folder on the server with Tom Jones's patient ID has all studies in it, he gets all studies.


    If he marks the 4 CR's, he gets ALL the studies 4 times, again, because all the studies are in the one folder and Conquest is repsonding to the request at the patient level instead of the study level.


    Both Conquest repsond like this. There is no where I can find that lets you set the level to respond at the study level. It seems to default to the patient level since it is sorted and kept under one folder, patient ID or patient level.


    However, if I use iQ-View to query a Siemens, Fuji, Cedeara, etc and ask for just one study, that is all I get. They are set to repsond at study level.


    I need that with Conquest. At a hospital of this size, there could be studies associated and in that patient folder from many years back. We have many instances of a doctor trying to retrieve just an US, but taking hours to get because Conquest sends EVERYTHING in the patient folder in chronological order, from the earliest date forward. Imagine if they are trying to retrieve the most current US and the prior US only. They mark both of them for retrieveal and get everything TWICE. 10's of thousands of images can be sent out just trying to get 4 images from 2 CR's.


    All the other PACs software I deal with let you send at the study level, but since the structure of the Conquest database is to put all studies for uniquely identifed patients in one folder, when queried, it will send the whole folder contents.


    That is why I need the ability to retrieve at the study level. It is not an error that I know of, it is how the Conquest is set up.


    I see no errors. Just that Conquest did send the items. iQ-VIew also shows no errors, just that it got all the data.


    Thanks

  • Hi Pat,


    conquest can definitively retrieve at ANY level - not just the patient level. You can see that if you experiment with the query/move page. And, there is no relation between the patient folder organization and queries, queries are all done through the database that has tables at ALL levels.


    So, there must be a bug somewhere causing this behavior. Can you therefore get still get me the full debug log of the commands that IQ-View sends when you have this problem. It should be easy to see what goes wrong. And maybe you should also post at the IQ-View page.


    I use an old K-PACS and that definitively does NOT show this behavior.


    Marcel

  • attached is the logs from both iQ-View and Conquest. This is a perfect example. I queried by "today" and then selected the patient ID and then queried again by the ID. There were four studies (Bolden). I looked in the folder (data) in Conquest and saw all four studies. I then selected only 1 CT to be retrieved and ended up with all four studies.


    Thanks.


    (Marcel: I downloaded and deleted the attachment)

  • Hi,


    Can you do it again at the highest debug level (push the up arrow four times next to the debuglog checkbox after enabling debug log).


    This would show a dump of the request recieved by conquest. As I see it the query looks allright. What database are you using?


    Marcel


    This is the interesting bit: it asks for a single STUDY, and four series (621 slices total) are returned.


    1/12/2009 4:32:53 AM [TIASISTERS] UPACS THREAD 279: STARTED AT: Mon Jan 12 04:32:53 2009
    1/12/2009 4:32:53 AM [TIASISTERS] A-ASSOCIATE-RQ Packet Dump
    1/12/2009 4:32:53 AM [TIASISTERS] Calling Application Title : "SISTERSIQ"
    1/12/2009 4:32:53 AM [TIASISTERS] Called Application Title : "TIASISTERS "
    ..
    1/12/2009 4:32:53 AM [TIASISTERS] Query On Image
    1/12/2009 4:32:53 AM [TIASISTERS] Failed on VR Search: 0008 0080
    1/12/2009 4:32:53 AM [TIASISTERS] (testing phase) - ignored
    1/12/2009 4:32:53 AM [TIASISTERS] Issue Query on Columns: DICOMImages.SOPClassUI, DICOMImages.SOPInstanc,
    ..
    1/12/2009 4:32:53 AM [TIASISTERS] Values: DICOMStudies.StudyInsta = '1.2.840.113696.625608.500.878580.20090112010036' and DICOMSeries.StudyInsta = DICOMStudies.StudyInsta and DICOMImages.SeriesInst = DICOMSeries.SeriesInst
    1/12/2009 4:32:53 AM [TIASISTERS] Tables: DICOMImages, DICOMSeries, DICOMStudies
    1/12/2009 4:32:54 AM [TIASISTERS] Records = 621
    1/12/2009 4:32:54 AM [TIASISTERS] Number of Images to send: 621
    ..

  • Sure thing. Also, I just tried it with my K-Pacs, it did the same thing. But if I use the K-PACS or IQ-VIEW to query a Cedeara PACS, it only gives the study I asked for even though there are more studies related to the patient.


    So I don't think it is an IQ-VIEW or KPACS problem. It must be something with the Conquest. I am using the default database and also version 1.4.12C. I had too many problems with the lastest version, especially with the memory.


    That is what I mean, I only asked for one CT and got 2 CT and 2 CR. All of that is in the data folder in the folder with that patient ID.

  • Hi,


    please check that your dicom.sql is denormalized, i.e., that Studyinstance is part of the image table. This is (only) required for the default (dbf withotu odbc) database. If it is not, the database will not perform correctly, and it may behave as you see.


    If it is not, (MAY TAKE A LONG TIME): you need to delete dicom.sql, restart the server and regenerate. This will probably fix your problem.


    I guess the downgrade procedure is not fail safe: probably you have downgraded from a non-dbf database. the older servers will not rewrite dicom.sql.


    The new version should be stable as well. Let me know your problems if you have time.


    Marcel

  • ok, i did as you said. I still had the same problem. After deleting the .sql, I ended the program and stopped the service. I then restarted the program and ran a regen. Same thing. I then removed the dbase folded in the data folder, deleted the .sql again, and the ran regen. Same thing. I then deleted the entire program (except the data folder, but I did delete the dbase folder again) and reinstalled the newer version (1.4.14). I made the change needed to correct for the "out of memory" error you get when you regen. I packed the database and ran a regen. It works perfectly now.


    Must be something in the older version, but I don't know what. Thanks for your help. I could not have solved it without your pointing me in the right directlon.


    Pat

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!