Escaping in HL7 messages

[mikedaw99]

It says in the documentation that a DTL data transformation automatically deals with HL7 escaping but that's not the behaviour we are seeing.

A DTL transformation from a cache class containing the '&' character to an HL7 message is not escaped

A DTL transformation from an HL7 message to a cache class leaves the \T\ in the cache class.

Has anyone got this working without having to manually escape HL7 delimiters?

Thanks

Mike

[David Blake]

Hi Mike

 

Here’s a good explination of the when why and why nots of Ensemble (un)escaping that Dale offered some time ago to another customer. I think it explains things very well and hope that it answers your question.

 

The documentation that you referred to is not overly clear about when Ensemble does and does not perform (un)escaping. The separators on HL7 messages are the determining factor in whether Ensemble escapes or unescapes the HL7 data. If the contents of any field conflict with one of the separators, the conflicting characters are then escaped. If the separators are change Ensemble will escape or unescape 

characters as necessary. In your case, however, Ensemble has no way of knowing whether your destination field is (or is not) going to be used in an HL7 message, nor is there any way of knowing whether the field is going to have the same (or different) separators. As such, we don't automatically escape (or unescape) data pulled directly from an HL7 message using HL7message.GetValueAt() or the 

equivalent HL7message.{virtual:doc} syntax - that is the responsibility of the application designer, who knows what needs to happen to the data after retrieving it from the HL7 message. It is for this reason that the EnsLib.HL7.Segment Escape() and Unescape() methods exist.

Here is an example of the Unescape method for your reference

    <assign property='target.FieldTest' 

value='source.GetSegmentAt("PID").Unescape(source.{PID:PatientName.familyname})' 

action='set'/>

 

In addition to this; something that you should be aware of is that unescaping only acts on maximum 32k strings. This will leave you with some work to do if you wish to unescape steams that are longer as the escape string may cross the 32k boundery.

 

Best regards

 

Dave

--
You received this message because you are subscribed to the Google Groups "InterSystems: Ensemble in Healthcare Community" group.
To post to this group, send email to Ensemble-in...@googlegroups.com
To unsubscribe from this group, send email to Ensemble-in-Healt...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/Ensemble-in-Healthcare?hl=en

[Ted Peck]

I don't think the documentation is right. Can you send the WRC a link to
the offending passage?

The issue is that because of HL7's multiply nested separators scheme it
is impossible to be sure which characters are separators and which are
content if they are all unescaped. (Also if you don't know which
separators were in use, as is the case when populating fields in a
non-HL7 object.) For this reason Ensemble does not automatically
unescape when retrieving values from an HL7 field: because it might have
sub-fields and you might lose the ability to parse them.

We have considered offering a method call that would automatically
unescape, to be used in situations where you are confident there are no
sub-fields. We haven't thought of a way that this could work seamlessly
with DTL however so we haven't done it. So you must explicitly call our
unescape method if you want to be clear of escape sequences. This has
the effect of making sure you don't care about sub-fields when you unescape.

Ted

[mikedaw99]

Thanks Ted I have sent a link to the documentation to the WRC.

Mike

[mikedaw99]

Thanks for the explanation Dave. I do think the documentation is unclear and I have sent a link to it to the WRC

Regards

Mike

[Ali Ruhul (RQ8) Mid Essex Hospital]

I have noticed similar, we are sent a ‘\T\’ and all is well, as it hits the outbound adaptor it gets converted to a ‘&’ by Ensemble automatically.  I always thought this to be normal functionality?

 

For us it has caused problems as we have a FRL system, where bytes need to be declared in the message. ‘\T\’ being 3 character bytes, whereas the automatic conversion back to ‘&’ dropping two bytes (we initially calculated in DTL for 3 for the escape routine) causes issues for the receiving system we send to.

 

I did a $REPLACE as a work around, but would be interested to hear responses.

 

From: ensemble-in...@googlegroups.com [mailto:ensemble-in...@googlegroups.com] On Behalf Of mikedaw99
Sent: 31 August 2011 11:43
To: Ensemble-in...@googlegroups.com
Subject: [InterSystems-EnsHlth] Escaping in HL7 messages

 

It says in the documentation that a DTL data transformation automatically deals with HL7 escaping but that's not the behaviour we are seeing.

--

You received this message because you are subscribed to the Google Groups "InterSystems: Ensemble in Healthcare Community" group.
To post to this group, send email to Ensemble-in...@googlegroups.com
To unsubscribe from this group, send email to Ensemble-in-Healt...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/Ensemble-in-Healthcare?hl=en

Care, Excel, Innovate

Apply to be a member of our Foundation Trust. See the web site at www.meht.nhs.uk for further details.

Information in this message may contain confidential and privileged information. If you are not the intended recipient please accept our apologies; please do not disclose, copy or distribute information in this e-mail or take any action in reliance on its contents: to do so is strictly prohibited and may be unlawful. Please inform us that this message has gone astray before deleting it.

Content of emails received by this Trust will be subject to disclosure under the Freedom of Information Act 2000. Unless the information is legally exempt from disclosure, confidentiality of this e-mail and your reply cannot be guaranteed. Thank you for your co-operation.