A national repository of complete radiotherapy plans: design, Results, and experiences

Abstract

Background

Previously, many radiotherapy (RT) trials were based on a few selected dose measures. Many research questions, however, rely on access to the complete dose information. To support such access, a national RT plan database was created. The system focuses on data security, ease of use, and re-use of data. This article reports on the development and structure, and the functionality and experience of this national database.

Methods and materials

A system based on the DICOM-RT standard, DcmCollab, was implemented with direct connections to all Danish RT centres. Data is segregated into any number of collaboration projects. User access to the system is provided through a web interface. The database has a finely defined access permission model to support legal requirements.

Results

Currently, data for more than 14,000 patients have been submitted to the system, and more than 50 research projects are registered. The system is used for data collection, trial quality assurance, and audit data set generation.

Users reported that the process of submitting data, waiting for it to be processed, and then manually attaching it to a project was resource intensive. This was accommodated with the introduction of triggering features, eliminating much of the need for users to manage data manually. Many other features, including structure name mapping, RT plan viewer, and the Audit Tool were developed based on user input.

Conclusion

The DcmCollab system has provided an efficient means to collect and access complete datasets for multi-centre RT research. This stands in contrast with previous methods of collecting RT data in multi-centre settings, where only singular data points were manually reported. To accommodate the evolving legal environment, DcmCollab has been defined as a ‘data processor’, meaning that it is a tool for other research projects to use rather than a research project in and of itself.

Keywords:

• Radiotherapy
• databank
• national infrastructure
• big data
• DICOM-RT

Background

At the beginning of this century, multi-centre radiation therapy (RT) studies mostly operated with a limited set of manually reported data such as dose prescription, treatment technique, and single DVH-values. They had a tendency to be error-prone [1] and were burdensome to complete due to logistical and infrastructural challenges. At the same time, the scientific RT community were increasingly interested in more detailed dose information from RT plans, which was cumbersome to collect – especially in multi-centre projects. Fortunately, the use of digital treatment planning and digital archival of treatment planning data was reaching a level of maturity that prompted a group of Danish researchers collaborating in the national research centre, CIRRO [2], to propose a novel method of collecting RT data for clinical studies.

The goal was to collect complete RT plans centrally with a minimum of human interaction, to store these data for re-use across trials, and to provide quick yet detailed insights for the users into the nature of the collected data. Furthermore, to fulfil legal requirements, access to data needed to be restrictive and possible to define in detail.

A system for storing data based on the Digital Imaging and COmmunication in Medicine (DICOM) [3] standard was proposed to solve the task described above. It would have similarities with normal Picture Archive and Communication Systems (PACS), which were abundantly available from commercial vendors already. However, a normal PACS system could not address the following issues: (1) Increased security and user access control. DICOM does not have much security designed into its standard. User management or access control is not part of the default implementation, so a security layer was necessary to ensure proper protection of the personal health information in the system. (2) The ability to group data into any number of collaborative projects. The assignment of data to one project should not exclude it from other projects – on the contrary, data re-use should be encouraged, in adherence to the FAIR principles of data management [4]. (3) Focus on DICOM-RT data and its reference structure. As the acronym implies, most PACS are focused on image data. DICOM-RT implements a sophisticated set of inter-references typically not handled by normal PACS.

The proposed approach should use the data structure defined in the DICOM standard and aim to keep the workload involved with collecting data at an absolute minimum. The system was named DcmCollab with ‘Dcm’ being an abbreviation of DICOM, and ‘Collab’ an abbreviation of ‘Collaboration’. Many of the Danish Multidisciplinary Cancer Groups (DMCG) were already experienced in collecting clinical data in databases across centres [5,6]. Still, these data were mostly clinical outcome data, and single Dose Volume Histogram (DVH)-parameters. So the DcmCollab solution was a logical next step to ensure the possibility of addressing research questions based on the entire dose distribution. DcmCollab was introduced in 2009 and its basic functionality was described by Westberg et al. in 2014 [7]. The development was supported by the national research collaboration CIRRO, which was later succeeded by DCCC-RT [2]. This article presents a selection of the experiences collected, the projects supported, and the solutions implemented in the course of the last ten years of the DcmCollab system. It will display the merits of a tool like DcmCollab for collaborative research projects in RT.

Methods and materials

DcmCollab began as a relatively small implementation based on the Conquest DICOM server [8], but after many iterations, the system is now structured as indicated in Figures 1 and 2. The top part of Figure 1 illustrates the participating hospitals. These are linked to DcmCollab via (1) DICOM via the Danish Health Data Network (SDN) [9], which is an isolated computer network for exchanging patient-sensitive information between Danish healthcare facilities, and (2) an HTTPS secure web interface. These are depicted as green and red arrows in Figure 1, respectively. The DcmCollab servers are designed as a frontend server in a secure environment, depicted as the grey box in the centre of Figure 1, and a backend server located in a trusted area of the hospital network and shown in more detail in Figure 2. All servers, data storage, and data processing are located inside the local hospital network, but with an option to send data to external server if requested by the researchers. The backend server is also indicated at the bottom of Figure 1, and the frontend server at the top of Figure 2. On the frontend, a DICOM network service (Figure 1A) receives data directly from the local treatment planning system at the participating hospitals, while a web interface (Figure 1B) provides user access to the data. Finally, an encrypted transit area (Figure 1C) provides a means for the two servers to exchange data securely. Services on the backend server (Figure 2A) receive the submitted data via the secure transit area, stores them in a storage area (Figure 1D), and populates an SQL (Figure 1E) database with key data points and aggregated information, which provides data for the website. The SQL database also contains user- and access management data, data segregation into protocols and collaboration projects, and logging information. It is important to highlight that all the raw data are stored in DcmCollab, which enables future detailed evaluations of the data without re-submitting. Furthermore, the data are available for export to other centres or trials if that is needed later on. All items within the frontend- and backend servers in Figures 1 and 2 are developed explicitly for DcmCollab. The ClearCanvas [10] library for C# was used for all DICOM operations, the website is implemented in Asp.Net, the services on the backend server and the DICOM network service on the frontend are developed in C#, and the SQL database is a Microsoft SQL database.

Figure 1. A schematic overview of the frontend part of the DcmCollab system. Participating hospitals are connected to DcmCollab via the isolated computer network, SDN, and a website with TLS encryption. The DcmCollab servers shown in the lower part of the figure consist of (A) a DICOM receiver, (B) a web interface, (D) storage for all DICOM files, (E) an SQL database for key data values to be presented on the website, and a backend server which is described in further detail in Figure 2. Green arrows represent DICOM communication, red arrows represent HTTPS communication, orange arrows represent file access, and blue arrows represent SQL data communication.

Figure 2. A schematic overview of the backend part of the DcmCollab system. The register-, analyze-, and calculate services (A) all extract different levels of information from the submitted DICOM data and use it to populate the SQL server (B). the completeness service (A) evaluates whether a DICOM image set appears to be complete or if image slices are missing. The trigger service (A) scans the submitted data for features that should trigger actions in the system. The cleanup service (A) removes old data that has been submitted to DcmCollab but has not been assigned to a protocol and disables user permissions to protocols that have not been renewed in a timely fashion. The notification service (A) distributes user notifications to the users of the system via email or text message. Orange arrows represent file access, and blue arrows represent SQL data communication.

To measure the research impact of the DcmCollab system, the following aspects are evaluated: (1) The extent of clinical use (2) The experience of the users of the system (3) Tools and extensions implemented based on user suggestions, and (4) Legal implementation.

Results

The results are described below, separated into the categories mentioned in the previous section.

Clinical use of the system

The ease of use of DcmCollab and its capacity for handling large data cohorts has allowed it to support small and large trials. Some of the largest clinical trials are related to recurrence patterns in Head and Neck cancer patients with 3007 patients [11–13] and the DBCG trials of Hypofractionated breast cancer treatment with 2716 and 1529 patients respectively [14,15].

DcmCollab has been used to support clinical trials in many different manners. Below, some of these use cases are described and exemplified.

Data collection

Some trials use DcmCollab mainly to store data from all participating institutions [15–19]. In these use cases, trial scientists can later request a bulk export of the raw DICOM data for in-depth analysis outside DcmCollab.

Data re-use

In some cases it has been possible to re-use data that had been submitted as part of an unrelated trial. One example of this mode of usage is the heart substructure auto-contouring project of Finnegan et al. [20]. In that study, the dataset of 1500 patients was collected for an unrelated project [15], but the nature of the data made them an obvious candidate for the auto-contouring project. Since all data was already collected, it was only a matter of legalities to pass it on.

Another case of data re-use is the work by Brink et al. [1] to assess the quality of automatically submitted data using DcmCollab, compared to manually submitted data. This project showed a significant increase in data quality when submitted automatically to DcmCollab.

DcmCollab calculated parameters

Other studies, e.g. Thomsen et al. [21] and Berg et al. [22], do not need to access the details of the DICOM data, as dose metrics from the DVH stored in the SQL database of DcmCollab suffice. In that case, these values can be directly requested from the web interface and are provided to the user as, e.g. comma separated files. If such workflows are sufficient, the resources needed to finish a project are often reduced significantly. Furthermore, the study’s specific dose metric does not need to be defined before data collection since the entire dose-volume information is readily available in DcmCollab. Besides being available directly for studies, the dose information provided in the web interface is also a tool that can be used routinely as part of the quality assurance while the trial is acquiring data.

An integrated part of the trial design

Some trials, e.g. von Buchwald et al. [23], have integrated DcmCollab directly into their design. This use case is also applied in several proton treatment trials [17,24] in which local centres forward the locally created proton plan to the national proton facility. The initial plan is not used clinically but to evaluate whether the patient should be randomised between proton and photon treatment. Utilising the DcmCollab trigger feature described in the tools and extensions subsection, the local plan can be forwarded directly to the proton centre from the local planning system.

Audit studies

The Audit Tool, which will be described in more detail in the tools and extensions subsection below, has been used for several new studies, including workshops on national consensus on delineation guidelines [25,26]. Using the DcmCollab Audit Tool to facilitate the creation, distribution, and collection of anonymised datasets made the studies easier to perform and has therefore been used in several formalised audit studies, pre-trial QA, for ad-hoc projects, and for generating data for delineation and planning workshops.

Overall use of DcmCollab

As described above, the use of DcmCollab can have different perspectives. They all contribute to patient data in the system which can potentially be used in other trials if legal permission is granted. Figure 3 shows the accumulated number of patients as a function of time since the introduction of the DcmCollab system. The graph shows an approximately linear increase from 2008 and onwards, with a mean increase of 953 patients per year.

Figure 3. The cumulative number of patients in DcmCollab as a function of first treatment date.

In 2019 DcmCollab enabled the submission of data from countries outside of Denmark using an upload form on the website. Some trials have started using this possibility, e.g. DBCG’s hypofractionation trial Skagen 1 [14] and the dose escalation trial NARLAL2 [27]. Thus, there is per 2023 data for 796 patients from outside of Denmark in the system. These have been de-identified at the submitting centre to make the submission across national borders legally feasible.

At the time of writing, 75 projects are registered in DcmCollab, excluding demo- and test protocols. Not all of these have started routine data submission yet, but 50 of them have at least 20 patients enrolled (a list of protocols and the number of patients included is shown in Supplementary). The list of protocols shows clear variation among the different cancer groups (DMCG’s) within Danish RT. This variation reflects the degree of adoption of DcmCollab and the number of RT trials initiated within each research group.

The user experience

By using DcmCollab for data storage, it has been possible for protocol managers to follow the data submission process during the trial to ensure that the data needed is indeed collected. The easy and online data access has helped researchers intervene at an early stage if the submitted data did not fulfil the criteria set up in a trial. However, early in the life of the system, a user was required to manually log in to the web interface and attach the submitted data to the correct research project. This process was tedious, required many resources, and was error-prone due to the level of human interaction. To improve on this, triggering feature support was implemented, practically eliminating the need for data submitting users to access the web interface.

In general, the preferred aim has been to reduce the number of interactions required from the users as much as possible. And the interactions which were not possible to eliminate, should be as simple, effective, and intuitive as possible. Therefore the design and development of new features has always happened in close collaboration with the users, reducing the risk of spending developer resources on unnecessary features, and also improving the sense of ownership of the system among its users. Some of these features are described below.

Tools and extensions implemented based on user suggestions

Several features have been developed in close collaboration between the users and the developers of the system. Some of them will be described briefly in the following sections.

Close integration with local treatment planning systems

The SDN provides isolated computer network connections between all Danish RT centres for patient-sensitive information. Thus, using SDN, DcmCollab can be defined as a DICOM network node in the Treatment Planning System (TPS) at each participating centre, similar to any other DICOM destination in their system. This makes data transfer between the local centre and DcmCollab identical to any other DICOM transfer performed at the local centre.

Internal re-calculation of DVH data made available for bulk download

Pre-calculated DVH data are not guaranteed in a DICOM RT plan export. Therefore, DcmCollab performs an independent DVH calculation, ensuring consistent and comparable data, and stores this in the database. These are available for review graphically on the website and in comma-separated data files available for download for each protocol or collaboration project.

ROI name mapping

Standardised naming of Regions Of Interest (ROI)s is often attempted in the definition of a clinical trial. Experience shows that slight variations almost always arise across and within centres. A standardised naming is needed to allow easy extraction of data for a specific ROI for all patients in a protocol. The ROI name mapping feature in DcmCollab facilitates this standardisation. The feature allows users to define a set of mapping rules to map any number of permutations of ROI names to general, protocol-specific ROI types. Part of the interface for creating mapping rules is shown in Figure 4, and an example of the overview of matches in a protocol is shown in Figure 5.

Figure 4. A section of the ROI name mapping scheme for the DAHANCA19 [37] protocol using Historical data. Note the use of ‘*’ and ‘?’ in the entry column, which is used to map ROI matches to the DcmCollab name stated in the StructType column. The institution column shows which participating institution a given mapping rule applies for (in this example, all the mapping rules are applied to data from all centres).

Figure 5. A section of the overview of the Results of a ROI mapping scheme. The red X means no ROI’s have been mapped, the green checkmark means one ROI has been mapped, and the yellow checkmark means that more than one ROI has been mapped to the same general ROI type.

Triggering features

As mentioned in the section describing the user experience of the system, the concept of ‘triggering features’ was developed in order to limit the need for manual user interaction. Initially, these were limited to empty ROI’s created by the user with a pre-defined ROI name, which triggered actions in the system. The first action that could be triggered was to include data in a specific protocol. Later, forwarding triggers were implemented, allowing users to trigger an export of data from DcmCollab to another centre as soon as they were received – again reducing the need for manual access to the website.

The latest expansion of the trigger feature set will allow any set of DICOM tags to trigger actions. This lets image data trigger functions without having a related structure set.

RT plan viewer

To allow users to review the plans submitted to DcmCollab online in the web interface, a rudimentary RT plan viewer was implemented. The viewer shows image sets, iso-dose curves as well as delineation contours. The viewer does not have capabilities comparable to most RT plan viewers available but is meant for the users to have an integrated, online way of reviewing singular datasets that may need attention. The RT plan viewer is shown in Figure 6.

Figure 6. The RT plan viewer.

Audit tool

To support the process of performing delineation or treatment planning audit studies, the Audit Tool was implemented. It allows the user to select datasets from the DcmCollab database and generate any selected number of individually anonymised copies, each with individual patient IDs and instance UIDs. DcmCollab then facilitates the distribution and following collection of the data from the participating centres, minimising the workload for the scientists managing the study.

In the past, while generating anonymised data for audit studies, DICOM issues often arose, mostly related to UID- or patient ID collisions. This could occur from a lack of detailed understanding of how DICOM works or from using software tools unsuitable for the job. Along with the infrastructure that DcmCollab provided, this prompted the development of the Audit Tool.

Legal status

During the development of DcmCollab, the legal demands for storing patient-sensitive data have evolved substantially. Initially, DcmCollab was defined as one large research project containing all the data submitted to DcmCollab. With the introduction of GDPR the legal role of DcmCollab has changed such that it is a system that can host data for research projects in line with other clinical tools such as, e.g. PACS systems. So in terms of GDPR, DcmCollab’s legal status today is a ‘data processor’ and not ‘data controller’, as was the initial status. The legal obligation will always be on the ‘data controller’ (the researchers), but to support the researcher’s use of DcmCollab, legal framework agreements with all regions of Denmark have been negotiated. These frameworks address all the security and access issues related to the fulfilment of the GDPR requirements. So currently the researcher can refer to these frameworks as part of their research description. Thus, DcmCollab is legally handling data on the users’ behalf and is not allowed to use the data for any purpose other than those stated by the data controllers. This also means that all negotiations about the reuse of data for other projects will be between the relevant researcher, and upon agreement, DcmCollab can immediately grant access to the relevant data.

Discussion

DcmCollab is the default means for RT plan data collection in Denmark, especially for multi-centre projects, but to some extent for single-centre studies as well. The system has facilitated many projects covering a wide range of subjects within the RT field. The simple data submission workflow, the feature of segregating data into collaboration projects, and the fine-grained user access control have been the key features of the system, described in Westberg et al. [7], upon which the rest of the project has been built. Other multi-centre research databases have been documented, yet they are either implemented for one project [28] or one hardware product specifically [29], do not support the DICOM-RT modalities [30], or require third party software installed in the participating clinics [31]. One strong alternative which has emerged recently is ProKnow [32,33] (Elekta AB, Sweden), which has many useful tools, a user-friendly interface, and supports DICOM-RT. It is a cloud based system, though, which would require Danish users to anonymize all submitted data, and connecting it to the SDN does also not appear to be an option. Thus, the level of support for RT projects combined with the ease of data submission and openness of the architecture makes DcmCollab unique in the field, to the best of the knowledge of the authors.

The users of DcmCollab have been quick to realise the system’s potential and have been central in providing input for its further development. Planned future development include QA of data returned using the Audit Tool, validation of data included in protocols, support for external processing of data - including automatic AI delineation, integration with federated learning setups as described in [34,35], an API to allow access from external code, and expanded support of the FAIR [4] principles of data access.

The future work with the DcmCollab system will be substantially supported by the newly founded DESIRE project funded by the Novo Nordisk Infrastructure Grant [36] over the coming five years. This project will develop a national research infrastructure, partly based on the current infrastructure provided by DcmCollab.

Should another team plan to implement a system similar to DcmCollab, they should be aware of the three key prerequisites that were present in Denmark prior to the implementation of DcmCollab: (1) the isolated computer network connections of the SDN, (2) the unique medical record number (CPR), and (3) the fact that all RT centres are in public hospitals. If any one of these are not reproducible in the country of implementation, measures should be taken to accommodate for this.

In summary, the DcmCollab system was developed to accommodate the need for a means to collect complete RT plan data on a national and international scale in an easy and secure manner. Since its introduction, several features, including the Audit Tool, ROI name mapping, triggering features, and the plan viewer, have been added, to ease the workflows surrounding the system, with many more scheduled for future development.

Disclosure statement

No potential conflict of interest was reported by the author(s).

Data availability statement

Data sharing is not applicable to this article as no new data were created or analyzed in this study. The source code for DcmCollab is not available for sharing but the corresponding author is open for discussions and sharing of overall design details.

Additional information

Funding

This work was funded by the Lundbeck Foundation Centre for Interventional Research in Radiation Oncology (CIRRO), The Danish Cancer Society (DCCC Radiotherapy), the Danish Medical Research Council and the Novo Nordisk Foundation.