Help with @ symbol in Cloverleaf

[Tiffany Bohall]

I am new to Clovertech and tried to research if this question had been asked and could not find anything. Please direct me if I just missed it…

I have a customer who is adamant about receiving the patients email address to her downstream system. It is currently sent in 2 different custom user fields from our Invision feed.

I have tried to explain to her the message will most likely fail because of the @ symbol. We are entertaining the idea of using TCL logic on the inbound feed from Invision to search for the special user field and if there is an @ symbol replace it with an *, then send it downstream, but the downside to that is that we will need

Topic

[Jim Kosloskey]

Tiffany,

What do you want to know about the @?

Something related to it being in a message, in the Xlate, in Tcl?

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

[Robert Milfajt]

I am unaware of any problems with the @ symbol in Cloverleaf using @.  However, I there are plenty of problems with the & sign.  You should mock up an interface and send a message containing @ to see if there is indeed a problem.

Bob

Robert Milfajt
Northwestern Medicine
Chicago, IL

[Chris Williams]

We send email addresses in our ADT feeds without any problems. The @ won’t hurt anything, but as Bob says, watch out for those user-entered ampersands.

Chris

[Tiffany Bohall]

Thank you for the feedback thus far.  We can receive the @ fine but once we send it through an xlate that has an iteration/if statement looping through a segment to find the variable, if that variable happens to have an @ in the free text user field, the message goes to the EDB.  The seniors I work with have a theory that the message goes to the EDB because we are trying to iterate on a field that could potentially have a user entered @ symbol and Cloverleaf chokes on it, thinking it is an encoding character when in these cases, it is not.

Given our long history of bad luck with @ symbols, I have code in the xlate that searches the 2 custom user fields (email is sent in 2 diff fields as each field is only 20 chars long) and then concatenates them together on the outbound message, so it passes as 1 field.  I tested it in the testing tool and my the code retrieves and concats just find but the testing tool removes the @ symbol, which we do not understand either.

[Jim Kosloskey]

Tiffany,

Can you give us a more specific example?

Is it at an IF that the message goes to the Error DB?

Is there any Tcl involved in the Xlate at that point.

What does the log show?

What is the Error: field content on the Action that is failing?

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

[Tiffany Bohall]

Please see attached word doc.

[Jim Kosloskey]

Tiffany,

What is the Data Type for the ZPV#61 field in your variant?

Also what releease of Cloverleaf?

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

[Tiffany Bohall]

Good question!  

All xlates are using variant 2.3 and we are on version 5.7 of CL.

Number 90561, type = ST, length = 256, Name = Case User Data, marked as optional and repeats.

[Jim Kosloskey]

Tiffany,

OK well that Data Type by definition does not describe componentized fields. Cloverelaf is trying to assist you as much as possible but evetnually (and I don’t know why the @ is causing this) you have gotten to a point where Cloverleaf cannot make sense of the discrepancy between the Data Type described and the actual data (the ^ in this case really are just part of a string – ST).

Most of the above is my theory.

This is the problem with these vendors that abuse the standard with unnecessary Z segments and User fielkds – they also do not use the proper Data Types.

Perhaps a better Data Type for that field would be CM (Composit) or CE (Coded Element) although there are others that coul apply as well. But in my opinion ST has the potential for issues given the data I see.

For validation, try Copying the variant you are using to another temporary variant, change the Data Type at the field to CM or CE and retry to see if the issue goes away (you might have to experiment with the Data Type since the vendor cannot tell you what it should be). When I have faced similar issues I have found CM worked well but I try to pressure the vendor to tell me exactly which of the HL/7 Data Types this field really represents.

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

[Tiffany Bohall]

The problem you are having with & is the same issue we have with @.  Our Invision encoding characters, post ebcdic to ascii conversion are ” ^~@ “.

[Jim Kosloskey]

Tiffany,

Well new info – although I still maintain you should use the proper Data Type.

Now that you let us know the @ is your subcomponent separator this is the real issue.

You can try using PATHCOPY for those fields/components that have the subcomponent separator as data instead of as a separator. In reality if the source system is sending that data it should be encapsulated according to the rules clearly spelled out in the HL/7 standard.

But I doubt seriously Siemens will accomodate that.

So if you are using an IF of course PATHCOPY won’t work in that case you need to use subcomponent notation and potentially some clever concatenating. By the way since the @ is a separator the challenge with subcomponent notation is you need to know exactly how many and where.

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

[Author]

Replies