Skip to main content
NCBI home page
Radiographics logoLink to Radiographics
. 2011 Jan 19;31(1):295–304. doi: 10.1148/rg.311105085

Informatics in Radiology: An Information Model of the DICOM Standard1

Charles E Kahn Jr ✉, Curtis P Langlotz, David S Channin, Daniel L Rubin
PMCID: PMC3399709  PMID: 20980665

A unifying and computationally accessible information structure of the DICOM standard for medical imaging is presented.

Abstract

The Digital Imaging and Communications in Medicine (DICOM) Standard is a key foundational technology for radiology. However, its complexity creates challenges for information system developers because the current DICOM specification requires human interpretation and is subject to nonstandard implementation. To address this problem, a formally sound and computationally accessible information model of the DICOM Standard was created. The DICOM Standard was modeled as an ontology, a machine-accessible and human-interpretable representation that may be viewed and manipulated by information-modeling tools. The DICOM Ontology includes a real-world model and a DICOM entity model. The real-world model describes patients, studies, images, and other features of medical imaging. The DICOM entity model describes connections between real-world entities and the classes that model the corresponding DICOM information entities. The DICOM Ontology was created to support the Cancer Biomedical Informatics Grid (caBIG) initiative, and it may be extended to encompass the entire DICOM Standard and serve as a foundation of medical imaging systems for research and patient care.

©RSNA, 2010

Introduction

For more than 25 years, imaging device manufacturers and medical professionals have worked together to define a global standard for the trans-mission, storage, and display of medical imaging information. The result of that effort is Digital Imaging and Communications in Medicine (DICOM) (1,2). DICOM has been highly successful; it has been incorporated throughout the medical imaging industry and has improved the interoperability of healthcare systems. In this article, we discuss an effort to represent DICOM in a machine-readable form that facilitates continued innovation on the basis of the DICOM Standard.

DICOM

DICOM works by modeling the image acquisition process and information objects related to imaging, and it provides a specification for how image data, metadata, and related information objects are represented in a binary format and transmitted over computer networks. The DICOM Standard specifies a rich and diverse set of information about patients, imaging equipment and procedures, and images. The official DICOM Standard is large; it is published online in 17 parts in approximately 4100 printed pages (3). The text documents are published in Microsoft Word format and Adobe Portable Document format. In this article, all references to sections, figures, and tables of the DICOM Standard refer to the 2009 edition.

DICOM documents are organized according to templates and are presented in tables that set forth how particular components of information are presented. However, DICOM currently lacks a “reference information model,” a description of all information pertinent to the imaging domain that is transmissible in DICOM objects, and developers who use a subset of DICOM in their applications must manually extract the pertinent portions of the standard. The text-based representation of the DICOM Standard is difficult to peruse, and any ambiguities may be implemented in disparate ways by developers. Moreover, the current representation of DICOM is not interpretable by machines, and development of new applications that are based on the standard may be time consuming.

To reduce the time, effort, and errors associated with the development of DICOM-based information systems, we sought to create an information model of the DICOM Standard in a computationally accessible format. Our goal was to model the DICOM Standard as an ontology, a machine-accessible and human-interpretable representation that may be viewed and manipulated with information-modeling tools. By providing this representation of DICOM, we sought to allow users to share consistent meaning, establish semantic interoperability, and improve the efficiency of developing DICOM applications. We developed a prototype knowledge model called the DICOM Ontology, which is designed to ultimately serve as a model for representing the entire DICOM Standard.

Ontologies

An ontology describes a set of entities and their relationships (4). It formally specifies the entities in a domain and their properties (attributes), and it allows people and information systems to access the knowledge stored within it. The RadLex® (Radiology Lexicon) radiology vocabulary has been developed into an ontology, and large sophisticated ontologies have been developed for genetics and human anatomy (5–7). Currently there are nearly 200 different ontologies for a variety of biomedical disciplines (http://bioportal.bioontology.org). Ontologies are “computable,” meaning the highly structured information they contain may be used to improve information retrieval, knowledge discovery, and automated reasoning (8–12).

In addition to terms and their definitions, ontologies define the relationships between entities, which frequently are connected by “is-a” (generalization-specialization) and “part-of” relationships and which enable the formation of hierarchies. Organizations such as the Open Biomedical Ontology Foundry and the National Center for Biomedical Ontology provide opportunities to integrate knowledge among different biomedical ontologies (13–15). Applying ontologic modeling to DICOM provides an opportunity to bring the benefits of this approach to the radiology domain.

Modeling the DICOM Standard

To build an information model, we reviewed the following sections of the DICOM Standard: Part 3, which specifies a “real-world” model, an information model, information object definitions (IODs), and modules and macros in a tabular form; Part 6, which specifies the data dictionary, including the type and multiplicity of each data element used as an attribute within objects defined in Part 3; and Part 16, which defines the value sets (context groups) referenced by the information objects in Part 3 as well as templates for structured reports. We also reviewed the content concerning model structure (the entity-relationship diagrams) in the text form of Part 3 of the DICOM Standard. These diagrams, as well as the relationships they specify, are not explicitly encoded in the tables of DICOM that represent the other information aspects of the standard. Thus, the diagrams were manually reviewed to encode these relationships into the DICOM Ontology.

Ontology Building

In attempting to model the DICOM Standard, our goal was to represent the existing DICOM model as it is defined—both explicitly and implicitly—in the DICOM Standard. To do this, we created classes within the DICOM Ontology that represent DICOM entities; these classes were named similarly, if not identically, to those of the DICOM Standard. The DICOM Ontology was designed to closely follow the way the DICOM Standard represents information in terms of modules, macros, and data elements. The attributes of entities in DICOM were named similarly to those in the DICOM Ontology, and the cardinality and conditionality of relationships were modeled to be identical to the extent that they are consistent within DICOM.

The DICOM Ontology provides a formal, explicit, and logically consistent description of entities in the imaging domain, which are represented by classes such as patients, images, and imaging devices. The ontology also describes the properties, features, and attributes (also called “slots” or “properties”) of each domain entity. The DICOM Ontology was developed with Protégé (http://protege.stanford.edu), a widely used system for creating and maintaining ontologies (16).

Ontology Scope and Hierarchy

We created two domain models in the DICOM Ontology: a real-world model and a DICOM entity model. The real-world model includes classes that match the ways people think about the radiology domain in terms of patients, studies, images, and other features (Figs 1, 2). In this model, real-world objects are modeled hierarchically (Fig 3). The DICOM Ontology not only models the DICOM real-world model; it also explicitly creates connections between real-world classes and the classes that model the corresponding DICOM information entities. This function enables the ontology to stay true to the DICOM Standard while making the connections between real-world objects and the DICOM model explicit.

Figure 1.

Figure 1

Open in a new tab

Entity-relationship diagram illustrates the DICOM real-world model, in which a Patient has one or more Studies and each Study contains one or more Series. The Series serves as a container that aggregates zero or more objects such as Waveforms, Images, Raw Data, and Presentation States. The numbers next to the arrows or shapes indicate the cardinality of the relationship: 1 = exactly one, 0-n = zero or more, and 1-n = one or more. For example, in the “Patient” to “Study” relationship, a Patient has one or more Study objects, but a Study pertains to only one Patient. (Adapted, with permission of the National Electrical Manufacturers Association, from the DICOM Standard [2009 edition; Part 3, Figure 7-1a].)

Figure 2.

Figure 2

Open in a new tab

Entity-relationship diagram shows the DICOM information model, which distinguishes real-world objects, such as patients, from their corresponding DICOM objects, the information-system representations of real-world objects. Instead of the real-world “Patient,” the information model depicts the Patient IOD, which references one or more Study IODs. 1 = exactly one, 0-n = zero or more, and 1-n = one or more. (Adapted, with permission of the National Electrical Manufacturers Association, from the DICOM Standard [2009 edition; Part 3, Figure 7-2a].)

Figure 3.

Figure 3

Open in a new tab

A portion of the DICOM Ontology model in the Protégé system shows the specific types of real-world objects. The open circle next to “Real_World_Object” indicates that this class is abstract; it cannot have any instances. The closed circles next to the other entities indicate that they are concrete classes and therefore may have instances. Thus, “Patient” describes the properties of a patient, and an instance of this class would describe a specific patient. According to this diagram, “CT_Image” is a subsclass of “Image,” which is a subclass of “Real_World_Object.”

Each object in the real-world model contains a slot called “has_DICOM_IE,” which links to the corresponding DICOM information entity that models the real-world object. For example, the “CT_Image” real-world object links to the “CT_Image_Module” DICOM object. Classes in the real-world model are connected to other real-world objects by using relations that are modeled as slots. For example, the “Patient” real-world object relates to a “Study” through the “has_study” slot, and it relates to a “Visit” in the “makes_visit” slot (Fig 4).

Figure 4.

Figure 4

Open in a new tab

The “Patient” object. View of the Protégé ontology development system shows the “Patient” object. In addition to the hierarchical relationship to “Real_World_Object” (at left), the “Patient” object has two attributes, or slots. The “has_study” attribute indicates an instance of the “Study” class; thus, an instance of “Patient” (ie, a specific patient) will have one or more “has_study” links to specific “Study” instances. Similarly, the “makes_visit” relation indicates one or more “Visit” instances. The “has_DICOM_IE” relation (bottom right) links the real-world “Patient” object to corresponding information entities in DICOM, namely, the “Patient_Module” and “Clinical_Trial_Subject_Module” objects.

Because the DICOM Standard is large and our goal was to develop an initial model that could be expanded in the future to encompass the remainder of DICOM, we limited the scope of our project to one IOD: the CT Image IOD, which is defined in Part 3, section A.3 of the DICOM Standard (Figs 5, 6). This IOD was selected because it has a manageable size and is representative of the diversity of DICOM objects that need to be modeled in the DICOM Ontology. Therefore, it may serve as a template for modeling other DICOM IODs in the future.

Figure 5.

Figure 5

Open in a new tab

The CT Image IOD. The CT Image IOD is defined as a list of modules: The first column gives the name of each Information Entity, the second column gives the name of a DICOM module, and the third column gives the section of Part 3 of the DICOM Standard in which the module is defined. The last column specifies whether a module is mandatory (M), user-defined (U), or conditional (C). (Reprinted, with permission of the National Electrical Manufacturers Association, from the DICOM Standard [2009 edition; Part 3, Table A.3-1].)

Figure 6.

Figure 6

Open in a new tab

Ontology model of the CT Image IOD. View of the Protégé ontology model of the CT Image IOD shows the representation of each line of the table in Figure 5 as a “CT_Image_IOD_Specification” object, which specifies the module name (eg, Patient_Module) and usage (eg, “M”). The “CT_Image_IOD” object has an attribute (“IOD Module Specifications”) that associates all of these modules with the IOD.

Modeling DICOM Modules and Macros

A DICOM module specifies the DICOM data elements that must appear or that may appear in the DICOM model. Each module is defined in a table in the DICOM Standard. For example, the “CT Image” module lists a set of data elements that are required or permitted to describe a CT image (Figs 7, 8).

Figure 7.

Figure 7

Open in a new tab

A portion of the table that defines the attributes of the CT Image module. Attribute names and their tags are defined in Part 6 of the DICOM Standard. Each data element (attribute) has a unique pair of tags that consist of four hexadecimal (base-16) digits. The “Type” indicates whether elements are required (type 1) or optional (type 2). (Reprinted, with permission of the National Electrical Manufacturers Association, from the DICOM Standard [2009 edition; Part 3, Table C.8-3].)

Figure 8.

Figure 8

Open in a new tab

Attributes that constitute the CT Image module. View of the Protégé ontology shows the attributes that make up the CT Image module. Each module contains a slot that lists all of its constituent data elements (attributes), which are listed here as “children” or subclasses of the “CT_Image_Attribute” class. Each attribute includes pointers to a data element (as defined in the DICOM Data Dictionary, Part 5) and a data element type.

The DICOM Standard uses macros to represent repeated groups of data elements within a definition of a module. In our model, two types of macros are considered: “inline” macros and “fully enumerated” macros. An inline macro appears completely within the table in which it is used. For example, in Figure 9, three rows of the module definition table are prefixed by one or more “>” characters, which define an inline macro for “Other_Patient_IDs.” A fully enumerated macro is incorporated into a module by way of a reference to a separate table where the macro is described. For example, the “Patient” module includes the service-object pair (SOP) instance reference macro (Fig 9, 7th row). SOPs are the functional units of DICOM and constitute a service class and an information object. Information objects define the core content of medical imaging, and service classes define what to do with that content. Thus, the attributes of this fully enumerated macro (which is described in DICOM Part 3, Table 10-11) should be directly included in the Patient module specification. Inline and fully enumerated macros are modeled the same way, and, in fact, modeling of macros is analogous to that of modules, except the attributes of a macro are subclasses of “DICOM_Macro_Attribute” rather than of “DICOM_Model_Attribute.”

Figure 9.

Figure 9

Open in a new tab

A portion of the table that defines the attributes of the Patient module shows attribute names and their tags, which are defined in Part 6 of the DICOM Standard. “Type” specifies whether attributes are required (type 1), optional (type 2), or conditional (type 3). An SOP, the functional unit of DICOM, pairs a service class with an information object and contains both fully enumerated macros (eg, the “SOP Instances Reference Macro”) and inline macros (eg, the “Other Patient IDs Sequence”). (Reprinted, with permission of the National Electrical Manufacturers Association, from the 2009 DICOM Standard [Part 3, Table C.7-1].)

Class Hierarchy

The DICOM model consists of classes named according to the types of entities in DICOM such as elements, information entities, modules, and IODs (Figs 7, 8). The ontology also incorporates macros, which are relatively short lists of data elements that are used in a variety of DICOM modules (Figs 9, 10). The real-world model comprises subclasses of “Real World Object,” which represents entities in the radiology domain.

Figure 10a.

Figure 10a

Open in a new tab

Protégé ontology development environment shows the “SOP Instance Macro,” a fully enumerated macro (a), and the “Other Patient IDs Macro,” an inline macro (b). In DICOM, macros provide a way to specify frequently used or repeated data elements within modules. In b, the table reference indicates the corresponding table in the DICOM Standard, and “Macro Attributes” lists the data elements included in the macro.

Figure 10b.

Figure 10b

Open in a new tab

Protégé ontology development environment shows the “SOP Instance Macro,” a fully enumerated macro (a), and the “Other Patient IDs Macro,” an inline macro (b). In DICOM, macros provide a way to specify frequently used or repeated data elements within modules. In b, the table reference indicates the corresponding table in the DICOM Standard, and “Macro Attributes” lists the data elements included in the macro.

A developer who is interested in determining which data elements DICOM uses to describe CT images may access this information by looking up the real-world object “CT_Image,” noting the DICOM information entities associated with the object (this is done by following the “has_DICOM_IE” slot), and directly browsing the DICOM elements associated with the corresponding DICOM objects. One such object is the “CT_Image_Module” entity, which indicates various module attributes (through the “Module_Attributes_Or_Macros” slot) such as “CT_Image_Attribute_001,” which specifies the data element “Image_Type (0008,0008).” Thus, one may directly trace general real-world objects, such as “CT_Image,” to specific DICOM data elements such as “Image_Type” and “Samples_per_Pixel.” The relationships among classes in this model are shown in Figure 11.

Figure 11.

Figure 11

Open in a new tab

Diagram shows the relationships between various objects that constitute the CT Image IOD.

Other Approaches

Other approaches to represent the structure of the DICOM Standard have been taken. The DICOM Standards Committee undertook to encode the entire standard into the Extensible Markup Language (XML), and diagrams within the Standard are being redrawn in the XML-compatible Scalable Vector Graphics format (17). Encoding of the Standard into XML should facilitate modeling the remainder of the Standard as an ontology. The Oracle 10g database management system (Oracle Corporation, Redwood Shores, Calif) and the open-source dcm4che2 DICOM Toolkit (http://dcm4che.org/) include functions for exporting DICOM objects into XML (18). Encoding of the DICOM standard or of DICOM objects into XML provides a more structured approach than the textual format of the current standard. Such information is useful and may be used to form part of an ontological model of the DICOM Standard. We sought to provide additional functionality by modeling the relationships between DICOM entities and classes of entities.

Applications

In 2004, the National Cancer Institute launched the Cancer Bioinformatics Grid (caBIG) program to promote sharing of information technology infrastructure, data, and applications among federally supported cancer research centers (19–21). Because of the importance of medical imaging for cancer research and patient care, the caBIG In-vivo Imaging Workspace undertook several major open-source software projects (22) Projects such as the eXtensible Imaging Platform (XIP), Annotation and Image Markup (AIM), and Algorithm Validation Tools (AVT) require access to the information contained in DICOM and may benefit from a Reference Information Model of DICOM. Each group is creating models that contain subsets of the information in DICOM needed for their project such as patient, study or series, and anatomic information; radiology findings; and image pixel data. A developer interested in learning which data elements DICOM uses to describe CT images may access this information by looking up the real-world object “CT_Image,” finding the DICOM information entities associated with it (by following the “has_DICOM_IE” slot), and directly browsing the DICOM elements associated with the object.

The DICOM Ontology represents a more comprehensive and complete model of imaging objects than is currently available to caBIG projects. To demonstrate the potential relevance and value of the DICOM Ontology to caBIG projects, we examined the information model adopted by the National Biomedical Image Archive (http://ncia.nci.nih.gov/) and compared its data elements to those in the DICOM Ontology. The current NBIA model is limited in scope because it was developed on the basis of the NBIA database in use at the time; it contains only 76 of the more than 300 attributes that describe CT image objects. For example, “Series Date” and many DICOM attributes related to image pixel data are absent from the NBIA model. These data elements are readily accessible in the DICOM Ontology, which allows developers to more easily peruse the DICOM model and extend the content of NBIA beyond caBIG, where access to the DICOM Standard is needed.

Future Work

Expansion to Include All of DICOM

The DICOM Ontology currently models a single IOD from the DICOM Standard to demonstrate the feasibility of building the ontology. However, to be useful to a broad range of projects, the DICOM Ontology must include content from all of the relevant imaging IODs. The current structure of the DICOM Ontology will be useful for modeling the rest of DICOM. The steps needed to create the content in the DICOM Ontology are outlined in a report to the National Cancer Institute (https://gforge.nci.nih.gov/projects/dicomontphase1/).

Ontology-based Applications

Although the overarching objective of the DICOM Ontology project is to produce a computer-readable information model of the DICOM Standard, certain applications must be developed in order for the ontology to be used for a variety of purposes. Such applications will enable use of the DICOM Ontology to further develop the DICOM Standard and to support the use of DICOM in biomedical imaging software. In particular, it will be important to provide a text-based view of the DICOM Ontology similar to the text-based format of the DICOM Standard. To support this functionality, software may be developed to extract from the DICOM Ontology the tabular components of the entire standard that would otherwise be maintained manually (eg, the tables in Parts 3 and 6); Part 3 alone consists of hundreds of tables that span more than 1300 pages of printed text. Because of the inherent challenges of maintaining so many tables, automated approaches to validate the standard and generate its textual representation may help assure the quality, consistency, and accuracy of the content.

Vocabularies, Ontologies, and the caDSR Common Data Elements

Some attributes in DICOM IODs are controlled terms that are summarized in tables of terminology in Part 16 of the DICOM Standard. Harmonization of all such DICOM terminology with the Cancer Data Standards Registry and Repository (caDSR) (https://cabig.nci.nih.gov/concepts/caDSR/) and Enterprise Vocabulary Services (EVS) (https://cabig.nci.nih.gov/concepts/EVS/) will be beneficial. This process will include the following tasks: (a) extracting tables from Part 16 of the DICOM Standard and their relevant context groups, (b) reconciling the coded concepts in those tables with EVS or importing them into EVS, (c) reconciling the coded concepts with RadLex, and (d) identifying each term in EVS that may be included in the DICOM Ontology as well as the appropriate source name and unique identifiers, which will serve as references to the source terminology. If no existing terms in EVS are required by the DICOM Ontology, new terms will need to be created for incorporation into EVS.

Summary

The DICOM Ontology is readable by humans and computable by machines. It expresses hierarchical (subtype-supertype) and merological (part-whole) relationships among the information entities, modules, and data elements that constitute the DICOM Standard, and it may facilitate construction of wide-scale interoperable systems for biomedical imaging. It was created to support the caBIG initiative, and it may serve as a foundation of systems to be implemented nationwide for cancer research and patient care.

Acknowledgments

The authors thank the National Electrical Manufacturers Association for granting permission to reprint content from the DICOM Standard. The DICOM Standard undergoes frequent modification; the current version is freely available at http://dicom.nema.org/.

Presented as an education exhibit at the 2009 RSNA Annual Meeting.

C.E.K. is an officer and shareholder for Hotlight; C.P.L. serves on the advisory board for Reed Elsevier and General Electric Company; D.S.C. is an officer and shareholder for Hotlight and a speaker for Carestream Health; and D.L.R. received a research grant from General Electric Company.

Supported in part by the National Cancer Institute as part of its Cancer Biomedical Informatics Grid (caBIG) initiative.

Abbreviations:

caBIG
Cancer Biomedical Informatics Grid
caDSR
Cancer Data Standards Registry and Repository
DICOM
Digital Imaging and Communications in Medicine
EVS
enterprise vocabulary server
IOD
information object definition
SOP
service-object pair

References

  • 1.Flanders AE, Carrino JA. Understanding DICOM and IHE. Semin Roentgenol 2003;38(3):270–281 [DOI] [PubMed] [Google Scholar]
  • 2.Kahn CE, Jr, Carrino JA, Flynn MJ, Peck DJ, Horii SC. DICOM and radiology: past, present, and future. J Am Coll Radiol 2007;4(9):652–657 [DOI] [PubMed] [Google Scholar]
  • 3.National Electrical Manufacturers Association Digital Imaging and Communication in Medicine (DICOM). http://dicom.nema.org/. Accessed December 1, 2009
  • 4.Gruber TR. Toward principles for the design of ontologies used for knowledge sharing. Int J Hum Comput Stud 1995;43(5-6):907–928 [Google Scholar]
  • 5.Rubin DL. Creating and curating a terminology for radiology: ontology modeling and analysis. J Digit Imaging 2008;21(4):355–362 [DOI] [PMC free article] [PubMed] [Google Scholar]
  • 6.Harris MA, Clark J, Ireland A, et al. The Gene Ontology (GO) database and informatics resource. Nucleic Acids Res 2004;32(database issue):D258–D261 [DOI] [PMC free article] [PubMed] [Google Scholar]
  • 7.Rosse C, Mejino JL., Jr A reference ontology for biomedical informatics: the Foundational Model of Anatomy. J Biomed Inform 2003;36(6):478–500 [DOI] [PubMed] [Google Scholar]
  • 8.Müller HM, Kenny EE, Sternberg PW. Textpresso: an ontology-based information retrieval and extraction system for biological literature. PLoS Biol 2004;2(11):e309. [DOI] [PMC free article] [PubMed] [Google Scholar]
  • 9.Bodenreider O. Biomedical ontologies in action: role in knowledge management, data integration and decision support. Yearb Med Inform 2008:67–79 [PMC free article] [PubMed] [Google Scholar]
  • 10.Manning M, Aggarwal A, Gao K, Tucker-Kellogg G. Scaling the walls of discovery: using semantic metadata for integrative problem solving. Brief Bioinform 2009;10(2):164–176 [DOI] [PubMed] [Google Scholar]
  • 11.Reimand J, Tooming L, Peterson H, Adler P, Vilo J. GraphWeb: mining heterogeneous biological networks for gene modules with functional significance. Nucleic Acids Res 2008;36(web server issue):W452–W459 [DOI] [PMC free article] [PubMed] [Google Scholar]
  • 12.Rubin DL, Shah NH, Noy NF. Biomedical ontologies: a functional perspective. Brief Bioinform 2008;9(1):75–90 [DOI] [PubMed] [Google Scholar]
  • 13.Smith B, Ashburner M, Rosse C, et al. The OBO Foundry: coordinated evolution of ontologies to support biomedical data integration. Nat Biotechnol 2007;25(11):1251–1255 [DOI] [PMC free article] [PubMed] [Google Scholar]
  • 14.Bodenreider O, Stevens R. Bio-ontologies: current trends and future directions. Brief Bioinform 2006;7(3):256–274 [DOI] [PMC free article] [PubMed] [Google Scholar]
  • 15.Rubin DL, Lewis SE, Mungall CJ, et al. National Center for Biomedical Ontology: advancing biomedicine through structured organization of scientific knowledge. OMICS 2006;10(2):185–198 [DOI] [PubMed] [Google Scholar]
  • 16.Rubin DL, Noy NF, Musen MA. Protégé: a tool for managing and using terminology in radiology applications. J Digit Imaging 2007;20(suppl 1):34–46 [DOI] [PMC free article] [PubMed] [Google Scholar]
  • 17.DICOM Standards Committee April 13, 2010 Minutes: National Electrical Manufacturers Association, Rosslyn, VA, 2010. http://medical.nema.org/Dicom/minutes/Committee/2010/2010-04/DICOM_2010-04-13_Min.doc/DICOM_2010-04-13_Min.doc. Accessed July 25, 2010
  • 18.Gettys B, Mauro J. Oracle Database 10g Release 2 DICOM Medical Image Support: 2005. Oracle Corporation, Redwood Shores, CA: http://www.oracle.com/technology/products/intermedia/pdf/dicom_technical_wp.pdf. Accessed July 25, 2010 [Google Scholar]
  • 19.caBIG Strategic Planning Workspace The Cancer Biomedical Informatics Grid (caBIG): infrastructure and applications for a worldwide research community. Stud Health Technol Inform 2007;129(pt 1):330–334 [PubMed] [Google Scholar]
  • 20.Fenstermacher D, Street C, McSherry T, Nayak V, Overby C, Feldman M. The Cancer Biomedical Informatics Grid (caBIG™). Conf Proc IEEE Eng Med Biol Soc 2005;1:743–746 [DOI] [PubMed] [Google Scholar]
  • 21.von Eschenbach AC, Buetow K. Cancer informatics vision: caBIG. Cancer Inform 2007;2:22–24 [PMC free article] [PubMed] [Google Scholar]
  • 22.Prior FW, Erickson BJ, Tarbox L. Open source software projects of the caBIG In Vivo Imaging Workspace Software special interest group. J Digit Imaging 2007;20(suppl 1):94–100 [DOI] [PMC free article] [PubMed] [Google Scholar]

Articles from Radiographics are provided here courtesy of Radiological Society of North America

RESOURCES