Posts by ChrisDiehn

  • Converter: check for already-routed studies

    Apologies if this has been asked before, I browsed a few pages in the forum and ran a search and didn't find anything.


    I'd like to add some logic to prevent routing for studies that have already been routed to the destination system. I can think of a couple logical ways to do this, but I don't know of the mechanism to achieve it.


    1. Check if the file already exists in Conquest; I'm forwarding everything that comes through, so if the file exists it will have been forwarded previously.
    2. Query the destination system for the StuInsUID and then discard the file or stop the converter if it does exist there.


    Would this be doable with Lua? I don't see that any of the built-in functions will do what I want. Thanks!


    Edit: one thing that's troubling me with the fundamental idea is that if there's been a change in the DICOM, implementing this may cause me to lose updated studies from facility QC, etc. Is there a way to evaluate whether an incoming file is different from an existing file?


    Chris

  • Passing DICOM elements to external script (Linux)

    I've got dgate (1.4.16, build Mon Jun 24 09:35:20 2013, bits 64) running on CentOS 6.4, and part of my configuration is intended to pass the accession, StuInsUID, and SerInsUID to an external script for Key Images series. Here's the relevant ImportConverter:


    Code
    ImportConverter0 = ifequal "%V0008,103E", "KEY IMAGES"; system /opt/tools/KeyImages/insertSOPs.sh %VAccessionNumber %VStudyInstanceUID %VSeriesInstanceUID &; destroy


    The equals test seems to be satisfied, as destruction occurs, but I see nothing for the system call, nor any error.



    Is the "system" ImportConverter command supported?

  • Successful Local Move, No Remote Move

    Here, I issue a move to CDKP from AISDEPOT7, and it hangs the same way. So, it must be in the way movescu is handling the association.


    Code
    [CONQUESTSRV1] 

    [CONQUESTSRV1] UPACS THREAD 37: STARTED AT: Mon Aug 04 16:49:30 2014

    [CONQUESTSRV1]  Calling Application Title : "AISDEPOT7       "

    [CONQUESTSRV1]  Called Application Title : "CONQUESTSRV1    "

    [CONQUESTSRV1]  Application Context : "1.2.840.10008.3.1.1.1", PDU length: 16384

    [CONQUESTSRV1]  Presentation Context 0 "1.2.840.10008.5.1.4.1.2.2.1" 1

    [CONQUESTSRV1]  Presentation Context 1 "1.2.840.10008.5.1.4.1.2.2.2" 1

    [CONQUESTSRV1]  C-Move Destination: "CDKP"

  • Successful Local Move, No Remote Move

    I was able to successfully C-MOVE from a K-PACS workstation:

    Code
    [CONQUESTSRV1] UPACS THREAD 17: STARTED AT: Mon Aug 04 16:38:03 2014[CONQUESTSRV1]  Calling Application Title : "CDKP"[CONQUESTSRV1]  Called Application Title : "CONQUESTSRV1    "[CONQUESTSRV1]  Application Context : "1.2.840.10008.3.1.1.1", PDU length: 16384[CONQUESTSRV1]  Presentation Context 0 "1.2.840.10008.5.1.4.1.2.2.2" 1[CONQUESTSRV1]  C-Move Destination: "CDKP"[CONQUESTSRV1] Number of Images to send: 4[CONQUESTSRV1] Sending file : E:\dicomserver1417\Data\12\1.2.840.113663.1100.156556189.2.0.120091013.1162611_0001_000003_1384185304ae3b.dcm[CONQUESTSRV1] [recompress]: recompressed with mode = un (strip=1)[CONQUESTSRV1] Sending file : E:\dicomserver1417\Data\12\1.2.840.113663.1100.156556189.2.0.120091013.1162611_0001_000000_1384185303ae2f.dcm[CONQUESTSRV1] [recompress]: recompressed with mode = un (strip=1)[CONQUESTSRV1] Sending file : E:\dicomserver1417\Data\12\1.2.840.113663.1100.156556189.2.0.120091013.1162611_0001_000002_1384185304ae40.dcm[CONQUESTSRV1] [recompress]: recompressed with mode = un (strip=1)[CONQUESTSRV1] Sending file : E:\dicomserver1417\Data\12\1.2.840.113663.1100.156556189.2.0.120091013.1162611_0001_000001_1384185303ae27.dcm[CONQUESTSRV1] [recompress]: recompressed with mode = un (strip=1)[CONQUESTSRV1] C-Move (StudyRoot)[CONQUESTSRV1] UPACS THREAD 17: ENDED AT: Mon Aug 04 16:38:03 2014[CONQUESTSRV1] UPACS THREAD 17: TOTAL RUNNING TIME: 0 SECONDS


    But PACS still fails.


    Code
    [CONQUESTSRV1] 

    [CONQUESTSRV1] UPACS THREAD 18: STARTED AT: Mon Aug 04 16:38:32 2014

    [CONQUESTSRV1]  Calling Application Title : "AISDEPOT7       "

    [CONQUESTSRV1]  Called Application Title : "CONQUESTSRV1    "

    [CONQUESTSRV1]  Application Context : "1.2.840.10008.3.1.1.1", PDU length: 16384

    [CONQUESTSRV1]  Presentation Context 0 "1.2.840.10008.5.1.4.1.2.2.1" 1

    [CONQUESTSRV1]  Presentation Context 1 "1.2.840.10008.5.1.4.1.2.2.2" 1

    [CONQUESTSRV1]  C-Move Destination: "AISDEPOT7 "


    So now it's a game of "Find the difference".

  • Successful Local Move, No Remote Move

    I've been given an export of data from another practice on a Windows server running Conquest with PostgreSQL. I've used Conquest before on Linux, so I added my PACS server (AISDEPOT7) to ACRNEMA.MAP, and I'm able to query for a study:


    Code
    [admin@aisdepot7] {~} findscu -S --aetitle AISDEPOT7 --call CONQUESTSRV1 -k 0008,0052=STUDY -k 0020,000D=1.2.840.113663.1100.156556189.1.0.120091013.1162611 -k 0010,0010 -k 0010,0020 -k 0008,0050 -k 0008,0060  -k 0008,0020 10.46.148.17 5678RESPONSE: 1 (Pending)# Dicom-Data-Set# Used TransferSyntax: LittleEndianExplicit(0008,0020) DA [20091013]                               #   8, 1 StudyDate(0008,0050) SH (no value available)                     #   0, 0 AccessionNumber(0008,0052) CS [STUDY ]                                 #   6, 1 QueryRetrieveLevel(0010,0010) PN [TESTING ]                               #   8, 1 PatientsName(0010,0020) LO [12]                                     #   2, 1 PatientID(0020,000d) UI [1.2.840.113663.1100.156556189.1.0.120091013.1162611] #  52, 1 StudyInstanceUID


    And I'm able to move that study from the GUI to AISDEPOT7 using "Copy to destination":

    Code
    StudyDate    QueryRetrieveLevel    PatientName    PatientID    ---------------------------------------------------------------------------------------------------------------------------------------------------------------[20100125]    [STUDY ]    [^TEST ]    [1234]    ---------------------------------------------------------------------------------------------------------------------------------------------------------------Total of 1 item(s) found------------ started copying ------------Copying for patient: 1234Slice 1 of 5Slice 2 of 5Slice 3 of 5Slice 4 of 5Slice 5 of 5------------ finished copying ------------


    But a C-Move doesn't work:


    Code
    [admin@aisdepot7] {~} movescu -S -v -d --aetitle AISDEPOT7 --call CONQUESTSRV1 --move AISDEPOT7 -k 0008,0052=STUDY -k 0020,000D=1.2.840.113663.1100.156556189.1.0.120091013.1162611 -k 0010,0010 -k 0010,0020 -k 0008,0050 -k 0008,0060  -k 0008,0020 10.46.148.17 5678Request Parameters:Our Implementation Class UID:    1.2.276.0.7230010.3.0.3.5.4Our Implementation Version Name: OFFIS_DCMTK_354Their Implementation Class UID:Their Implementation Version Name:Application Context Name:    1.2.840.10008.3.1.1.1Calling Application Name:    AISDEPOT7Called Application Name:     CONQUESTSRV1Responding Application Name: resp AP TitleOur Max PDU Receive Size: 16384Their Max PDU Receive Size: 0Presentation Contexts:  Context ID:        1 (Proposed)    Abstract Syntax: =FINDStudyRootQueryRetrieveInformationModel    Proposed SCP/SCU Role: Default    Accepted SCP/SCU Role: Default    Proposed Transfer Syntax(es):      =LittleEndianExplicit      =BigEndianExplicit      =LittleEndianImplicit  Context ID:        3 (Proposed)    Abstract Syntax: =MOVEStudyRootQueryRetrieveInformationModel    Proposed SCP/SCU Role: Default    Accepted SCP/SCU Role: Default    Proposed Transfer Syntax(es):      =LittleEndianExplicit      =BigEndianExplicit      =LittleEndianImplicitRequested Extended Negotiation: noneAccepted Extended Negotiation: noneRequesting AssociationConstructing Associate RQ PDUPDU Type: Associate Accept, PDU Length: 221 + 6 bytes PDU header  02  00  00  00  00  dd  00  01  00  00  43  4f  4e  51  55  45  53  54  53  52  56  31  20  20  20  20  41  49  53  44  45  50  4f  54  37  20  20  20  20  20  20  20  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  10  00  00  15  31  2e  32  2e  38  34  30  2e  31  30  30  30  38  2e  33  2e  31  2e  31  2e  31  21  00  00  1b  01  00  00  00  40  00  00  13  31  2e  32  2e  38  34  30  2e  31  30  30  30  38  2e  31  2e  32  2e  31  21  00  00  1b  03  00  00  00  40  00  00  13  31  2e  32  2e  38  34  30  2e  31  30  30  30  38  2e  31  2e  32  2e  31  50  00  00  3e  51  00  00  04  00  00  40  00  52  00  00  22  31  2e  32  2e  38  32  36  2e  30  2e  31  2e  33  36  38  30  30  34  33  2e  32  2e  31  33  35  2e  31  30  36  36  2e  31  30  31  55  00  00  0c  31  2e  34  2e  31  36  2f  57  49  4e  33  32Association Parameters Negotiated:Our Implementation Class UID:    1.2.276.0.7230010.3.0.3.5.4Our Implementation Version Name: OFFIS_DCMTK_354Their Implementation Class UID:    1.2.826.0.1.3680043.2.135.1066.101Their Implementation Version Name: 1.4.16/WIN32Application Context Name:    1.2.840.10008.3.1.1.1Calling Application Name:    AISDEPOT7Called Application Name:     CONQUESTSRV1Responding Application Name: CONQUESTSRV1Our Max PDU Receive Size: 16384Their Max PDU Receive Size: 16384Presentation Contexts:  Context ID:        1 (Accepted)    Abstract Syntax: =FINDStudyRootQueryRetrieveInformationModel    Proposed SCP/SCU Role: Default    Accepted SCP/SCU Role: Default    Accepted Transfer Syntax: =LittleEndianExplicit  Context ID:        3 (Accepted)    Abstract Syntax: =MOVEStudyRootQueryRetrieveInformationModel    Proposed SCP/SCU Role: Default    Accepted SCP/SCU Role: Default    Accepted Transfer Syntax: =LittleEndianExplicitRequested Extended Negotiation: noneAccepted Extended Negotiation: noneAssociation Accepted (Max Send PDV: 16372)================================Sending queryMove SCU RQ: MsgID 1Request:# Dicom-Data-Set# Used TransferSyntax: UnknownTransferSyntax(0008,0020) DA (no value available)                     #   0, 0 StudyDate(0008,0050) SH (no value available)                     #   0, 0 AccessionNumber(0008,0052) CS [STUDY]                                  #   6, 1 QueryRetrieveLevel(0008,0060) CS (no value available)                     #   0, 0 Modality(0010,0010) PN (no value available)                     #   0, 0 PatientsName(0010,0020) LO (no value available)                     #   0, 0 PatientID(0020,000d) UI [1.2.840.113663.1100.156556189.1.0.120091013.1162611] #  52, 1 StudyInstanceUIDDIMSE Command To Send:# Dicom-Data-Set# Used TransferSyntax: UnknownTransferSyntax(0000,0000) UL 0                                        #   4, 1 CommandGroupLength(0000,0002) UI =MOVEStudyRootQueryRetrieveInformationModel #  28, 1 AffectedSOPClassUID(0000,0100) US 33                                       #   2, 1 CommandField(0000,0110) US 1                                        #   2, 1 MessageID(0000,0600) AE [AISDEPOT7]                              #  10, 1 MoveDestination(0000,0700) US 0                                        #   2, 1 Priority(0000,0800) US 1                                        #   2, 1 DataSetTypeDIMSE sendDcmDataset: sending 106 bytesDIMSE sendDcmDataset: sending 114 bytes


    Sits there for ages on the PACS, and on Conquest I see:


    And it's sitting there. If I kill the Conquest server, the movescu dies on PACS, so the connection is open. What am I missing? Is this just terrible database performance and the query is hanging? If that were the case, I wouldn't expect to have success sending from the GUI.


    Thanks!

  • Splitting Series into New Study Based on BodyPartExamined

    I have a CR scanner which cannot split different exams into different StuInsUIDs, and cannot apply a StudyDescription. The scanner DOES use BodyPartExamined correctly, so if I look at a set of 4 studies (under one StuInsUID) I can see which images (one image per series) belong to which study without having to open them individually:


    Code
    [admin] {1.2.392.200036.9107.500.111168513121102020} find ./ -path *.dcm -exec dcmdump {} \; | egrep "StudyDescription|BodyPartExamined" | sort | uniq

    (0008,1030) LO (no value available)                     #   0, 0 StudyDescription

    (0018,0015) CS [CSPINE]                                 #   6, 1 BodyPartExamined

    (0018,0015) CS [LSPINE]                                 #   6, 1 BodyPartExamined

    (0018,0015) CS [SHOULDER]                               #   8, 1 BodyPartExamined

    (0018,0015) CS [TSPINE]                                 #   6, 1 BodyPartExamined


    Can I use a builtin command or lua to split the series/images for each BodyPartExamined into a new study, and then map the BodyPartExamined to StudyDescription? What would that look like?

  • Changing VR Type or Contents with ImportConverter

    Using your lua:


    Code
    Tue Feb 19 16:01:09 2013 *** lua run error [string "print('before' .. Data['0040,9210']); Data[..."]:1: attempt to concatenate field '0040,9210' (a nil value) in 'print('before' .. Data['0040,9210']); Data['0040,9210'] = nil; print('after' .. Data['0040,9210']);'

  • Changing VR Type or Contents with ImportConverter

    I have tried dgate --debuglevel:4, but the only change in the log is:


    Mon Feb 18 17:08:15 2013 Server command sent using DGATE -- option


    Don't see any mention of delete failing because the item is missing...


    Code
    Mon Feb 18 17:08:59 2013 [recompress]: recompressed with mode = jk (strip=0)

    Mon Feb 18 17:08:59 2013 Importconverter1.0: queued forward ser - (single object   of 48-241038290) to AISMIGRATION

    Mon Feb 18 17:08:59 2013 Rewritten file: /usr/local/conquest/data/2.16.840.1.114151.4.580.39312.5003.2367946/1.3.46.670589.11.17235.5.0.2248.2007082212580292391/1.2.840.113837.2947041227.20120224165613.1.dcm


    I'll try the lua.

  • Changing VR Type or Contents with ImportConverter

    I've split the forward and delete into two separate converters with very little logic:


    Code
    ImportConverters = 1ImportConverter0 = delete 0040,9210ExportConverters = 1ExportConverter0 = forward series compressed as jk to AISMIGRATION


    And still all I see is this, no mention of the ImportConverter at all in the log:


    Code
    Mon Feb 18 15:36:20 2013 Exportconverter0.0: queued forward ser - (single object   of 48-241038290) to AISMIGRATION


    I also don't notice any difference in the logging after issuing the debuglevel:2 command.

  • Changing VR Type or Contents with ImportConverter

    I'm using Conquest to assist me with a data migration project, but I'm having some trouble with data manipulation. I've got some studies that have an incorrect VR type for 0040,9210 (LUTLabel); the VR in the header is SS, but should be SH. I'd like to either change or remove the VR so I can bring the study into my main PACS system.


    I couldn't find any commands to change VR type, but I did see in the manual that "delete xxxx,yyyy" is a valid command, so I've configured thusly:


    Code
    ImportConverters = 1ImportConverter0 = ifequal "%u", "DCMSND"; delete 0040,9210; forward series compressed as jk to MIGRATION_AE


    However, the change doesn't appear to be made, as nothing is logged stating so; the only ImportConverter event is:


    Code
    Fri Feb 15 16:20:49 2013 Importconverter0.2: queued forward ser - (single object   of 48-241038290) to MIGRATION_AE


    And MIGRATION_AE is still rejecting the images:


    Code
    DCM Incorrect VR (SS) for attribute with tag (0040, 9210)- Expected VR (SH)


    Am I missing something in the configuration for the ImportConverter, or do I misunderstand how the delete command should work?


    Thank you.

  • Rejected for Incorrect VR sending to PACS

    Thanks much, Marcel. I placed the dgate.dic update on the server, and in testing today we haven't received a single error. dcmpschk still complains of incorrect attribute in (0002,0001), but no more 0040,xxxx errors. I think this may have resolved our problem. I will follow up if not so.


    Thanks again!

  • Rejected for Incorrect VR sending to PACS

    I'm setting up Conquest 1.4.16 on Ubuntu 11.10 as a DICOM router to allow us to set up devices at client networks to send images to our main PACS. This will allow us to extend our service to practices that don't have enterprise VPN hardware. I've got the routing configuration set to my satisfaction, but I'm seeing some errors during forwarding. This doesn't occur on all studies, and I haven't yet identified a commonality between studies that it does occur on.


    From the logs on the PACS:


    Code
    ERROR: (loadDicomObject) Unable to open [/usr/local/PACS/images/tmp/MRG-KAL-SPOKE_OT.24975.1.dcm].  CTN error:DCM failed to open file: /usr/local/PACS/images/tmp/MRG-KAL-SPOKE_OT.24975.1.dcm in DCM_OpenFileDCM group/element out of order (0000 0000) in checkAttributeOrder


    and


    Code
    DCM Unrecognized VR code (^T) in (readVRLength) for element (0040, 0007)



    If I run a check tool on the temp file saved by our PACS, I see the following.



    I'm wondering whether I'm seeing one issue or two. Is the bizarre VR (^T) for (0040,0007) a transport issue? Or does everything stem from the issues with (0002,0001) and the other 0040 elements in the check tool?