The following discussion focuses on building and supporting interfaces in Corepoint Integration Engine’s GUI environment, in contrast to UnityPoint Health’s previous engine, which required coding.
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.
Part 1: Operating system considerations and platform performance
Part 2: A more productive team
Part 3: Building and supporting interfaces
Part 4: Impact of an integration engine on patient care
Joe: I would counter that with, do you really want to sit there and write the same lines of code over and over and over and over and over and over? We have 550 interfaces, I could do this all day. I don’t think you want to do that, right?
I’m a coder at heart. I love to code. But, when you write five interfaces, and you have to copy and paste the code from one to the next, that’s not a lot of fun. So, for somebody that says they’re a pure coder and they need that coding to get the job done, the first question that I would ask them is, “Well, what exactly are you trying to accomplish?” And then the second question is, “Well, have you tried to do that with the built in?” Don’t go out and build something just because you want to build it. Something that’s custom or otherwise. Because if you build that and its custom, you’re the one person that knows how it works.
By having a platform that doesn’t rely on that kind of custom coding, but instead has standard actions, you can be guaranteed that every member of your team is going to be able to look at that code and know what’s going on and be able to tell how it works and what it’s doing. And like I said, in three plus years [using Corepoint], we’ve never had a problem that we can’t solve with the standard actions.
So, having it in this way where there’s the functionality of picking actions to meet the need and functions, you’re challenged in a different way. You don’t have to write the code. But, you still have to think logically about how does this go together? How do we solve this problem? Where we’ve just written code before. How do we solve this problem? Well, you pick the actions in the right order and you do it. And it’s much easier. The monotony is not there.
Beyond the Video
- Coding in other engines compared to Corepoint Integration Engine
- Resistance to change, trying new methods
- Evolution of engine capabilities and impact
Describe your prior engine platform experience. It was a modern engine with a gooey interface, and it looks like there’s not much coding. What was your experience in actually building 100s of interfaces in terms of the amount of coding that was actually left to do?
Joe: So, what’s interesting about that is the previous one was running a scripting language. And there was some drag and drop that could be done. Quite frankly, with the drag and drop, it was like auto-mapping fields if you will. So, “X equals X” from one message to the next. It didn’t document very well. Didn’t always get the result you wanted when you used that feature. So you end up having to go in and do a lot of writing your own in the coding space.
And I love writing code, but, it takes time. And each line of code you write, you have to test. With Corepoint, a lot of the functionality that’s built in there allows for more function-based driving. Instead of having to write the code, it’s like you’re plopping in a function and just giving it inputs. Much easier. Much faster.
Dave: Historically, engine coding involved a lot of copy and paste. It was pretty monotonous, involving taking code that may not be 100% tested and pasting it into another spot, rather than being able to leverage it across multiple interfaces one time, write it, and then maintain it there. Those “coder guys” are staring at 10 years of experience on some older engine, you can imagine they’re tilted towards Unix, because to them that means reliability. They’re tilted towards coding because that’s either what they enjoy or that’s all they’ve ever done. How would you expect that team people, used to coding on an older school engine, to get interested in or get excited about an engine that’s “pointy, clicky, draggy, droppy?”
Joe: The reality is you have to ask the question, what business need are you trying to solve? Because ultimately that’s what it should come down to. How can we solve more business problems in a quicker way? I might ask, “Why don’t you still use your flip phone? Why do you have a smart phone?” Because you wanted something new and faster and better and to be able to do things quickly, right? Instead of having to open up your computer to check your email, now you can check it on your phone. Why would you do that? What made you change?
I think I would look at what problem are you trying to solve and ask those questions and maybe try to find analogies that could hit home. I think there are going to be some folks out there who are pure coders and just their ears just shut off when you start talking about anything other than code. But why would you want to go out and write something custom if you can do it click, click, click and be done so you can then move on to something else really fun and interesting?
I just think that the coding aspect of it is really old school and I would try and encourage folks to think outside the box.
Dave: And the box includes things like quality of the interfaces and tying it all the way back to patient satisfaction and patient safety around a higher quality, better tested interface with a team that is doing a faster turnaround on interfaces and has the business and clinical analyst involved as a team member. It means that you end up with something that is of higher value to the organization.
Dave: Similar question. There’s a CIO, there’s a Director of Clinical Applications, there’s an Interface Engine Manager and they say, “You know, we’ve had an engine for a long time. It’s working well enough. We don’t really have a motivation to change.” The similar category of new school flip phone versus smart phone. What would you tell them that would be a motivator to look at another engine given that what they have is working well enough?
Joe: I guess I would ask them, “Are you always satisfied with the way things are or are you constantly looking for ways to make things better?” I mean, an engine is a pretty significant investment, there’s no doubt about that. It’s fairly costly changing from one engine to another, but if you look at the big picture and all the things that we’ve talked about so far, I think that you would be crazy not to be thinking and looking for ways to do things better and faster. Just because you’ve been doing something the same way for the last five years doesn’t mean that’s what it needs to look like the next five years.
Challenge yourself to think, “What could we do better?” Don’t be satisfied until you feel that you’re perfect, and nobody’s perfect so you’re never going to get there, so keep pushing. Keep looking. Keep trying to find out what’s out there and just ask some questions. There’s no harm in asking questions. You might find something that you really like.
Dave: Somebody might say, “Come on, Joe. How could an engine make that much difference?” All engines push messages. How much impact is it really going to have on my world?
Joe: If you look at engines just generally speaking, what is an engine? It’s a transport method. We have great organizations, HL7.org, that said, “This is the standard for healthcare messaging and everybody has generally accepted it.” Well, guess what? The actual transport methodology for HL7 is the same regardless of the engine you use. They all connect the same. They’re all using the same protocols.
Ask yourself, where can we really get the benefits? Can we get the benefits from development? Can we get the benefits from tool sets that provide efficiencies in testing? Can we get the benefits from being able to push X number of messages a day?
Overall, you have to look at the engine as a whole and find where you can gain your efficiencies. Whether it’s freeware or a $5 million system. Nobody cares. The more interesting pieces are around development and how it works during testing and how do you move from test to production. What does that look like? There’s some feature sets built into Corepoint that are much better than other systems that I’ve worked with that allow us to actually test the code as though it’s running on the production engine from our desk. We can test it against the test engine and the production engine without ever leaving the application we’re in. I don’t know of anybody else that does that.
Additional UnityPoint Health Interviews