Initial Draft
Digital Imaging and Communications in Medicine (DICOM)
White Paper: DICOM Post-Processing Software Application Programming Interface
Prepared by:
Lawrence Tarbox, Ph.D.
DICOM Standards Committee, Working Group 10
1300 N. 17th Street
Rosslyn, Virginia 22209 USA
VERSION:
Working Draft 06
August 19, 2004
Table of Contents
2
Introduction...................................................................................................................................................... 3
Overview ......................................................................................................................................................... 3
4
Use Cases ....................................................................................................................................................... 5
AGENT SPECIFIC POST PROCESSING ................................................................................................ 5
6
SUPPORT FOR MULTI-SITE COLLABORATIVE RESEARCH .............................................................. 7
SCREENING PLUG-INS .......................................................................................................................... 8
8
SOP CLASS SPECIFIC POST PROCESSING ........................................................................................ 9
Technology ...................................................................................................................................................... 9
10
SOAP ........................................................................................................................................................ 9
COMMON INTERMEDIATE LANGUAGE ................................................................................................ 9
12
WEB APPLICATION SERVICES ............................................................................................................. 9
GRID COMPUTING – GLOBUS TOOLKIT ............................................................................................ 10
14
Staging .......................................................................................................................................................... 10
STAGE ONE – ACCESS TO DICOM DATASETS AND RESULTS RECORDING ............................... 10
16
STAGE TWO – ACCESS TO APPLICATION SERVICES ..................................................................... 11
STAGE THREE – STANDARDIZED GUI ELEMENTS .......................................................................... 11
18
STAGE FOUR – STANDARD WORKFLOW DESCRIPTIONS ............................................................. 11
Next Steps ..................................................................................................................................................... 11
20
22
Introduction
This document outlines a proposal for standardizing an Application Program Interface (API) based on data
semantics defined in the DICOM Standard for launching and interfacing with post processing software.
The initial thrust of this proposal is to provide an interface between two software applications. One
26 application, which we’ll call the Hosting Application, provides the second application with data, such as a
set of images and related data. The second application, which we’ll call the Hosted Application, analyzes
28 that data, potentially returning the results of that analysis, for example in the form of another set of images
and/or a structured report, to the first application. Such an API differs in scope from other portions of the
30 DICOM standard in that it proposes the standardization of data interchange between software components
on the same system, instead of data interchange between different systems.
24
This is a white paper to be used as a starting discussion point within DICOM Working Group 10 (Strategic
Advisory), and eventually the DICOM Standards Committee. Whether or not this white paper leads to a
34 Supplement to the DICOM Standard depends on multiple factors. This topic, though related to data
interchange, would be a new domain within the DICOM Committee. Certainly part of the discussion will
36 center on whether or not this topic should be within the scope of the DICOM committee. Other discussion
points might include the utility and feasibility of this proposal and the availability of technology for
38 implementing a solution.
32
To initiate this discussion, this white paper will introduce the proposal, with several suggested use cases,
followed by a brief discussion of technology that potentially could be used to implement the proposal and a
suggestion for how to develop the API in stages. This paper only gives a sampling of the technology
42 behind and uses of the proposal. If the DICOM Standards Committee decides to take on this task, the
ensuing discussion might include many additional ideas.
40
44
46
48
50
52
54
Initially the API and the post-processing software that utilizes the API will be used on an experimental
basis in research settings, where FDA safety regulations are less of a concern. However, before the API
or post-processing software that utilizes the API can be deployed in clinical systems, FDA safety
regulations would need to be addressed. One of the primary advantages of the API proposed in this white
paper is that it allows an appropriately written piece of post-processing software to run on multiple
platforms. As the number of platforms and pieces of post-processing software increase, it will become
increasingly difficult to test all combinations of platforms and post-processing software. Addressing the
safety issues may require a dialogue with the FDA on how to handle the explosion of testing combinations
cost effectively while still maintaining safety. Potential resolutions to these issues are not covered by this
white paper. Although the FDA safety regulations may be part of the technical discussion, the full
resolution of these issues may be out of the scope of the DICOM Committee.
Overview
56
58
60
62
64
Our proposal is to create an open, standardized Application Program Interface (API) to a DICOM-based
medical computing system, into which programs written to that standardized interface can ‘plug-in’ (see
Figure 1). The notion of software add-ons or ‘plug-ins’ is quite common in the computing world, and has
been successfully employed to extend the capabilities of web browsers, media players, graphical editors,
publishing programs, etc. A system implementer need only create the standardized API once to support a
wide variety of add-on applications. An application written to the standardized API can be run in any
environment that implements the interface (see Figure 2). Such an API could be defined using recent
developments in the web-based IT world, such as XML, SOAP, common intermediate language, and GRID
computing concepts to enhance its host- and language-independence as well as to simplify the distribution
of the ‘plug-in’ applications that use it.
Hosted Application (Plug-in)
API (Plug)
API (Socket)
Hosting Application (e.g. Medical Workstation)
66
Figure 1.
Interface between Hosted and Hosting Application
The same Hosted Application can
run on any platform (Hosting
Application) that supports the API.
A
A
B
A
…
A
C
D
A
E
68
Figure 2.
Illustration of platform independence via plug-in architecture.
The success of utilizing plug-in technologies depends on appropriate definition of the API functions. One
must balance ease of use and simplicity of implementation against providing sufficient functionality in the
72 interface to support the types of medical applications needed for the targeted use cases. The starting
point for creating the API would be loading and storing of DICOM data. The DICOM semantics not only
74 provides the pixel data, but also various types of meta-data. For example, the Hosting Application could
give the Hosted Application a set of data to analyze when it starts up. When the Hosted Application has
76 completed its analysis, it would return to the Hosting Application DICOM data sets recording the result.
70
78
These data sets could include any class of DICOM data, including but not limited to images, structured
reports, and presentation states. Simple exchange of DICOM data could cover the majority of the needs
for several use cases.
If there is demand, the interface could be extended to cover other services, such as printing and archiving.
Another potential enhancement might be access to basic GUI services, to allow the plug-in to adapt to the
82 GUI style elements of the runtime environment. Essentially the application could be provided with different
‘skins’, similar to the way the GUI of media players, OS utilities, and productivity applications can be
84 tailored to suit the taste of the individual and the underlying style selected. However, it might be wise to
leave such topics to future extensions, and just concentrate on the data exchange question in the initial
86 version of the API definition.
80
The design goals for the API might include such things as:
88

Language independence – the API is defined in such a way that programs written in any common
programming language could utilize it.
90

Platform independence – the API is defined in such a way that it is not dependent on any particular
computing platform or operating system.
92

Extensible – the API can be extended in a backwards compatible fashion. Old applications still work
even with new extensions in place, while new applications that are aware of the extensions can gain
access to a richer set of functionality.

Protected – the API design insures that intellectual property rights can be protected, and that
appropriate permissions and licenses are in place. In other words, a Hosting Application will be able to
launch a plug-in without being able to ‘see’ the internals of that plug-in, nor will the plug-in be able to
steal internal code of the Hosting Application. The Hosting Application would not be able to launch a
Hosted Application without permission or license from the owner of the Hosted Application.

Secure – the Hosted Application’s access to data on the Hosting System would be controlled via the
API by the Hosting Application. The Hosting Application would be responsible for access controls and
audit logging, since it is the one providing the data to the Hosted Application.

Simultaneous Launching (simplified Multi-threading) – the Hosting Application will be able to launch
several instances of the same or of different Hosted Applications at the same time.
94
96
98
100
102
104
106
The above are only suggestions. The working group defining the API could change the design goals. It is
also possible that the first few iterations of the API definition do not meet all of the desired design goals.
This would be the subject of a staging plan.
Use Cases
108
The initial driver for the development of a standard API between medical imaging software proposed here
was the advent of molecular imaging, which we predict will greatly increase both the complexity and
number of post-processing applications. After initial presentations, we quickly realized that the plug-in
112 methodology proposed might also be useful in multiple application domain areas. The molecular imaging
use case, along with a few additional use cases, are described here.
110
114
AGENT SPECIFIC POST PROCESSING
116
Historically, medical imaging metabolic/contrast agents have provided signals whose intensity varied
according to degree of uptake in tissues or organ systems based on metabolic process or physiologic state
(nuclear medicine metabolic/contrast agents), or space-occupying characteristics (radiographic contrast
118
120
122
124
126
metabolic/contrast agents, including CT and MRI). Recent advances in the understanding of cellular
processes, ranging from antigen expression and the expression of other, non-antigenic protein markers, to
the elucidation of intracellular signal transduction pathways, and the identification of alterations in the
genetic matrix itself, e.g., have led to the development of more specifically-targeted imaging and
therapeutic metabolic/contrast agents. These metabolic/contrast agents are often themselves very small
biological or molecular constructs, giving rise to the term molecular medicine, and, in the present context,
molecular imaging. The innate specificity of such metabolic/contrast agents allows increasing their dose
in target tissues, improving their biological activity, whilst avoiding or minimizing morbidity due to effects on
normal tissues.
Molecular imaging can provide diagnoses, assist in the selection of patients for appropriate therapies, and
guide and evaluate subsequent treatments, whether traditional or molecular. By using the same molecular
targeting entity with different conjugates for imaging and treatment, it may be possible to use the
130 information concerning the biological distribution of the imaging agent to provide stage- or patient-specific
dosimetry prior to the initiation of therapy. In this way, medical imaging will not only be used for diagnosis
132 of disease, but also will be a key component in controlling and monitoring the effectiveness of therapy.
The choice of treatment and positive clinical outcome are strongly affected by the degree to which medical
134 imaging demonstrates the presence, location and extent of the targeted disease (e.g. cancer).
128
136
138
140
142
144
146
Many of the coming metabolic/contrast agents require more than just simple imaging to provide the
needed data. Rather than just detecting the presence or absence of the metabolic/contrast agent,
calculations based on relative uptake rates, or decay rates, comparisons with previous or neighboring
data, fusion of data from multiple sources or time points, etc. may be necessary to properly evaluate image
data with these metabolic/contrast agents. Often the nature of this processing is closely related to the type
of agent, the anatomy, and the disease process being targeted. The processing is often so specific that
the general-purpose image processing features commonly found on current medical imaging workstations
are inadequate to properly perform the procedure. The effective use of a particular agent for a particular
procedure depends on having properly tuned, targeted post-processing. Both the algorithms used as well
as the workflow in performing the analysis may be customized for performing procedures with a particular
agent.
Editor’s note: Specific examples of customized post processing for particular agents could be
added here, if desired.
Obviously, the main sponsors for developing such agent- and exam-specific post-processing applications
are the pharmaceutical companies who create those agents. They have a vested interest in insuring that
150 such post-processing applications can run on a wide variety of systems. The proposed standard postprocessing software API outlined in this paper could simplify the distribution of such agent-specific analysis
152 applications. Rather than creating multiple versions of the same application, each version targeted to a
particular medical imaging vendor’s system, the application developer need only create a single version of
154 the application, which would run on any system that implemented the standard API.
148
Besides the factors affecting image quality mentioned previously, such as biodistribution of infused
imaging agents, residual vascular activity, dose limitations, etc., idiosyncratic preferences for particular
tomographic reconstruction and filtering parameters are often based on personal experience with
158 volumetric imaging in general, and molecular imaging agents specifically. Differences are accentuated by
variations in the physical characteristics of different imaging system brands, models, installed
160 configurations, accessory components, and processing algorithms. By allowing the sharing of applications
based on camera-independent (or conversely, camera-specific) procedures, the plug-in technology will
162 reduce these differences to a minimum, further supporting a uniformly optimal image quality and approach
to diagnostic interpretation across the currently diverse medical imaging landscape.
156
One could even distribute these applications, for example, through a web-based application server, to
reduce distribution costs. Similar to the way a web browser can be configured to always search for the
166 latest version of a web page, and application launcher on a medical workstation could grab the latest
version of an analysis application from a web-based server, given the type of procedure being performed
168 and the type of agent being used.
164
SUPPORT FOR MULTI-SITE COLLABORATIVE RESEARCH
170
172
174
176
178
180
As mentioned above, molecular imaging of disease processes requires sophisticated visualization and
analysis software customized to the specific anatomical, functional and molecular features of the disease.
Clinical research groups funded by NIH and/or pharma/biotech companies play a leading role in
developing such software applications. However, current software development technology presents
major obstacles for researchers to build consensus through collaboration, and for translating such
“research prototypes” into FDA approved applications running on commercial imaging workstations. The
consequences include multi-year delays in the clinical acceptance and use of new imaging agents, and the
deployment of qualitatively different applications on each commercial platform, increasing the costs of
development, training and quality assurance. The standard API proposed herein could help streamline
and accelerate the pace of this research. This in turn will hasten the development of personalized
medicine through molecular imaging.
In this section we explore more generally the issues raised above.
182
184
186
188
190
192
194
Site-specific problems: The development of molecular imaging applications can be accelerated with
multiple site cooperation in the validation of new algorithms and software. However, the run-time
environment and tools available at one site typically are not matched identically at other sites, hampering
the sharing of applications between sites. For example, many of the research sites involved in nuclear
medicine use IDL, a commercially available image processing toolkit. Using the same tools allows them to
share applications. However, suppose that one of the partners in a collaborative research effort utilizes
MatLab for most of their work, while yet another partner develops most applications with VTK/ITK. One
cannot simply take an application written at one of these sites, and make it run on the other site without
major software work involving the installation and configuration of multiple tool packages. Even after
installing the needed tools and libraries, software developed at one site may be trying to access facilities
that are unavailable at the other site, for example, facilities to store, access, and organize the image data.
Often the data formats applications from one site are expecting are incompatible with the data formats
available at other sites. Having a standard API could help minimize these data incompatibilities.
Gap between research and clinical environments: The initial versions of agent-specific applications are
typically created in a research environment, and are not easily accessible in the clinical environment. The
early experimental work generally is done by exporting the image data out of the clinical environment to
198 research workstations, and then importing the results back into the clinical system once the analysis is
done. While exporting and importing the images may be sufficient for the early research work, clinical
200 acceptance of an application can be significant enhanced if that application could run in the same clinical
environment where the images are collected, in order to better fit into the clinical workflow.
196
202
204
206
208
210
212
214
The problem of mismatched run time environments becomes even more acute when attempting to run the
typical research application on a production clinical workstation. Due to a variety of legal and commercial
concerns, vendors of the systems utilized in the clinical environment generally do not support running
unknown software, nor do most commercial vendors have the time or resources to assist the hundreds of
researchers who might wish to port a particular application to that vendor's system. Even if researchers
manage to load an experimental program onto a clinical system, the experimental program rarely has
direct access to the data stored on that clinical system, nor can it directly store results back into the
system’s clinical database. Conversations with product managers from imaging equipment vendors
indicate that they do not consider as commercially viable the creation and support of a custom, systemspecific API that allows researchers to access the internal functions of the system for running user-created
or 3rd party applications. Without such access, users have to resort to the cumbersome and timeconsuming export and input routines to be able to run research programs on clinical data. It is expected
that the constrained environment that a standard API provides would be simpler to validate, particularly if it
is universally deployed by multiple vendors, and could lessen the burden on any individual system vendor.
Plug-in Architecture: Given that the application software add-on, or ‘plug-in’ is a black box to the system
on which it is running, it is possible to create plug-ins that use a variety of 3rd party or locally-created
218 toolkits (see Figure 3 below). The plug-in environment would adapt the toolkit to the standardized
interface, allowing the researchers to work with the tools they already know, yet create plug-ins that
216
potentially could run on a wide variety of platforms. In addition, the plug-in interface could give the
researchers access to services on clinical workstations that they might not have access to in their ad-hoc
222 research environments.
220
Figure 3.
224
Illustration of internal plug-in architecture.
Since the plug-in is constrained to the standard API, the job of converting a research prototype into a
commercially viable, FDA approved post-processing software application is simpler than trying to convert
the ad-hoc code currently being generated at research institutions into ‘industrial strength’ applications.
228 The developers doing the conversion would not need to learn the multiple unique development
environments and infrastructure. Since the standard API provides many services, the research portion of
230 the software that actually needs conversion is expected to be smaller (just the upper box) than it would
have been without the use of the standardized API.
226
For those collaborative projects where different sites use different toolkits, the proposal for a standardized
interface to add-on software applications allows the collaborative group to create and distribute a limited
234 number of plug-in environments supporting those tool kits. Once installed, this small set of plug-in
environments would support running a large number of diverse applications built on those multiple toolkits.
232
236
Note that molecular imaging research is just one example of collaborative research that could be done.
Clearly many other application fields face similar issues and could benefit from the proposed solutions.
238
SCREENING PLUG-INS
Computer Aided Diagnosis and Decision Making (CAD) is becoming more prevalent in radiology
departments. Many classes of exams now routinely go through a computer screening process prior to
reading. One potential barrier to more widespread use of CAD screening is that the various vendors of
242 CAD applications typically only allow their applications to run on servers or workstations provided by those
companies. A clinical site that wishes to utilize, for example, mammo CAD from one vendor and lung CAD
244 from another often is forced to acquire two different servers or workstations from the two different vendors.
240
246
The plug-in concept described in this paper could be used to facilitate the running of multiple CAD
applications from multiple vendors on the same computer system. Technology exists to protect (e.g. via
encryption) the intellectual property of the vendors involved.
248
SOP CLASS SPECIFIC POST PROCESSING
As medical imaging progresses to new, diverse devices and applications, there is the need to occasionally
extend SOP Classes, or to create entire new ones. For example, certain types of ultrasound images, such
as intravascular ultrasound images, are more efficiently processed and stored in the format in which they
252 were acquired. For example, vessel wall detection in intravascular ultrasound is often easier if the images
are left in radial form. Unfortunately, most DICOM workstations would not know how to deal with images
254 in such a strange format even thought the workstation might recognize that it is an image SOP Class.
250
256
One possible solution is for a workstation to seek out an appropriate plug-in for handling SOP classes that
it does not recognize. This would allow for automatic handling of all image types by a generic imaging
platform.
258
PRINT FORMATING
Another possible use case is a common layout/format manager for printing that can be used on multiple
systems. Users have often complained that the look and layout of prints are different, since many systems
now utilize system-specific software for handling print functions. A standardized post-processing API
262 would allow print providers themselves to create print layout and formatting programs, optimized for their
particular printer, and available on multiple system types.
260
Technology
264
266
Technology created for enhancing web-based services could facilitate the creation and distribution of
portable software application add-ons. A few examples of this technology are listed here.
SOAP
Simple Object Access Protocol (SOAP) provides a programming-language and machine independent
method based on XML for describing the interface into a software system. Being completely portable
270 between systems, SOAP may provide a means for specifying an object-oriented interface to a medical
system. Several modern software development systems now utilize SOAP routinely, and readily
272 understand its syntax. The SOAP standard is maintained by the W3C organization.
268
COMMON INTERMEDIATE LANGUAGE
Popularized by Microsoft’s .net environment, among others, the common intermediate language
standardized by ECMA allows an application to be complied into a machine independent form, which
276 simplifies web-based distribution. The common intermediate form is similar the output of the first passes
of a multi-pass compiler, just prior to final code generation. This form is not dependent on any particular
278 machine instruction set. The final code generation step to a particular machine’s instruction set is done
prior to use on a particular system. This allows a developer to build an application without regard to what
280 system it will eventually run on. The final code generation occurs when the application is installed.
274
WEB APPLICATION SERVICES
The IT world is converging on standardized access to web services. Again, several software development
environments are utilizing such services for distribution of runtime modules from central repositories. This
284 allows a system to call up the ‘latest and greatest’ version of a particular software module automatically, in
a fashion similar to the caching and updating of Web pages. A recently used application that is already in
286 the cache and that has not changed in the repository would run directly out of the cache. If the application
is not in the cache, or a later version is available from the repository, the system would download and
288 cache the latest version. Such services could be useful in controlling access to and the distribution of
medical software application add-ons.
282
290
GRID COMPUTING – GLOBUS TOOLKIT
Another alternative for distribution of software and data, as well as for defining machine independent
interfaces is the GLOBUS toolkit used in GRID computing. Much of GLOBUS is a specification of how a
GRID computing environment utilizes other standards, such as those described above. As such, it could
294 provide a consistent framework, independent of the underlying systems, for describing a standard
computing environment for medical image and data processing.
292
296
Staging
298
It is proposed that the definition and rollout of a standardized interface for medical software add-ons occur
in a series of stages, each building on the functionality of the previous stage. The goal is to allow early
experimentation with the interface, utilizing that feedback to shape future specifications.
A suggestion is to define the content of the stages such that they can be rolled out on a regular basis, for
example, one stage each year. The development schedule for each stage could follow a defined cycle,
302 such as
300
304
1. Requirements definition – using experience gained from the previous stage, and the list of wishes for
future enhancements, refine and set the scope for the coming phase.
306
2. Technology planning – select the technology to be utilized to meet the requirements of the coming
stage. This could include utilizing existing standards, or defining new ones as needed.
3. Draft Standard Definition – formal writing of the draft standards specification for this phase.
308
4. Trial implementation – based on the draft standards, get feedback from early implementers.
5. Refine Standard – finalize the standard for publication.
The stages outlined here are only suggestions. The committee may decide to alter the content of the
stages. In addition, whatever group actually assigned the task of creating the standardized interface may
312 decide to change the boundaries and the content of each stage.
310
STAGE ONE – ACCESS TO DICOM DATASETS AND RESULTS RECORDING
The first stage could be simply providing a means to launch an add-on application, provide it with one or
more DICOM Datasets to work on, provide simple access to application local system services, and return
316 one or more DICOM Datasets. In this first stage, the software application works independent of the
medical system after it is launched. The intention is to exchange of DICOM Datasets using DICOM
318 semantics, but not necessarily DICOM syntax. No formal attempt to coordinate GUIs or access to other
resources would be provided.
314
This stage would also add the capability for the add-on application to return one or more DICOM Datasets
for storage in the medical system’s database. These Datasets typically would hold the results of the post322 processing or analysis.
320
324
It is expected that the first stage would support the majority of basic needs. Subsequent stages may allow
for more seamless integration into the medical system and for improved workflow support.
It is also desirable to include a mechanism to securely identify a plugin, e.g. digital signature.
326
STAGE TWO – ACCESS TO APPLICATION SERVICES
A possible second stage would be to give an application add-on access to common services within a
medical system, such as image print services, media creation, query and data access, etc. User demand
would probably dictate what services are desirable. As such, the exact definition of the content of this
330 phase probably should wait until some experience is gained in the first two phases.
328
332
Another potential avenue is to specify standardized access to toolkits, such as the open-source vtk and itk
toolkits, for common visualization and processing algorithms. Again, user demand should dictate the level
of support that would be useful.
334
STAGE THREE – STANDARDIZED GUI ELEMENTS
A third stage may be to create a standard set of GUI elements, driven by style sheets, to allow an
application’s ‘look and feel’ to be adapted and customized. For example, the application add-on would
request the use of particular named GUI elements, and define some generic characteristics of those
338 elements (e.g., ranges, selection lists, data formats). The medical system would automatically create the
elements, based on the system’s style sheets, in a form consistent with other applications that run on that
340 system. Another possible variant would be to utilize ‘skin’ definitions in some form of standardized
language, to allow system or site customizations of an add-on application’s user interface.
336
342
344
346
348
350
352
354
356
STAGE FOUR – STANDARD WORKFLOW DESCRIPTIONS
Another possible stage would be creation of a higher-level workflow description. This would allow a metaapplication to be created from a series of other standard applications. The output of one application would
feed the input of a subsequent application. While such application chaining could be useful, it is definitely
not within the scope of the early stages of this proposal. Another possible aspect of workflow could also
include coaching the technologists and physicians on how to do a particular exam. Several
pharmaceutical companies that we talked to in preparing this proposal indicated that unfamiliarity with the
steps involved in doing an examination, from patient prep to setting up the acquisition to processing the
acquired images to generating a report, limits the widespread acceptance of the exam. They surmise that
some guidance along way as to the workflow of a particular type of examination might give caregivers
more confidence in doing the exam, and might improve the consistency of the result. Again, such topics
are definitely not in the scope of the early stages of this proposal.
Next Steps
The first decision that needs to be made is whether or not this effort is within the scope of the DICOM
committee. If it is not in the DICOM scope, then a suggestion of where to forward this proposal would be
appreciated.
If the committee decides that this work should be in the scope of the DICOM committee, the next step
would be to create a work item for the first stage, and assign the task to an appropriate working group.
360 WG 10 and/or the DICOM committee could give guidance as to what the scope of this first stage work item
should be. It is suggested that the work follow a phased plan, similar to the staging described above.
362 Furthermore, it is suggested that instead of going directly to letter ballot, drafts should be frozen for trial
use prior to ballot, in order to prove the concepts through sample or demonstration implementations.
358