|Home | About | Journals | Submit | Contact Us | Français|
The question of whether Radiology IT systems should be composed of multiple applications integrated using standard data exchange protocols, such as DICOM and HL7, or implemented using consolidation of applications and systems has been debated for the past 30 years. The adequacy of the former approach has become a burning issue because the demands on Radiology IT systems have increased greatly. We report here on the experience of the Radiology Information Technology (IT) implementation at the Memorial Sloan-Kettering Cancer Center (MSKCC) over the past 11 years; during this time, the weekly image accumulation rate increased from 100,000 to 2,000,000 images. During the implementation period, major difficulties were encountered, largely as a result of the inadequacies of the Radiology IT architecture widely used in the healthcare industry. The approach we chose to correct some of these difficulties has been consolidation of some of the multiple systems and applications. Three examples of systems consolidation are discussed: (1) converting a dual-tier image storage system to a single tier, (2) consolidation of Mammography reading into PACS, and (3) enabling 3D visualization and analysis on the PACS workstation. Nevertheless, substantial research and development are needed in order to proceed with more extensive systems consolidation and, thus, a more manageable IT installation.
The question of whether Radiology IT systems should be composed of multiple applications integrated using standard data exchange protocols, such as DICOM and HL7, or implemented using consolidation of applications and systems has been debated for many years. The adequacy of the former approach has become an acute issue because the demands on Radiology IT systems have increased substantially. We report here on the experience of the Radiology Information Technology (IT) implementation at the Memorial Sloan-Kettering Cancer Center (MSKCC) over the past 11 years, during which the weekly image accumulation rate increased from 100,000 to 2,000,000 images.
The MSKCC Department of Radiology expanded its IT operation significantly with the startup of a Picture Archiving and Communication System (PACS) in December, 1998. This expansion continued during the next 11 years, with the addition of 3D visualization and analysis, addition of dictation with speech recognition, addition of PET/CT reading, separation of the archiving system from the core PACS, two replacements of the RIS, replacement of the system for reading Nuclear Medicine exams, and addition of other smaller Radiology applications. This was accomplished using an IT architecture that has been in widespread use for many years and is still widely deployed. Applications are purchased from different vendors as well as from different divisions of the same vendor. A fully functioning system is then configured with the addition of components for data exchange among applications based on standard data transmission protocols. A common example is data exchange between Hospital Information System (HIS), Radiology Information System (RIS), and PACS [1, 2]. Underlying this approach to the IT architecture is the notion that superior services for users can be provided by selecting best-of-breed applications. Reliability and cost-effectiveness are thought to be ensured by rigorous adherence to standards for data exchange among applications. By this approach, the same architecture is extended to encompass the entire enterprise, with the inclusion of many more applications providing specific clinical services. Data exchange for the enterprise relies on Health Level 7 (HL7) , with one or more interface engines routing data among the ensemble of applications.
The term “applications integration” will be used to refer to this architecture for building an IT implementation. There are several motivations for this architecture. There is a desire to avoid vendor lock-in and the higher associated costs. The opportunity to select the optimal application for a particular service is another motivation. Another important factor is that no vendor in healthcare has achieved the dominance required to offer a complete and smoothly integrated IT solution for Radiology and, by extension, for the entire enterprise.
Optimism regarding this type of architecture has been noted previously “with the expertise and resources to do so, the interfaced approach offers an attractive alternative” . The question addressed here is whether the applications integration approach to IT architecture remains appropriate and cost-effective as more applications are added, the complexity of the implementation increases, and the size of the enterprise grows, or whether an alternative IT architecture should be used by vendors and healthcare institutions.
The most direct way to understand the motivation for the present work is to reach back into the past and read the record of a 1982 panel discussion on PACS . Some of the specific issues brought up in this panel discussion have changed, but the basic principles have not. One illustrative comment was made by Joe Darlak, MD, Louisiana State University: “We need a radical departure to do things in a way that will help the medical profession do a better job: increase the throughput; decrease the cost; and increase the value of the information of that data”. This quotation applies directly to the MSKCC experience 28 years later. Significantly lower Total Cost of Ownership (TCO) is essential. Systems performance must keep pace with demand. A robust and streamlined business continuity solution (including High Availability and Disaster Recovery) must be in place even if the vendor does not support such a feature. Addition of application feature sets must be aligned with the rapid pace of advances in the capabilities of imaging equipment.
Practical experience with a large Radiology IT implementation is one way to examine the adequacy of the component-based approach. For this purpose, some of the key elements of the MSKCC Radiology IT installation are outlined in this section. Radiology IT at MSKCC has been implemented by assembling a set of applications which are designed to supply the various functions required by radiologists, technologists, managers, administrators, and IT support staff for operating the Department of Radiology (Fig. 1).
For the present analysis, an application is viewed as a set of components consisting of the programs implementing a specific feature set, a data repository, and a technology platform on which the application is built. Multiple protocols are used to exchange data among applications.
The principal applications are the Radiology Information System (GE Healthcare RIS-IC V10.5), the Picture Archiving and Communication System (GE Healthcare Centricity PACS V18.104.22.168), and the dictation system with speech recognition (Nuance PowerScribe V4.8). Each of these principal applications may also include multiple component applications. For example, PACS is partitioned into major subsystems, acquired from two divisions of the same vendor. The platform used by one subsystem is Linux and Sybase, while the other subsystems are built on Microsoft Windows and SQL Server.
Departmental workflow is maintained by data exchange among the various applications using HL7, Digital Imaging and Communications in Medicine (DICOM) , Structured Query Language (SQL), and the Common Internet File System (CIFS). Client to server system communication uses Hypertext Markup Language (HTML), SQL, or a proprietary Application Programming Interface (API). The expectation is that the entire system will work as specified, i.e., support a cost-effective and efficient departmental workflow, if messages among applications conform to standards.
The Radiology applications are, in turn, dependent on extensive data exchange with enterprise systems. A message forwarding system (Sun SeeBeyond eGate), including a queuing system to manage data flow interruptions, is used for this data exchange.
A consolidated IT installation, illustrated below, offers several advantages over the applications integration architecture, including: (1) reduced TCO, (2) a simpler IT configuration, (3) a more manageable and robust business continuity solution, and (4) reduction of support requirement, thereby enabling development of processing functions to exploit the capabilities of the new imaging equipment being released by vendors at an unprecedented rapid pace. This last point can be stated in terms of the widely recognized 80/20 problem of support vs. new initiatives.
In this approach to the IT implementation, an attempt is made to consolidate systems and applications, removing data exchange among application silos whenever possible. Compared to the applications integration, the term used for this IT architecture is “applications consolidation”.
With the architecture shown in Fig. 2, the resources of each application development team are allocated to deliver a specific set of functions, thereby adding value, rather than building yet another copy of the IT infrastructure. The most critical part of the infrastructure is the database and associated data stores. Focusing on just this component of applications consolidation, the benefits of such a next-generation IT architecture can be easily defended. Excluding image acquisition equipment, MSKCC Radiology uses 11 distinct database schemata for its IT operation, even though actual need is for only one database schema. And even though the database is a primary component of Radiology IT, it is completely devoid of any standards.
The issue of standards is, of course, by no means new. Following many dissenting and flawed comments regarding standards by vendors (that are repeated to this day), Jason Zielonka, MD, Massachusetts General Hospital, made a compelling case for standards during the previously referenced 1982 panel discussion on PACS . The following remark was made in 1991: “To a large extent, the problem rests on the fact that there are no PACS database standards (data schema, manipulation language, etc.)” . Twelve years later, system architects were still looking for a solution “…it is the database content that remains valuable and should be defined using a well-structured approach to a controlled medical vocabulary…” .
There are some very critical reasons to build a Radiology backend infrastructure around a single database instance. First among them is the need for data transaction integrity, a fundamental capability that has been refined over many years. Furthermore, databases as stores of data have added many new features during the past few years that no other method for storing data can approach. Some of the more important advances include addition of a hierarchical organization using embedded Extensible Markup Language (XML)  as well as the traditional relational organization, extremely capable data migration tools, much enhanced functionality for incorporating binary data structures, database design tooling that facilitates the transition from conceptual modeling to physical implementation, much improved decoupling of procedural coding from physical database implementations, middleware to link Web clients to databases, and database mirroring for business continuity.
Yet all standards efforts have been devoted to data exchange protocols, and not at all to the component that is central to the smooth functioning of the workload for a Radiology IT operation, i.e., the database. And of course applications consolidation is highly dependent on a standard for the data store.
A second beneficial advance is a common technology platform for all applications. Tasks that can be performed in minutes when working within a single technology platform can stretch into days or months when dealing with interoperability between two distinct technology platforms. In some cases, it is simply impossible to perform a particular task, or resolve a particular problem, when two technologies must interact. The most obvious example of this very expensive platform issue is an enterprise whose IT infrastructure is built on Microsoft Windows, one vendor division delivers a major application built on Linux, and a second vendor division delivers another major application built on Microsoft Windows. It is an exceptionally costly configuration for the customer. And this problem was recognized many years ago; Joe Smith, for example, stated in 1982: “I think that people tend to pick at standards on the basis of little issues, but it is much better to all speak the same language and then go to a whole major improvement rather than to make tiny tiny little improvements which prevent everybody from talking to each other and make the whole business more complicated” .
The best solution for the problems resulting from the IT architecture illustrated in Fig. 1 is a full consolidation of the entire application stack, including application functions, data repository, and technology platform. Primary candidates are RIS, PACS, and the dictation system.
Implementing such a large consolidation, although highly desirable, is a difficult long-term project. At MSKCC, the direction of development has therefore been to gradually work toward this goal by consolidating specific subsystems of the IT installation.
The following sections outline some of the architectural adjustments using systems consolidation that have been made at MSKCC.
Figure 3 illustrates an example of the integration of two applications into a single application.
The principal function of the PACS archive for access to prior studies was merged into a single application for image management and storage. The image online storage system was replaced and expanded with a storage system with a capacity for all images acquired since startup of PACS in December, 1998. This was followed by a 9-month image migration project to move all images to the online storage system. Data replication to a remote data center was added at the same time for business continuity. All images are also written out to LTO tape for Disaster Recovery. Starting in September 2007, no images have been recalled from the PACS archive.
Several benefits of this consolidation project can be cited. Seven archive libraries have been removed and the remaining two units are scheduled for removal. A complex image prefetching subsystem has been decommissioned. An elaborate subsystem for removing online exams to free space for new exams has also been decommissioned. User complaints about unreasonably long access times to prior studies have been completely eliminated. It is a particularly welcome systems improvement for a cancer center where almost all exams read by radiologists require comparison to one or more prior studies.
A notable challenge of the implementation was data migration. Scripts were written in-house to complete the migration within a reasonable time period. Inadequate performance of the image management server required periodic configuration enhancements. Continuous, round-the-clock monitoring of data movement was essential for prompt recovery from errors.
An important effort at MSCC has been to enable reading of all imaging modalities on PACS. This now includes reading Mammography exams using a Mammography module that is fully integrated into the PACS workstation application (GE Healthcare Centricity PACS V22.214.171.124 client) as shown in Fig. 4.
Benefits of this consolidation are that prior exams are directly accessible from online storage. MRI breast exams and breast Ultrasound can be read on the same workstations, and an application for kinetic analysis of MRI breast exams has been added. A second workstation with a reading application different from the PACS application was eliminated, and the effort by technologists to route current and prior exams to workstations has been discontinued.
There was a collaboration with the vendor to make sure that features of the stand-alone mammography workstations application were also made available on PACS. Not surprisingly, some effort was required to assist radiologists in making the transition from an application they had been using for many years to the corresponding implementation on PACS.
Figure 5 illustrates how partial consolidation of applications was achieved by including the 3D visualization application on the PACS workstation (GE Healthcare, Advantage Workstation Suite).
The 3D application can be launched on the PACS workstation with sharing of patient, examination, and image series context. Images are read once into the workstation and shared in memory by both applications. The capability for reading exams generated by seven PET/CT scanners is included as well, eliminating the requirement for additional workstations dedicated for each PET/CT scanner model. Moreover, reading of PET/CT is no longer confined to locations with specialized workstations. In addition, radiologists have direct access to comparison studies acquired on other modalities. Reduced space utilization is also a consideration, particularly in our Manhattan locations, where space is very costly.
The platform for the 3D application is Linux, while the PACS application platform is Windows; this difference resulted in a complex consolidation implementation. Communication between applications is vendor proprietary. A more standards-based approach, as currently being considered by DICOM Working Group 23, was not an option. For these reasons, one staff member was trained to provide expert technical support.
The examples given in the previous sections demonstrate that consolidation of systems components is possible in order to improve the usability of Radiology IT systems. However, far more extensive changes in the IT architecture are essential. A current project is to merge the dictation system into RIS as shown in Fig. 6 (GE Healthcare RIS-IC V10.7, Precision Reporting):
A collaboration with the vendor is in progress to ensure a seamless transition from our current reporting system to the new system.
A project for a merger of Nuclear Medicine reading into the PACS workstation has been initiated. However, a highly desirable consolidation of RIS and PACS remains elusive.
The previous sections outline specific IT consolidation projects that have been implemented, and the benefits derived from such a consolidation are enumerated. Nevertheless, considerable additional effort is required.
At MSKCC, the image accumulation rate has grown as shown in Fig. 7.
Growth of image volume has triggered two major difficulties. One is the time lag until performance enhancements are made across all Radiology systems. Vendor and customer resources required to provide a reasonable level of service for users are exceptionally high when IT systems reach, and even exceed, their performance limit.
Image volume growth has particularly negative consequences at a cancer center, where nearly all exams are read with reference to one or more prior exams. In fact, it can be stated that without image storage consolidation, MSKCC would not have a functioning PACS implementation today, given the image volume growth since 2005, when problems with the prior implementation first appeared.
Compounding the problem of application silos is that large enterprises build their own IT infrastructure with the expectation that the applications delivered by vendors will be compatible with the choices the enterprise has made. It is a largely unexplored area, with products being delivered by vendors that at times fail to interoperate with even the most basic technologies that every large enterprise demands for a workable IT environment. Examples are Domain Name System (DNS), Dynamic Host Configuration Protocol (DHCP), Windows domains, Active Directory (AD), etc. A very definitive trend at MSKCC is the expectation that vendors conform to the IT infrastructure already in place, and not deliver incompatible technology that imposes an unacceptable burden on support staff.
The workflow as shown in Fig. 8 requires exchange of data among applications, an essential component of the IT installation that is associated with very high cost.
Each data interface is accompanied by a capital acquisition, expensive professional services during installation, a line item on a service contract, and a surprisingly high demand for customer resources to identify and correct data exchange failures among applications. The MSKCC experience is that repair of an interface design flaw may take as long as 1 year. And, since each application is built independently, complete transmission of clinically important data may not be possible if one or more of the applications severely constrains the amount of data that can be received and forwarded to the next application.
Business continuity is an essential component of a large imaging enterprise, including High Availability as components fail and Disaster Recovery following a major event such as a power failure, degraded network services, data loss, Denial of Service attack, etc. MSKCC has adopted a solution whereby Radiology IT services can be provided by either of two geographically separated data centers. Ongoing services are provided by the primary data center, with failover to the second data center if operations of the primary data center are unrecoverable within a reasonable time period.
Based on the MSKCC experience, providing services for business continuity is considered the most important motivation in reexamining the architecture of the Radiology IT installation. TCO is unacceptable because MSKCC must operate five business continuity solutions, each using a unique technology depending on the application: PACS, RIS, diagnostic reporting, Nuclear Medicine mini-PACS, and image storage services. Periodic failover testing has shown that for some systems the failover procedures are very complex, in particular for systems that were not designed to accommodate failover to a remote data center. PACS, RIS, and diagnostic reporting are obvious candidates for a single business continuity solution with an efficient failover procedure, resulting in substantial reduction of TCO.
While the positive aspects of application and systems consolidation have been emphasized in previous sections using three MSKCC consolidation projects, any development that transforms Radiology IT toward a future architecture must take into account and find solutions for some predictable potential problems. For example, data consolidation raises three key issues: (1) demanding too much information, (2) no effective versioning strategy, and (3) no support for system-level extension .
Operating systems is another key obstacle. The IT industry has the choice of making the very large investment for Windows/Linux interoperability or a simply deciding that a particular installation will use only one of these two platforms. This conclusion is simply the result of repeatedly observing that specific desired functionality works well when implemented within one technology platform, but cannot be made to work at all when interoperability between two different technology platforms is required. And this conclusion applies even if highly skilled engineers tackle interoperability failures.
The most significant benefit for Radiology IT can be achieved by a consolidation of the RIS and PACS applications. The RIS and PACS databases contain a substantial number of data instances that are identical, resulting in wasteful duplication of data sets. Departmental workflow is less than ideal, since the progression from order entry to report delivery must cross the boundary between RIS and PACS. It is worth mentioning that awareness of this problem should not be surprising. The initial implementation of MSKCC PACS, first conceived in the early 1990s, included basic RIS functionality.
Additional insight can be gained by examining the work started by the early visionaries designing PACS [7, 12] and later expanded upon by others [13, 14]. Radiology IT will never solve the 80% (support)/20% (new initiatives) problem until RIS and PACS are merged into one application. This opinion is not meant to ignore the fact that consolidation of databases with radically different schemata as incorporated in RIS and PACS may present engineers with an intractable problem at the present time.
There are alternatives to the approach taken at MSKCC, for example, a Grid-Based model  leaves the heterogeneous back-end organization intact, while presenting a single data interface for applications. However, researchers involved in such work are cautioned that the problems with the present Radiology IT architecture run far deeper than can possibly be outlined in a single paper. To mention a few of these issues, environments with multiple RIS and PACS  installations add complexity, radiologists demand more extensive and relevant information about patients during interpretation , and sharing PACS among disparate institutions .
Another option is a Service-Oriented Architecture (SOA). Full scale conversion to SOA requires a major rebuilding of the IT infrastructure. Nevertheless, selected services should be considered. For example, communication of information to radiologists during a reading session such as reason for study, clinical history, and allergies is a good candidate for an enterprise service. Such an implementation avoids a data truncation problem as information is passed through multiple systems prior to presentation in the radiologist’s reading application. Already implemented at MSKCC is a service to deliver images for viewing while a clinician is accessing patient information in the Electronic Medical Record (EMR). It is not a true SOA configuration, but it is implemented as a service provided by Radiology IT for integration with the EMR.
Practical experience with a large and growing imaging enterprise (Fig. 7) has shown that a widely deployed Radiology IT architecture (Fig. 1) using applications integration is not sustainable. Consolidation of technology platforms, data repositories, and applications is essential for lowering TCO. Manageable and robust business continuity is highlighted as a very difficult implementation problem within the confines of the most commonly used Radiology IT architecture. Resources currently allocated mostly for maintenance and support must be shifted toward adding such critical functions as business continuity and adding features required by ever more sophisticated imaging equipment being installed in Radiology.
At MSKCC, limited progress toward a viable IT implementation using an architecture based on applications consolidation has been demonstrated. But it should be highlighted that in some instances the effort was not driven by achieving incremental enhancements, but more by a concern that the entire system will fail, and systems recovery will be unacceptably long. And such events have happened to a varying degree at MSKCC prior to some of the consolidation and business continuity installations. Nevertheless, substantial research and development effort remains to design and implement a cost-effective and usable Radiology IT architecture. One purpose of this report is to stimulate research on the transition toward a next generation IT architecture.
The author acknowledges the significant contributions of Kate Lynch, MBA, to the implementation of the Radiology IT installation, and the substantial efforts of Nabila Sobhy, MS, in implementing the many data interfaces among applications.