DOI: 10.1148/rg.275065139
RadioGraphics 2007;27:1523-1530
© RSNA, 2007
Informatics in Radiology
SimpleDICOM Suite: Personal Productivity Tools for Managing DICOM Objects
Barton F. Branstetter, IV, MD,
Steven D. Uttecht, BS,
David M. Lionetti, BArch, and
Paul J. Chang, MD
1 From the Department of Radiology, University of Pittsburgh Medical Center, 200 Lothrop St, PUH Room D132, Pittsburgh, PA 15213 (B.F.B., S.D.U., D.M.L.); and the Departments of Radiology and Pathology, University of Chicago, Chicago, Ill (P.J.C.). Presented as an infoRAD exhibit at the 2005 RSNA Annual Meeting. Received July 24, 2006; revision requested November 15 and received January 2, 2007; accepted February 12. S.D.U. received research funding from Koninklijke Philips Electronics NV (Stentor); P.J.C. is a cofounder of Stentor; neither remaining author has any financial relationships to disclose.
Address correspondence to B.F.B. (e-mail: bfb1{at}pitt.edu).
 |
Abstract
|
|---|
Commercial picture archiving and communication systems (PACS) are adept at supporting mainstream radiology work flow, but radiologists frequently encounter situations requiring additional functionality. For example, the incorporation of foreign or nonradiologic images and the deidentification of examinations for research purposes are useful tasks that do not fall within the purview of most commercial PACS. A suite of free, downloadable, vendor-independent software programs designed as PACS add-ons, the SimpleDICOM (Digital Imaging and Communications in Medicine) Suite, has been developed to aid radiologists in performing these tasks. Clinically relevant software design and informed administrative decisions during deployment allow optimal function of this software suite, which is available for download from the Internet.
© RSNA, 2007
|
Introduction
|
|---|
In many ways, picture archiving and communication systems (PACS) have become a mature technology. There are numerous vendors offering second- and third-generation commercial products with various pricing and support models. Image storage and retrieval are no longer technologic hurdles, and competing products are differentiated on the basis of subtleties of user interface. Communication standards such as Digital Imaging and Communications in Medicine (DICOM) are widely accepted, allowing users to select best-of-breed components from different vendors (1). Modern PACS have begun to show a uniformity of interface, which suggests a convergence of design evolution. Images are shown in well-recognized presentation states that have become familiar across different PACS.
Despite the maturity of PACS in general, there are many tasks within the radiology department that are not part of the standard work flow supported by commercial PACS—peripheral tasks that do not affect every radiologic examination but that must be performed several times each day throughout a radiology department. For example, most radiologists are provided with comparison examinations from other enterprises on a daily basis. As PACS have become more prevalent, these examinations are increasingly provided on digital media such as the compact disk (CD), rather than on film (2). For uniformity of presentation, and to ensure the persistence of the images in the local environment, it would be desirable to incorporate examinations from these "outside" CDs into the local PACS.
Another such task is incorporation of nonradiologic images into the PACS (3). The hospital system may wish to leverage the robust storage and distribution system of its radiology PACS to manage medical images from other departments (eg, endoscopic images, retinal images, clinical photographs). Within the radiology department, it is often useful to control the distribution of DICOM images outside the usual PACS pathways, so that deidentified research and teaching servers can be established.
Because these peripheral tasks are not included in the baseline work flow of conducting and interpreting radiologic studies, they are frequently overlooked by both vendors and users when planning PACS implementations. Eventually, PACS vendors will develop solutions to these work flow issues to differentiate their product from that of the competition. Even with pressure from users, however, commercial software is, of necessity, slow to adapt to less frequently performed work flow tasks. In the interim, additional software is needed to address these peripheral tasks to ensure efficient radiology operations in a digital environment.
In this article, we present SimpleDICOM Suite, a suite of four free, downloadable, vendor-independent software applications (Simple-DICOM Sender, SimpleDICOM Wrapper, SimpleDICOM Receiver, SimpleDICOM Viewer) that address the peripheral tasks not generally included in commercial PACS implementations. We discuss SimpleDICOM Suite in terms of functional requirements and productivity tools. In addition, we briefly discuss pertinent financial and scheduling issues.
|
Functional Requirements
|
|---|
In developing software add-ons for PACS, we targeted four work flow tasks that fall outside the usual specifications of commercial PACS:
- Incorporating foreign examinations from other hospitals supplied on digital media such as CDs.
- Incorporating nonradiologic images from other medical departments.
- Receiving and storing examinations in a de-identified format on a local desktop personal computer (PC).
- Viewing DICOM objects outside the confines of the main PACS.
For each of these tasks, we developed a software tool to support the desired work flow. These tools shared several critical design requirements, the first two of which were ease of download and ease of installation. The software was specifically designed for novice users to download and install on standard desktop PCs. The installation packages are similar in appearance to those of commercial PC software, so that the process will be familiar to most users. Desktop icons are automatically generated, and step-by-step instructions are provided. Ease of deployment was considered critical because some of the software tools are designed to be distributed in clinics and offices throughout the hospital enterprise. To avoid overburdening support personnel, the software should be almost self-explanatory, so that troubleshooting can be accomplished without the immediate physical presence of these personnel.
Ease of use was also considered a critical design element. The most frequently used controls were made prominent, so that base-case users wouldn’t be confused by more powerful options. Color coding of buttons was used to guide novice users through the basic processes.
It was important that the software be vendor independent, so that it could interact with virtually any PACS. Conformance to DICOM standards ensures interoperability. The software was designed to run on off-the-shelf computers (primarily desktop PCs) without any specialized hardware.
The software was also designed to be distributed as freeware. Although open-source coding was considered, the use of commercial software development tools interfered with a fully open-source implementation. Because Windows operating systems (Microsoft, Redmond, Wash) are ubiquitous in hospital environments, the software was written for these platforms. Macintosh operating systems (Apple Computer, Cupertino, Calif) are not supported.
|
Productivity Tools in the SimpleDICOM Suite
|
|---|
A separate software element was developed to address the functionality of each of the tasks listed in the design specifications. SimpleDICOM Sender extracts images from outside CDs and sends them to the hospital PACS; Simple-DICOM Wrapper imports nonradiologic images into the PACS; SimpleDICOM Receiver deidentifies and stores DICOM objects; and Simple-DICOM Viewer displays DICOM images outside the PACS environment. Taken together, these four productivity tools are called the Simple-DICOM Suite, each element of which will be discussed separately.
SimpleDICOM Sender
SimpleDICOM Sender reads DICOM Part 10 files from a CD or other digital medium and transmits the images to a PACS or other DICOM receiver. The software can automatically scan the entire file structure of a disk to identify DICOM files and extract the appropriate metadata (eg, name, medical record number, date of birth, date of examination) (Fig 1a). SimpleDICOM Sender is designed with connectivity and error checking built in, so that transmission errors can be readily identified.
View larger version (67K):
[in this window]
[in a new window]
[Download PPT slide]
|
Figure 1a. SimpleDICOM Sender. (a) The software searches a CD for DICOM files. Search parameters can be modified to balance speed of search against completeness of search. Desired examinations are selected by the user. Color-coded buttons (circled) make base-case navigation straightforward. (b) Patient metadata are modified to conform to the local hospital environment. Walk-through instructions (not shown) are always available. (c) While images are being transferred to the PACS, status updates (circled) and error capturing (arrow) are used to guide any necessary troubleshooting.
|
|
View larger version (60K):
[in this window]
[in a new window]
[Download PPT slide]
|
Figure 1b. SimpleDICOM Sender. (a) The software searches a CD for DICOM files. Search parameters can be modified to balance speed of search against completeness of search. Desired examinations are selected by the user. Color-coded buttons (circled) make base-case navigation straightforward. (b) Patient metadata are modified to conform to the local hospital environment. Walk-through instructions (not shown) are always available. (c) While images are being transferred to the PACS, status updates (circled) and error capturing (arrow) are used to guide any necessary troubleshooting.
|
|
View larger version (58K):
[in this window]
[in a new window]
[Download PPT slide]
|
Figure 1c. SimpleDICOM Sender. (a) The software searches a CD for DICOM files. Search parameters can be modified to balance speed of search against completeness of search. Desired examinations are selected by the user. Color-coded buttons (circled) make base-case navigation straightforward. (b) Patient metadata are modified to conform to the local hospital environment. Walk-through instructions (not shown) are always available. (c) While images are being transferred to the PACS, status updates (circled) and error capturing (arrow) are used to guide any necessary troubleshooting.
|
|
Patient metadata can be modified before exporting images (Fig 1b), thereby allowing unique identifiers such as medical record number to be modified to align with the new hospital system. Modification of patient metadata also allows "anonymization" if desired. During transmission of data, SimpleDICOM Sender monitors the transactions and provides updates on transfer status (Fig 1c). SimpleDICOM Sender acts as a client-side DICOM Service Class User (SCU).
Unfortunately, some commercial PACS store onto portable media in proprietary formats, rather than using DICOM Part 10 standards. Such studies cannot be imported without dedicated DICOM export software provided by the PACS vendor.
SimpleDICOM Wrapper
SimpleDICOM Wrapper takes non-DICOM images, such as Joint Photographic Experts Group (JPEG) and Tagged Image File Format (TIFF) files, and turns them into DICOM objects that can be stored in a PACS (Fig 2). Each image is given a DICOM header and formatted to DICOM specifications. Such images can then be distributed along with radiologic images throughout the enterprise. Metadata such as patient name, medical record number, and study date and time are provided by the user in constrained input fields. The user interface is customized to the type of image being incorporated (Fig 2).
View larger version (65K):
[in this window]
[in a new window]
[Download PPT slide]
|
Figure 2a. SimpleDICOM Wrapper. (a) Dermatologic images, obtained with a digital camera, are uploaded into the software. Appropriate metadata are assigned to the images with constrained data fields or by clicking on the homunculus at the upper right. (b) Retinal images require a different interface for incorporation and different fields for metadata. Interface customization is essential for software acceptance. (c) With respect to the display and distribution of images within the hospital PACS, nonradiologic images may appear in the PACS along with radiologic images or may be conferred special status to avoid cluttering.
|
|
View larger version (59K):
[in this window]
[in a new window]
[Download PPT slide]
|
Figure 2b. SimpleDICOM Wrapper. (a) Dermatologic images, obtained with a digital camera, are uploaded into the software. Appropriate metadata are assigned to the images with constrained data fields or by clicking on the homunculus at the upper right. (b) Retinal images require a different interface for incorporation and different fields for metadata. Interface customization is essential for software acceptance. (c) With respect to the display and distribution of images within the hospital PACS, nonradiologic images may appear in the PACS along with radiologic images or may be conferred special status to avoid cluttering.
|
|
View larger version (45K):
[in this window]
[in a new window]
[Download PPT slide]
|
Figure 2c. SimpleDICOM Wrapper. (a) Dermatologic images, obtained with a digital camera, are uploaded into the software. Appropriate metadata are assigned to the images with constrained data fields or by clicking on the homunculus at the upper right. (b) Retinal images require a different interface for incorporation and different fields for metadata. Interface customization is essential for software acceptance. (c) With respect to the display and distribution of images within the hospital PACS, nonradiologic images may appear in the PACS along with radiologic images or may be conferred special status to avoid cluttering.
|
|
Incorporated images appear in the PACS time-line as though they were radiologic images (Fig 2c). Users must ensure that patients are registered in the hospital information system and radiology information system (RIS) before images are sent to the PACS.
SimpleDICOM Receiver
SimpleDICOM Receiver is a client-side DICOM Service Class Provider. It resides in the background on a client machine (either a desktop PC or a server) and awaits DICOM files from a DICOM SCU. Typical SCUs are modalities or PACS. Data are saved in a format compliant with DICOM Part 10 (1).
The SimpleDICOM software optionally deidentifies incoming examinations for compliance with the Health Insurance Portability and Accountability Act (HIPAA) (4). Like other elements of the SimpleDICOM Suite, SimpleDICOM Receiver is designed to be easy to download and deploy on a local machine, without extensive computer knowledge. The program maintains a log of received files and provides steadily updated information during transfer (Fig 3). The user interface may optionally be hidden so that the software runs in the background with minimal system demands.
View larger version (47K):
[in this window]
[in a new window]
[Download PPT slide]
|
Figure 3a. SimpleDICOM Receiver. (a) List of incoming studies. Note that, with the click of a button (arrow), the interface can be hidden to run in the background. (b) File log. The file log provides a history of transactions as well as error capture for troubleshooting.
|
|
View larger version (43K):
[in this window]
[in a new window]
[Download PPT slide]
|
Figure 3b. SimpleDICOM Receiver. (a) List of incoming studies. Note that, with the click of a button (arrow), the interface can be hidden to run in the background. (b) File log. The file log provides a history of transactions as well as error capture for troubleshooting.
|
|
SimpleDICOM Viewer
SimpleDICOM Viewer displays DICOM images that are stored on the local machine, usually a desktop PC. Future software versions will include up-to-date DICOM libraries to ensure that most modern encoding schemes, including encapsulated JPEG images, are supported. The software includes basic PACS functionality such as window width and level (Fig 4). Basic image manipulation functions such as flip, rotate, invert, and crop are also permitted. SimpleDICOM Viewer can export images to traditional file formats such as JPEG or TIFF for use in teaching, research, or remote consultation.
View larger version (53K):
[in this window]
[in a new window]
[Download PPT slide]
|
Figure 4. SimpleDICOM Viewer. This software element provides basic PACS functionality outside the main hospital PACS. This functionality may be particularly useful for research and teaching.
|
|
|
Discussion
|
|---|
SimpleDICOM Sender
One of the major benefits of using SimpleDICOM Sender is the ability to extract and retain images in the PACS while returning the original medium to the patient. Patients understandably wish to keep their medical records with them in case they transfer care to other facilities, and there is the (reasonable) fear that any institution may lose the CD on which an examination is stored. Using SimpleDICOM Sender to extract images allows radiologists and clinicians to retain images for comparison with future studies and for documentation of the clinical decision-making process.
Another benefit of placing images into the PACS is uniformity of viewing interface. Exported CDs from different vendors will have unfamiliar software, and the high-security workstations that are commonly present in hospitals and clinics may be unable to display images from the CDs. Furthermore, comparing two examinations is easier when the task is performed in a single software environment, rather than switching between two different programs. Radiologists who provide written dictations when they perform a secondary interpretation will find it easier to dictate in the familiar environment of the local PACS.
Institutions that use SimpleDICOM Sender will need to decide on an appropriate work flow model for image incorporation. Without constraints, the PACS might become flooded with foreign images. In a centralized work flow model, only specific personnel within the radiology department are authorized to send images to the PACS. Foreign CDs are brought to the radiology file room or PACS data center for image incorporation. In a distributed model, personnel in each clinic or ward are authorized to incorporate foreign examinations. This model is more convenient for the clinicians but is harder to support and manage. SimpleDICOM Sender is designed to be simple to use, so that only minimal training is needed for distributed clerical personnel to use the software.
Another important choice is whether to allow permanent storage of images in the main PACS or to relegate foreign examinations to a temporary cache or secondary PACS. A robust business model would allow both options, since some outside examinations may not be directly pertinent to patient care, a factor that is only identified after incorporation and review of images. Other images may be of use only until a relevant comparison image is generated. However, some images need to be stored permanently for long-term comparison.
Some PACS vendors allow incorporation of foreign examinations if the examinations were created using that vendor’s software. Simple-DICOM Sender provides vendor independence by relying only on the DICOM Part 10 file format (5). Unfortunately, some vendors use proprietary file formats rather than conforming to the DICOM standard. SimpleDICOM Sender is unable to interpret such media.
The Integrating the Healthcare Enterprise (IHE) profile on Portable Data for Imaging (PDI) specifies much of the same functionality that is available from SimpleDICOM Sender and has been implemented by some PACS vendors (6). If the IHE-PDI specifications were universally implemented, SimpleDICOM Sender would be unnecessary. As of this writing, however, the PDI specifications have not yet been finalized, and once they are finalized, it may be several years before the majority of vendors are in full compliance. Critical functionality, such as the ability to modify patient metadata to conform to the host PACS, may not be available from all vendors for some time.
SimpleDICOM Wrapper
Although radiologists were the first to embrace the digital transformation of medical imaging, most other departments use some form of medical imaging to document and support clinical decision making. For example, pathologists use gross and microscopic images of pathologic specimens; ophthalmologists take pictures of the retina; dermatologists take pictures of specific skin lesions to evaluate change over time, and may also use full-body photography in patients at high risk for skin cancer; and gastroenterologists and otolaryngologists obtain endoscopic images.
Nonradiologic medical images are grouped under the term "visible light [VL] images." DICOM standards are being formulated to account for VL images, and some of these standards are now available (7); however, it may be years before PACS vendors fully incorporate support for these images. SimpleDICOM Wrapper was designed to allow incorporation of VL images into any existing PACS.
The advantage of placing VL images into the radiology PACS is that the existing PACS distribution model can be leveraged for all medical images. Although it may be possible to create a parallel distribution method, such a method would be less efficient for the hospital enterprise. Furthermore, incorporation of images into an electronic medical record is made easier if all images are derived from a single source. Resource sharing across all medical images reduces hardware, development, and support requirements.
One of the keys to successfully incorporating VL images is customization to different users (Fig 2). The metadata required to put an image into the appropriate medical context differ with the body part being imaged. For example, images of the skin need to be placed on a homunculus, whereas retinal scans require associated physical examination findings. These metadata can be incorporated into the DICOM header within specialized fields. These metadata "tags" are defined within SimpleDICOM Wrapper for ophthalmology and dermatology. Future versions of the SimpleDICOM Suite will allow user customization of stored metadata. Customization of the interface allows SimpleDICOM Wrapper to optimally support the work flow in each department.
The DICOM Visible Light standard provides syntax for the incorporation of nonradiologic images into a PACS. Thus, most vendors’ PACS will accept VL images in this format. However, the DICOM standard does not provide specific recommendations for incorporating images that do not originate on a DICOM-compliant modality or for applying appropriate header information and patient metadata (7).
SimpleDICOM Viewer and Receiver
SimpleDICOM Viewer and Receiver perform functions similar to those of a traditional PACS, namely, storing and displaying DICOM objects. However, they can be deployed in ways for which traditional PACS are not intended, and thus may supplement existing PACS implementations. In particular, the anonymization tool in Simple-DICOM Receiver has been useful for establishing deidentified research servers, which became necessary after the passage of the privacy regulations in HIPAA. We have found anonymization particularly useful for multi-institutional trials, in which it allows images to be sent from one institution to another without elaborate security protocols. Digital teaching file software makes similar use of anonymization. Although our institution has opted for a central teaching file server, users at other institutions could deploy SimpleDICOM Receiver on a desktop PC to create deidentified personal teaching files that include entire examinations (8).
In combination, SimpleDICOM Viewer and Receiver can provide limited PACS functionality, either temporary or permanent, outside the main PACS. This functionality may be useful for experimental studies that do not generate a formal accession number and are thus not well received by the PACS. An imaging modality can be configured to send images directly to SimpleDICOM Receiver.
The Teaching File and Clinical Trial Export integration profile from the IHE initiative outlines many of the same functions described for SimpleDICOM Receiver and Viewer (9). Although SimpleDICOM Viewer and Receiver achieve many of the same goals as this integration profile, the SimpleDICOM software does not rely on PACS vendors’ acknowledging the IHE specifications. Instead, the SimpleDICOM Suite acts as a DICOM Service Class Provider and is thus vendor independent. In contrast to the specifications outlined in the IHE profile, in the Simple-DICOM Suite the anonymization functionality resides with the Receiver, not the Exporter. This adaptation was necessary because commercial PACS do not generally utilize the Export Manager actor from the IHE profile, so that it was necessary for the anonymization to be performed after PACS export.
Although SimpleDICOM Receiver and Viewer are not designed to function as a stand-alone PACS, they can serve in this capacity on a small scale for institutions that cannot afford to purchase a PACS or wish to have an alternate distribution method. It should be noted that these tools are not sufficiently reliable to act as the primary means of distribution and storage of patients’ health information.
Financial and Scheduling Issues
The incorporation of images that are not generated within the radiology department requires a carefully planned financial policy. Many PACS vendors charge on a per-case basis, and the radiology department may wish to charge the per-examination costs to the department that generated the images. This is true for both SimpleDICOM Wrapper, in which the images are generated within the enterprise, and SimpleDICOM Sender, in which the images originate outside the enterprise.
The radiology administration must decide whether the department will support the cost of incorporating all outside studies or charge the cost to the clinical department that wishes to store the data. Even without a per-examination charge, the department may consider charging a nominal fee to offset the cost of purchasing and maintaining the PACS.
Alternatively, if the PACS is considered an enterprise function and is financed by the institution rather than the radiology department, the benefits of shared resources may be sufficient to justify the incorporation of VL images. In radiology departments without a PACS, these financial considerations may bolster the argument for a transition to PACS.
In combined RIS-PACS architectures, the addition of images may be sufficient to trigger a scheduling event within the combined RIS. In most RIS-PACS instantiations, however, the RIS requires a scheduling event to maintain synchronicity with the PACS. This requirement creates an additional work flow step for incorporation of both VL images and foreign radiologic images. The patient must be assigned a mock event within the RIS to represent the additional images in the PACS.
To prevent the overloading of radiology personnel, personnel in other departments or within the radiology file room should be authorized to schedule patients in the RIS. In smaller hospitals, it may be possible to centralize this function to a few individuals. In larger systems, however, scheduling privileges in the RIS may need to be made more widely available than they traditionally have been in the past.
Ideally, all of the elements in the Simple-DICOM Suite will be short-term solutions designed to fill a work flow gap while PACS vendors test and deploy similar functionality within their own software. Although the SimpleDICOM Suite can be used with any PACS, improved integration would be achieved if PACS vendors incorporated these functions into their software packages, in accordance with appropriate DICOM standards and IHE profiles. Our freeware solutions are intended to prove that the concepts outlined in this article are technically feasible, in the hope that users will pressure vendors for fully integrated commercial versions of these tools.
|
Conclusions
|
|---|
Most commercial PACS are adept at supporting mainstream radiology work flow, but radiologists frequently encounter situations requiring additional functionality that can be addressed with free, vendor-independent add-on software. The SimpleDICOM Suite is available for download at http://www.radiology.upmc.edu/software.html.
|
TAKE-HOME POINTS
|
|---|
There are many tasks within the radiology department that are not part of the standard work flow supported by commercial PACS.
- Additional software is needed to address these peripheral tasks to ensure efficient radiology operations in a digital environment.
- SimpleDICOM Sender extracts images from outside CDs and sends them to the hospital PACS; SimpleDICOM Wrapper imports nonradiologic images into the PACS; SimpleDICOM Receiver deidentifies and stores DICOM objects; and SimpleDICOM Viewer displays DICOM images outside the PACS environment.
- One of the keys to successfully incorporating VL images is customization to different users.
- The incorporation of images that are not generated within the radiology department requires a carefully planned financial policy.
|
Footnotes
|
|---|
Abbreviations: CD = compact disk, DICOM = Digital Imaging and Communications in Medicine, HIPAA = Health Insurance Portability and Accountability Act, IHE = Integrating the Healthcare Enterprise, JPEG = Joint Photographic Experts Group, PACS = picture archiving and communication system, PC = personal computer, PDI = Portable Data for Imaging, RIS = radiology information system, SCU = Service Class User, TIFF = Tagged Image File Format, VL = visible light
|
References
|
|---|
- Graham RN, Perriss RW, Scarsbrook AF. DICOM demystified: a review of digital file formats and their use in radiological practice. Clin Radiol 2005;60: 1133–1140.[CrossRef][Medline]
- Morin RL. Outside images on CD: a management nightmare. J Am Coll Radiol 2005;2:958.[CrossRef][Medline]
- Kuzmak PM, Dayhoff RE. The use of digital imaging and communications in medicine (DICOM) in the integration of imaging into the electronic patient record at the Department of Veterans Affairs. J Digit Imaging 2000;13:133–137.[Medline]
- Johnson MS, Gonzales MN, Bizila S. Responsible conduct of radiology research. V. The Health Insurance Portability and Accountability Act and research. Radiology 2005;237:757–764.[Abstract/Free Full Text]
- National Electrical Manufacturers Association web site. Available at: ftp://medical.nema.org/medical/dicom/2006/06_10pu.pdf. Accessed December 19, 2006.
- Integrating the Healthcare Enterprise web site. Available at: http://www.ihe.net/Technical_Framework/upload/ihe_tf_rev7.pdf. Accessed December 19, 2006.
- National Electrical Manufacturers Association web site. Available at: ftp://medical.nema.org/medical/dicom/2006/06_03pu.pdf. Accessed December 19, 2006.
- Branstetter BF, Siddiqui KM, Lionetti DM, Chang PJ. Defining a digital teaching file workflow: specifications for software development. J Digit Imaging 2003;16:37–40.
- Integrating the Healthcare Enterprise web site. Available at: http://www.ihe.net/Technical_Framework/upload/IHE_TF_Suppl_Teaching_File_Clinical_Trial_Export_TI_2005-04-22.pdf. Accessed June 8, 2006.
Top
Abstract
Introduction
