Using the DicomAnonymizer dateinterval Function

This article describes how to configure the DICOM anonymizer to use the dateinterval function. The intended audience for this information is clinical trial coordinators.

The DicomAnonymizer dateinterval function computes the number of days between two dates, typically a StudyDate and a base date associated with the PatientID and stored in the anonymizer's lookup table.

The function has three arguments:

• DateElementName specifies the date element in the DICOM dataset to serve as the end of the interval.
• KeyType specifies the subset of the lookup table containing base dates.
• KeyElementName specifies the element in the DICOM dataset to serve as the key under which to find the base date of the interval.

The function subtracts the base date from the DateElement value and converts the result to days.

For example, if it is desired to store the date interval in an element during the anonymization process, the script for the element might be written as:

@always()@dateinterval(StudyDate,basedate,PatientID)

In this example, the KeyType is specified as "basedate", but it could be any single-word text.

Note: the @always() function call is required to force the creation of the element if it is not already present in the data object.

If the base date is not present in the lookup table, the DicomAnonymizer will quarantine the object.

A more convenient way to trap objects for which the base date is missing is to put a LookupTableChecker pipeline stage before the DicomAnonymizer. Here is a configuration illustrating how to do it:

<Configuration>
    <Server
        maxThreads="20"
        port="9666"/>
    <Pipeline
        name="Test Pipeline"
        root="test">
        <DicomImportService
            class="org.rsna.ctp.stdstages.DicomImportService"
            logConnections="no"
            name="DicomImportService"
            port="104"
            quarantine="quarantines/DicomImportService"
            root="roots/DicomImportService"/>
        <LookupTableChecker
            class="org.rsna.ctp.stdstages.LookupTableChecker"
            id="LookupTableChecker"
            name="LookupTableChecker"
            quarantine="quarantines/LookupTableChecker"
            root="roots/LookupTableChecker"/>
        <DicomAnonymizer
            class="org.rsna.ctp.stdstages.DicomAnonymizer"
            lookupTable="scripts/LookupTable.properties"
            name="DicomAnonymizer"
            quarantine="quarantines/DicomAnonymizer"
            root="roots/DicomAnonymizer"
            script="scripts/DicomAnonymizer.script"/>
        <FileStorageService
            class="org.rsna.ctp.stdstages.FileStorageService"
            name="FileStorageService"
            port="9667"
            quarantine="quarantines/FileStorageService"
            returnStoredFile="yes"
            root="roots/FileStorageService"/>
    </Pipeline>
</Configuration>

When an object is encountered that will cause a lookup or dateinterval function call in the anonymization script to quarantine the object, the LookupTableChecker will put the object in its quarantine and make an index entry in its database identifying the offending elements. The LookupTableChecker servlet provides a convenient user interface to allow the table to be updated, after which the user can view the quarantine contents and click the Queue All button and process the quarantined objects.

Note: The id attribute of the LookupTableChecker stage is used to specify the context of the LookupTableChecker servlet, so in configurations with multiple LookupTableChecker stages (as might occur in multi-pipeline configurations), it is necessary to ensure that the id attributes are unique; otherwise, only the last stage that claimed the id attribute will be visible to the user interface (although all the LookupTableChecker stages will properly check objects and quarantine them as necessary).