What should be done according to the HL/7 standard is the sub-component separator (in this case the &) should be represented by T (assuming the defined escape character in the MSH-2 is ).
Normally this should be done by the originating system before the message is sent out. So the first approach I would use would be to try to convince the source system they are not compliant with the standard and to change.
Then there could be issues with the receiving system if it cannot reverse the process.
If the source will not comply then the answer depends on the release of Cloverleaf you are on and whether you want to do this inside an Xlate or not.
So knowing what release of cloverleaf you are on will help – also do you want this to occur inside an Xlate?
In any case, you will need to predetermine what fields are the likely culprits as I think you will need to attack this on a field-by-field basis.
Hi Jim,
I agree with your take on the matter. However, It is not an option to fix it at the route, so I will have to try to make it work within the cloverleaf engine. We have recently upgraded to 6.2 version. I would like to do it within an xlate if possible, but I am not really sure how to go about this. I have narrowed it down it only affecting one field which is OBR.4. I appreciate your response and willingness to help. Thank you!
.
