Interoperability: An Open-source Toolkit

Twitter icon
Facebook icon
LinkedIn icon
e-mail icon
Google icon

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 Leap

If 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