Up until recently, the pathology lab at a Midwestern university medical center used an open-source integration engine that was incurring increased moments of unexpected failure.
They had other ongoing issues with their engine on top of downtime. The engine appeared to be nearing its capacity for work it could handle, which resulted in performance degradation. For example, each of their interfaces made numerous database calls, and simply accessing the view of their logic and overall server were slow moving.
With their existing support set to expire, they knew it was time for a change. Determined to implement a more capable interoperability solution, they selected Corepoint Integration Engine and enlisted the help of Corepoint Health’s Professional Services to set up their test and production environments, as well as convert their 100+ connections.
Converting the interfaces to Corepoint Integration Engine was no small feat. They had interfaces connecting to various systems, including Athena, Orchard, and Atlas. Each interface had large amounts of data going to their internal database using stored procedures, and some interfaces used outdated logic that produced questionable outgoing messages.
To ensure everything transitioned nicely to Corepoint Integration Engine and was easier to maintain, our Integration Engineer worked with the customer’s team to update the logic and stored procedures for a number of interfaces.
For example, one of the original interfaces contained 4–5 connections, with ADTs and ORMs coming in through different feeds. In an effort to streamline the workflow and reduce the number of connections, the customer made changes to their database while Corepoint’s Professional Services assisted with the overall architecture and creating the logic.
To achieve this, logic was put in place that stored these types of messages in a database, and Corepoint Integration Engine would check incoming ADTs and ORMs against the stored messages in order to locate the corresponding message, combine the two, and send them out together.
If, after a determined amount of time passed (i.e. one week), there was an unmatched ADT or ORM stored in the database, the team was notified that there was a missing piece of information.
After building the new interfaces on the Corepoint side, our Integration Engineer used test messages to help with the validation process.
“I was able to use the Corepoint test collections and some base runs to pull in the messages they originally ran through their open source engine, and once I built out my logic, I was able to validate that the messages leaving Corepoint matched up with the messages that originally left their previous engine.” — Corepoint Professional Services Engineer
On the customer’s side, there was a big priority around making these interfaces go live with no real noticeable changes—and they achieved just that.
Since going live, they’ve set up alerts in Corepoint Integration Engine for their operations team to manage. And with the assurance there is a reliable, scalable engine in action, they’ve even added more interfaces due to growth.
Click here to learn more about what Corepoint Integration Engine can do for you!
