Query/Retrieve from PACSONE to dcmtk storescp

[4tvarian]

I get this error upon trying a query/retrieve to dcmtk storescp:

find() failed: error = Invalid Dataset Type: group = 0 element = 120

In my logs on the storescp side I get this:

Association Received
Association Acknowledged (Max Send PDV: 16372)
Received C-Echo RQ: MsgID 1
AffectedSOPClassUID: =VerificationSOPClass
Data Set: Not Present
Association Release
Association Received
Association Acknowledged (Max Send PDV: 16372)
(but no valid presentation contexts)
storescp: DIMSE Failure (aborting association)

What do you make of this? Am I doing something wrong?


Regards,

4tvarian

[pacsone]

The log on the STORESCP side indicated a C-ECHO verification request, not the C-FIND sent from PacsOne, can you make sure PacsOne is querying the right AE?

What response do you get when you PING the STORESCP AE? Did you get a Success response or some kind of error?

[4tvarian]

I can ping fine from the pacsone machine.

The storescp error looks like this:

Association Received
Association Acknowledged (Max Send PDV: 16372)
(but no valid presentation contexts)
storescp: DIMSE Failure (aborting association)

I can send dicom files fine to the pacs server from these affected boxes and they can also receive files from other workstations (Currently its a mix of solaris machines(dcmtk) and windows workstations running efilm).

Regards,

4tvarian

[pacsone]

Another thought about this: Do you know for sure STORESCP supports C-FIND queries? Last time I used STORESCP it's a C-STORE SCP and don't know if it has a database of some kind to handle C-FIND queries.

The other thing you can try is to turn on more debugging for STORESCP, I think if you run STORESCP -v -d PORTNUMBER it will give you more debugging information.

A third thing you can try is to use a third-party C-FIND client to query STORESCP to see what kind of response you can get. One free query client can be downloaded below:

http://www.jeffro.net/mind/

[4tvarian]

Nice Client. I have queried and sent studies from the pacsone server to the machine running storescp with mind. Everything works great. Querying from mind to the machine running storescp nets me this result:


*************BEFORE ACCEPT*************
*************AFTER ACCEPT(sock: 4/errno: 20)*************


PDU Type: Associate Request PDU Length: 257
01 00 00 00 00 fb 00 01 00 00 6a 75 70 69 74 65
72 20 20 20 20 20 20 20 20 20 66 72 65 61 6b 6e
69 78 32 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 20 00 00 38 01 00 00 00 30 00 00 1b 31
2e 32 2e 38 34 30 2e 31 30 30 30 38 2e 35 2e 31
2e 34 2e 31 2e 32 2e 31 2e 31 40 00 00 11 31 2e
32 2e 38 34 30 2e 31 30 30 30 38 2e 31 2e 32 50
00 00 5e 51 00 00 04 00 00 40 00 52 00 00 1e 31
2e 32 2e 38 34 30 2e 31 31 33 36 35 34 2e 32 2e
33 2e 31 39 39 35 2e 32 2e 31 30 2e 32 55 00 00
0d 4d 49 52 43 54 4e 32 32 4f 43 54 39 38 54 00
00 1f 00 1b 31 2e 32 2e 38 34 30 2e 31 30 30 30
38 2e 35 2e 31 2e 34 2e 31 2e 32 2e 31 2e 31 01
00
Association Received
Parameters:
Our Implementation Class UID: 1.2.276.0.7230010.3.0.3.5.2
Our Implementation Version Name: OFFIS_DCMTK_352
Their Implementation Class UID: 1.2.840.113654.2.3.1995.2.10.2
Their Implementation Version Name: MIRCTN22OCT98
Application Context Name: 1.2.840.10008.3.1.1.1
Calling Application Name: freaknix
Called Application Name: jupiter
Responding Application Name:
Our Max PDU Receive Size: 16384
Their Max PDU Receive Size: 16384
Presentation Contexts:
Context ID: 1 (Proposed)
Abstract Syntax: =FINDPatientRootQueryRetrieveInformationModel
Proposed SCP/SCU Role: SCU
Accepted SCP/SCU Role: Default
Proposed Transfer Syntax(es):
=LittleEndianImplicit
Requested Extended Negotiation: none
Accepted Extended Negotiation: none
Constructing Associate AC PDU
Association Acknowledged (Max Send PDV: 16372)
(but no valid presentation contexts)
Our Implementation Class UID: 1.2.276.0.7230010.3.0.3.5.2
Our Implementation Version Name: OFFIS_DCMTK_352
Their Implementation Class UID: 1.2.840.113654.2.3.1995.2.10.2
Their Implementation Version Name: MIRCTN22OCT98
Application Context Name: 1.2.840.10008.3.1.1.1
Calling Application Name: freaknix
Called Application Name: jupiter
Responding Application Name: jupiter
Our Max PDU Receive Size: 16384
Their Max PDU Receive Size: 16384
Presentation Contexts:
Context ID: 1 (Abstract Syntax Not Supported)
Abstract Syntax: =FINDPatientRootQueryRetrieveInformationModel
Proposed SCP/SCU Role: SCU
Accepted SCP/SCU Role: Default
Requested Extended Negotiation: none
Accepted Extended Negotiation: none
DIMSE receiveCommand

[pacsone]

There it is! The lines below indicated that STORESCP does not support Patient-Root Informational Model queries, it may only support Study-Root Informational Queries but I wouldn't be surprised if STORESCP does not support C-FIND at all.

Context ID: 1 (Abstract Syntax Not Supported)
Abstract Syntax: =FINDPatientRootQueryRetrieveInformationModel

[4tvarian]

DAMN. That sucks.

Now that that I have your undivided attention:

Can you query an efilm workstation from the pacsone server? That probably should have been my question all along. That MIND tool you referred me to was cute and I will use it for lots of things (Incidently it appears to have a search function that is broken in a similar fashion.)

Regards,

4tvarian

[pacsone]

I know eFilm 1.5.3 has a bug in the C-FIND-RSP where it's including an extra Message ID tag (0000,0110) in the response it sends to the querying client, in addition to the Message ID Being Responded To tag (0000,0120).

Don't know if the vendor of eFilm has fixed this bug or not but you can try querying it using MIND or a third-party query client to see if they complain about the invalid tag (0000,0110) in the C-FIND-RSP returned from eFIlm. I know PacsOne Server will complain about the invalid tag and return an error status for the query.

It may be possible to modify PacsOne Server so that it can ignore the extra tag sent from eFilm, but that'd make an excuse for companies like eFilm not sticking to the DICOM standard, though.

[4tvarian]

I wouldn't change for them. I think they need to write better code. We have a devil of a time keeping our efilm users happy when they receive cd's from the outside since efilm is so picky about what it will import.