DcmCollab
was created in 2009 as a tool to collect, share, and compare radiation therapy
plans among the Danish radiotherapy centers. During the initial design of the
system, it was obvious that security and user rights should be central in the
system’s infrastructure. Data should only be seen by those it was expressly
intended for.
To add data
to the DcmCollab system Danish radiotherapy centers, a DICOM SCP receiver was
set up on the secure Danish hospital network, “Sundhedsdatanettet”
(SDN). Each center has DcmCollab set up as an export destination in their
treatment planning system, so that sending data to DcmCollab is as easy as
possible. Each submitting server is registered in the DcmCollab database, and
only data from registered servers is imported in the database. Data from
unknown senders is quarantined for review before import.
When data
is first imported, it is only visible to users from the data’s submitting
institution. If nothing is done with the data in 180 days, it is deleted again,
to avoid a build-up of “garbage” data.
To solve
the high degree of user control, the following concepts were introduced:
· Protocols
· Permissions
· Permission Levels
A Protocol would typically represent a
clinical protocol but in DcmCollab it is implemented as a grouping of DICOM
series. A DICOM series submitted to the system can be put in one or more
protocols.
For a user
to add data to a protocol, the user must be associated to the protocol by a Permission. A user’s association can be
defined as a normal user who is only
allowed to add data to the protocol, or a protocol
key user, who is allowed to adjust the advanced settings of the protocol.
To view
data submitted to a protocol from other centers, PermissionLevels are introduced.
These refer to a specific permission and define a user’s access level to data
from other centers in the given permission. The permission levels are Summary: The user is only allowed to see
aggregated statistics of the data from the given center, View: The user is allowed to see all the information DcmCollab has
extracted from each DICOM series from the given center, Export: The user is allowed to export the original DICOM data to
any destination registered in the DcmCollab database.
Formally,
user rights are assigned using the General Data Agreement which states that
data from one institution which is put in a given protocol should be accessible
to a specified permission level for specified users. The data agreement is
signed by the local Principal Investigator (PI) of the related clinical study at the submitting institution.
For users
to access the DcmCollab system, a web interface was implemented. After a user
has logged in they can view data submitted from their institution and assign it
to protocols for which the user has permission.
If a
complete set of data describing an RT plan, being RTPLAN, RTDOSE, RTSTRUCT and
RTIMAGE, is submitted, the system performs an independent calculation of
structure volumes and DVH’s and stores these data in the database for quick
assessment and statistics via the web interface.
The web
interface also allows protocol key users to set up a number of settings and
features for protocols. These include the Struct Dictionary, Protocol
Statistics, Trigger Structs, and Auto Export.
The struct
dictionary feature allows a protocol key user to define mappings from given
struct names in the DICOM data to generalized struct types. I.e. the protocol
key user might define an External Contour struct type and define that both the
struct names “external”, “body”, and “external contour” should be seen as
External Contour struct types.
These
mappings are useful in extracting DVH stats for the struct type in the entire
population in the protocol, and also to verify that all submitted plans have
all the defined struct types contoured, regardless of local naming schemes at
the different local institutions.
When a
complete DICOM plan, including the RTPLAN, RTDOSE, RTSTRUCT, and RTIMAGE
modalities, is received in DcmCollab, the system will re-calculate the DVH’s of
the structs in the plan. The re-calculated DVH’s are stored with 1 Gy resolution from 1 Gy to 100 Gy, readily available to extract minimum, mean, and maximum
values on the entire population in a protocol. Furthermore a higher resolution
DVH is stored for plotting and individual download via the web interface.
The trigger
structs feature was implemented to streamline the workflow of submitting DICOM
data specifically to a protocol in DcmCollab. A protocol key user can define a
trigger struct name with the prefix “trigger_” in a protocol for one or all
submitting institutions. If the system receives a structure set with an empty
ROI with this trigger name, it will automatically be put in the protocol along
with all referenced data.
The auto
export feature is almost self-explanatory. When data is put in a protocol with
the Auto Export feature enabled, the data is automatically exported to a
selected external DICOM node.
Combined
with trigger structs this allows protocols to be set up so that data can be
sent via DcmCollab directly from one institution to another without manual
interaction with the web interface.
The audit
tool uses data submitted to DcmCollab to generate anonymized data sets for
audit trials. The workflow begins with searching for the original data via
patient ID. A user can use data submitted from their own site or data that they
have access to via protocol permission levels for audit data.
When the
original data is selected, the user is prompted for a new name and patient ID
prefix and the number of copies to generate. The user is also presented with
options to pre-link the generated data to a new or an existing protocol, and to
create a trigger struct in the generated data.
Finally the
user selects which destination each copy of the generated data should be exported
to.
When the
user clicks “process”, DcmCollab generates the selected number of anonymized
copies of the original data and exports them to the selected destinations. The
generated data is not added to the
DcmCollab database at this point, only when or if the receiving institutions
return the data will it be added to the database. If the user selects to link the generated
data to a protocol, the generated DICOM instance UID’s are registered as
belonging to the selected protocol, which is then remembered for when or if the
data is returned.