Ron Hosenfeld and RivRad: Building an Effective Distributed Reading Solution

The road to a distributed reading model is paved with WAN accelerators, DICOM gateways, and sleepless nights, to hear one practice CIO describe it. Nonetheless, three and a half years after he began building a distributed reading solution to support the subspecialty reading model of Columbus, Ohio-based Riverside Radiology, CIO Ron Hosenfeld sleeps better and Riverside Radiology has a robust and reliable information-technology infrastructure to support teleradiology over an expanding geographic area for its 60-plus radiologists. As many radiology practices hope to compete based on the subspecialty reading model, the experience of Riverside Radiology’s Hosenfeld will no doubt prove instructive. Riverside has experienced systematic growth in the past four years. When Hosenfeld, a mechanical/electrical engineer with Air Force satellite communications experience, joined Riverside Radiology in 2004, the practice had 8 to 12 employees and 34 radiologists. Today, there are more than 60 radiologists covering six hospitals and 16 outpatient centers scattered over an area 160 miles in diameter. Last year, the practice read 900,000 studies and employed 150 people. Hosenfeld has four IT staff reporting directly to him and two additional employees who do operations and analysis. “Teleradiology has been a huge focus in relation to our ability to support the subspecialty reading model,” Hosenfeld says. “That’s been a clear driver in our technology as a whole. The greatest challenges we face now are both workflow-related and end-user–support related: the ability to give a remote user the feeling that there is someone there to support them, answer their needs, and keep the small problems as small problems.” Countering Chinese Water Torture Beginning with a Synapse PACS from FUJIFILM, Stamford, CT, Hosenfeld has built a global worklist by taking different feeds from multiple sites and running the studies through an HL7 interface engine both to track and to manipulate data as the are received to create a common worklist. “We do an awful lot of work through our interface engine, taking all of the different feeds from the different sites and creating a common worklist within our PACS and our voice-recognition systems,” Hosenfeld explains. “Workflow is still a constant struggle and ongoing process all the time. We want to make the radiologist as efficient as possible, and while three clicks are not a lot, if you add up three clicks over 150 cases, it starts to detract from their workflow. All of the things that you hear users complain about, we try to focus on, because over time it does make a difference. It’s Chinese water torture related to clicks on the computer.” Hosenfeld’s team created several DICOM gateways that allow the PACS to accept and modify examinations coming from outside centers so that they fit into the practice’s workflow. Integrating voice recognition with the PACS has also yielded happy dividends in a single-screen sign-on for any of the 10 sites from which radiologists read. “That had to be planned for so that it was responding to us, and we were not responding to it,” Hosenfeld notes. Still, Hosenfeld acknowledges that the worklist is not truly universal. “Some of the [information] is controlled by facilities that give us a limited snapshot of it, so we can’t combine that completely with our data because of HIPAA security,” he notes. “We are able, however, to make it seem very transparent, or nearly transparent, to radiologists through some tools that we put in front of that.” Hosenfeld’s team currently is working on writing the software for a dashboard, what he calls a home page for reading, where the radiologists can launch any of the work that they are responsible for, regardless of the source of the work or the location of the radiologist. “Subspecialty reading has been one of the founding principles of our group in that we have fellowship-trained, board-certified radiologists who come to this group specifically to read their area of interest,” Hosenfeld says. "If you’re a neuro MR specialist, you are not going to have a full day of work from a single facility, but if we can consolidate all of the neuro MR from the central Ohio region, we can now keep several specialists busy all day long reading only the cases that are most interesting to them.” Bandwidth Economies One of the early hurdles that Hosenfeld had to clear as the practice followed a rapid growth trajectory was finding enough bandwidth to keep from slowing down the workflow. Ultimately, the quest led to a costly solution: leasing a private fiber network. Hosenfeld moderates that cost, though, by using a WAN accelerator. “That examines the data at a bit level, or a ones-and-zeros level, so that site A will say, ‘I am going to send data pattern 153,’ and site B on the other end says, ‘I already have pattern 153, don’t send it,’ and it just gets inserted on the other side of the WAN connection,” he explains, “so things happen very fast. This makes an acceptable network an outstanding network." Hosenfeld says, “There is an awful lot of dark space in medical imaging—a lot of repeated blank space. Whether it is your MR, my CT, or someone else’s x-ray, there is an awful lot of repeated data at a ones-and-zeros level. What these do is remove all of that repeat traffic from the network and really speed things up moving the large data sets." He adds, “A lot of WAN acceleration in the past has been associated with similar styles: your Word document and my Word document, or my Word document, multiple times. What these devices do is examine it at a much more base level, so it is actually watching the data stream using a mathematical algorithm to memorize those different patterns and notify the other end of a pattern that they share in common. That chunk of data it could have learned from my head CT, but now it wants to send your leg x-ray; that bit pattern gets reinserted on the remote end and never goes across the WAN, in effect." Hosenfeld continues, “The great thing about the devices is they appear completely seamless to the network. You are saving bandwidth, and you are saving cost because you require less bandwidth. It also allows you to do things like backing up more efficiently. We back up data at remote sites and this makes those backups happen much more quickly. That allows us to do that much more often.” No Magic Bullet Scalable may be a buzzword in the PACS world, but it was a key to building a teleradiology solution for Riverside Radiology. “You hear the word scalable a lot,” Hosenfeld agrees. “A lot of times, that is accomplished by throwing more hardware at it. It’s scalable, but the architecture changes as you scale. In a scalable system, the architecture should be identical, from a philosophical standpoint, whether it is 10 studies or 10,000 studies.” Riverside Radiology’s PACS is very Web-focused, and the Web architecture is a linchpin of scalability, Hosenfeld believes. “It needs to behave the same way for 10,000 studies as it does for 10 studies, so that the user’s interaction and our management of it are identical,” he explains. “We don’t change our behavior or techniques based on increased volume; we only adjust the capacity. We don’t go from a 14-passenger van to a city bus. Our vehicle dynamically grows with the more passengers we have, but it’s the same vehicle.” Hosenfeld continues to struggle, however, with the issue of interfacing with existing PACS in the hospitals that Riverside covers. “We have used a solution successfully to migrate from one PACS to another,” Hosenfeld notes. “It was not a perfect process, in my mind, so we are looking at ways to do that in a more real-time way. The migration took a fair amount of upfront work and some time. I would like to implement a solution whereby it happens almost as a matter of operation: a real-time or as-needed migration, rather than an upfront migration.” Riverside is currently evaluating three different solutions to ease the process. Historically, the migration process has involved moving one bucket of data to an existing bucket of data, thereby creating a new bucket of data from which to work. “One of the approaches we are taking right now is that only as we receive a case do we retrieve any associated things and migrate the data, so that it happens as a matter of real-time operations,” he explains. “It’s easier to say than it is to do.” Current challenges notwithstanding, Hosenfeld is confident that Riverside’s IT systems and processes are sufficient to weather any current challenges. “Several years ago, I started a policy: If I lie awake at night thinking about something, the very next day, I put a plan in place so that I don’t lose sleep over that issue again,” he explains. “We are at a mature enough point now that I am very comfortable with our procedures and processes. If someone were to steal one of our buildings, I would be comfortable that I could restore the information that was lost. If a building burned to the ground, we would be OK; we would be OK in those catastrophic cases.”