· Jan 25, 2017

DT doesn't allow accents and spanish character

Hi all,

We have a big problem with spanish accent and special characters using Data Transformation (HL7 Messages).

We have some DT to transform HL7 messages to other type (OUL^R22 To OML^O21) so it copys the PID segment to the new one, but if in the PatienName field has any special character, the transformation stops and it not continues with the transformation.

This is the message

PID|1|1234567890134567890|00000000R||MUÑOZ LÓPEZ^JUAN^||19900101000000||||&||


The transformation changes the "Ñ" and the "Ó" to "?", however if I'm using a personal structure based on HL7 2.5, the transformation doesn't work and the test page gets stuck.

In Spain this is usual have this characters in the name so it could be a big problem in the integration with the hospital.

Is there any idea what is happening?

My Ensemble version is

Cache for Windows (x86-64) 2016.2.1 (Build 803U) Wed Oct 26 2016 12:31:28 EDT [HealthShare Modules:Core:15.01.171 + Linkage Engine:15.0.171]

Thanks in advance

This is the DT

<?xml version="1.0" encoding="UTF-8"?>
<Export generator="Cache" version="25" zv="Cache for Windows (x86-64) 2016.2.1 (Build 803U)" ts="2017-01-25 09:36:08">
<Class name="Test.OULR22ToOMLO21">


<Parameter name="REPORTERRORS">


<XData name="DTL">
<transform sourceClass='EnsLib.HL7.Message' targetClass='EnsLib.HL7.Message' sourceDocType='2.5:OUL_R22' targetDocType='2.5:OML_O21' create='new' language='objectscript' >
<assign value='source.{PIDgrp.PID}' property='target.{PIDgrp.PID}' action='set' />
<assign value='source.{MSH}' property='target.{MSH}' action='set' />
<assign value='"OML"' property='target.{MSH:MessageType.MessageCode}' action='set' />
<assign value='"O21"' property='target.{MSH:MessageType.TriggerEvent}' action='set' />

Discussion (1)0
Log in or sign up to continue

The reason this is happening is because your message specifies UTF-8 in MSH:18.  If you remove that from your test message, it will look correct.

When using the 'test' button to test a DTL, it will always try to use the encoding defined in MSH:18 to read the message.

When using a business service to read the message, it will try to use the encoding defined in MSH:18 if it is defined.  If it is not defined, then the 'Default Char Encoding' setting determines which encoding will be used.  You can force the 'Default Char Encoding' to override MSH:18 by putting a ! before it.