LHP Hospital Group Q&A
Deliver vital patient data to the bedside using Corepoint Integration Engine
”In terms of differences between HIS systems, each have their unique characteristics and tools, but in the grand scheme of things they’re all the same— they’re going to push and receive data. ”
Greg Plank, Manager, Integration Services
LHP Hospital Group oversees the operations of five hospitals in Idaho, Florida, Texas, and New Jersey. LHP has three analysts who are responsible for all 305 interfaces in production, linking their four hospitals using McKesson Paragon and one hospital using MEDHOST’s HMS.
Topics: Hospital Integration, Health System, McKesson Paragon, Action Points, Medhost, Workflow Architecture
The following Q&A was conducted with Greg Plank, Manager, Integration services at LHP Hospital Group.
Since your hospitals use two different EHRs (Paragon and MEDHOST), do you see any technical differences from a health data integration and interoperability perspective?
Not at all. Each system has applications and they all have interfaces that run in and out of Corepoint. I don’t see the size difference of the hospital having much difference in terms of interfacing performance. Both EHR vendors obviously want us to create point-to-point interfaces so they can charge us for every connection and modification.
We are in the process of installing Corepoint at Mountainside right now. They didn’t have an engine previously, so they dealt with the EHR-built interfaces. They had to go back to the vendor every time they needed a new integration with an application.
We’re now dealing with their vendor and have informed them that we are implementing Corepoint Integration Engine and that we need generic interface feeds for all event types. All records. Whether it’s a lab result, a lab order, radiology order, ADT, physician update—all of it. They were hesitant at first because they read the writing on the wall. They know what’s going on, but we insisted upon the feeds. Of course they’re going to charge us a little more for those feeds because they know we’re not going to be coming back to them as much for future integration needs.
In terms of differences between HIS systems, each have their unique characteristics and tools, but in the grand scheme of things they’re all the same— they’re going to push and receive data.
You have previous experience using Cloverleaf. What do you think is different about using Corepoint Integration Engine? And, how different would your data workflow look like if Cloverleaf was in place at LHP?
It’s been over three years since I used Cloverleaf, but the versions I worked with were not easy to develop with. You had to know TCL, and be able to develop using TCL scripts to do a lot of the things that Corepoint can do within its application.
TCL is not easy to learn and it’s not easy to develop with. TCL was required for many things that I wanted to do for a customer.
Corepoint is so much simpler to use. It’s more intuitive and I can get things done a lot quicker. I can set up an interface in less than 10 minutes with connectivity.
Cloverleaf is not that simple. Users are restricted by character limitations in the connection names, by a limited number of threads in a process, number of processes in a site… things like that restrict you during development. It also makes it harder to support, especially if there is a problem and things crash and burn. I haven’t experienced anything like that with Corepoint Integration Engine.
When I first started with LHP, we had purchased a new site shortly after I started and I was able to develop all of the interfaces for that particular site, on my own, in a very short period of time. That site had close to 70 interfaces. I did all the development for it in Corepoint without assistance and had everything complete within four months. That would not have been possible with Cloverleaf.
What kind of unique workflow projects have you accomplished in Corepoint Integration Engine?
I think the coolest feature was implemented just a few weeks ago. We utilized Action Points to create paging logic that alerts caregivers via pager with patient information that is on their specific floor of the hospital.
We have two connections that we monitor for specific information. Depending upon the qualifications (being a nurse unit or a medication that was ordered) we use some logic within an Action List to create a message to send to a pager. We utilize Action Points to create a pager message through an Annotation set doing a dynamic lookup for the specific pager that is utilized on a specific floor of the hospital. When triggered, the engine sends a message with that text to that pager, letting the respiratory therapist know what room the patient is in and what medication or procedure was ordered. This eliminated the delay that was experienced in treating patients by notifying the respiratory therapists as soon as Corepoint received an order from Paragon.
You’re extracting specific data from the EHR record and you’re sending it to the caregiver who is on the same floor treating the patient?
That’s correct. This was identified as a need just two weeks prior to an EHR go live. I was able to come up with the limited scope and within two weeks we had it paging the ED department. They were so thrilled with the results that they wanted to send data to every floor in the hospital for the respiratory therapists. What other feedback did you receive from the caregiving team? It’s funny, when it was first implemented, they claimed it wasn’t working. I could see that the engine was sending things out—once I got them to finally realize that their pager needed a new battery the information was extremely helpful. Since then, we’ve implemented the process on six additional floors over the past month.
I keep telling them to let me know who’s next, so we can push it out to the rest of the team.
This has been so successful, we have had a request from our other hospitals to implement the same process for their respiratory techs. We hope to do so in the near future.