Jefferson Radiology Q&A
Radiology: teleradiology and EMPI integration
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.
Doing more with less is exactly what Brian Whittle, interface analyst at Jefferson Radiology has been able to achieve. Jefferson Radiology’s corporate offices are in East Hartford, Conn., with several imaging centers throughout Connecticut and referring and hospital partners throughout the region.
The following Q&A was conducted with Brian Whittle, Interface Analyst at Jefferson Radiology.
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?
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.
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.
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 to 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.
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 Health 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.