Within radiology, interoperability and sharing information are among our most challenging and important tasks. Not only does the coming wave of adoption of electronic medical record (EMR) technology mean that we need to be able to exchange electronic information with other providers and health-care software systems, but even within our enterprises, we need to connect disparate data sources as a critical part of how we take care of patients. Historically, IT professionals have relied on proprietary software packages to provide health-care software, but a growing movement toward open-source software signifies new options for health-care providers in selecting the best tools to meet our software needs.
Open-source software has been licensed to allow the end user to view and modify its source code; often, the license requires changes in the code to be made available to a group named in the license. It is fairly typical for the software, or at least the source code, to be available without cost. Some might equate open-source software with free software, which can be misleading. Some free software is not open-source software: You can use the software without paying, but you cannot see or alter the source code.
Similarly, there are companies that profit from open-source software, usually by providing support for the software under some type of maintenance package. There are myriad applications available for radiologists that border on the cheap, but they might not be the best choices. Likewise, there are still plenty of vendors committed to giving you the very best solution at the most expensive price.
How the IT department makes software decisions of this magnitude depends on several variables:
- the willingness of management personnel to entrust the bread and butter of the business to open-source alternatives,
- overall budgetary restrictions or cost-saving expediencies, and
- the knowledge of the IT staff.
This final factor is the most crucial, as that staff will be maintaining this infrastructure. Managers need to sleep well, knowing that the IT department has all the bases covered and is willing to care for open-source applications as though they were its own.
Open-source solutions are viable if the five following conditions can be met. First, the institution must have a very knowledgeable IT staff versed not only in health-care software, but also in Linux, MySQL®, and other open-source applications. The IT department’s personnel must be committed open-source advocates who have been trained appropriately and are dedicated to the open-source cause. Only then will they have a vested interest in making open-source solutions work.
Second, a limited budget and a need for enterprise-ready solutions (without the software cost) should be present to inspire the pursuit of open-source solutions. Third, server-class hardware must be in place. Throwing open-source software at shoddy hardware is the worst thing that can happen in a project of this kind. Managers will be quick to blame the software (rather than the hardware) if something fails.
Fourth, a stable backup solution must be in place. Should anything fail, you must be able to restore any lost data/function quickly. Again, it is best not to have managers blaming the software rather than the process. Fifth, plenty of documents, communities, and people must be in place to support the software. All companies are ready to cast blame when things go wrong. If a software supplier is being paid for its services, then it will naturally be first to take the hit. If, however, you are using open-source software and there is no cost for it, then the next person to be blamed is you (since you are drawing the salary).
Making the LeapIf all these conditions have been met completely, a great opportunity exists for your facility to begin using some of the more productive and cost-saving applications on the open-source market (or, at least, to test drive them). There are free alternatives, readily available, that can further the interoperability of disparate image workflows. Our recommendation is to test new products in conjunction with existing applications.
If you see similar performance from the open-source software and the proprietary software, then you can begin the migration process. Of course, not all free software is right for every setting, and being free can stigmatize a product, in the view of many business-minded executives. If, however, you can give your IT staff the necessary leeway and incentives to develop and take ownership of the software, cost savings and performance improvements will become possible.
There is an additional consideration in choosing an open-source application: the stack (the collection of supporting applications on which the principal application runs). Commonly, this stack is composed of an operating system (OS), a Web server, a scripting package, and a database. This can be important because not all open-source applications run on open-source stacks. For example, the LAMP stack, consisting of the Linux OS, the Apache Web server, the MySQL database, and the PHP scripting engine, is all open-source software.
Other open-source projects, however, might use a well-known proprietary OS, Web server, and database, in which case none of these stack components are open source, even if the database can be used free. Paying attention to the stack is important because running an open-source application on a proprietary stack might entail purchasing additional licenses for terminal services, antivirus software, client access, and the server OS, even when the open-source application is free.
Open-source alternatives for the OS include a Linux or BSD variant. Linux and BSD are both free, beating initial proprietary-software costs (with licenses and renewals) while allowing you the freedom to modify the software as needed. No matter what open-source OS you choose, the cost savings are remarkable, and this allows for investment elsewhere (for example, in hardware).
When information is shared among systems in radiology, it usually is in two forms: HL7 and DICOM. In general, HL7 is the standard used for exchanging text information, while the DICOM standard allows the exchange of image data. It follows that a number of open-source products exist to allow the exchange of either HL7 or DICOM information. Myriad options exist that we have used in our institutions; what follows is a sample drawn from these. There are many other solutions that might be equally valuable, and we do not mean to do any disservice to the communities that develop, foster, and use those solutions.
Open-source PACS There are many open-source options for a DICOM-compliant PACS but we will focus on two. These are tools that even organizations with full-blown proprietary PACS might want to adopt, as both products can be very useful in exchanging information among disparate DICOM entities. Two important features that both systems offer are autoforwarding and DICOM header manipulation.
Autoforwarding allows the user to define, in advance, various algorithms for sending DICOM studies to different destinations based on information found in the DICOM header. Many PACS versions lack the ability to perform complicated, rules-based autoforwarding. For example, a radiology department might want to send copies of all CT and MRI studies to a DICOM archive in a cardiology department if the ordering physician is on a list of cardiologists. In a similar vein, outside institutions might want DICOM studies sent to their archives only during off hours, and only based on ordering physician, modality, or other items in the DICOM header.
Similarly, when exchanging information among DICOM archives at different institutions, there often is a need to alter the DICOM header before accepting a foreign study into a PACS. Most PACS software expects the DICOM object to come from a modality within the enterprise and, therefore, to have the correct medical-record number (MRN), study description, and exam number already embedded within it.
Such a PACS cannot handle values that did not come from the in-house order placer. For example, an imaging study done at institution A will have an MRN and a unique exam number that do not exist at institution B. These numbers might require alteration in the DICOM header before the study is imported into the PACS at institution B. While this is the most obvious example, other elements of the DICOM header often need to be cleaned or altered before a PACS will accept a study.
PACSOne Server: This is a DICOM 3.0 compliant PACS application combining a DICOM server, a PACS server using the open-source MySQL database, a Web server using the open-source Apache 2.0 HTTP server, and the PHP scripting engine for the Web-user interface. PacsOne, in the basic edition, is free. It is less complicated than some of the proprietary PACS solutions because it requires only a single server, instead of multiple servers that must be maintained. It also runs on the hardware platform of the institution’s choice, whether that is a workstation, a server with RAID, a blade server, or even a laptop. In addition, it can run on either open-source Linux or a proprietary OS.
ClearCanvas: This company offers open-source PACS, RIS, and workstation/viewer applications. ClearCanvas software, however, runs on a mixed stack of Windows plus an open-source database. Built on an extensible application framework, it is useful not just to radiologists and clinicians, but also to researchers wishing to create new, cutting-edge tools that can be tested easily in a clinical environment. ClearCanvas Workstation is free; as with PACSOne, users can purchase optional support for the software.
An HL7 Interface EngineInterfacing with other clinical systems can be a complex, expensive proposition when multiple parties try to work together. By using an open-source interface engine, one can bring powerful tools in-house to provide interconnectivity.
In addition, the Health Information Technology for Economic and Clinical Health (HITECH) Act requires providers with EMRs to send orders, and to be able to receive results, electronically. At first, the HITECH Act gives health care providers incentives to make these functions available, but within a few years, CMS will reduce payments to providers that cannot meet this need. Most radiology providers, therefore, must either establish what are potentially hundreds of interfaces in the near future or face some very unhappy referring offices.
Mirth: This interface engine runs on an Apache/MySQL/PHP stack that can be hosted on Windows or Linux. In this sense, it can be open-source software from application to stack. Roger Anderson, the HL7 engineer at Scottsdale Medical Imaging in Arizona, notes that Mirth provides a second layer of interoperability to round out the proprietary interface engines both on the radiology side and for the ordering providers’ EMRs.
Anderson reports that Mirth is “a very versatile and stable open-source piece of software that provides a number of functions that many HL7 interface engines don’t. We use it mainly as an HL7 receiving engine at our referring physicians’ offices. It’s simple to install and configure, and it has a wide range of options, such as message transformation, segment substitution, and PDF creation, as well as FTP and SFTP socket support,” he says.
As it is for many open-source software packages, however, finding and using documentation for Mirth can sometimes be challenging, and unpaid support might require the end user to be creative. Anderson says, “While some of the more advanced uses and configurations are somewhat cumbersome, and lack of adequate documentation and examples is apparent, these problems are easily overcome by visiting the user boards,” in addition to employing trial-and-error methods.
PACS ViewersWhile most US PACS users run their viewers on a proprietary OS, in other parts of the world, users (including governments) have pushed to avoid the proprietary OS, and they seek alternative viewers for this reason. Even in the United States, on occasion, referring offices might ask for a viewer that does not require a common proprietary OS. Open-source adopters on the bleeding edge might also look for a completely open-source solution, from stack to viewer. In all of these cases, there are options.
Aeskulap: In companies that have fully embraced the open-source revolution (for example, those that are using Linux on the desktop and running servers on Linux or BSD), some consideration might be given to Aeskulap, a medical image viewer. It can load a series of special images stored in DICOM format for review. In addition, Aeskulap is able to query and fetch DICOM images from archives or PACS over a network. The goal of this software project is to create a fully open-source replacement for commercially available DICOM viewers. Though Aeskulap was designed to run under Linux, versions of it are available for different platforms.
K-PACS: Though its author’s Web page states that for legal reasons, this software should not be used for any medical purposes, K-PACS is a fully functional DICOM viewer. It features a patient level table and thumbnail previews, modifiable annotations, and CD or DVD creation with an internal library. If a DICOM viewer/burner is required to address patients’ requests for images, K-PACS is a full-featured solution.
A DICOM UtilityFor testing and monitoring existing systems, financial justification of the purchase of costly DICOM utility software can be difficult. Fortunately, open-source utilities are available. Before you can even start working on interoperability with DICOM, the ability to connect at a basic level must be confirmed to avoid a complex troubleshooting process for the exchange of information among DICOM nodes.
DICOM PiNG: This is a fast, robust, full-featured, and free DICOM utility used for testing connections among DICOM routers, modalities, and other DICOM-based services. It can be used to determine whether a server is reachable or to test advanced TLS (SSL) connections for servers supporting the secure transmission of images.
Organizations that are committed to open-source solutions will find that open-source software can be quite useful as they seek greater interoperability, both within the organization and across the care continuum. Migration to any of these recommended software packages might not only save on cost, but make your company more robust and nimble in the current turbulent economy, where all cost savings and performance improvements are welcome bonuses.
Kerry Cox, PhD, is CIO, Mountain Medical, Murray, Utah. James T. Whitfill, MD, is CIO, Scottsdale Medical Imaging, Scottsdale, Arizona.