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 can have three or four 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.
• OriginDate specifies a date to which the computed number of days is added before returning the resulting date.

DICOM date elements have the format YYYYMMDD. The format used for base dates in the lookup table is the more conventional M/D/YYYY, as in 7/4/1776 or 12/25/2017. The OriginDate argument, if present, must be in DICOM format. The OriginDate argument may be supplied as a parameter reference.

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

If the OriginDate argument is not supplied, the function returns the computed interval in days.

If the OriginDate argument is supplied, the function adds the computed number of days to the OriginDate and returns the resulting date in DICOM format.

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.

As another example, if it is desired to create dates starting from some origin in time, offset by the computed interval, and 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,20000101)

In this example, the OriginDate is specified in the function call itself, but if several elements are to be offset in this way, it would be more convenient to specify the OriginDate as a parameter reference (e.g., @ORIGINDATE).

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 to process the quarantined objects. The LookupTableChecker stage provides access to its database and quarantine through its status page, which is available by clicking the stage in the left pane of the CTP home page.

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).