DICOM Software & Applications for the Medical Imaging Industry

Laurel Bridge Software, Inc. has decades of experience developing technical software and medical imaging systems in collaboration with engineers from Blair Computing Systems, Inc. (bcsi). In the history of Laurel Bridge, our engineering teams have developed our own DICOM software libraries and adapted other DICOM libraries many times over, and have been involved in some of the earliest development of medical imaging routers, filters and storage systems beginning in the early 1990s.

The DCF software and related tools capitalize on this broad experience, with this early work leading directly to many of the products we offer today. In addition to the medical market, we are experienced with many technical software application areas, including electronic imaging for the printing and publishing industry, real-time and embedded systems, inter-networking, and device control. Over the years, we have worked with a wide variety of clients and partners.

Design and Evolution of the DCF

The DICOM Connectivity Framework (DCF) is the result of a long history of software design and development in the area of medical imaging and networking. In 1998, Laurel Bridge Software (LBS) identified a need in the marketplace for a component-based, object-oriented (OO) implementation of the DICOM protocol suite, although related development began 10 years earlier. Such a programming framework would provide major benefits to medical imaging OEMs seeking to use the latest software development tools and models in the development of software for new modalities and peripheral devices. The result of this market need is the DCF.

Medical imaging has long used an approach of integrating electronic patient information within a digital file consisting of medical images and corresponding patient, study, series and image information, stored typically as a series of “tags.” Upon standardization in 1992, the DICOM standard functioned in this way, with each medical image file containing essentially a database of patient and image data. Software created to manage this information in the earliest years of DICOM took enormous effort to implement, eventually providing an interface where programmers could use software modules to automate the process of searching and retrieving patient data tags and images from within a DICOM file. Engineers from bcsi were involved in early efforts to develop that very sort of software starting in the late 1980s.

Identifying a Rich Feature Set

Beyond DICOM files, the DICOM standard involves protocols for communication, including storage, retrieval, annotating, printing and managing data in a variety of ways. Among the common and well-known tasks that the DICOM standard defines, and which the DCF provides support for, are routing, store-and-forward, and dynamic filtering and modification based on user-defined rules. While these concepts are neither unique nor novel in the area of networking and medical imaging, the ability to easily work with DICOM images and network communications in these ways is a vital need of medical imaging professionals, facilities and device manufacturers. Any successful DICOM software product produced since the early 1990s invariably incorporates capabilities such as routing, forwarding, rules-based dynamic filtering and on-the-fly modification of DICOM data, and it is these well-known needs, and how to streamline their implementation, that formed much of the initial motivation for developing the DCF.

The DCF Today

Today, the DCF is a collection of advanced, object oriented software components implementing the DICOM v3.0 protocol for OEM medical imaging systems. The DCF enables a medical imaging system, which may include printers, scanners, archive devices, workstations, and DVD burners, to communicate with other devices over a network, using the DICOM protocol. Using the DCF, an OEM can provide DICOM connectivity for their application or device with a minimum of effort. Years of effort and experience have resulted in the DCF having an extensive feature set that includes:

  • A robust, portable and high performance implementation of DICOM protocol services.
  • A simple yet powerful API for communicating medical imaging information between the OEM’s code and the DCF, such that detailed knowledge of DICOM is not required.
  • An architecture that includes common services components that can be used as is, or can be easily customized by the OEM to fully integrate the DCF into their own software architecture.

Foundations of DCF

The innovation and elegance of the DCF is revealed through the history of its motivation, development and evolution. Software engineers at LBS sister company Blair Computing Systems, Inc. (bcsi) have been working since 1989 on medical imaging and networking products. As a product development company, Laurel Bridge Software has made continual use of the design and development expertise of bcsi software engineers.

Originally, most DICOM implementations were programmed in C, often as a result of the widely used Mallinckrodt DICOM reference implementation, which was written in C. One such product was Sterling Diagnostic Imaging’s Linx® networking product, originally developed by DuPont Medical Imaging, with bcsi engineers playing an important role in the design and development of Linx since its initial development in 1989. By 1999, Sterling had installed Linx on more than 10,000 nodes worldwide, making it one of the most popular medical networking applications of its time.

Innovations made by bcsi engineers in the 1990s include the development of medical imaging routers, filters and storage systems. One current example of this continued innovation is the Switchboard product, an instance of how bcsi and LBS innovations have evolved since the early 1990s. The Switchboard is an all-in-one solution for routing, filtering, monitoring and conversion of DICOM Datasets, and relies on technology for routing and filtering that was first developed by bcsi engineers starting in 1989. Early Switchboard functionality was released in 2002 as the DICOM Protocol Analyzer, which was later extended to the current Switchboard product, released in 2007.

Switchboard provides the ability to transparently monitor, log, filter, and convert DICOM datasets during DICOM network communications. Designed primarily for network or PACS administrators, developers, field service engineers, migration specialists, or anyone responsible for integrating DICOM devices, the LBS Switchboard facilitates interconnection of otherwise incompatible DICOM devices and rule-based correction of dataset elements in real-time. Among the innovations provided by the Switchboard are correcting and routing of DICOM file to multiple storage service class users, using a rule-based approach to automatically perform modification or replacement of one or more DICOM tags on the fly, and further to provide accurate confirmation of the receive or failure status for a wide range of defined operations.

Object-Oriented DICOM

As object-oriented (OO) approaches to software development gained in popularity in the 1990s, LBS engineers translated their extensive experience by developing in 1998 the first OO implementation of key image-handling portions of DICOM, written in Java. The first fully functional proof-of-concept application using this early OO version of DCF was a Java-based DICOM image viewer called the “Java Litebox”. With this initial implementation, DCF development began in earnest.

Recognizing the need for a robust Software Development Kit (SDK) that would enable developers to quickly implement DICOM applications, LBS recognized that the time was right for a full OO DICOM implementation. In 1999, LBS began simultaneous implementation of two versions of the DCF in C++ and Java, the two most commonly used OO programming languages at the time, relying on CORBA technology and other related state of the art software tools.

For the core of the DCF software, LBS approached Agfa Medical Imaging in 1999 and purchased portions of a DICOM library, which Agfa had acquired through their purchase of Sterling Diagnostic Imaging, which was formerly DuPont Medical Imaging. The core of this DICOM library was originally developed by Polaroid’s medical printer group in 1993. That group at Polaroid was purchased in 1995 by DuPont Medical Products, which was subsequently acquired by Sterling, and then by Agfa.

Design Emphasis on Rapid Development

From its first version, core DCF technology has been designed with software developers in mind, with substantial effort put into defining consistent and robust APIs to facilitate rapid DICOM-enabled application development. LBS’s own Migration Controller product is an example of how a complex medical imaging software solution can be developed using the DCF. The Exodus product, formerly known as the Laurel Bridge Migration Controller, is a highly configurable, intuitive application that provides automated facilities and services that allow migration of DICOM studies, series and SOP instance data from one DICOM 3.0 compatible physical archive to another. Exodus supervises and schedules the transfer, and also provides validation to ensure that a migration is complete and accurate. Migration history is logged and performance statistics are gathered. Various levels of reports are provided to summarize the status and progress of a DICOM migration. Using the DCF, basic migration functionality, such as query, retrieve and move operations, was incorporated in a matter of one or two days, greatly accelerating development of the first commercial version. Enabling rapid development of DICOM-enabled medical imaging applications is a hallmark of the DCF.

The base components of the DCF have the reliability that comes from these years of refinement, testing, and continued development. The design of the DCF benefits from bcsi’s many years of effort in implementing DICOM interfaces for some of the most prominent OEMs in the medical imaging field, beginning with Sterling’s Linx system. The DICOM interface for the Direct Ray® 1.x systems, which Direct Radiography Corporation of Hologic, Inc. purchased from Sterling, uses this codebase as well.

As an example of how LBS benefits from the hands-on development experience that began with Sterling’s Linx system, and which was accumulated on numerous other projects, LBS created Compass (formerly the DICOM Store Gateway). Compass makes use of the routing technology developed over the years for the DCF to function as a gateway interface engine, allowing the user to route, replicate, monitor, and optionally alter DICOM store jobs. Because unrestricted end to end communications are difficult to manage, many facilities use interface engines as central mapping programs; Compass acts in that role for DICOM communications. By using powerful mapping rules, one can easily route DICOM store jobs from point A to point B.

DCF Enters the Marketplace

In 1998, bcsi engineers teamed with Codonics, Inc. to develop a variety of medical imaging and printing devices, with the line of Horizon™ medical printers and Virtua™ medical disc publishers being among the most prominent. As the first version of the DCF was produced in 1999, engineers began to incorporate DICOM support into the Codonics product line. For example, the Virtua makes use of the same technology developed for the LBS Mercury Archive Engine™, which provides the core for a custom OEM medical image archive or PACS. Released in 2007, Mercury is a robust, fully functional DICOM store archive that forms the foundation for a rich set of pluggable, interchangeable modules, which allow an OEM to very rapidly deploy a custom archive that can leverage their existing databases, persistence mechanisms, and look-and-feel.

As the need for enterprise workflow solutions increased, Laurel Bridge Software responded with two applications. In 2013, LBS released Navigator, a multi-source, image fetching and routing solution that provides robust and scalable configuration management, priors fetching and a wide range of other enterprise-scale features. Following the success of Navigator, LBS released Director™, an event-driven workflow manager that enables the user to characterize and automate business processes, define conditions for those processes and describe events that may trigger checks of those conditions.

Other OEMs who have benefited from the dependability and reliability of the DCF and the experience of LBS engineers include ATL, GE, Marconi, Agfa, OEC, Apex Radiology, Cardiac Sciences, the Department of Veterans Affairs, DuPont, DR Systems, Faxitron, Hologic, LORAD, MedQuest Associates, Nighthawk Radiology, Siemens, and Virtual Radiologic, and many others.

The Past Informs the Future

The history of Laurel Bridge Software’s DICOM Connectivity Framework, which began with bcsi engineers developing medical networking applications in the 1980s, through the 1990s with OO design and many innovations such as routing, filtering and monitoring, has culminated with the current DCF in the 2000s. The DCF SDK now provides support for multiple languages and multiple platforms, enabling rapid development of DICOM-enabled applications, devices and networks. Designed from the start to be an object-oriented implementation, it is the only DICOM solution on the market that provides programmers with a consistent API to C++, Java, and Microsoft COM/.Net (C#/C++/.Net), and supports Windows, Linux, Solaris, and other Unix platforms.

Whether an OEM’s needs are for basic DICOM protocol support and programmer APIs, advanced rules-based monitoring, filtering, routing, logging or dataset conversion, or turnkey archive and migration solutions, the DCF product line has a solution. With support for a variety of the most popular platforms and languages, and an ongoing commitment to serving the software needs of the medical imaging community, Laurel Bridge Software will continue to refine the DICOM Connectivity Framework, developing new features and applications, for the foreseeable future.

Key Innovations

In addition to the standard DICOM functionality expected of all medical imaging software libraries, the DCF product line supports a range of critical functionality that supports the needs of software architects, engineers and product developers, including:

  • Robust programmer API for integrating and accessing electronic patient information with an electronic medical image file.
  • Easily integrated with database storage of electronic patient information.
  • Functionality to receive, store, forward, filter, route and modify DICOM medical image files.
  • Receive and process medical images from multiple sources.
  • Inclusion of DICOM medical image viewer on CDs or DVDs of medical image data, as has been commonly done by most medical imaging CD and DVD archiving devices for many years.
  • Incorporate and retrieve user annotations in a DICOM file.
  • Use rules-based logic to modify DICOM tags, or to filter, route or forward DICOM files across a network.
  • Store and forward of DICOM image files from one DICOM storage service class to another, using a rules-based approach.
  • Rules-based approach to modifying DICOM tags as part of a store and forward network connectivity mechanism.
  • Provide standard DICOM router configuration, including port numbers, local application entity titles, server names, internet protocol addresses and other standard configuration options.
  • Support routing rules and replacement rules for DICOM files, and the DICOM tags within the DICOM files, as they are being transmitted across a medical imaging network.
  • Automatic handling and routing of DICOM files in response to processing errors during migration, storing or forwarding of DICOM images, particularly when dealing with the output of older CT and MRI devices.

Chronology

  • 1985 – First medical imaging standard released, precursor to DICOM
  • 1989 – bcsi engineers develop Linx system, developing expertise in medical imaging protocols, routing, filtering and networking

  • 1992 – “DICOM” standard officially released
  • 1994 – Rules-based filtering and routing logic implemented by bcsi engineers for Linx
  • 1997 – Design and specification of DCF software begins
  • 1998 – Java Litebox DICOM Viewer developed by LBS using protoype DCF version
  • 1998 – Development of full DCF product line begins
  • 1999 – LBS purchases DICOM library components from Agfa Medical Imaging

  • 2000 – DCF introduced, integrated into Codonics Horizon printer
  • 2001 – LBS releases version 1.6 of DCF Toolkit, supporting Java and C++
  • 2002 – DICOM Protocol Analyzer product released by LBS
  • 2003 – Hologic integrates LBS’s DCF into Direct Radiography Systems
  • 2004 – Advanced rules-based filtering introduced by LBS in DICOM Protocol Analyzer
  • 2004 – DICOM store gateway prototype product developed
  • 2004 – Automated DICOM migration control software development and testing begun
  • 2005 – LBS announces DCF support for Windows .NET/C#
  • 2005 – Laurel Bridge Migration Controller product released
  • 2006 – LBS attends RSNA for first time, major DCF release announced
  • 2007 – LBS releases Switchboard, Compass, and Mercury Archive Engine products
  • 2008 – DCF improves support for C#, C++ and Java on Windows, Linux, and Solaris
  • 2009 – Variety of new versions and applications released or updated, built on DCF, including PowerTools, Compass, Mercury, Switchboard and Exodus

  • 2010 – Laurel Bridge continues improvements to product line and DCF
  • 2011 – Product line in use by over 60 major clients worldwide
  • 2012 – LBS broadens marketplace reach with numerous updated products and services, including migration and developer kit licensing and DICONDE support
  • 2013 – Navigator enterprise workflow solution released
  • 2014 – Switchboard gets responsive, web-based user interface
  • 2015 – Enterprise Imaging Workflow Solutions popularity increases LBS market share for Navigator, Compass, Switchboard and Exodus products