[Tony Benitz]

It’s a BUG – Solution is HOT FIX – 6.2.6.1 per support – to bad I missed the critical fix notification before I loaded 6.2.6.0 into our production environment – now to get another downtime to load the fix.. just is life of an interface engineer I guess..

 

[Tony Benitz]

Thanks – we are on 7.8 at this time

[Tony Benitz]

We have encountered this issue as well after installing 6.2.6.0.

I have opened a support ticket.

The last message that we get in the process log before it dies is

WARNING: Message [0.0.149720326] is in the RDB and was left bound into Tcl
terminate called after throwing an instance of ‘std::logic_error’
what():  basic_string::_S_construct null not valid

Anyone find a work around or is the solution to load the 6.2.6.1 patch

 

[Tony Benitz]

Go to the latest version of Cloverleaf for sure.

We are moving from AIX to Linux and we have not run into any issues with the latest CLVF service pack – 6.2.1.0

[Tony Benitz]

Steve; that is what I thought.. The reasoning (No Cross Process) is because it WAS that way, but now, there is a better way to do it.

Thanks for the response and confirming my suspicions concerning this subject..

Now for a redesign..

[Tony Benitz]

I have an interest with this subject as well.

We have designed our entire interface engine with the overriding idea of NO CROSS PROCESS threads, so we have ALOT of hops, both intra and inter site.

Gets really confusing sometimes.

I also get when looking at a “process” view, you would NOT see the “other” process associated to the viewed process.

So you would need to take this into account when looking at views.

Bottom line.. It was a problem, it is still a problem?

We are looking at a possible re-design for our 6.2 upgrade coming in 2018

Thanks in advance.

[Tony Benitz]

Given that you get a daily batch file that contains multiple records for multiple individuals, you are going to have to read through the file and do a patient sort first.

So.. First step is to read the and break it out by patient

I would create a FILE for each patient, if it is new, add the header info

Issue here is the visit information (Patient Account).. so you might want to use the actual billing information to create the file of charges.

Then you have several files, one for each account, that has all the billing information (FT1 segments) there were encountered in the batch file.

Then take this collection of files through your process for final delivery to the target system..

Kind of klugie but you only have the tools that are provided and you need to parse the first file and pull the matches to build the final file and cloverleaf has issues with look ahead.. single message at a time, thus the pre-parse and build a collection of files.

Good luck, sounds like a fun one.

[Tony Benitz]

We (Legacy Health) moved to Epic going on 6 years ago.

We have cloverleaf and it works just fine with Bridges.

The trick is WHER you going to do your translations?

We have tried to keep it all in Cloverleaf.

If you have Epic user web, check out the online training for Bridges and you will need to get the training.. I did mine 2 years ago 2010 and it was three days.. Go in the spring and stay downtown.. Madison is pretty nice.

TonyB

[Tony Benitz]

Right, that is what we thought as well.  It would just work, but it didn’t

Here is the version information

Host Server Build Information:

     Version: 6.0.2.0P

        Date: Thu Feb 20 2014

        Time: 05:27:19 AM

    Platform: Windows_NT

 Java Vendor: Sun Microsystems Inc.

 JDK Version: 1.6.0_31

Swing Version: 1.6.0_31

 RMI Version: 1.6.0_31

[Tony Benitz]

RESOLUTION  😀

The issue was resolved by changing the DESTCONN metadata on the reply, then the message is sent to the new thread.

Let me know if anyone is intrested in the details.. all the magic that makes it happen.

Special Shout out to Bob Milfajt who sent me an email with the bread crumbs that lead to the solution.

Thanks.. TonyB

[Tony Benitz]

Jim;

They are TCP/IP connections and we are using system level acks.

I can find the inbound message in the SMAT file (associated to the receiving thread), but NOT in the outbound SMAT file.  That is the strange thing.

Even stranger is when I run the route test, all is good, it shows that the message will be delivered as it should be.

At this point I have 6 messages out of over 15 thousand a day that went MIA at the end of December.  We have not had any other reports of missing data.  I am more and more inclined to say that there was a change in the engine code, but yet I can’t find a change and why did only some of the messages go MIA?  Very strange indeed.

Thus the need to externally audit what I get and what I send.

I am currently working on building a TCL proc that will produce a file with key information if one of the suspect messages is received on the inbound thread.  Then on the outbound thread I will again examine the message for the suspect message type and if found, write to another file (MRN,ACCT,DOS).  Run a diff at the end and the day and if NOT good, I can at least find them before my users do and be able to diagnosis real time instead of a month later.

The perl over SMAT is so I can look at the files produced by the engine and not effect the processing within the engine. (reading every message twice)  Only problem there is that I can write TCL way faster then I can perl.

Jim Kosloskey wrote:

Tony,

I would be intersted to find out if these are TCP/IP connections AND if you are using application level acknowledgment.

If you are not using any acknowledgment protocol, then I find no surprise you might be missing messages. A resend could very well work.

If you are using an acknowledgment protocol, then check the SAMT for the acknowledgments and the foreign system to insure acks were properly processed.

Like Jim Cobane said if they are not in the inbound SMAT, then Cloverleaf did not get them.

Jim Kosloskey

[Tony Benitz]

Richard, sounds like this is what I need, Can you forward me the source file?

Richard Hart wrote:

Tony.

I have a Perl script that parses SMAT files with usage below.

If you can code Perl, this can easily be changed.

Usage: /hci/InfoHEALTH/bin/smatList.sh

[Tony Benitz]

Ya know the same thing happened to me

[Tony Benitz]

Bryan, etal.

[Tony Benitz]

There lays the problem, I don’t if I want to kill the message until I am in the translator.

The message is a result, the Order category is contained with the ORC/OBR pairing, which repeats, the problem is that the single message contains multiple orders.  One order for X and one order for Y.

In the translator, I split apart the message and get a message for X and a message for Y.  I currently have a post xlate filter, BUT the question remains, How to kill in the translator.

I found the suppress will NOT kill the message.

What does suppress really do?

Can you KILL the message in the translator?

Tony

[Author]

Replies