When I say connect message, a mocked up dummy HL7 connect message is sent by BizTalk across the interface.
In my specific case this was an allergy interface that sends ADT^A60 messages to cloverleaf where the word “CONNECT” was placed in MSH-10 which I look for and filter out those messages preroute.
My story to share about BizTalk was the people that had access to the BizTalk piece of the integration kept telling me it was designed as a web service interface tool and not a real-time persistant tool.
In any event they only new how to use it for web services integrations thus my work around.
The integration engineer was literally told he had to use BizTalk and pretty much hated it.
At least I assumed he hated it when he told me he would rather write the interface from scratch than have to use it.
Ironically I worked with one of their team members years ago who wrote a TCP/IP real-time interface from scratch for DMS and they had that in their back pocket to drop in place.
I was told the consulting group had a conflict of interset causing a bias towards the less suitable BizTalk solution.
I suggested if BizTalk was being chosen for the business rules then use it for that and use something better for the interface data movement.
The group this mandate was coming from was used to web services and had little or no experience with what a real-time persistant interface was.
For a while they thought I was making things up when I told them what a real-time persistant interface was because they had never heard of such a thing; I’m not kidding.
I’m not certain but the HL7 standard might specify that an interface be persistant and when I hented at that as a standard and that it was definetly a hospital wide standard by adoption that seemed to help satisfy them to put the effort into a real-time persistant solution even though they still wondered if I was making this stuff up.
They didn’t even want to use cloverleaf and do most everything point to point but were unable to get BizTalk to do a real-time persistant interface to any commercial down stream systems like Cerner or Centricity.
They knew I did this all the time and as a last resort used me to figure out a way to make it work.
I observed after getting them around this one they have used my work around and gone back to their point to point practices.
It is ashamed they wish to be another silo within the enterprise but we have so much more integration work flowing in than we have people to satisfy the demands.
By the way, I found using hcitcptest at the command prompt to be very helpful to test the various message senarious that BizTalk had to be jury rigged to do such as:
– resend message if no ACK received in time out period
– send email/pages when NAK occurs
– cycle BizTalk interface and have it connect when message are queued
– cycle BizTalk interface and have it connect when no messages are queued
– cycle cloverleaf side of the interface when BizTalk had no messages queued and have it connect
The guys I worked with seemed to have difficulty at first getting BizTalk to use a single dedicated port.
I tried multi-server to help see if my suspicion about web services behavior was correct and that partly functioned but they worked with me to overcome until we got the normal one port dedicated server working.
My co-worker Jim Kosloskey shared with me that other hospitals have been dissapointed with BizTalk and knew of at least one that tossed it in the trash can.
I have not had direct hands on usage with BizTalk, but would proably cringe at the thought of doing another BizTalk interface.