Outpatient Imaging Affiliates featured in Decisions in Imaging Economics
RIS Interfacing: The Happy Handshake
When building customized RIS interfaces, an interface engine is the key to integrating on the enterprise level. Outpatient Imaging Affiliates (OIA), LLC, Franklin, Tenn, prides itself on its ability to take an available database from one of its joint-venture partners and use that database to integrate its outpatient imaging with the larger radiology delivery system. The clienttypically an academic medical institution does not have to spend its own IT resources bringing the outpatient imaging center on board. OIA builds the interface that lets the imaging center operate within the university network. To that end, OIA has determined that an interface engine is a critical component in making the integration happen.
“One of the keys for us in making ourselves attractive,” says Jeff Tumbleson, an independent consultant who handles most of the integration for OIA, “is that we tell the universities their information technology folks will have to do nothing or near nothing. Just give us what you can and we’ll go from there.”
Handling the integration by building its own interfaces is part of the “turnkey” service that OIA provides, according to its president and CEO Frank Kyle. “But there’s no cookie cutter here,” he says. “Our joint venture partners are all at different levels of PACS (picture archiving and communications system) and RIS (radiology information system). We try to take advantage of what their capabilities are, but if they are not competitive and the outpatient center needs to be, we will install our own equipment.”
To facilitate speed and efficiency to stay on top of the outpatient flow, OIA early on determined it needed its own RIS hardware/software array that it would install for each of its partnerships, Tumbleson says. Having chosen a RIS vendor, the challenge then became integrating any partnering university hospital’s data with the OIA RIS at that site. That is where Tumbleson comes in.
“If you go out in the market today and buy any RIS and any PACS, then through HL-7 and DICOM (Digital Imaging and Communications in Medicine) codes you can have RIS and PACS interfaces,” says Tumbleson. The systems will talk to each other or create a handshake. Tumbleson says he determined that the most proficient way to integrate with an academic partner would be to interface the OIA outpatient center RIS with the university hospital’s HIS (hospital information system). From there, the goal would be to make the OIA RIS compatible with the hospital’s PACS and even its voice recognition (VR) radiology report transcription system. This level of integration would allow OIA to perform the scheduling and billing services that are part of its turnkey service package. The processing would take place with as little human intervention as possible.
Interface engines are software systems that help programmers like Tumbleson create code that will get one system (the HIS in this case) to handshake with another (in this case OIA’s RIS), even if there are anomalies in the old system’s coding. When OIA purchased a commercial interface engine, the programming efficiency with which it could create a HIS/RIS interface multiplied severalfold, Tumbleson says. He says the interfaces he does would take much longer without the interface engine there to help build them.
He uses the example of ADT (admit-dischargetransfer) codes that he might receive from the hospital’s HIS. The ADT fields comprise the most essential patient data. They are transmitted digitally in HL-7.
“The HL-7 standard alone gives you a road map of where the information you’re looking for should be. But some hospital’s antiquated systems don’t send HL-7 messages, so they built tools to do that. But it may send the information in different fields. So our interface engine tool kit allows me to put it back into HL-7 the way I want it to be& I can do with an inbound message whatever I need to do. I can take off leading zeroes, I can add leading zeroes&.
“One thing I was able to code for was when the first name and middle initial of the patient were both put in the first name field. Or if I see a full middle name, I can just say left trim one digit and it will trim to the middle initial. I don’t have to go back to the hospital and say, Hey, can you tell everybody to send it this way.’ Just give me what you can and I’ll take care of it.”
Tumbleson says it would have been possible to write some workable interface code without the interface engine, but to integrate OIA’s outpatient center with the larger university radiology network on the enterprise level would have been nearly impossible.
“The two interfaces that I did would have been impossible without the [interface engine] tool kits,” he says. “You can parse through a message, take that information, and put it where you want it, but when you do that on a scale of 50 different ways for each piece of information, that could be 100 lines of programming if you don’t have the tool kits. Even so, they weren’t a walk in the park, but they were certainly easier&. If things change on the hospital side, with the interface engine I can make just one change in the formatting.”
Tumbleson says he has used the interface engine to tie the OIA RIS to a hospital HIS in ways that give OIA much faster processing in patient scheduling and billing.
In the first interface he created, which will be a model for future handshaking, the university hospital staff is able to go through their HIS to schedule an appointment for a patient at the outpatient imaging center on the center’s RIS. The hospital worker can do the scheduling or the order can be placed unscheduled for the imaging center to work out with the patient. In the latter case, what Tumbleson calls an “unscheduled order toss,” the OIA computer will pick the best schedule time based on patient availability, known patient needs such as added time for a claustrophobic patient, and also “modality throughput,” says Tumbleson.
Because the OIA RIS talks with the hospital HIS, no human has to manually enter patient data or perform tasks such as confirming insurance approval. Everything proceeds automatically until the patient arrives.
“First, the ADT information comes across, and then an ORM (order message field) that tells us what we need to schedule. Along with that will be a DFT (detailed financial transaction) field that will show the charges for the services to be rendered,” says Tumbleson.
“The patient comes in, has the study, then it goes from our modality to the hospital PACS for modality worklist management. Then the radiologist dictates the VR report. There is an HL-7 interface to the VR on our RIS, so the completion of the VR transcription creates the ORU (completed report) message, which is a header and segments. One of those segments is the transcribed interpretation. That literally attaches to the examination on the PACS. There are a number of information flows back and forth between our center and the hospital.”
The transcribed report also stays on OIA’s RIS where it automatically drops into what Tumbleson calls a “queue” for OIA’s human coders to go through. The system automatically displays CPT codes that are generated at the modality based on the type of examination performed.
“Based on the transcribed results, the coder assigns the ICD-9 codes according to the diagnosis,” Tumbleson says. From that step the bill is sent to the patient or the insurer.
“This interface with the HIS is the most difficult,” Tumbleson says. “You have to build a series of tables that will relate the information the hospital sends and make it usable to the RIS. They may name the modalities differently so you create a translational table and map those fields accordingly. Anything you can think of in terms of how to manipulate data is done in making that interface work. The tool kit that does it is the interface engine.”
The second interface to the OIA RIS that Tumbleson created is much simpler. It allows a referring physician to call up an examination order form on his or her computer and fill in the fields to initiate a scheduling for the designated examination. The physician cannot schedule the examination because (unlike the hospital partner) the doctor is not privy to OIA’s imaging center schedule.
“You can’t reveal your schedule because then your competitors could see how busy you are,” says Tumbleson.
The electronic order form does not make the process paperless. While a hospital patient might only have to show ID, a patient from an outside referrer has to bring a signed order from the doctor. That paper is then scanned onto the RIS for processing that patient.
Building interfaces, even with the help of an interface engine, is a time-consuming process that involves continual review and revision, says Tumbleson.
“You do a ton of sampling and testing to make sure you’ve captured the gamut of how information can be sent. You look at a thousand messages and say why don’t those 99 work, and you go through and handle each different exception. At some point you need to decide Am I going to code for this or am I going to drop it into an error queue for the humans to take care of?’ Don’t underestimate the amount of testing.”
Tumbleson says he thinks the next big electronic efficiency will come in the form of touch-screen template systems that radiologists can use to produce their reports quickly. “One reason VR works so well in the radiology market is that a lot of it is repetitive.”
But in the near term, interfacing and electronic transmission and configuration will continue to be a sort of unexplored frontier that will present hurdles to programmers, Tumbleson adds.
“Early adopters of technology are going to be blazing a trail,” he says. “You don’t know what you don’t know until it happens.”
George Wiley is a contributing writer for Decisions in Imaging Economics.