Trying to understand interfaces with Soarian

[Peter Heggie]

I’ve read all the threads which mention Soarian, but I’m still confused. Can someone point me to a diagram showing the major components of Soarian, and describe the interfaces between them and with ancillaries or Cloverleaf?

We are looking at replacing Invision with Soarian, but it seems like there is not a one to one match between Soarian components and Invision components. If we get Soarian Clinicals and Financials, do we still need Invision for registration and (TIF/RTIF) ADT? If so, do we need Cloverleaf to talk to both Invision and Soarian?

Also, am I to understand that connecting Cloverleaf directly to Soarian is problematic, therefore it is better to pay for an instance of Openlink to sit between Cloverleaf and Soarian?

Also, this problem with Last/Not Last, is this only with XML interfaces or all interfaces? Is there more than one type of problem with protocols, or has all the discussion on Clovertech been about (only) the Last/NotLast?

They are coming on site soon to show off Financials and Clinicals, but I’m wondering if they are leaving out the piece dealing with ADT interfaces.

Peter

Peter Heggie

Topic

[Ed Mastascusa]

Hello Peter,

Our IDN recently went live with Soarian on 9/15. We did not purchase openlink, so I can attest to some of the issues encountered receiving HL7 2.X ADT with about 30 downstream systems.  

1) Dynamic Delimiters. This one was my pet peeve. Soarian HL7 has an unusual approach to the implementation of characters that would otherwise be escaped.  In their messages they default to the standard delimiters, but if some of the message data happens to contain a delimiter, they do not encode the data with an escape sequence. Soarian has a list of “dynamic” delimiters and they try to pick delimiters from the list such that the delimiters do not conflict with the data.  So the delimiters will change from message to message depending on the message content.  Cloverleaf can handle this but many of our downstream ADTs weren’t dynamic enough.

To resolve this we wrote a tps proc to identify messages using the dynamic delimiter “feature”, then parse every field, locate the fields with the original standard delimiters, do the appropriate escape sequences, then reassemble the messages using standard delimiters. (I’ll post the proc at some point if anyone wants it)  

The list of delimiters is 16 long, and if you happen to deliberately test to see what happens when all the delimiters are used up, the outbound ADT is unable to send.  I should also add that given the large number of possible delimiter combinations you can’t test your routine with a huge deal of confidence.

2) In many of the “code set” type fields HL7 width conventions were totally ignored. Again, cloverleaf could handle the issue with variant changes but many of the downstream systems had truncation issues. In many cases we ended up mapping the Soarian codes to shorter mnemonics in cloverleaf.

3) This one is more of a business process issue, but our old system was all upper case and soarian allows mixed case. We ended up forcing a number of fields to be upper case in the interface several weeks after go live.

4) There are obviously going to be a lot of business process related issues. we had filter out a number of messages based on “non current” enounter indicators in the PV1:40. The Soarian concept of an “observation” patient being different from the business caused some issues for us.

5) in many of the ID list fields you may find you need to sort or toss out much of the data as lists are sent that include expired matter – we generally did this via tps procs.

feel free to contact me with specific questions

[Peter Heggie]

Thanks Ed and thanks Glen – it was a real eye-opener. The response time of support, especially for the test environment, is also a big concern for us. I can only hope we have less implementation obstacles if we are locally hosted.

Peter

Peter Heggie

[Author]

Replies