Clinical Oncology
Volume 22, Issue 8 , Pages 681-687, October 2010

PACS in Radiotherapy

  • J. Shakeshaft

      Affiliations

    • Corresponding Author InformationAuthor for correspondence: J. Shakeshaft, Alan Walker Cancer Centre, Rocklands Drive, Tiwi, NT, 0810, Australia.

Physics Department, Clatterbridge Centre for Oncology, Bebington, Wirral, UK

Received 15 February 2010; received in revised form 26 March 2010; accepted 15 June 2010. published online 14 July 2010.

Article Outline

Abstract 

In recent years, the use of the Picture Archiving and Communications System (PACS) has become widespread in the area of diagnostic radiology for archival, review and reporting of patient data. However, the adoption of PACS within the field of radiotherapy is still very limited, despite the fact that most radiotherapy systems now use Digital Imaging and Communications in Medicine (DICOM) for both storage and communication. This paper discusses the challenges of integrating PACS into a radiotherapy department as a long-term archive of patient treatments. A possible solution based on a large English department is used as an example.

Key words: DICOM, PACS, radiotherapy

 

Back to Article Outline

Introduction 

Over recent years, all radiotherapy vendors have made increasing use of open standards to both store data and communicate with other devices. However, many departments (particularly those who have chosen not to purchase all equipment from a single vendor) struggle with storage and communication issues. In many cases, the result is that the same data are stored in multiple proprietary databases and communication between different systems is suboptimal. The increased availability of the Picture Archiving and Communications System (PACS) within the hospital environment offers the potential and opportunity to use a single well-managed storage solution for radiotherapy data. Additionally, within England, there is the potential for these data to be shared between sites using the PACS data sharing that should be provided by the Connecting-for-Health PACS solution.

The Digital Imaging and Communications in Medicine Standard 

The de facto standard for connectivity in the radiotherapy community has become the specifically designed objects with the Digital Imaging and Communications in Medicine (DICOM) standard [1]. These have for a number of years been known as DICOM-RT. However, they form an integral part of the full DICOM standard and should simply be referred to as radiotherapy DICOM objects. A summary of the radiotherapy objects is given in Table 1. An explanation of some standard DICOM terms is given in Table 2. (Where these terms have been clarified in the tables, they are indicated using an asterisk.)

Table 1. The radiotherapy Digital Imaging and Communications in Medicine (DICOM) objects
ObjectDescription
RTSTRUCTDetails of structures contoured on images. Each contour is linked to an image.
RTPLANTreatment delivery details and geometry, either by external beam or brachytherapy.
RTDOSEDose delivered by plan.
RTIMAGESimulator, Digitally Reconstructed Radiograph or portal image. Contains some geometry information.
RTRECORDRecord of a radiotherapy treatment. This may be a record of a single session, or a summary of treatments.
Table 2. Some Digital Imaging and Communications in Medicine (DICOM) terminology
TermExplanation
[group, element]Data within DICOM objects are held in elements. These elements are divided into groups and are encoded using 16-bit hexadecimal group and element numbers. For example, the study description is held in element 1030 of group 0008 and is represented [0008,1030].
Type-1, type-2 and type-3The standard elements contained with a particular type of DICOM object (SOP class) are defined in part 3 of the standard [1]. These are either type-1 (mandatory), type-2 (mandatory, but may be null) or type-3 (optional).
Query/retrieveA DICOM method by which a PACS can be interrogated (queried) for a list of studies that match particular criteria (for example, patient identification) and then told (retrieve) to send the DICOM data to another DICOM application.
Storage commitmentA service that is used to confirm that an image has been permanently stored by a device (either on redundant disks or on back-up media, e.g. burnt to a CD).
Unique Identifier (UID)A globally unique string composed of numbers and periods associated with the item. For example the study UID is a globally unique string contained within [0020, 000D] for all DICOM objects within a particular study.

These DICOM radiotherapy objects, in principle, allow the recording and transmitting between different equipment of information associated with a radiotherapy treatment. Potentially they also allow the sharing of radiotherapy treatment data between different institutions. However, attempts to integrate radiotherapy equipment rapidly demonstrate a number of issues:

The radiotherapy DICOM objects are quite flexible and contain a large number of optional (type-2* or type-3* elements). However, for equipment from a particular manufacturer to work correctly, it may be that a particular non-null type-2 or type-3 element is required. Alternatively, it may be that one manufacturer only supports a subset of the values allowed for a particular element, whereas another manufacturer supports a different mutually exclusive set of allowed values for the same element.

Although the radiotherapy DICOM objects were designed in a very flexible way and have supported the changes that have occurred in technology very well, inevitably there are pieces of information that need to be stored that do not have a suitable DICOM element. This has led to the extensive use of manufacturer-specific (or private) elements within the radiotherapy community. Inevitably this leads to interoperability issues.

Plan revisions: Unlike DICOM objects in diagnostic imaging, in radiotherapy a number of versions of the same object rapidly accumulate. In some cases these can be deleted as they are simply works in progress. For example, several versions of the structures in a patient may be saved by a clinical oncologist while outlining for IMRT. In other cases the different versions may be important. For example, a plan may be adapted as a patient goes through treatment. Tracking through different versions of the same object determining the reason for a change (or what the change was) can be difficult. In the case of plans, some assistance can be obtained by examining the referenced plan sequence [300C,0002]*, and the plan relationship [300A,0055] if these are implemented. However, these elements do not include a description of or a reason for the change.

Radiotherapy object identification: If radiotherapy objects are stored on a generic PACS, the identification of the object that is required can be difficult because the radiotherapy objects have a description in a DICOM element specific to the object modality. These descriptions are not returned in a query/retrieve*. For this reason, some manufacturers are also putting a description in the generic series description element [0008,103E]*. This is proving to be useful when radiotherapy objects are used within a PACS environment.

Integrating the Healthcare Enterprise 

Integrating the Healthcare Enterprise (IHE) (http://www.ihe.net) is an organisation that exists to ‘improve the exchange of information among healthcare systems’. IHE works by producing documented clinical workflows and communication pathways, and promoting existing standards, such as DICOM and HL7 [2]. It has had much success in improving workflows and connectivity in, for example, the radiology world.

IHE has also been working in the area of radiotherapy (radiation oncology) to develop standards that should allow systems from different modalities to communicate. In radiotherapy, the underlying standard used by IHE profiles is DICOM and currently there are three different profiles [3] in various stages of preparation:

Normal Treatment Planning–Simple (NTPL-S), which illustrates the flow of three-dimensional treatment planning data from computed tomography to dose review.

Multimodality Registration for Radiation Oncology (MMR-RO), which shows how three-dimensional treatment planning systems integrate magnetic resonance imaging and positron emission tomography data into the contouring process and dose review.

Radiotherapy Treatment Workflow, which integrates daily imaging with radiotherapy treatment using workflow parts of the standard.

Within the IHE profiles it is assumed that all data are stored on a PACS-like archive; when it is needed by various actors it is pulled off the archive, processed and then re-stored using DICOM transactions. This is illustrated in Fig. 1 for the ‘contourer’ actor. For each profile, a minimum required dataset is defined; this may be a subset of that required by the DICOM standard (i.e. not all type-1* elements are included) or it may specify some IHE mandatory elements that are not type-1 elements in the DICOM standard. In some cases, only a subset of values permitted by the DICOM standard is supported by the IHE profile. The Radiotherapy Treatment Workflow makes extensive use of the DICOM Supplement 96: Unified Worklist and Procedure Step, which has the status of ‘frozen draft’ for trial use. The Unified Worklist is more comprehensive than the Modality Worklist with which many users of radiology systems will be familiar. It is simpler to implement than the rather complex General Purpose Worklist. The principle is that the (radiotherapy) Treatment Management System (TMS) can drive the workflow of any connected device from any manufacturer using open standards.

Many of the well-known radiotherapy equipment manufacturers are already beginning to support the draft radiotherapy IHE profiles, particularly NTPL-S, which already has the status ‘draft for trial implementation’. Although the IHE technical profiles support transactions using an open standard (DICOM), few manufacturers are using a generic DICOM archive in their implementations. Therefore, the potential for minimising multiple copies of the same data and sharing data between applications is not fully realised.

Back to Article Outline

The Clatterbridge Centre for Oncology Solution 

The Clatterbridge Centre for Oncology (CCO) uses a wide variety of equipment to optimise treatment to its patients. Although the use of equipment from a number of manufacturers maximises flexibility and allows the use of the best tool for the task, it does create a number of integration issues. As many independent systems are used, there are many independent databases that often contain the same data. If the relevant data could be archived in the hospital PACS system and removed from the individual systems once treatment has finished, there would be a number of potential benefits: (i) systems management would be easier as there would be less data on the individual radiotherapy systems to back up; (ii) information governance would be improved as enterprise systems tend to have better facilities for access control and audit than small departmental systems; and (iii) historic treatment data would potentially be available more widely (for example, in remote clinics, where the provision of access to enterprise systems is becoming standard). Additionally, if these data were stored correctly in the Connecting-for-Health PACS, they should be available to other treatment centres, should patients return to a different centre for subsequent treatment. The range of equipment that is required to be included in such a scheme at the CCO is shown in Table 3.

Table 3. Range of equipment in use at the Clatterbridge Centre for Oncology
Equipment typeEquipment model
Localisation image generationPhilips AcQSim single-slice computed tomography
Philips Brilliance BigBore multi-slice computed tomography
QADOS OSIRIS contouring system
Varian Acuity Simulator (shares single database with Eclipse/ARIA)
Nucletron Simulix Simulator
Various magnetic resonance imaging scanners
Virtual simulation and treatment planning systemsMedcom Prosoma
Philips Pinnacle-3
Varian Eclipse (shares single database with Acuity/ARIA)
Varian Smart-segmentation (auto-contouring) (stand-alone product)
Brainlab iPlan
Treatment management system (record and verify)Varian ARIA (shares single database with Acuity/Eclipse)
Verification imaging systemsVarian Acuity Simulator (shares single database with Eclipse/ARIA)
Nucletron Simulix Simulator
Elekta iViewGT MV Portal Imager
Varian PortalVision MV Portal Imager (images included in ARIA database)
Varian On-Board Imaging (OBI) (images included in ARIA database)

Risks 

Although the concept of storing radiotherapy treatment data on a PACS that is readily accessible locally (and potentially elsewhere) is extremely attractive, it is not without some risk, particularly if the record is incomplete (or cannot all be interpreted). For example, a patient has a treatment plan prepared for a particular radiation dose that was prescribed by their clinical oncologist. This prescribed dose is stored both within the DICOM plan and dose objects. However, for various reasons a patient may not complete their course of treatment. The DICOM standard allows for this by using the RTRECORD object. However, there has been poor commercial uptake of this object. Therefore, one possibility would be to store only the planned (or intended) dose in the widely available PACS. The dose actually delivered to the patient would only be stored in the local TMS. However, with this approach there is the risk that those with access to only PACS will assume that the planned dose was actually delivered. This could cause decisions to be made in the future that would be detrimental to the patient’s care.

The risk of data being deleted prematurely also needs to be considered, particularly if PACS is being shared with radiology. There is much debate within the community over how long radiotherapy records should be stored. However, there is some guidance in England [4], [5], which amounts to a longer time frame than for most diagnostic data.

Solution Overview 

In May 2007, a group of radiotherapy professionals from various centres met to consider how PACS could be used within radiotherapy in the UK. The result of this meeting was a three-stage proposal that was designed to be both practical and safe [6]. The solution that has been developed at the CCO and is described here is based on phase 2 of this proposal, and considers the risks described above.

The flow diagram shown in Fig. 2 illustrates how the different items of equipment at the CCO are linked together to store data on PACS. In this solution, completed plans are stored on PACS and are generally available. However, verification images are only stored in the TMS (ARIA). Because there is a significant cost in fully integrating systems with the Connecting-for-Health PACS system, we have chosen only to integrate a single system – Prosoma (Medcom). Although the Prosoma system has many workstations, for DICOM transactions with the PACS the server acts as a proxy, so the multiple workstations appear as a single entity to the PACS. This has simplified integration issues greatly.

Integration with the GE Centricity Picture Archiving and Communications System 

As part of the English national PACS procurement programme, the CCO (in common with many other hospitals) has purchased the GE Centricity PACS system. In order for objects to be correctly stored both locally and in the long-term store, it is first necessary to create a ‘folder’ for the DICOM study. (Although the creation of a ‘folder’ is not required by the DICOM standard, a number of PACS systems, including GE Centricity, require a ‘folder’ to be created by a Radiology Information System [RIS] before the study is fully committed to the archive.) Therefore, patients undergoing radiotherapy localisation imaging have an appointment created on the RIS that is connected to the PACS. Where the localisation image includes computed tomography, the scanners are connected to the RIS using the DICOM Modality Worklist, which ensures robust patient demographics and that the images have the RIS-generated DICOM accession number and study UID∗, which means that they (and associated radiotherapy objects in the same study) are filed in the correct PACS folder. For the simulators and OSIRIS, which do not support the DICOM Modality Worklist, the situation is a little more complex, and a system has been developed to merge the DICOM objects with worklist-generated demographics at a later stage. In principle this can be achieved automatically using the facilities on the GE RA600 workstation. However, because these workstations are both relatively expensive to buy and carry a significant maintenance charge, software has developed locally to accomplish this task. In order to select the correct study from the RIS-generated worklist, the study identification (which is entered as the course identification in ARIA) is entered in the format YYYYMMDD and is matched with the worklist study date and patient identification. Potentially this allows multiple anatomical sites within the same study. This approach is consistent with that proposed by the English National Cancer Services Analysis Team and required by the English Radiotherapy Dataset.

Plans with a Three-dimensional Dataset 

Plans with a three-dimensional computed tomography dataset are prepared in a conventional way. If co-registered magnetic resonance data are required, then these can be exported from Prosoma to other systems and re-sampled into the same plane and slice positions as the primary computed tomography data. (Although the export of re-sampled data is considered an inferior option to exporting DICOM registration objects along with the original data, many systems do not yet support the IHE MMR-RO profile and so reformatted datasets are used for pragmatic reasons.) If the planning is carried out in a system other than Eclipse, the completed plan (including reference images) is imported into the ARIA/Eclipse system. It is then transferred back to Prosoma ready for onward transmission to PACS (as Prosoma is the only system that is fully integrated with PACS). The RTDOSE objects exported are ‘RELATIVE’ so only contain dose delivered relative to the prescription point. This should minimise the risk of objects stored on PACS being used to conclude the dose that was actually delivered to the patient.

Achieving this with three-dimensional data has been relatively simple with Pinnacle version 9 and ARIA/Eclipse version 8.8. There has been some requirement to copy information between plan name/description [300A,0002/4] and series description [0008,103E] elements to make the plan easily and uniquely identifiable in each system. This need would be obviated if all manufacturers used the series description element to contain a uniquely identifiable description of the plan, as this element is read by most systems (although not ARIA) and integrates well with the PACS Query/Retrieve model.

Plans without a Three-dimensional Dataset 

Plans based on simulator images and without a three-dimensional dataset, although the simplest, are the most difficult to handle. This is because there is no standard method of delineating the area to be treated as there is with the radiotherapy structure set and computed tomography data. Varian have used the DICOM curve module for this purpose in their ARIA TMS. However, because this module has now been retired from the DICOM standard, it is not well supported by other vendors (including PACS). Other systems, such as Prosoma (MedCom), use private elements for this purpose, which by definition are not readable by other systems.

Therefore, in storing simulator localisation images to PACS, the simulator wires are the only easy means of identifying the area that was intended to be treated. This is not ideal because often fields are modified after the localisation images are acquired, either by moving a field edge or by adding additional shielding (or both). Therefore, when storing to PACS, we have to store both the localisation image and the treatment plan and require that both are retrieved into a radiotherapy system for reinterpretation. Another (and possibly better) solution would be to store some sort of treatment verification image on PACS for these patients, as then it would be much clearer on subsequent review which area had been treated.

The DICOM RTIMAGE, which is generated by all modern simulators, allows the storage of the beam shape in the DICOM beam module within the header of the image. This shape can then be extracted and displayed as an overlay on the RTIMAGE without reference to any other object. However, support for the beam module within RTIMAGES is generally poor and for this solution to be realised is going to take work by both standards bodies (such as IHE) and then manufacturers (including PACS manufacturers) to implement the overlay display.

Plans Based on a Paper or Optical Outline 

Plans based on a paper or optical outline are handled in a similar manner to those based on a three-dimensional computed tomography dataset. At the CCO, this has included writing a utility to convert outlines from the OSIRIS optical outlining device to a standard DICOM radiotherapy structure set, although the standard solution of burnt-in computed tomography images could have equally well been used.

Review of Historic Radiotherapy Stored on the Picture Archiving and Communications System 

Ideally it would be possible to review the radiotherapy data stored on PACS within the viewers and workstations supplied with the system. However, few commercial PACS systems support the viewing of radiotherapy objects. Fortunately, software vendors within the radiotherapy community are developing alternatives. Use of these radiotherapy viewers obviously requires direct access to the PACS archive, which sometimes takes negotiation within the English Connecting-for-Health Information Governance framework.

In the CCO solution, the same software (Prosoma, Medcom) is used for both contouring and reviewing the plan data that have been stored on the PACS. This is advantageous, as clinicians are not required to learn another software package.

Back to Article Outline

Discussion and Conclusion 

The system described here does not provide the flexibility of systems proposed by IHE. Nor is it quite as ‘plug-and-play’ as an IHE compliant system might be, as it has required a small amount of bespoke modification of DICOM objects to make it work (processes shown with a grey background in Fig. 2). However, it is available now and allows the storage of historic plan data in a readily accessible form using open standards.

In the design of any solution, a balance needs to be drawn between usability and robustness. Usability may require the same image data to be stored on multiple systems (at least on a temporary basis). For example, to increase the speed of retrieval. However, robustness and good data management practice would suggest an approach more similar to that proposed by the IHE, where a single copy of any image data is held on a PACS and accessed by multiple systems. The approach that is beginning to be adopted by a number of manufacturers is that image data are initially stored to PACS and retrieved when required by the individual local system. The local system then allows removal of the image data from the local database (as it is already on PACS) and archival of the locally created radiotherapy DICOM objects to the same PACS when the patient is not in constant use. A small reference to the location of the data on PACS is maintained in the local database. Manufacturers that have or are beginning to adopt this approach for three-dimensional image sets include Medcom (Prosoma), Nucletron (MasterPlan) and Varian, although better automation of the archival process in all cases is still required. This approach would appear to be a good compromise between usability and robustness, although if it is going to be fully robust there needs to be support of DICOM Storage Commitment* in radiotherapy systems to ensure that the PACS has correctly stored the archived data.

Although not discussed in detail here, in order to maintain the integrity of the link between data held in the PACS (which has a demographic feed from the hospital patient administration system) and the long-term data held in the TMS, the TMS has also required an HL7 demographic feed from the patient administration system to be implemented.

Further developments will include the storage of verification data, particularly cone-beam computed tomography, which is large in volume. The process of storing this additional DICOM data will not be difficult, but storing it in such a way that it can unambiguously be retrieved and interpreted at a later date is more challenging. Further work by standards bodies is probably required in this area, although the bare bones of a solution do exist in the form of the DICOM Spatial Registration Objects (both rigid and deformable).

Back to Article Outline

References 

  1. Digital Imaging and Communications in Medicine (DICOM) standard 2008. National Electrical Manufacturers Association. Available at: http://medical.nema.org/
  2. HL7 (Health Level Seven) provides standards for interoperability that improve care delivery, optimize workflow, reduce ambiguity and enhance knowledge transfer. Available at: http://www.hl7.org/
  3. IHE Technical Framework . ACC/HIMSS/RSNA. Available at: http://www.ihe.net/
  4. NHS Executive . For the record: managing records in NHS trusts and health authorities. Health Service Circular HSC1999/053. London: Department of Health; 1999;
  5. Royal College of Radiologists . Guidance on the retention and destruction of NHS medical records concerned with chemotherapy and radiotherapy. BFCO(96)3 London: Royal College of Radiologists; 1996;
  6. IPEM. IPEM report number 99: DICOM image and data management for nuclear medicine, physiological measurements, radiotherapy and ultrasound. York: Institute of Physics and Engineering in Medicine, in press.

PII: S0936-6555(10)00207-4

doi:10.1016/j.clon.2010.06.010

Clinical Oncology
Volume 22, Issue 8 , Pages 681-687, October 2010