segment ## is out of order for message type XXXXXX

You will get this error usually when the variant is expecting a segment and the message doesn’t have it.  Check and see if you have some segments marked as “required” in the variant.

You can also get these errors because of a TCL proc using the wrong

HL7 variant or GRM commands.

Mary,  Are you by any chance on 5.2.1, rev2?

The reason I ask is that I just started receiving this error on a message that hasn’t changed in any way (no variant change, no change in segments in the message, no tcl changes, etc.).

All of a sudden I started getting “#6 segment OBX is out of order for message type ORM_O01”.  Here is the message layout:

MSH

PID

PV1

ORC

ODS

NTE

OBX

ZOM

Note that OBX is #7, not #6.  Just for laughs I decided to make the NTE segment repeating and it tested fine, no errors.  I ran the ORM through the engine again, and no more errors.  I don’t know why this would be when the NTE is not repeating, and the OBX segment is really #7, not #6.

Hi Mary,

You probably should be on 5.3 by now.

Was your problem solved in 5.3?

I am encountering similar problems for the same translation in 3 different boxes – 2 on 5.3 and 1 on 3.8.1. The XLT uses A31 for both inbound and outbound formats.

But the error is complaining about A08:

“The # 3 segment encountered ‘OBX’ is out of order for message type ‘ADT_A08’.  Segment ignored.”

PV1 is mandatory for A08, but optional for A31.

The error disappeared when we made PV1 optional for A08.

Strange…..

We are on 3.5.2P… I think it is a bug in the software… In my variant I created a ORU_R01 message, but when the engine runs it always defaults to ORU. The message I created (ORU_R01) is total different than the ORU. To stop the messages, I think I’m going to have to revert back to the ORU structure, but mark any required segments to optional and then add what I need…

BTW, I’m hoping our hosptial will be on 5.3 by fall!…

Thanks for all your responses.

I had the same thing happen to me and here is what had happened.

I had created a message type that was not part of the HL7 standard like ORU_R01 in your case but it had something to fall back on if not found like ORU in your case.

I developed the xlate with ORU_R01 tested and went live.

For some reason the site specific varinat directory tree in $HCISITEDIR/formats/hl7/2.3/my_ORU_R01_variant got deleted.

Then the engine tried its best to use the next best thing form the standard HL7 variant which was ORU.

In my case ORU and ORU_R01 were identical so this went on for years just fine without me knowing of the problem.

I noticed it when we got to QDX 5.2.1P2 and tried to open the xlate and found that the newer GUI is more strict about this sort of oversight.

With all that said, I suggest you cd to your formats directory in your relevant site at the command prompt on the cloverleaf server and check that the variant you used to develop the xlate is still there.

For example:

cd $HCISITEDIR/formats/hl7/2.3/messages

ls -l ORU_R01

Another thing would be to use the HL7 configurator from the same site the Xlate is in to see if you can open the ORU_R01 variant and view the layout of the ORU_R01.

Ovbviously if you can’t do both of these you may need to recreate the variant.

Hi Russ,

Checked both points, and everything is intact.

The 3 boxes I mentioned are maintained by 3 different persons, each following an agreed specs to develop the new HL7 variant. It’s really interesting to see the same error happening in all 3 boxes, particularly when you consider the fact the 2 are on QDX 5.3 and 1 on QDX 3.8.1. 🙂

Things are working now with the workaround, but just curious what’s the root issues. 🙂

I’m grasping at straws but take a close look and make sure your zeros are not O’s and vice versa.

In other words, make sure the variant is defined as ORU_R01 and not something like ORU_RO1.

Also, check in the actual message that it is coming across as ORU_R01 and not something like ORU_RO1 (this has happened to me once upon a time, too).

Hi Russ,

Sorry for not giving more details.

We created a new variant ‘HL7_CMIS’. For my case, the issue is with A31, not ORU. And the error (as mentioned) prompted A08 instead….stange….

I believe it’s a bug. 😛

David,

  When you build a translation based on a message type, in your case A31, for the translation this is only a template to let you choose the fields but it does not tie your translation to only A31 messages.  The only way to limit what message actually uses the translation is by the route. When the translation is in use by the engine, the message will be parsed and validated based on the actual message type.  In your case you where getting an A08 with out a mandatory PV1, so the HL7 parser was correctly identify your missing segment when translating the message.