segment ## is out of order for message type XXXXXX

[Anonymous]

Hi All,

I’m at a loss… I’m getting the following messages every time one of these goes through. I’ve matched the HL7 variant with the message, and made sure I’m using it in the Xlate and in the configurations. What am I missing? The message is ok, but the errors are filling up the logs.

Thanks in advance for any help!…

Mary Kobis

Crouse Hospital

[msg :RecD:WARN/0:    fr_dphone] Can’t find message def for type ‘ORU_R01’. Trying ‘ORU’ as a fallback.

03/10/2005 00:46:03

[msg :RecP:WARN/0:    fr_dphone] [0.0.410721008] The # 1 segment encountered ‘PID’ is out of order for message type ‘ORU_R01’.  Segment ignored.

03/10/2005 00:46:03

[msg :RecP:WARN/0:    fr_dphone] [0.0.410721008] The # 2 segment encountered ‘OBR’ is out of order for message type ‘ORU_R01’.  Segment ignored.

03/10/2005 00:46:03

[msg :RecP:WARN/0:    fr_dphone] [0.0.410721008] The # 3 segment encountered ‘OBX’ is out of order for message type ‘ORU_R01’.  Segment ignored.

03/10/2005 00:46:03

[msg :RecP:WARN/0:    fr_dphone] [0.0.410721008] The # 4 segment encountered ‘DSC’ is out of order for message type ‘ORU_R01’.  Segment ignored.

03/10/2005 00:46:05

Topic

[Stephan Head]

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.

[Anonymous]

You may also want to run the inbound message through HL7 tester to see if the message meets your variant format.

…hai

Mayo Clinic

[Anonymous]

Mary, do you have message type ORU_R01 defined (in the hl7 variants) that correspond to the hl7 version in use, and do the segments defined in that variant match your message ?

[Alice Kazin]

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

HL7 variant or GRM commands.

[Debra Downs]

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.

[Anonymous]

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.

[David Teh]

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…..

Mary Kobis wrote:

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.

[Russ Ross]

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.

Russ Ross
RussRoss318@gmail.com

[David Teh]

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. 🙂

[Russ Ross]

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).

Russ Ross
RussRoss318@gmail.com

[David Teh]

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. 😛

[John Mercogliano]

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.

John Mercogliano
Sentara Healthcare
Hampton Roads, VA

[Author]

Replies