Information Systems and Data Management
Sam Brain
Bruce H. Curran
Computers have become ubiquitous and essential to most technical disciplines. This is no less true for the field of radiation oncology and especially image-guided adaptive radiation therapy (IGART).
The use of computers in radiation therapy (RT) appeared in the late 1960s and represents the beginning of the modern era of radiation treatment.1 As computer performance improved and costs lessened, the use of computers became more and more routine in radiation treatment, so that by the late 1970s, computers were considered a necessary tool in the process of treatment planning.
Although the inclusion of imaging with RT treatment planning was present in the early 1970s,2, 3, 4 the inclusion of image-guided techniques as a basis for planning of radiation treatments can be traced to early work from Sherouse et al.5,6 and Goitein et al.7,8 Sherouse’s efforts, in particular, led to the development of the Computed Tomography (CT) Simulator, a software application that simulated the patient anatomy allowing more accurate definition and positioning of radiation beams.
Although the work of Sherouse and Goitein provided three-dimensional (3D) visualization in the RT process, their efforts lacked a 3D dose calculation algorithm that could take advantage of the increased imaging and anatomic information available. Fraass and McShan,9 along with collaborators, constructed the first 3D treatment planning system, enabling not just advanced imaging input, but also novel 3D planning and computational algorithms, and thus defined a platform upon which IGART could be advanced. These advancements were quickly adopted by numerous commercial vendors, and by the early 1990s, a number of 3D treatment planning systems were available to all users.10
Now that treatment planning systems could emulate the treatment delivery process, advancements in delivery technology quickly followed. Theoretical simulations of such devices as multileaf collimators, intensity-modulated RT (IMRT), and adaptive RT promised benefits to the patient undergoing radiation treatment.11, 12, 13 Increases in computational power allowed researchers to explore hypotheses of improved delivery accuracy and reduced normal tissue margins, encouraging further development of new delivery paradigms.
Although these advancements provided a basis for 3D treatment planning and image-guided techniques, a serious impediment was the lack of standardization for the exchange of such information. Each imaging manufacturer had its own protocol for the storage and exchange of imaging information, and little to no standardization existed for the exchange of radiation treatment information. Fortunately, such development was occurring and, by the early 1990s, was beginning to reach fruition in the radiation treatment process.
ROLE OF DATA STANDARDS IN IMAGE-GUIDED ADAPTIVE RADIATION THERAPY
The data flows vital to IGART would not be possible without data standards. In the same way that the Internet depends on such low-level standards as Ethernet, Transmission Control Protocol (TCP)/Internet Protocol (IP), and HyperText Markup Language (HTML), the field of IGART depends on higher-level standards that define the way that medical data are formatted and transmitted over local area networks (LAN) or wide area networks (WAN).
The data standard with greatest relevance to IGART is, of course, the widely used Digital Imaging and Communications in Medicine (DICOM) standard and especially those parts of DICOM that address the so-called radiotherapy objects.
Before the introduction of DICOM, vendors of imaging equipment used mutually incompatible, proprietary communications protocols and image data formats to transfer and store medical images. This plethora of formats gave rise to a cottage industry in file-format conversions and consumed many programmer hours of effort.14
The DICOM standard was developed by a collaboration of the American College of Radiologists (ACR) and the National Electrical Manufacturers Association (NEMA) to facilitate the interchange of medical images like CT, magnetic resonance imaging (MRI), and ultrasound between imaging modalities (scanners), imaging workstations, and picture archiving and communication systems (PACS).
The first version of the document, named ACR-NEMA 300 Version 1, was published in 1985, and an updated Version 2.0 was published in 1988. By this time, however, computer networks were coming into widespread use, but ACR-NEMA
Versions 1 and 2.0 were ill suited to network usage, defining instead a 50-pin point-to-point cable as the standard communication interface. Although it was possible to send ACR-NEMA data over a network, and indeed the standard mentions an otherwise-unspecified Network Interface Unit, ACR-NEMA left many details of network transmission unspecified.
Versions 1 and 2.0 were ill suited to network usage, defining instead a 50-pin point-to-point cable as the standard communication interface. Although it was possible to send ACR-NEMA data over a network, and indeed the standard mentions an otherwise-unspecified Network Interface Unit, ACR-NEMA left many details of network transmission unspecified.
The ACR/NEMA Working Groups went back to the drawing board and substantially redesigned and reorganized the standard. This new version of the standard, Version 3, was published in 1992 and renamed Digital Imaging and Communications in Medicine Version 3 (DICOM-3). This original standard defined objects for nuclear medicine, CT, MRI, ultrasound, and secondary capture.
The new standard was much more extensive than the previous versions and incorporated many new features:
Data elements. Although DICOM-3 retained the basic tagged data format of ACR-NEMA, shown in Figure 21.1, the range of data types was expanded to include various string types: (e.g., person’s name, date, time, age, decimal numbers) and binary data types (signed and unsigned long and short integers, single- and double-precision floating point numbers, image pixels). One significant addition is a mechanism for multiple repeating groups of data elements, called sequences, in DICOM. This mechanism is used, for example, in nesting multiple beams inside a radiotherapy plan object.
Network capabilities. DICOM uses the reliable data stream delivery capabilities of TCP/IP for all data transmissions. This avoids the need for data stream checksums, which ACR-NEMA required. DICOM also allows choices in the “endian-ness,” or byte order of the network data stream, and later enhancements included data compression.
Object-oriented design. DICOM defines data objects that model the real world, so that, for example, an image object contains not only pixels and other image-related parameters, but also details of the patient, series, and study. DICOM also adopted the International Organization for Standardization (ISO) concept of the Unique Identifiers (UIDs) by including it as a DICOM data type. UIDs have several roles within the standard, but their most extensive role is that of identifying every DICOM object uniquely. This allows DICOM objects to reference others (e.g., grouping images into a study or grouping studies into a series, or allowing a radiotherapy treatment plan object to reference an associated dose object and CT series).
Methods/services. In the object-oriented world, methods act upon objects. In DICOM, methods are known as services, and they are the mechanisms by which DICOM data objects are transferred over the network. The two workhorses of DICOM services are popularly called “push” and “pull” (or “query/retrieve”). The “push” service is used when the DICOM object transfer is initiated by the sending process. For example, a push could be used to send image data from a PACS or imaging modality to a workstation at the request of an operator. The DICOM standard refers to the push as a C-STORE service, part of the Storage Service Class.
The “pull” service, part of the DICOM Query/Retrieve Service Class, is best demonstrated by a concrete example—a workstation retrieving a set of images from a PACS. First, the workstation sends a C-FIND request to the PACS containing attribute values (e.g., patient name, date of study, etc.) used as keys to select a set of patients, series, exams, or images. The C-FIND response from the PACS contains a list of matched object keys. The workstation (after the user selects an object from the returned list) then sends a C-GET service request to the PACS for the objects required. The PACS sends that object to the workstation using a C-STORE (i.e., a “push”). Alternatively, the workstation may send a C-MOVE request to the PACS to push the objects to another destination (i.e., not to the original querying workstation).
Conformance. This is a framework for describing the capabilities of DICOM applications and is a critical mechanism for ensuring interoperability. Every conformance statement includes a list of DICOM objects that can be sent or received by the application and what DICOM services are used for the data transfer.
Extensibility. The standard was separated into parts, each addressing a different aspect of the standard (e.g., data objects, services, network protocols, conformance, etc.). Implementation details were moved to appendices, which DICOM calls annexes. The addition of new objects to these annexes makes extensions to the standard easy.
 Figure 21.1. Digital Imaging and Communications in Medicine (DICOM) tagged data format. |
In 1995, American Association of Physicists in Medicine (AAPM) initiated the first demonstrations on the use of the DICOM standard in radiation oncology. The 1995 AAPM Annual Meeting, held in Boston, Massachusetts, provided a venue for manufacturers to demonstrate their ability to receive, display, and base calculations on imaging data sets received using DICOM-based CT images. Although not straightforward, by the end of that meeting, a number of treatment planning system manufacturers were able to demonstrate the utilization of DICOM images in the treatment planning process (B. Curran, personal communication, 1998).
Because DICOM-3 was designed to make it easy to extend, the standard has undergone a continuous process of expansion and refinement since its initial publication. The list of extensions include the addition of objects from many other medical disciplines, (e.g., cardiology and hematology); methods for storing DICOM objects on media, such as magnetooptics disks, compact discs (CDs), digital video discs (DVDs), and universal serial bus (USB) flash memory; encryption of DICOM objects; sending DICOM by e-mail; and many more. Table 21.1 gives a partial list of the extensions that have been added or proposed (>130 in total as of this writing in mid-2008) since the original publication of DICOM-3. These extensions, or supplements, are listed online.15
In December 1994, two groups met at the Radiological Society of North America (RSNA) meeting with the purpose of defining an improved standard for the exchange of
treatment planning information in radiation oncology. (An early standard, based on the use of magnetic tape, had been developed by AAPM in the 1980s but had not, at that time, been widely adopted.) The two efforts were combined, with DICOM chosen as the desired standard for extension, and in January 1995, an initial group formed under the Radiation Therapy Section of NEMA to develop “RT Extensions to the DICOM Standard.”
treatment planning information in radiation oncology. (An early standard, based on the use of magnetic tape, had been developed by AAPM in the 1980s but had not, at that time, been widely adopted.) The two efforts were combined, with DICOM chosen as the desired standard for extension, and in January 1995, an initial group formed under the Radiation Therapy Section of NEMA to develop “RT Extensions to the DICOM Standard.”
TABLE 21.1 DICOM Extensions (2008) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The initial publication of the RT extensions occurred in 1997, defining objects for RT plans, doses, and structure sets. In 1999, objects were added that describe a radiotherapy treatment record. These are the RT beams treatment record, RT brachy treatment record, RT treatment summary record. Most recently, in 2006, radiotherapy objects for ion therapy were added to include descriptions of treatment plans for proton and ion beam therapy. A description of the DICOM RT objects is given in Table 21.2.
Several other recent DICOM extensions merit inclusion for their possible relevance to IGART. They are the spatial registration, deformable registration, segmentation, and surface segmentation objects. They are briefly described in Table 21.3.
The DICOM standard is revised yearly to incorporate new objects as they are defined and also to include published corrections and deletions. The latest version of the standard at the time of writing is DICOM 2008.16
In addition to the DICOM services that involve movement of medical data such as images, plans, doses, and so on, there is an important class of DICOM services, which rather than moving medical data, are used for workflow management by exchanging DICOM objects describing tasks and procedures. These services are seldom used in RT because most of the radiation oncology clinical process is driven either by user interaction, which triggers DICOM “push” or “pull” movements of data, or by vendor-specific, proprietary methods of communication.
These workflow-centric services are used extensively in other specialties. For example, in radiology, they are used by the radiology information system (RIS), imaging modalities, and workstations to process and query worklists. Worklists are collections of tasks to be carried out, for example, at the imaging modality. Using the DICOM Modality Worklist Management class, the modality may query the Information System (IS):
for a schedule of imaging procedures to be performed, including details of each task
to download patient demographic information to be incorporated into the DICOM image data acquired at the modality.
Using the DICOM Modality Performed Procedure class, the modality may send procedure status information to the IS. For example:
Notification that the procedure has started
Progress of the procedure
Notification that the procedure has been completed or cancelled
Working Group 7, the committee within the DICOM structure responsible for extending DICOM, has recently authored, in conjunction with other DICOM working groups, two supplements, 74 and 96,17,18 that extend worklist concepts to radiation oncology. These concepts are being used in an Integrating the Healthcare Enterprise (IHE) Radiation Oncology Profile for RT Treatment Delivery. This profile is expected to be demonstrated in 2009.19
DATA FLOWS
Related posts:
Stay updated, free articles. Join our Telegram channel
Full access? Get Clinical Tree
