Issues with receiving HL7 messages on dcm4chee-arc-light 5.23.2 on linux

[Rade Markovic]

In one hospital we were deployed dcm4chee-arc-light 5.23.2 on Debian 10 Linux server. DICOM parts works as expected without problems. 

We use dcm4chee-arc-light 5.23.2 binary distribution from source forge.

LDAP server is ApacheDS.

Database is PostgreSQL14.

Physicians want to send MWL lists to dcm4chee-arc-light from their current HIS. But then we encountered issues...

currently this test message does not pass, no matter what tool we use to send it:

MSH|^~\&|BIS|HOSPITAL|ASTREOS|PACS|20220211092649.772+0100||ORM^001^ORM_O01|74b29345-dcd0-4c1c-a5fe-15b5252139c8|P|2.4||||||UNICODE UTF-8
PID||72402|72402||CYZić^INAMe||19420830|F
PV1||O|||||^Mr sci med. dr Ime Šprezime|^Mr sci med. dr Ime Šprezime
ORC|NW|101119|||||^^^20220211092649.78+0100
OBR|1|101119|101119|||||||||||||||||||||CR
ZDS|1.2.40.0.13.1.1.1.192.168.20.201.20220211085138535.32771^TEST^CR

We got answer:

MSH|^~\&|ASTREOS|PACS|BIS|HOSPITAL|20220217121055.022||ACK^001^ACK|154829536|P|2.4||||||UNICODE UTF-8
MSA|AR|74b29345-dcd0-4c1c-a5fe-15b5252139c8|Message Type not supported
ERR|||201|E||||Message Type not supported

tcpdump of this message exchange does not indicate any communication error.

researching further we sensed that most likely the first useful byte of the message (letter M) was lost during parsing of the message and thus the whole message was moved by that 1 byte which leads to the fields in the message being moved by 1 field and thus the message id came in the message type field.

I've been looking for the cause of the problem for a couple of days now and I can't find it. When sending, I can get test programs to add a 1 letter in front of the message being sent and then I don't get an error message. But that is not the solution because I cannot get such a message from their existing HIS. The worst part is that the dcm4chee answer is strictly by standard.

What can we do to establish proper communication between hl7 tools and servers on the one hand and dcm4chee-arc on the other?

[Vrinda Nayak]

Have you checked ORM^O01 is configured as Accepted Message Type in your ASTREOS|PACS HL7 Application?

Also, ORC segment in above message does not have any value in field 5 - so even if you get past "Message Type not supported", you will later encounter "Invalid Order Control Code or Order Status". See https://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol2.pdf#page=108

[Rade Markovic]

Thanks for suggestions...
After watching carefully at hex dump of senders message we found error which was make us crazy several day...
Now we have issues with message format which you mentioned... But not just ORC segment...

We will investigate this further using https://dcm4chee-arc-hl7cs.readthedocs.io/en/latest/orm/inbound.html ...

[Rade Markovic]

After resolving issues with Message Type not supported we encountered new ones:

$ ./dcm4che-5.23.2/bin/hl7snd -c 172.21.32.2:2575 c.hl7
13:29:37,618 INFO  - Initiate connection from 0.0.0.0/0.0.0.0:0 to 172.21.32.2:2575
13:29:37,628 INFO  - Established connection Socket[addr=/172.21.32.2,port=2575,localport=50995]
13:29:37,631 INFO  - Socket[addr=/172.21.32.2,port=2575,localport=50995] << MSH|^~\&|SendingApp|SendingFac|ReceivingApp|ReceivingFac|20160629095023||ORM^O01^ORM_O01|168715|P|2.5
PID||1|A-10001||DOE^JOHN
PV1||RAD|||||REF_PHYS_ID^REF_PHYS_FIRST^REF_PHYS_LAST|^ReferringPhysLast^ReferringPhysFirst
ORC|NW|1|||||^^^20150414120000
OBR|1|1|2|1100|||||||||||||||2|SPS_ID||||CT||||||||||PERFOMING_TECH
ZDS|1.2.4.0.13.1.432252867.1552647.1^AETitle^StationName

13:29:37,631 DEBUG - Socket[addr=/172.21.32.2,port=2575,localport=50995] << MSH|^~\&|SendingApp|SendingFac|ReceivingApp|ReceivingFac|20160629095023||ORM^O01^ORM_O01|168715|P|2.5
PID||1|A-10001||DOE^JOHN
PV1||RAD|||||REF_PHYS_ID^REF_PHYS_FIRST^REF_PHYS_LAST|^ReferringPhysLast^ReferringPhysFirst
ORC|NW|1|||||^^^20150414120000
OBR|1|1|2|1100|||||||||||||||2|SPS_ID||||CT||||||||||PERFOMING_TECH
ZDS|1.2.4.0.13.1.432252867.1552647.1^AETitle^StationName

13:29:37,641 INFO  - Socket[addr=/172.21.32.2,port=2575,localport=50995] >> MSH|^~\&|ReceivingApp|ReceivingFac|SendingApp|SendingFac|20220218132937.636||ACK^O01^ACK|154829540|P|2.5
13:29:37,641 DEBUG - Socket[addr=/172.21.32.2,port=2575,localport=50995] >> MSH|^~\&|ReceivingApp|ReceivingFac|SendingApp|SendingFac|20220218132937.636||ACK^O01^ACK|154829540|P|2.5
MSA|AR|168715|Could not compile stylesheet
ERR|||207|E||||Could not compile stylesheet

13:29:37,641 INFO  - Close connection Socket[addr=/172.21.32.2,port=2575,localport=50995]

After looking at wildfly server.log file we found next block:

2022-02-18 13:29:37,630 INFO  [org.dcm4che3.net.Connection] (EE-ManagedExecutorService-default-Thread-1) Accept connection Socket[addr=/172.21.33.214,port=50995,localport=2575]
2022-02-18 13:29:37,634 INFO  [org.dcm4che3.hl7.MLLPConnection] (EE-ManagedExecutorService-default-Thread-11566) Socket[addr=/172.21.33.214,port=50995,localport=2575] >> MSH|^~\&|SendingApp|
SendingFac|ReceivingApp|ReceivingFac|20160629095023||ORM^O01^ORM_O01|168715|P|2.5
PID||1|A-10001||DOE^JOHN
PV1||RAD|||||REF_PHYS_ID^REF_PHYS_FIRST^REF_PHYS_LAST|^ReferringPhysLast^ReferringPhysFirst
ORC|NW|1|||||^^^20150414120000
OBR|1|1|2|1100|||||||||||||||2|SPS_ID||||CT||||||||||PERFOMING_TECH
ZDS|1.2.4.0.13.1.432252867.1552647.1^AETitle^StationName

2022-02-18 13:29:37,636 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-11566) ERROR:  '/PACS/wildfly/standalone/tmp/dcm4chee-arc/hl7-adt2dcm.xsl (No such file or directory)'
2022-02-18 13:29:37,636 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-11566) FATAL ERROR:  'Could not compile stylesheet'
2022-02-18 13:29:37,638 INFO  [org.dcm4che3.hl7.MLLPConnection] (EE-ManagedExecutorService-default-Thread-11566) Socket[addr=/172.21.33.214,port=50995,localport=2575] << MSH|^~\&|ReceivingAp
p|ReceivingFac|SendingApp|SendingFac|20220218132937.636||ACK^O01^ACK|154829540|P|2.5
2022-02-18 13:29:37,646 INFO  [org.dcm4che3.net.Connection] (EE-ManagedExecutorService-default-Thread-11566) Close connection Socket[addr=/172.21.33.214,port=50995,localport=2575]

We can't find this file in downloaded dcm4chee-arc-5.23.2-psql-secure.zip used for installation. I looked in the source tree for dcm4chee-arc-5.23.2 and found that there is a package dcm4chee-arc-conf-data that is not packaged in a binary distribution but that contains that and a few other hl7 .xsl files. The question is whether that package was intentionally omitted or is there a bug related to the installation packaging? Could I try to compile and deploy only that package to see did it resolve all problems?

[fleetwoodfc]

The .xsl files are packaged in vendor-data.zip: see Vendor Data 

It looks like your system. is having an issue with file permissions i.e dcm4chee does not have permission to write to the /PACS/wildfly/standalone/tmp so it cannot compile the stylesheet it needs to handle the HL7 message.

Also the message ORC segment is still missing ORC.5 should be:

ORC|NW|1|||SC||^^^20150414120000