[Gregg Price]

The receiving system wants the NTEs combined into one area of the message as multiple NTEs – not one NTE segment.

We’re checking to see if the sending system can put the first NTE group next to the second NTE group.

[Gregg Price]

And, yes, the receiving system wants it after the OBR.

[Gregg Price]

I was worried the change would require a different group and corresponding changes to segments following that group.

Thanks for your help.

[Gregg Price]

Good idea on the HL7 Tester

Here is what the actual inbound message contains in that section:

ORC|RE|

NTE|1||A copy of this report will be faxed to:  Dr. Parikh.br|||

OBR|1|

NTE|1||Please fax to Dr. Parikh 507-266-xxxx.br|||

The attached file shows how the inbound format views the message – the first NTE segment is a copy of the 2nd NTE segment.  It does not recognize the first NTE.

I’m trying to build the outbound to look like:

ORC|RE|

OBR|1|

NTE|1||A copy of this report will be faxed to:  Dr. Parikh.br|||

NTE|2||Please fax to Dr. Parikh 507-266-xxxx.br|||

[Gregg Price]

I cycle save the live threads weekly.  If I have to go back and find a message, it’s a little easier than looking through daily files.

If you mean reboot the system, then that’s more of a quarterly time period.  It takes at least 20 minutes to accomplish everything, so I don’t like to do it too often.

[Gregg Price]

You were very close.  I didn’t need the in the copy command.

COPY =*XR ABDOMEN  SUPINE —> @mytemp

Copying the value to a variable and then testing the field against the variable did work.

Thanks!

[Gregg Price]

Charlie Bursell wrote:

What version of Cloverleaf?

[Gregg Price]

BTW, my other ‘good’ interface was also failing the messages.  I was so busy checking the actual OB messages I never looked closely at its status_report.  Because the people on the other side said the messages looked good, I didn’t verify it on my end.

Live and learn.

[Gregg Price]

Charlie Bursell wrote:

My suggestion would be to use the standard reply procs provided by us.

i found where the check_ack proc resides.  It’s under recover_33.tcl.  It looks like it’s expecting an AA and not a CA for a good ACK.

I’ll see if the sending system can respond with an AA.  That will probably fix the issue.

[Gregg Price]

Charlie Bursell wrote:

My suggestion would be to use the standard reply procs provided by us.

The TPS Inbound reply is check_ack, and that’s not one we’ve written.  It must be one of yours.  Does the error indicate otherwise?

[Gregg Price]

Keith McLeod wrote:

Check the inbound tab to see if ‘Outbound Only’ is checked.

It is NOT checked, and that’s similar to my other OB threads.

[Gregg Price]

Thank you.  That’s exactly what I need.  It will save us much time.

[Gregg Price]

The patient is manually created in the RIS if it doesn’t exist.

During the manual order entry, our MRUN is entered into a comment field of the order in the RIS.  The RIS interface uses that field to populate our MRUN field when it sends ORM updates and the ORU.  Our MRUN can’t be stored within the patient database section of the RIS.

[Gregg Price]

Start with the Scheduled Tasks as Ian indicated.

My backup directory is defined in the file, CL_archive_list, under quovadxqdx5.7integratortcllibarchive.  For my Windows system, the archive folder is C:archive_CL

[Author]

Replies