Can I change message type in xlate

[Rich Durkee]

When you create a new Xlate, you have to specify the output file format of the HL7 message – ADT-A01 for example. Suppose that a certain inbound message contains data that causes the vendor to want an ADT-A08 message instead on an ADT-A01. Is it possible to overlay the message type field in the MSH segment with a different type than was specified in the original file format? Does this confuse Cloverleaf or cause other problems?

Thanks

Rich Durkee

Topic

[Daniel Lee]

No, I’ve had to do this quite a bit.

[Vince Angulo]

Agreed.  Here at Children’s we almost always configure translations to use the ADT_A08 as it’s basis.  It’s the most robust transaction type in terms of segments defined.  We just end up tweaking the variant(s) to make sure all our Z segments are accommodated.

[Jim Kosloskey]

Rich,

From a technical standpoint you can change the Message Type field in the Xlate to whatever you want.

As to whether that will cause a problem downstream, that all depends on what is going on downstream (including the receiving system).

If you have any follow on procs which are sensitive to the Message Type being correct that may be a problem.

If the receiving system needs to have a specific structure/content for an A08 which is different than what you normally provide for an A01, then you will either need to accomodate both in one Xlate – or create two Xlates (one with A01 in and out; one with A01 in and A08 out); then using a pre Xlate proc in the Route Details you can invoke the appropriate Xlate depending on the conditions detected.

The latter way is the way I do it – seems to have less potential for problems immediately and in the future.

Jim Kosloskey

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Charlie Bursell]

Not only can you do it, I highly encourage it.  It makes no sense to me to have 12 – 15 different ADT translations when 95% of each translation is the same.  Simply set up the variant to make all of the messages the same (I usually use ADT_A01).  Then, for  the messages that don’t have some of the segments. make the segment optional.

If a certain type needs special processing, just use an “IF” statement.  For example if you want to do something different with a discharge just put something like:  if 0(0).EVN.#1 eq A03 …..

Doesn’t it make more sense to have a single translate to maintain?  If you have to change something just change one file rather than a bunch.

This will work for all ADT types that have sequentially the same segments,  It won’t work for an ADT_A17 because of the repeating PID/PV1.

Also, when build the translations, use the # paradigm rather than the HL7 address.  For example, 0(0).PV1.#3 rather than 0(0).PV1.00133.  When was the last time someones discussed an HL7 field with you by HL7 address?  No one is going to ask you ablout PV1 field 00133, they would ask you about PV1 field 3.

As any of you that have been in any my presentations know, I constantly preach *MAINTAINABILITY*.  In the above, which is easier to maintain?  Ease of maintenance translates into cost savings!

End of Charlie’s soapbox   🙂

[Daniel Lee]

Amen!  Learned that the hard way and now I have a major system with 1 Xlate for each transaction type that needs to be updated whenever there is a change.

[Jim Rawls]

Cloverleaf 5.1 on AIX 5.1

I have a legacy translate file that is for ADT^A02 messages; it was cloned from an ADT^A03, and has in the configuration an ADT^A03 input and output.

The translation is very vanilla and is performing straight moves, field by field.  (MSH-9 is being moved but not changed.)  Unfortunately it is changing the message to A03 when it should be going out as an A02. 😯

We have numerous translations that change message types and work just fine.  Are there apparently circumstances where the configuration chosen determines the output message type?  Does anyone know what the rules are?

[Charlie Bursell]

As long as you do a BULKCOPY first or at least make sure you copy MSH.9 -> MSH.9 and EVN.1 -> EVN.1 everything will come out fine.

You *MUST* make a variant that matches for all types.  Iusually take an ADT_A01 variant and make any segments not used by all messages optional.  Then simply copy this message variant to all others; A03, A04, etc.

[Ryan Boone]

Would Charlie’s advice below from several years ago still be optimal for a STAR-to-Epic / eGate-to-Cloverleaf ADT migration? It seems that Cloverleaf, to an extent, enforces the event-type definition. But provided there isn’t a morass of conditionals based on event-type in an all-in-one Xlate scenario, is this still the best way to go?

Thanks for any recommendations.

Charlie Bursell wrote:

Not only can you do it, I highly encourage it.

[Max Drown (Infor)]

If in doubt, try it!! Setup a test xlate and send messages of different types through and see what happens.

Choosing the message type for new xlates or reconfiguring existing xlates simply determines what part of the variant is show in the xlate, but it does not determine how the message is parsed. For HL7, the message will be parsed based on the value in MSH.09.02. If your paths are different for different types, then you can reconfigure the xlate to see the paths for each different type. But, like Charlie said, its much easier to make every time look the same using optional and repeating components.

-- Max Drown (Infor)

[Ryan Boone]

Max Drown wrote:

If in doubt, try it!! Setup a test xlate and send messages of different types through and see what happens.

Choosing the message type for new xlates or reconfiguring existing xlates simply determines what part of the variant is show in the xlate, but it does not determine how the message is parsed. For HL7, the message will be parsed based on the value in MSH.09.02. If your paths are different for different types, then you can reconfigure the xlate to see the paths for each different type. But, like Charlie said, its much easier to make every time look the same using optional and repeating components.

Thanks, Max — I did test it, and it works fine in a controlled situation for all of the event types tested. My main concern is whether this goes against best practices since I’m essentially taking a vendor spec and creating a customized variant that melds all of the event types together as one long list of optional segments. On the other hand, I suppose if it gets too unwieldy during the build process it wouldn’t take much to split them out.

[Max Drown (Infor)]

I do consider it a best practice to use one xlate whenever possible.

-- Max Drown (Infor)

[Jim Kosloskey]

In this case ‘best practice’ is what is best for you.

If mashing together a variant to try to use one Xlate is your best practice then go for it.

If not you can do it the other way.

Here we use separate Xlates and consider that our best practice. With a stringent spec process, that has not caused us any undo maintenance (especially with the COPY/Paste capability in later releases).

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Robert Milfajt]

I’ve taken an ORM message and created and ADT followed by the ORM message, because the downstream system (Epic in this case) could not create a patient from an order.

Robert Milfajt
Northwestern Medicine
Chicago, IL

[Paul Johnston]

Quote:

As long as you do a BULKCOPY first or at least make sure you copy MSH.9 -> MSH.9 and EVN.1 -> EVN.1 everything will come out fine.

You *MUST* make a variant that matches for all types.  Iusually take an ADT_A01 variant and make any segments not used by all messages optional.  Then simply copy this message variant to all others; A03, A04, etc.

This is an interesting method I will have to try. Would it be any different to create the ADT variant , use it in a XLT but using a ‘ Wild Card ‘ route. Would this eliminate the MSH 9 and EVN copy . ?

[Max Drown (Infor)]

You would need to use a wildcard route, but you would still need to do the appropriate statements in the xlate. Give it a try!

-- Max Drown (Infor)

[Robert Kersemakers]

Paul, if using a certain message  for a ‘generic’ translation, you will always have to fill MSH-9 and EVN-1 yourself. This also applies when using wild card routes.

For instance if you use ADT^A01 as your outbound message, it will automatically fill in A01 in MSH-9.1 and EVN-1 if you don’t do it yourself.

I have created a message simply called ADT, made it very generic and also included the MRG segment. This way I can handle A18 messages as well, with just one translation. Previously I had about 12 or 15 translations from SAP HCM to HL7, which will work also until you need to change one or two things to all these translations. Having only 1 translation is a blessing.

Zuyderland Medisch Centrum; Heerlen/Sittard; The Netherlands

[Paul Johnston]

Right  🙂  … still need to COPY the MSH and EVN .

I believe I do the same as you Robert having a Wild Card route as ADT_A((0[1-8])|11|12|13|34) using the XLT X_Star_Nuance_ADT.xlt

and I created an HL7 variant with a message just called ‘ADT’ .

[Author]

Replies