- This topic has 12 replies, 5 voices, and was last updated 19 years ago by
.
-
Topic
-
-
Replies
-
-
-
-
What software is smart enough to know when you meant it to be an ampersand and when you didn’t? Your best bet if you can is to get the vendor to change the sub component separator character to something else.
Other wise, this normally occurs within a couple of fields. Then parse the message and change it only within those fields,
-
The appropriate thing to fix this would be to get the software vendor to abide by the HL7 standard (easier said than done) and use “escape sequences” in their interface. If you are unaware of escape sequences, they basically symbolize the HL7 delimiters of the message. Of course, the receiving side has to be able to accept them also, or they’ll just appear as the escape sequence, such as “f”, or “t”.
-
-
-
All, What if the Cloverleaf engine checks if the field has sub-components first? I agree that the issue is in the sender’s side but some times is hard to convince the vendor to fix it for free (some times the app team has no idea on how to fix it)
But, what if the Cloverleaf parser checks that field in the HL7 variance before interpreting the & as a separator?
If the HL7 field is defined as containg sub-components, then the & should be interpreted as a separator by the xlate, but if it is defined as text, then it should be interpreted as another character.
Will something like that work for everybody? Is this doable by Quovadx?
Best regards,
Carlos
-
Exactly Carlos, getting vendors to do the right thing is often more of a project than the actual project. We have many vendors that we end up just working around problems for that very reason. I don’t think checking if the field is text or not will work, because you still wouldn’t know if the & is supposed to be a delimiter or part of the field. The engine cannot know that.
I would suggest an appropriate workaround for this would be Vince/Charlie’s solution, assume that certain fields would not have an & delimiter, and use a regsub to replace them (in that field only) with another character.
-
-
Yes, I was talking about using the field types to determine if a field could have sub-components. This could only happen in a newer Cloverleaf version. For now, you are right, we need to use Vince/Charlie’s solution. What I was trying to say is that if I know that a field is not going to have sub-components, then I could set its type as “Text Data” (or a new data type “Text with no subcomponents”), but if I know that it may have sub-components, then I can declare it as “Composite” and then let the xlate grab the whole field and determine (looking into the data type) if any delimiters inside that field can be ignored. Of course, Quovadx would need to add the code to the parser to make it happen.
Do this make sense?
Carlos
-
Carlos, Makes sense except just as vendors don’t abide by the standard as far as controlling proper inclusion or exclusion of separators, many vendors also abuse the standard by utilizing subcomponents where none are defined in the standard.
The HL/7 folks realized that when utlizing structured message construction, it is essential the defined separators only be used as separators and provided a mechanism to allow vendors the flexibility to accomodate inclusion of separator characters (as escaped values) where they would not interfere with parsing.
I have little patience with vendors who are very boisterous in there proclamations how they are HL/7 compliant at sales time but are strangely quite and less than cooperative when it is shown where their products fail the standard at development/implementation time.
Normally the correction is relatively easy for the sending and receiving systems from a technical perspective but because only a few clients really object but instead apply local work arounds, there is little incentive for the vendors to correct the issues.
I guess if more clients refused to accept non-standard implementations there might be fewer of these issues.
Part of the problem is typically we as Intregration Engineers are not involved in the selection process so that the really pointed questions are not asked early on and potential deficiencies discoverd. By the time we get involved, typically, the project is well on its way and we become the ‘pimple on the butt of progress’ and work arounds are the only recourse.
I had the pleasure of once working in an environment where the integration capability of products was weighed heavily in the selection process and Integration Engineers reviewed each propsective system for integration flaws. The number of ‘surprises’ were greatly reduced. Of course, there was also detailed specification generation and excruciating testing both of which contributed to pretty stable production implementations.
That said, if after a little ‘wall to wall’ counseling with the vendor fails to produce a correction, I believe the only valid work around is to identify the offending fields and attempt to correct them prior to Xlate. However, never underestimate what can be entered any where in the message and so it would not be surprising if from time to time it would be necessary to either add fields to be corrected or change the correction necessary.
My .02…
Jim Kosloskey
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
-
- The forum ‘Cloverleaf’ is closed to new topics and replies.
