Posts by jwj

  • How to solve Inconsistent StudyModal and PatientNam

    Hi,


    We are getting more and more errors on inconsistent StudyModal and PatientNam. Looking in PacsTrouble.log reveals that there is indeed an inequality between the registered data in the Conquest database and the incomming data. But the violation is not severe, and there should be an option to storage the image instead of refusing.


    1) The inconsistent StudyModal can be ignored - it is a "calculated" field, and it can change as series with new modalities are added


    Inconsistent StudyModal in DICOMStudies: PatientID = '..' StudyInsta = ..', Old='RTPLAN\RTDOSE\RTSTRUCT', New='CT\RTPLAN\RTDOSE\RTSTRUCT'


    2) Inconsistent PatientNam in DICOMStudies: PatientID = '...' StudyInsta = '...', Old='A', New='B'


    This can be tricky, but in the end any person can change name (marriage/divorce, etc.), and often the inconsistentcy is caused by appended whitespaces or ^^ in DICOM. DICOM also have a OtherPatientNames (0010, 1001) - what if PatientName and OtherPatientNames were swapped? My point is that the PatientName is not unique (this is my point of view).


    So, my question is: Any good advice on how to handle inconsistentcy in Conquest?

  • Query Aria/Varian

    Removing the two lines the code is


    Code
    a=DicomObject:new()a.QueryRetrieveLevel='STUDY'a.StudyInstanceUID=''a.PatientID='0009*'b=dicomquery('Variansystem', 'STUDY', a)...


    and result is



    So, this does not seems to make any different. We also tested with finscu to ensure that it is still possible to query Aria from another application on the client.

  • Query Aria/Varian

    Hi Marcel,


    Thanks for the advice with ZeroBrane. The following Lua script returns "*** Virtual query - failed to connect for C-FIND to Variansystem"



    We have tested the three different transfer syntaxes listed in the Lua script with no luck.

  • Query Aria/Varian

    We have used findscu.exe and Conquest to query a Conquest DICOM server.


    Findscu with QueryRetrieveLevel="STUDY" and -S (Study Root Query/Retrieve Information Model) looks like this in the receiving Conquest debug log at level 4 (this is the query that works on Aria):


    Code
    [BATCH] Connected by address: 0100007f[BATCH] Testing transfer: '1.2.840.10008.1.2.1' against list #0 = '1.2.840.10008.1.2'[BATCH] Testing transfer: '1.2.840.10008.1.2.2' against list #0 = '1.2.840.10008.1.2'[BATCH] Testing transfer: '1.2.840.10008.1.2' against list #0 = '1.2.840.10008.1.2'[BATCH] [BATCH] UPACS THREAD 24: STARTED AT: Tue Jun 24 09:38:45 2014[BATCH] A-ASSOCIATE-RQ Packet Dump[BATCH]  Calling Application Title : "CAB             "[BATCH]  Called Application Title : "BATCH           "[BATCH]  Application Context : "1.2.840.10008.3.1.1.1", PDU length: 16384[BATCH]  Number of Proposed Presentation Contexts: 1[BATCH]  Presentation Context 0 "1.2.840.10008.5.1.4.1.2.2.1" 1[BATCH] Server Command   := 0020[BATCH] Message ID       := 0001[BATCH] 0000,0002     28 UI AffectedSOPClassUID    "1.2.840.10008.5.1.4.1.2.2.1"     (Study Root Query/Retrieve Information Model - FIND)[BATCH] 0000,0100      2 US CommandField           32 [BATCH] 0000,0110      2 US MessageID              1 [BATCH] 0000,0700      2 US Priority               2 [BATCH] 0000,0800      2 US DataSetType            1 [BATCH] 0002,0010     17 UI TransferSyntaxUID      "1.2.840.10008.1.2" [BATCH] (StudyRootQuery) search level: STUDY [BATCH] 0002,0010     17 UI TransferSyntaxUID      "1.2.840.10008.1.2" [BATCH] 0008,0052      6 CS QueryRetrieveLevel     "STUDY " [BATCH] 0010,0020      8 LO PatientID              "01023* " [BATCH] Query On Study[BATCH] Issue Query on Columns: DICOMStudies.PatientID[BATCH] Values: DICOMStudies.PatientID LIKE '01023%'[BATCH] Tables: DICOMStudies[BATCH] Sorting ((null)) DoSort := 0[BATCH] Query Distinct Tables: DICOMStudies[BATCH] Columns              : DICOMStudies.PatientID[BATCH] Where                : DICOMStudies.PatientID LIKE '01023%'[BATCH] Order                : (null)[BATCH] Records = 0[BATCH] C-Find (StudyRoot) located 0 records[BATCH] UPACS THREAD 24: ENDED AT: Tue Jun 24 09:38:45 2014[BATCH] UPACS THREAD 24: TOTAL RUNNING TIME: 0 SECONDS


    Findscu with -P (Patient Root Query/Retrieve Information Model)


    Code
    [BATCH] Connected by address: 0100007f[BATCH] Testing transfer: '1.2.840.10008.1.2.1' against list #0 = '1.2.840.10008.1.2'[BATCH] Testing transfer: '1.2.840.10008.1.2.2' against list #0 = '1.2.840.10008.1.2'[BATCH] Testing transfer: '1.2.840.10008.1.2' against list #0 = '1.2.840.10008.1.2'[BATCH] [BATCH] UPACS THREAD 25: STARTED AT: Tue Jun 24 09:39:38 2014[BATCH] A-ASSOCIATE-RQ Packet Dump[BATCH]  Calling Application Title : "CAB             "[BATCH]  Called Application Title : "BATCH           "[BATCH]  Application Context : "1.2.840.10008.3.1.1.1", PDU length: 16384[BATCH]  Number of Proposed Presentation Contexts: 1[BATCH]  Presentation Context 0 "1.2.840.10008.5.1.4.1.2.1.1" 1[BATCH] Server Command   := 0020[BATCH] Message ID       := 0001[BATCH] 0000,0002     28 UI AffectedSOPClassUID    "1.2.840.10008.5.1.4.1.2.1.1"           (Patient Root Query/Retrieve Information Model - FIND)[BATCH] 0000,0100      2 US CommandField           32 [BATCH] 0000,0110      2 US MessageID              1 [BATCH] 0000,0700      2 US Priority               2 [BATCH] 0000,0800      2 US DataSetType            1 [BATCH] 0002,0010     17 UI TransferSyntaxUID      "1.2.840.10008.1.2" [BATCH] (PatientRootQuery) search level: STUDY [BATCH] 0002,0010     17 UI TransferSyntaxUID      "1.2.840.10008.1.2" [BATCH] 0008,0052      6 CS QueryRetrieveLevel     "STUDY " [BATCH] 0010,0020      8 LO PatientID              "01023* " [BATCH] Query On Study[BATCH] Issue Query on Columns: DICOMStudies.PatientID[BATCH] Values: DICOMStudies.PatientID LIKE '01023%'[BATCH] Tables: DICOMStudies[BATCH] Sorting ((null)) DoSort := 0[BATCH] Query Distinct Tables: DICOMStudies[BATCH] Columns              : DICOMStudies.PatientID[BATCH] Where                : DICOMStudies.PatientID LIKE '01023%'[BATCH] Order                : (null)[BATCH] Records = 0[BATCH] C-Find (PatientRoot) located 0 records[BATCH] UPACS THREAD 25: ENDED AT: Tue Jun 24 09:39:38 2014[BATCH] UPACS THREAD 25: TOTAL RUNNING TIME: 0 SECONDS


    Next, we tested all the possible values of "Query level" in the Conquest GUI.


    Code
    //Query level = PATIENT[BATCH] 0000,0002     28 UI AffectedSOPClassUID    "1.2.840.10008.5.1.4.1.2.1.1" [BATCH] 0008,0052      8 CS QueryRetrieveLevel     "PATIENT " // Query level = STUDY[BATCH] 0000,0002     28 UI AffectedSOPClassUID    "1.2.840.10008.5.1.4.1.2.1.1" [BATCH] 0008,0052      6 CS QueryRetrieveLevel     "STUDY " // Query level = SERIES[BATCH] 0000,0002     28 UI AffectedSOPClassUID    "1.2.840.10008.5.1.4.1.2.1.1" [BATCH] 0008,0052      6 CS QueryRetrieveLevel     "SERIES" // Query level = IMAGE[BATCH] 0000,0002     28 UI AffectedSOPClassUID    "1.2.840.10008.5.1.4.1.2.1.1" [BATCH] 0008,0052      6 CS QueryRetrieveLevel     "IMAGE " // Query level = STUDY - StudyRoot[BATCH] 0000,0002     28 UI AffectedSOPClassUID    "1.2.840.10008.5.1.4.1.2.2.1" [BATCH] 0008,0052      6 CS QueryRetrieveLevel     "STUDY " // Query level = SERIE - StudyRoot[BATCH] 0000,0002     28 UI AffectedSOPClassUID    "1.2.840.10008.5.1.4.1.2.2.1" [BATCH] 0008,0052      6 CS QueryRetrieveLevel     "SERIES" // Query level = IMAGE - StudyRoot[BATCH] 0000,0002     28 UI AffectedSOPClassUID    "1.2.840.10008.5.1.4.1.2.2.1" [BATCH] 0008,0052      6 CS QueryRetrieveLevel     "IMAGE " // Query level = PATIENT - PatientStudyOnly[BATCH] 0000,0002     28 UI AffectedSOPClassUID    "1.2.840.10008.5.1.4.1.2.3.1"     (Patient/Study Only Query/Retrieve Information Model - FIND)[BATCH] 0008,0052      8 CS QueryRetrieveLevel     "PATIENT " // Query level = STUDY - PatientStudyOnly[BATCH] 0000,0002     28 UI AffectedSOPClassUID    "1.2.840.10008.5.1.4.1.2.3.1" [BATCH] 0008,0052      6 CS QueryRetrieveLevel     "STUDY " // Query level = Modality Worklist[BATCH] 0000,0002     24 UI AffectedSOPClassUID    "1.2.840.10008.5.1.4.31"     (Modality Worklist Information Model - FIND)[BATCH] 0008,0052      0 CS QueryRetrieveLevel     (empty)


    Thus, to archive the same result as with findscu the correct "Query level" in Conquest is the "STUDY - StudyRoot". Finally, comparing the log for a query from findscu and Conquest only show minor differences.


    Findscu with QueryRetrieveLevel="STUDY" and -S:


    Code
    [BATCH] Connected by address: 0100007f[BATCH] Testing transfer: '1.2.840.10008.1.2.1' against list #0 = '1.2.840.10008.1.2'[BATCH] Testing transfer: '1.2.840.10008.1.2.2' against list #0 = '1.2.840.10008.1.2'[BATCH] Testing transfer: '1.2.840.10008.1.2' against list #0 = '1.2.840.10008.1.2'[BATCH] [BATCH] UPACS THREAD 24: STARTED AT: Tue Jun 24 09:38:45 2014[BATCH] A-ASSOCIATE-RQ Packet Dump[BATCH]  Calling Application Title : "CAB             "[BATCH]  Called Application Title : "BATCH           "[BATCH]  Application Context : "1.2.840.10008.3.1.1.1", PDU length: 16384[BATCH]  Number of Proposed Presentation Contexts: 1[BATCH]  Presentation Context 0 "1.2.840.10008.5.1.4.1.2.2.1" 1[BATCH] Server Command   := 0020[BATCH] Message ID       := 0001[BATCH] 0000,0002     28 UI AffectedSOPClassUID    "1.2.840.10008.5.1.4.1.2.2.1"     (Study Root Query/Retrieve Information Model - FIND)[BATCH] 0000,0100      2 US CommandField           32 [BATCH] 0000,0110      2 US MessageID              1 [BATCH] 0000,0700      2 US Priority               2 [BATCH] 0000,0800      2 US DataSetType            1 [BATCH] 0002,0010     17 UI TransferSyntaxUID      "1.2.840.10008.1.2" [BATCH] (StudyRootQuery) search level: STUDY [BATCH] 0002,0010     17 UI TransferSyntaxUID      "1.2.840.10008.1.2" [BATCH] 0008,0052      6 CS QueryRetrieveLevel     "STUDY " [BATCH] 0010,0020      8 LO PatientID              "01023* " [BATCH] Query On Study[BATCH] Issue Query on Columns: DICOMStudies.PatientID[BATCH] Values: DICOMStudies.PatientID LIKE '01023%'[BATCH] Tables: DICOMStudies[BATCH] Sorting ((null)) DoSort := 0[BATCH] Query Distinct Tables: DICOMStudies[BATCH] Columns              : DICOMStudies.PatientID[BATCH] Where                : DICOMStudies.PatientID LIKE '01023%'[BATCH] Order                : (null)[BATCH] Records = 0[BATCH] C-Find (StudyRoot) located 0 records[BATCH] UPACS THREAD 24: ENDED AT: Tue Jun 24 09:38:45 2014[BATCH] UPACS THREAD 24: TOTAL RUNNING TIME: 0 SECONDS


    Conquest with Query level = STUDY StudyRoot:



    Is it an issue with the transfer syntax or presentation context - and why does it test four of the same (1.2.840.10008.1.2) in the beginning of the log?

  • Query Aria/Varian

    We are in the process of making CDonQuest query an Arian (Varian product), but currently unsuccessful. In order to debug the system we have used Dicom tool kit using the command findscu


    findscu.exe -v -aet BATCH -aec Variansystem -S -k QueryRetrieveLevel="STUDY" -k PatientName="H*" x.x.x.x y


    This is successful but only then using the command argument –S (query information model: Study) and not the command argument –P (query information model: Patient)


    Query retrieve level can be defined in the ConQuest GUI at the query page, but this is not the same as query information model.


    In the manual it is stated in appendix 7.1 that the Query & Retrieve Information Model is configurable on the “configuration” page of conquest. We have not been able to find this option on the configuration page but can it be defined directly in the dicom.ini file, and if so what is the syntax of that?


    This question might link to a previous posted topic:
    http://forum.image-systems.biz…hp?f=33&t=3218&hilit=aria

  • Why not to change patientID of a dicom image

    If deleting the patient to allow the incomming data to get stored (without Conquest refusing because of PatientId/Uid conflict), you could clean up the database by running the following sql AND manually delete the patient folder(s) containing the DICOM files.


    IMPORTANT: Only do this if the existing files are unwanted and blocking for the correct files to get stored.


    Code
    declare @PatientId varchar(64) = 'MamEdxt'delete from DICOMSeries where StudyInsta in (select StudyInsta from DICOMStudies where PatientID = @PatientId)delete from DICOMSeries where SeriesInst in (select SeriesInst from DICOMImages where ImagePat = @PatientId)delete from DICOMPatients where PatientID = @PatientIddelete from DICOMStudies where PatientID = @PatientIddelete from DICOMImages where ImagePat = @PatientId


    We use the sql listed above, because Conquest/dgate cannot delete a patient if the database is in a invalid state (for some reason). For example: the patient is not delete if the patient does not contain any study! In the example below the patient exists with several images but no study


    Code
    declare @PatientId varchar(64) = 'MamEdxt'

    select * from DICOMPatients where PatientID = @PatientId    -- 1 row

    select * from DICOMStudies where PatientID = @PatientId     -- 0 row

    select * from DICOMSeries where StudyInsta in (select StudyInsta from DICOMStudies where PatientID = @PatientId) -- 0 row

    select * from DICOMSeries where SeriesInst in (select SeriesInst from DICOMImages where ImagePat = @PatientId)   -- 1 row

    select * from DICOMImages where ImagePat = @PatientId     -- many rows

  • A real virtual server?

    Hi,


    Is it possible to retrieve data from a virtual server in conquest this way:


    1) Client "A" sends a query to Conquest
    2) Conquest acts as a virtual server for server "C" and forwards the query to "C", merges the result and replies to the client "A"


    This is all standard procedure in Conquest - but what about move:


    3) Client "A" wants to retrieve the data returned by the query
    4a) Conquest forwards the request to move data from "C" to "A"
    4b) OR does Conquest retrieve data from "C" and then moves data from Conquest to "A"?


    Both 4a and 4b make sense. Procedure 4a moves data directly from source to destination but in my case requires that the client "A" is registered in system "C". Contrary to 4b where data is temporary stored in Conquest and then pushed back to client "A", so the client "A" and "C" will never be connected.


    The problem is that we have a single connection to a external PACS and would like to use Conquest as a virtual server, so other clients in the department can retrieve data from the PACS without registering the clients AET in the external PACS? Hope it all make sense!

  • Execute LUA batch script in dgate

    Thanks. I have tested the script as you suggested using three Conquest 1.4.16k servers (source, destination and a third for running the script) on my local computer. It did NOT report any error - great! I assume the error occures in dicommove when communicating with some non-Conquester servers - but I cannot determine if the error is in the Conquest/dgate code or not. I checked the logs on the Mosaiq Data Director (MDD) but there haven't been any dicom error for a long time.


    Can I perform other tests to locate the error?

  • Execute LUA batch script in dgate

    Ok, thanks for clarifying - I will execute the script manually and only once.


    I wrote the script below but get a dicommove error AFTER the files have been written to the disk! It seems to work just fine but I am a little bit concerned about the reported error. What the script basically does is reading a text file with patient IDs, and for each patient it will fetch the requested modalites on the source server at SERIES level. Each series will then be copied (dicommove) to the destination server.


    The reason that I iterate the series is because the destination server (Mosaiq Oncology PACS - now Data Director) only supports the STUDY QueryRetrieveLevel on dicommove and requires the StudyInstanceUID, and I don't want to send the hole study as it might contain other modalities.


    Code
    -- execute this script by calling: dgate "--lua:dofile('script.lua')"inputFile = 'patient_ids.txt'srcAet = 'MOP_SCP'destAet = 'JONASPC'modalities = {'RTPLAN', 'RTIMAGE'}for line in io.lines(inputFile) do	-- send series of the requested modalities from the source to the destination	ptId = line	for key, modality in ipairs(modalities) do		print('Query: patient', ptId, 'on', modality, 'from', srcAet, 'to', destAet)		-- create query for dicom move		q = newdicomobject()		q.PatientID = ptId		q.Modality = modality		-- values to retrive should be included in the query as well		q.StudyInstanceUID  = '' -- StudyInstanceUID is required on the MOP for dicommove		q.SeriesInstanceUID = ''		q.PatientName = ''		q.SeriesDescription = ''		-- execute query for infomation on patient data on the source machine		a = dicomquery(srcAet, 'SERIES', q) -- sets QueryRetrieveLevel at call time		n = #a		print('  Query results:', n)		for i=0,n-1 do 			r = a[i]			print('  - Result ', i+1, 'of', n, '(', a[i].PatientID, '):', a[i].Modality, '-', a[i].SeriesDescription)			--print('  - Result ', i+1, 'of', n, '(', r.PatientID, '):', r.Modality, '-', r.StudyInstanceUID)			cmd = newdicomobject()			cmd.QueryRetrieveLevel = 'STUDY' -- only level supported by the MOP for dicom move			cmd.PatientID = ptId			cmd.Modality = modality			cmd.StudyInstanceUID = r.StudyInstanceUID			cmd.SeriesInstanceUID = r.SeriesInstanceUID			-- execute the move			dicommove(srcAet, destAet, cmd);		end	endendprint('..script done!')


    And this is the output from conquest (I removed the patient ID)



    All the files are copied and written successfully (5 files in 3 series with RTPLAN and RTIMAGE), but after each line containing TOTAL RUNNING TIME (the dicommove command) it report an error.


    I know it is a tricky question to answer regarding remote dicom errors, but I hope you might be able to help me - and maybe others can reuse the script for inspiration.


    Regards,


    Jonas

  • Execute LUA batch script in dgate

    Hi,


    Thanks for the LUA updates - it really makes a big difference.


    I am currently using the 1.4.16k version and LUA to auto forward data from our PACS to clients in the clinic (xvi, iview, brachy etc.).


    In cases where we need a large group of patient for a research study, I would like to use Conquest (dgate) to DICOM move the list of patient from the PACS to a research client machine for data processing. We could do this manually in Conquest but it becomes a tedious task to move hundreds or even thousands of patients.


    I was thinking of writing a LUA script for gdate and let the script read a text file containing all the patient IDs and requested modality, and then move the DICOM data from one destination to another.


    Is it possible to execute a LUA script in dgate only once? And is it save for large jobs (batches) - the Conquest Windows manual says "works directly - use with care" on page 44 in appendix 6?

  • LUA: Data.Modality is NIL after dicommove()

    Hi


    I've been testing the new LUA features in version 1.4.16j. In one of the tests I forward the current data using the global LUA variable "Data" and dicommove(), but the contents of Data (eg. Data.Modality) is NIL after the call to dicommove:


    Code
    print("1) Data is", Data, "and modality is", Data.Modality)dicommove(myAet, accAet , Data)print("2) Data is", Data, "and modality is", Data.Modality)


    The code will print


    Code
    1) Data is userdata:01227958 and modality is RTPLAN

    2) Data is userdata:01227958 and modality is nil


    Can you please clarify or advice me how to forward the current dataset - should i use newdicomobject() and :Read() to re-create the current dataset?