Rhapsody site logo

Case studies

Comanche County Memorial Hospital

Learning the product and migrating more than 70 interfaces in 30 days

Migrating to Corepoint Integration Engine was no small decision for the leaders at Comanche County Memorial Hospital, located in Lawton, Oklahoma. Not only was their legacy engine managed and maintained by a third-party vendor, their IT staff had limited experience creating and managing interfaces.

When Informatics Manager Lillian Estep made the decision to install Corepoint Integration Engine, she did not let those obstacles prevent her from making the right long-term decision for the hospital. In fact, after the decision was made, she tasked three members of her IT team to become proficient with the engine – and fully migrate all 76 of the hospital’s interfaces within 30 days.

We spoke to Lance Alston, Adam Switzer, and Kevin Kimbell – the three members of the Comanche IT team tasked with learning the engine and creating the interfaces – about their experiences migrating to Corepoint Integration Engine. Ralph Nehme, a member of Rhapsody® Health Solutions Professional Services team, also participated in the conversation.

What motivated Comanche County Memorial Hospital to change integration engines?

Lance: We were using a third-party company to do all of our interface engine maintenance, builds, and configurations. I believe the hospital saw an opportunity to reduce the monthly expenditures with this third-party vendor.

Adam, Kevin and I were chosen to take on the migration to Corepoint. Aside from cost savings, a strong secondary reason for the change was our desire to move interface maintenance troubleshooting in-house, instead of having to rely on our third-party vendor for that work.

Adam: A technical factor was the age of our old integration engine. We were going to have to upgrade and likely buy new hardware or change vendors. It was time to look at other options from a technical standpoint.

What reservations did your team have about migrating to a new integration engine?

Lance: In the realm of interface builds and implementations of new engines, the three of us that were selected to be on this project had little to no experience. I had some reservation only in the fact that this was a new realm for me. The migration required us to not only learn the engine, but also required us to actually migrate more than 70 interfaces in less than a month.

I never had real reservations regarding Corepoint. Our inexperience and the timeline were our biggest concerns. From the signing of the contract with Rhapsody Health Solutions to engine implementation, it took us one month.

Adam: Correct: we had to get Corepoint Integration Engine up and running from contract to go-live in about one month. It was really accelerated. We were expecting it to take months – plural — and we ended up getting it done in one month. Having Ralph Nehme from the Professional Services team at Rhapsody come on site for a week was really a life saver for us.

Describe how Professional Services helped with software training and the actual conversion?

Ralph: I went to Comanche and conducted a week-long workshop with Lance, Adam, and Kevin. We started by taking the existing workload from their old engine and sending it to the Corepoint engine. We then performed a lot of hands-on work in the engine.

We managed to actually convert 35 to 40 interfaces to Corepoint during the week I was there. Our workshops are very hands on and interactive and designed to allow customers to work on actual interfaces while they are learning the product, which really helps teach the product extremely well.

Lance: I’m going to go out on a limb and say if Ralph from Corepoint had not been here that week we would still likely be trying to decipher the technical debt in the form of code from the old engine.

I can’t say that my interfacing confidence was over the top when Ralph left at the end of the week, but he definitely did a fantastic job of getting us prepared in a five-day period for the work we had to accomplish over the next few weeks.

Adam: Ralph kept the workshop at a level that was easy to absorb and, most importantly, kept it fun. We got a lot done and it took a little bit of the stress off of doing something so new for us, yet vital for our operations. To me, changing over interfaces was a stressful deal. You mess that up and you can mess up some pretty important things. The workshop helped de-stress things a little bit.

And I agree with Lance – I think we would still probably be building interfaces if we did not have that onsite experience.

Kevin: I had the least amount of HL7 knowledge in the group. Ralph was able to put it in a form that I could really understand and actually get a grasp of.

After the workshop, what was it like converting the remaining interfaces on your own?

Lance: We’re now up to around 76 active connections and we converted half of those by ourselves. Having only been through a one-week training course, I’m proud of the success we made in such a limited amount of time.

I feel like this has been about as seamless of a process as any upgrade I’ve been a part of. Anytime anomalies arose, it was easy to resolve in-house or through Support. I feel our team should be proud to accomplish so much in such a small amount of time.

Before, when there was a problem with a connection, what steps did your team have to do to get things running properly?

Lance: Generally, end users created help desk tickets. Application tickets would come to us. Usually during the troubleshooting process, we would learn that the issue wasn’t an application problem, rather a problem with the interface or the interface engine. Adam or I would then reach out to the integration team at the third-party vendor that managed our engine. They would monitor, diagnose, and attempt to correct the problem.

Adam: While our third-party vendor had alerts set up and often were hard at work on the problem, we were left in the dark about what was being done to fix the interface. It was their responsibility, but the problem affected hospital operations. That really illustrates why we wanted to bring engine monitoring and maintenance in-house, so we could actively monitor and correct issues ourselves.

Lance: Now we handle this in house with Corepoint. It has greatly reduced downtime and it has greatly reduced the amount of time it takes to discover the problem and get the issue resolved.

Now that you’ve gained confidence in building interfaces in Corepoint, has the team expanded future connectivity plans?

Lance: Absolutely. We’ve added at least three new project connections since our go live. It makes the project transitions easier for new interface connections because we’re able to do the work ourselves internally, rather than serve as the middle men for vendors or outside consultants. Choosing Corepoint has reshaped and greatly improved our facility’s interface process.

Adam: It allows us to have creative control. So if I’m in a meeting and I overhear someone say, ‘We need this to happen.’ I can now say, ‘I think I might be able to use Corepoint to accomplish that.’

Corepoint has opened my eyes to more creative interface solutions.

How else is Corepoint Integration Engine helping you with your job?

Lance: The user experience of the engine is great when building an interface. Corepoint makes it easy while also keeping it challenging at the same time. There’s less time researching, and more time actually building and testing in the application.

Adam: I find the internal testing tool for Corepoint to be absolutely awesome. Being able to import a day’s worth, or a week’s worth of messages and run them through the Action List tester cuts back on a lot of development time.

After just four months using the engine, how would you grade your ability to use the engine, on a scale of one to five?

Lance: I’m probably at about a four right now, only because I think there’s always room for improvement. I feel like any of our team is more than capable of sitting down and building what the end users are requesting.

Adam: I agree. I’m never going to be 100 percent confident because there’s always something that comes up. But, for the most part, anybody can come to me and ask, “Can you build this?” And I would be able to answer, “Yes, yes I can.”

Additional resources: Steps to successfully replace an outdated interface engine

You might also like

Qventus achieves 10X performance and reduces customer onboarding time by 50%

Case studies

Qventus achieves 10X performance and reduces customer onboarding time by 50%

Qventus, a digital-health technology company, increased security, scalability, and resiliency by replacing legacy open-source integration engine with Rhapsody Integration Engine.

Read more >

Case studies

Amid M&A activity, West Virginia University Health System reduces interface development time by over 50% with Rhapsody

West Virginia University Health System (WVUHS) uses Corepoint Integration Engine, one of the Rhapsody health solutions, to support integration work during organizational growth.

Read more >

Case studies

A national e‑Prescription Service in the Kingdom of Saudi Arabia chooses Rhapsody to speed onboarding of new customers and optimize 3rd-party integrations

Learn how a national e-prescription for the Kingdom of Saudi Arabia deployed Rhapsody Integration Engine in the cloud to speed the onboarding of new data-trading partners, adapt to evolving compliance standards, and meet changing market needs.

Read more >