Radiology is often seen as a separate yet equal component of the healthcare system. The practice of radiology is quite different from what occurs in the typical operating and exam room, and that includes radiology’s demands for health data interoperability.
While radiology owes its existence to cutting-edge healthcare technology, radiology IT departments often are told to “do more with less” personnel and resources in regard to IT infrastructure and integrating and exchanging health data with the referring medical community. Radiology clinics typically only have 1 or 2 dedicated IT staff members who must not only maintain the practice’s multi-million dollar scanners, they also must keep coworkers’ laptops functioning in addition to building and monitoring interfaces to and from the referring medical community.
Doing more with less is exactly what Brian Whittle, interface analyst at Jefferson Radiology has been able to achieve, as you can see in the Q&A below. Jefferson Radiology’s corporate offices are in East Hartford, Conn., with several imaging centers throughout Connecticut and referring and hospital partners throughout the region.
Special thanks to Brian for taking the time out of his busy schedule.
You and your coworkers at Jefferson Radiology are doing some unique things using Corepoint Integration Engine. What projects do you think other radiology groups may be able to put into practice?
A: Right now the coolest thing that we did is use Corepoint Integration Engine to integrate with an EMPI solution called Occam using Web Services. The interesting part of this was that, prior to implementation, we did a lot of testing, we made sure everything worked, and we did everything we possibly could do to break it.
Read how Web Services are used in Corepoint Integration Engine.
I believe that in IT you’ll generally know after a few days or a week whether or not a project or implementation has been successful, and we’ve had no issue to date.
It’s important to note that we converted from using a different integration engine where we were working in Visual Studio. I’m not a programmer, so trying to figure out somebody else’s C-code, compile it, go through the debugging process, deploy into a package, and then deploy that into a bunch of different servers is exceptionally complicated.
I have a degree in electronics engineering with no programming experience other than assembly language. I’m surprised how easy it has been for me to learn Corepoint Integration Engine. I don’t think you have to have a degree, you just need to have an understanding of how things work and you have to be logically oriented.
The engine goes beyond HL7. There are many more capabilities that allow me to sit down with my CTO and explore what other opportunities we can accomplish. It’s amazing what you can do with the right tool, and Corepoint from an integration perspective is just that.
What kind of projects do you have on the horizon?
I’m hopeful that something happens with FHIR. I’ve talked to analysts and developers at a local hospital who are actually implementing their FHIR infrastructure right now.
I’m also going on vacation soon and we’ve got a lot of projects ongoing, including a significant go live. While I’m away, I’m confident those projects will stay on track thanks to Corepoint.
With our prior integration engine, we had to make major arrangements and contingencies for these types of events, and it was crazy. Now I’m easily able to tell the management teams at Jefferson, “I’m going to be out, here’s what you need to do,” and it’s basically just instructions to call Corepoint because your support staff is rock solid.
What types of interfaces/connections do you currently have in production?
We’re a radiology service and IT provider and we integrate our own internal systems and have interfaces with our client hospitals, as well as our referring providers to exchange orders and results.
During the learning process after converting to Corepoint, anytime that I got stuck I would simply call support. To date, despite my attempts, I haven’t been able to stump any customer service representative yet. Corepoint’s position in KLAS and reputation with customer support is obvious. From somebody who’s on the ground using it every day, you’ve always been outstanding.
How are you currently using teleradiology?
Providing the radiologist the ability to read from anywhere is important to Jefferson Radiology and entails several aspects, as you can imagine. For example, if there’s ever an overflow of patients, we can pass reading responsibilities over to our back up provider, who also is a Corepoint customer.
When we identify the need to send overflow exams to a different site, we just change a priority setting in our RIS that generates the HL7 message that sends the order to the different site.
When we send results back, it’s not just going back into our RIS for filing. It’s got into go to our image repository system and, ultimately, into our billing system. It is then delivered to the right hospital. Each of these steps are performed through Corepoint.
Do you have any unique workarounds being solved in Corepoint Integration Engine?
One unique way we’re using the engine happens with one of the sites that is not sending in the name of the doctor on EMR orders because users were taught to identify the physician in a unique way. To solve this problem, I inserted a translation or a correlation in Corepoint to translate the NPI to the Name field and perform an item-correlation lookup. As a result, we don’t have to call anyone at the facility and we get the required information into the record.
Performing that type of workaround in Corepoint is so easy that it’s literally like flipping a switch.
I also want to say the ability to test within Action Lists is phenomenal. If I make my changes in the Test environment, I can export them over to production once they are ready and then load the test message. I can literally run 5,000 messages in production through my Action List before I actually commit those changes. The ability to perform due diligence up front in testing prevents us from paying for problems later.
You can build it, you can test it, and then you can validate it against production.
What about handling feeds from referring hospitals?
We were able to overcome a major challenge with one of our referring hospitals where they could only send the information we needed in a legacy, old-school, custom flat file that was not in any kind of an HL7 or structured format. We were extremely concerned about having to deal with this file but I jumped on the phone with Corepoint’s Customer Support, showed them what the problem was, and we were fairly quickly able to parse the message. That feed is in production today.
We didn’t have to hire a bunch of consultants, we didn’t have to hire a team of people to come in. One individual – an interface analyst – was able to go through that with Corepoint’s help.
What are some of the biggest differences you see in Corepoint when compared to the two previous engines you used previously?
Ease of use and reliability.
With a lot of the other applications you’ll literally see a button that says, “Check This if You Want to Split the OBX Segments.” It’s like when they developed it they looked at it and they built something around an interface. There really is no comparison. Our prior engine is a C-programming tool. If you don’t have a development staff, you’re not doing anything at all, including supporting the product.
The biggest thing for me is that Corepoint really does empower its users. Corepoint is a development tool that ensures all the little features that are necessary for HL7 integration are available and easy to use.
