The following discussion focuses on the impact moving to Corepoint Integration Engine had on the productivity and happiness of the entire integration team at UnityPoint Health.
On a visit to Cedar Rapids, Iowa, Corepoint Health Founder and CTO, Dave Shaver sat down to interview Joe Hamilton, UnityPoint Health’s Technical Team Lead – Interoperability. Their conversation covered a variety of topics ranging from operating system performance, integration engine evolution, the growth and change of the healthcare industry, and ways in which engines and engine teams can impact patient care.
Topic: A more productive team
Topic: Building and supporting interfaces
Topic: Impact of an integration engine on patient care
Interview Highlights
Dave: Compare and contrast or draw out how much of your time you spend focused on the development of the interface compared to all of these other moving pieces?
Joe: When you think about building an interface, whether it’s new or whether it’s a modification of an existing one, there are several things to consider. There’s always analysis, there’s testing that you’re going to do as a developer. The actual development and then support after the fact.
Comparing our old product to our new product, development cycle for a new interface might take actually eight hours of development on the old platform, and probably closer to two to four on Corepoint. It literally was about 50% of the cost to develop on Corepoint versus our old platform. And stuff works. I know that sounds crazy, but Corepoint just works, so the amount of time we spend supporting after the fact is less.
Realistically we’re gaining efficiencies quite a bit, just by having the Corepoint platform, because it allows us to create more in less time without giving up the analysis and the testing and all the things that we would do for every interface anyway.
Dave: As you’ve added more interfaces the last three years, how has that impacted your speed to value and your total cost of ownership over time?
Joe: I’ll liken it to what I like to call work-life balance. The more hours that you work, and especially if it’s monotonous-type work, the less likely you’re going to be a happy person when you get home. There was a time when our staff was averaging 46 to 48 hour a week. And now, everybody’s right around 40.
So, imagine if you will, if you get six to eight more hours with your family every week, with your kids, with whatever. How much better will your life balance be? That can’t be measured in any of the standard measures used by a lot of employers. Happiness is hard to measure. And I can tell you that over the last, I think, 15 months now, we’ve had zero turnover on the team. And we were turning over one to two people every year.
And I would like to think that the move to Corepoint – the ability to not work the extra hours, not have to do monotonous coding – have helped make us a better team and better for the organization as a whole. Now we provide a better product in a shorter amount of time. Thereby, serving the patients that we have.
The number of interfaces we get done in a year and the more projects we’re able to do in a year are certainly reflective of the product. Happy people are also more productive. So, not only are we seeing the benefit of it taking less time to create, but the happiness has created much better, more efficient people.
Beyond the Video
- Involving clinical application team members
- Shorter development cycles
- Higher quality interfaces
Dave: Having been in this industry a long time, an interface developer or an interface programmer may not be exactly the same person as an interface analyst or an integration person. We’ve usually had that interesting two- or three-person team where there’s a business analyst, a clinical analyst, and then an HL7 programmer. Talk about how Corepoint impacts the collaboration between the business analyst, the clinical analyst, and the HL7 programmer. How have those roles shifted or mixed or mingled compared to other engines?
Joe: What we’ve actually considered now that we have Corepoint is that we’re trying to shift that a little bit more to the clinical application folks in that we feel like HL7 can be taught. We can teach them to know what it looks like. With our previous product we had issues when we had multiple people looking at the product at the same time or looking at messages, it actually could potentially bring the engine down. That’s not the case with Corepoint, so what we’re finding is that we’re going to be able to train our application folks to look up their own messages to see when data is crossing and not have to call us. Those application folks are the first people that hear when there’s a problem, even before we do.
Our team of interface folks, they do the development, but they also do the analysis. They’ll sit down with those application analysts and they’ll talk through, “Well, what does this workflow look like? What are you going to do? Are you going to register the patient when you place an order or is it going to do something else before you place the order?” We’re able to translate what that means in terms of, okay, when you do this, this is the message we expect and this is where we need to send it and these are the filters that we need. We get all that information by talking to the business analyst, the clinical folks.
That’s a little bit different at UnityPoint than it is in some places because other places actually have interface analysts and then they have interface developers, where the analysts go out and they get all the filter criteria and then get all the specification criteria, etc. They provide it to the programmers and say, “Here, go.”
I’ll be honest. I don’t think I could function in a world where I was the developer in that model because it would be boring. There wouldn’t be a lot of challenge there. I think the challenge comes being able to see the big picture and by having a product that allows us to develop quickly, that gives us more time to spend with others to get that big picture, thus making it a better overall experience for everybody, I think.
Dave: There’s several points that I think go together there. You hit it right at the end, especially, about a product that allows the developers to spend less time in pure development and that helps with analysis. The tooling inside Corepoint will help you do the analysis better than you could do it on your own, making that all more efficient and at the same time allowing deeper QA.
If we can produce more QA and we can produce a higher quality result in a faster time, and this is the speed-to-value part, it’s the fact that they now can say, “Well, my real customer satisfaction is around helping people solve their problems. I now have time to go out and actually teach them HL7,” as you said. There’s features inside Corepoint that allow users to extend some of that responsibility and empower other users to actually do some of their own diagnostics and their own work on an interface, that in other products isn’t even possible.
Freeing up some of the time, improving the quality, allowing for more testing allows users to ask the analyst more questions and say, “Hey, have you thought of this? You get new filter criteria for these points. I’m finding in the data more points than you gave me. What would you like to do about that? Let’s solve this together.”
Joe: Much like we have multiple projects going at any one time, so do the clinical analysts. When you think about it in that way, if they finished the part where we do the analysis with them and then they have to wait to go to the testing cycle until after we’re done developing, if it takes longer to develop and they might move on to another project. Then we have to wait days or weeks before we get that resource back to test.
By having the shorter cycle, we can say, “Yep, we’re going to work on developing this,” and in fact a lot of our interface folks do some of their development while they’re doing the analysis. Once they get to the end of what they call the analysis phase, they’re almost already for the test phase and so they don’t have to worry about losing that resource and figuring out when they’re going to get it back again to test. That is a big difference from what we used to have, because we’d have to set the code and wait and then we’d have to wait for the resources again.
We might have the coding done, but we would need the resources to test. An interface is never created in a vacuum. We’re a transport mechanism. We move data from point A to point B. We do a little bit of work inside there, sometimes moving stuff around if we need to, but we’re transport – we can’t deliver the package if the package isn’t there.
Dave: By having a faster turn time and a more iterative turn time on the development process, you’re able to keep the analyst engaged right from the start and keep them focused on a given project. To deliver that to an end user, which ultimately means we’re going to turn it over for user testing, that happens faster, which means that both the engine side of the house and the analyst side of the house can move on to the next project together.
Joe: Absolutely.
Additional UnityPo
