Use this evaluation process and criteria to select the appropriate software development kit for your needs.

June 17, 2015

11 Min Read
The DICOM Landscape: Selecting the Right Software Development Kit

Andrew Dallas

When projects require interfacing with Digital Imaging and Communications in Medicine (DICOM) data, development teams have a fairly broad set of software development kits (SDKs) from which to choose. Selecting a DICOM SDK represents a substantial commitment by the team in terms of initial adoption, implementation, and ultimately maintenance. These activities are costly, and if the most appropriate toolkit is not selected, the result likely means significant additional work, rework, or worse—serious system limitations.

This article details a process and criteria for evaluating DICOM SDKs and provides example toolkit evaluations.

Evaluation Process and Criteria

To choose the appropriate SDK, begin by identifying the requirements. This article covers only the common requirements that might apply to any development team seeking a toolkit.

The next step is to narrow the initial list of SDKs. There are dozens of DICOM SDKs available, and because it takes time to perform each evaluation, begin by narrowing the choices to those that meet your absolute musts. For example, you might eliminate any SDKs that have many complaints. Available SDKs include both open-source (DCMTK and GDCM) and commercial products (LEADTOOLS and Accusoft). One resource you can turn to for help in assessing the open source SDKs is Open Hub. Open Hub describes itself as “an online community and public directory of free and open-source software (FOSS) offering analytics and search services for discovering, evaluating, tracking, and comparing open-source code and projects.” See “Commercial or Open-Source DICOM Software Development Kit” for a discussion of those considerations.

Source Code Availability

The ability to access and modify the source code itself may be highly desirable to you. Some SDK vendors may make changes for you for a fee or allow you access to the code through a legal arrangement that may or may not involve a fee. The ability to access and modify the source code is beneficial for a few reasons. Sometimes providers lack the resources to make changes at the time you need them. It’s also not unusual for a vendor to go out of business, leaving you with no access to the underlying code base after you have invested thousands of hours in training and implementation. An option to protect against a vendor going out of business would be to have the source code held in escrow, but introducing legal negotiations is not a particularly appealing avenue. In addition, for regulatory traceability purposes, you may want to retain a snapshot of the code. These criteria favor an open-source solution.

Code Quality and Ease of Implementation

DICOM: Historical Context

The first CT Scan was performed October 1, 1971, at Atkinson Morley's Hospital, in London. Sharing data between physicians soon became difficult because each manufacturer stored the CT data in a different format.

In 1983, the American College of Radiology (ACR) and the National Electrical Manufacturers Association (NEMA) jointly developed the first CT scanning standard, named ACR/NEMA 300, which was published in 1985. Subsequent improvements have led to the current DICOM standard. http://medical.nema.org/standard.html.

As the standard was implemented by vendors, coordination and validation of its use became difficult because there was no official organization with the resources to do so. The “standard” was no longer universal but again was dependent on a vendor’s own version of it.

In general, the software industry became more aware of this problem of “vendor lock in” (i.e., reliance on a closed system provided by a single vendor), and the idea of open-source software started as a response.

One of the first open-source implementations of the DICOM standard was created at
Washington University’s Mallinckrodt Institute of Radiology under the name of “The Central Test Node” (CTN

This implementation was based on the 1994 paper:

Moore, S.M., Hoffman, S.A., Beecher, D.E., "DICOM Shareware: A Public Implementation of the DICOM Standard," in Medical Imaging 1994-PACS: Design and Evaluation, R. Gilbert Jost, Editor, Proc SPIE 2165, pp. 772-781 (1994).

Some commercial vendors and open-source toolkits may still base their code on this early implementation. If you search the source code for a toolkit, you may find the RSNA and Washington University copyright notice referenced.

You may also want to be sure the code is not unnecessarily difficult to obtain, understand, and compile. If this is the case, take the time to delve into a limited code review. A typical code review might include analysis for specific types of errors and a review of the error handling in the SDKs.

Development Environments and Compatibility

For the final target platform, decide if you want the resulting software to run on either Windows or Linux or both. You might also be looking for portability in the event of a possible future platform migration, so a platform-agnostic solution would be preferred.

If you are planning to do volumetric and planar image algorithm development, choose a toolkit that allows you to interact with the open-source Visualization Toolkit (VTK) and VTK file formats, and to make use of C++ VTK libraries to read and write those formats. Several commercial toolkits provide planar and volumetric image manipulation that can be used instead of VTK. However, if your product is going to benefit from working within the VTK and/or Insight Segmentation and Registration Toolkit (ITK) ecosystem, this factor may be a deciding one. As an aside, if you are planning to work with planar or volumetric images and haven’t started working with VTK and ITK, give them a look. They are powerful toolkits used by several industry leaders.

Performance

If you need the ability to quickly read very large DICOM studies (thousands of files) and generate a large file consisting of 3-D volume information, performance for reading both the metadata (to build the list of images in a series) and the image data must be very high, which you can evaluate by using large studies in an automated test harness.

Documentation

You should also look for sufficient documentation with the necessary depth for completing complex tasks, primarily to support future enhancements that might not be made by your team. Documentation should also accurately reflect the SDK, be reasonably complete, and not be out of date.

Price

While upfront and ongoing maintenance costs are a consideration, you should also be conscious not to focus exclusively on them. A free product that is awkward to use may well cost more due to development costs.

Toolkit Evaluations

Here is a summary evaluation of four popular DICOM SDKs, generated by using the process described in this article.

DICOM Toolkit (DCMTK)

DCMTK is an open-source DICOM toolkit developed and supported by the OFFIS Computer Science Institute. The toolkit has had a long history, beginning with its origins in the European Central Test Node (CTN) in 1993 through the first DCMTK release in 1996.

Open Hub statistics about DCMTK include the following:

  • Mostly written in C++.

  • High ratio of comment to code lines, an indication it’s well commented.

  • Over 500,000 lines of code.

  • Maintained by an average size development team relative to other open source code projects. The source code commits have been from 12 developers.

  • Represents 127 years of effort (using the COCOMO model).

  • Code Quality and Ease of Implementation

The code is exemplary. It is well commented and easy to read, and error handling seems well implemented. The code can be obtained directly from its Git repository using a labeled branch.

Development Environments and Compatibility

The code is mostly C++. However, DCMTK is somewhat limited in its support for other languages. While the code can be compiled on most platforms via the Cmake tool, if other languages such as C# or Java are a high priority, you will likely have to write interface code yourself, which can be a fairly large task.

Performance

The DCMTK compiled on Windows using the Visual Studio 2012 compiler without any problems, and the performance was more than adequate. Because you compile it yourself, you are free to try different compiler and tool chains to further increase performance if needed.

Compatibility

DCMTK was the only SDK that worked with every DICOM study used as part of this evaluation.

Documentation

The code is very well documented, and the online documentation (provided through doxygen) is consistent with the source.

Grassroots DICOM (GDCM)

GDCM development started in 2005 to specifically fill the need for a DICOM library that could be “wrapped” in Python and other scripting or high-level languages. Open Hub indicates GDCM has experienced steady development and offered these statistics:

  • Mostly written in C++.

  • Average level of commenting.

  • Nearly 400,000 lines of code.

  • Maintained by a large development team, with commits from 65 contributors.

  • Represents 105 years of effort (using the COCOMO model).

Code Quality and Ease of Implementation

One of the positive characteristics that makes GDCM an attractive candidate is the lack of “legacy” code. Because it is relatively new, more modern and robust coding styles could be present in the code, compared with older projects.

The code quality is good, and C++ exceptions are handled internally (one of the requirements for allowing other high level language interfaces). GDCM was compiled on Windows using the Visual Studio 2012 compiler without any problems.

Development Environments and Compatibility

As noted earlier, GDCM was designed to enable calling from Python, C#, and other scripting languages through the use of SWIG (Simplified Wrapper and Interface Generator). GDCM can also be used directly with C++ projects.

Performance

Performance is more than adequate.

Documentation

The code is not as well commented as DCMTK.

LEADTOOLS

The LEADTOOLS DICOM SDK is developed by LEAD Technologies Inc., a privately held company based in Charlotte, NC. Source code is not available for you to customize; however, LEADTOOLS offers fee-based customization services.

Code Quality

Because this is a proprietary toolkit distributed in binary form, you can’t assess the quality of the underlying code. However, the company has been in business since 1990, and the DICOM SDK was first released nearly 15 years ago, so its history in the marketplace suggests favorable quality.

The code quality of the examples provided by LEADTOOLS is good; however, the code has an older Windows style to it, no doubt a product of its longer history in the market.

Development Environment and Compatibility

Evaluation focused on C++/ Windows 64-bit environment. LEADTOOLS reports support for additional development environments including .NET, Linux, iOS, and Android.

The LEADTOOLS libraries could be a good choice for a team that needs a quick end-to-end solution, which includes reading files, image processing, and 2-D display. In addition, the support for newer platforms (iOS, HTML5) suggests aggressive, ongoing development of the product line.

Performance

The performance of the LEADTOOLS libraries was quite good and on par with the open-source C++ libraries compiled for the evaluation.

Documentation

The documentation for the LEADTOOLS toolkit was very good. However, LEADTOOLS and the other commercial toolkit evaluated focus on providing a complete end-to-end solution—from reading the DICOM files to image processing and display—which makes the documentation broad rather than deep.

Accusoft

Accusoft provides a medical imaging toolkit with DICOM support. The privately held company, founded in 1991 as Pegasus Imaging, operates out of Tampa, FL. Being proprietary software, it is not customizable, and the company does not appear to offer such services.

Code Quality and Ease of Implementation

Accusoft ImageGear Medical is a proprietary toolkit distributed in binary form so it’s not possible to assess the underlying code compiled in the libraries. The company introduced a DICOM SDK nearly 15 years ago and has continued supporting and enhancing it since that time. Based on this information, it can be assumed that the code functions well. The C/C++ API is similar to an old style Win32 API, which might take some getting used to for a team familiar with more modern C++ coding styles.

Development Environments and Compatibility

Accusoft ImageGear Medical can be licensed for use with development environments including Win 64, .NET, and Linux.

Like LEADTOOLS, the Accusoft SDK could be a good choice for a team looking to include DICOM file reading as well as image processing and display in one package. The API and development environment support do not include the new environments that LEADTOOLS supports, although the company has such environments for other toolkits so similar DICOM offerings from Accusoft are plausible.

Performance

The performance of the Accusoft libraries is quite good and on a par with the open-source C++ libraries compiled for the evaluation.

Documentation

The documentation for the Accusoft product was also good, but it was not as well organized as the LEADTOOLS documentation. This probably has to do with both the legacy of the Win32 API coding conventions, as well as the assumption that users want the imaging components of the API in addition to DICOM reading.

Overall Assessment

When evaluating SDKs, summarize your findings in a chart form, with a rating of 1 (lowest) to 5 (highest) for each factor considered. This allows you to more easily compare the SDKs and present the recommendation for the package that best suits your needs.

The sample evaluation reported on includes development of proof-of-concept applications to perform performance testing as well as compatibility testing with multiple DICOM study sources. From start to finish, the evaluation lasted approximately three months.

The information about the process, resources, and toolkit assessments provided in this article will hopefully help you in deciding which DICOM SDK best suits your project needs.

Andrew Dallas is president and chief technology officer at Full Spectrum Software Inc. (Boston), a software design, development, and testing firm. Reach him at [email protected]

Don't miss the MEDevice San Diego conference and expo, September 1–2, 2015.

[image courtesy of DAVID CASTILLO DOMINICI]

Sign up for the QMED & MD+DI Daily newsletter.

You May Also Like