[SOLVED] Problem sending lossy CR images via dcmsnd to DCM4CHEE v2

[Jamie Henning]

Version:  DCM4CHEE V2.17.2mssql
OS:  Windows 2008 R2

Hey all -

  Need some help as I ran into a problem back filling our archive.  We have a ton of CR images that are lossy compressed and while using the DCMSND tool from the v2.0.27 toolkit, it errors out.  I have also attached the dicom dump of the dicom image that errors.

Here is the output from dcmsnd:

F07:04:57,812 INFO   - RADARCH2(1) << 283:C-STORE-RQ[pcid=5, prior=0
        cuid=1.2.840.10008.5.1.4.1.1.1/Computed Radiography Image Storage
        iuid=1.2.840.113564.10.1.62263036234700166881451641142481035217758
        ts=1.2.840.10008.1.2.4.51/JPEG Extended (Process 2 & 4)]
07:04:57,828 INFO   - RADARCH2(1) >> 283:C-STORE-RSP[pcid=5, status=a900H
        error=SOP Instance UID in Dataset [1.2.528.1.1001.800.4.3185.2817.5728
        cuid=1.2.840.10008.5.1.4.1.1.1/Computed Radiography Image Storage
        iuid=1.2.840.113564.10.1.62263036234700166881451641142481035217758]
ERROR: Received RSP with Status A900H for .\148178049.0, cuid=1.2.840.10008.5.1.4.1.1.1, tsuid=1.2.840.10008.1.2.4.51
(0000,0002) UI #26 [1.2.840.10008.5.1.4.1.1.1] Affected SOP Class UID
(0000,0100) US #2 [32769] Command Field
(0000,0120) US #2 [283] Message ID Being Responded To
(0000,0800) US #2 [257] Command Data Set Type
(0000,0900) US #2 [43264] Status
(0000,0902) LO #64 [SOP Instance UID in Dataset [1.2.528.1.1001.800.4.3185.2817.5728] Error Comment
(0000,1000) UI #62 [1.2.840.113564.10.1.62263036234700166881451641142481035217758] Affected SOP Inst


So, its telling me that tags '0008,0018' & '0008,1155' differ from one another.

I am trying to enable debugging for 'org.dcm4chex.archive' but the log is only giving me INFO level logs.  (entry from chainsaw is attached as well) -- what other steps do I need to do to for it into 'debug'?

I can import this exam with Centricity Workstation and push the exam to DCM4CHEE with no issues.

Can anyone offer any advise or solution to help me get around my problem?

thanks - Jamie

[Docjay]

can anyone lend a hand?

thanks

[Arnold Maderthaner]

setting that to DEBUG should be enough. Did you restart dcm4chee so that it picks up the new logging config or try to invoke the reconfigure methode of Log4jService in jmx-console ?

[Docjay]

Arnold,

   Thanks for suggesting to use the JMX-console - that worked out much easier and displayed debug for the areas I wanted.  I am going to post my 'debug' log here and I am hoping that you could look over it for me?  The AE title that is sending the lossy CR images is 'RADARCH3' (old Radstore 2.1 archive) and the dcm4chee archive is named 'RADARCH2'

If there is anything else you can see or need in the log to help figure out why it won't accept my lossy CR images. 

Is there a way to tell DCM4CHEE to NOT compress CR images from a certain AE Title?  Maybe since I am doing 'lossless' compression, the lossy studies are erroring out because of that?

thanks

[Docjay]

I got this sorted out.  If anyone is interested, in my STORESCP service, I had to enter in the Calling AET of my sending device (the dcmsnd utility in this case) 'RADARCH3' into 'AcceptMismatchAffectedSOPInstanceUIDCallingAETiles'.  This was the perfect answer!

thanks

On Tuesday, March 26, 2013 3:12:25 PM UTC-5, Docjay wrote:

Arnold,

   Thanks for suggesting to use the JMX-console - that worked out much easier and displayed debug for the areas I wanted.  I am going to post my 'debug' log here and I am hoping that you could look over it for me?  The AE title that is sending the lossy CR images is 'RADARCH3' (old Radstore 2.1 archive) and the dcm4chee archive is named 'RADARCH2'

If there is anything else you can see or need in the log to help figure out why it won't accept my lossy CR images. 

Is there a way to tell DCM4CHEE to NOT compress CR images from a certain AE Title?  Maybe since I am doing 'lossless' compression, the lossy studies are erroring out because of that?

thanks

On Thursday, March 21, 2013 9:45:14 AM UTC-5, Arnold Maderthaner wrote: