Document Type Name with Ampersand and inbound HL7 message

[Kathy_Baumann]

HL7 inbound MDM message to OnBase - I just noticed there is an error processing an inbound MDM message when the document type has an ampersand in the name, “History & Physical” for example.

The error is:

-- Processor: Document Update processor, "MDM^T08 - Epic T08 - Doc Edit - Update Document" (169)
-- Result: Failure resolving keywords
-- Description: HL7 Inbound processor [Update Document Processor]:The document type [History] in the $$DOCTYPE mapped field could not be identified.

$$DOCTYPE is mapped to TXA-2.

For example:   TXA|1|History & Physical|SD|||20220103125659|||||XXXX^BAUMANN^KATHY|13496072|||||DI

Our Cloverleaf Engine translates "History \T\ Physical" to "History & Physical".

If we don't translate and leave as "History \T\ Physical", the message processes without errors.

We upgraded to EP3 April 2021, from Ver 16. I'm thinking Ver 16 required the translation based on our configuration. We never came across this error while testing EP3 - obviously this document type was not used while testing inbound MDM messages.

My question is, what is preferred way to resolve this? Do we remove the Cloverleaf translation? Are there any gotchas that I should be aware of? What about other standard escape characters?

Or is there a way to change OnBase to process document types that include the ampersand in the name?

Thanks in advance for your recommendations.

[CurtisFox · Accepted solution]

Hello Kathy, 

Thanks for reaching out! We did introduce global escape sequence handling in OnBase 17 (SCR # 262294), which is likely why you did not see this in OnBase 16. We now adhere to the HL7 V2 standard for escape sequences, with "\T\" being interpreted as subcomponent separator character (e.g. "&", like you're seeing), "\E\" being interpreted as the escape character (e.g. the backslash, "\"), etc. The best practice would be to have OnBase interpret the escape sequences and have your HL7 interface pass those along as-is rather than translating them.

I am not aware of any gotchas, although admins from other organizations may have some additional input for you on that piece. 

[Kathy_Baumann]

Thank you @Curtis Fox for your quick response.  That explains why I am seeing what I am seeing.  Hopefully there are no gotchas and we can confidently make that change and move on.  Thanks again!