ProKnow DICOM Agent: Configuring Anonymization

Anonymization Configuration

ProKnow DICOM services can be set up to automatically anonymize DICOM data prior to upload to ProKnow. The anonymization is customizable via anonymization configuration "rules files" that determine (1) which of the DICOM attributes to anonymize and (2) how to anonymize each attribute for the applicable DICOM service(s).

If you enable auto-anonymization for a DICOM service, you must specify a rules file. See Configuring Services for instructions on how to select the rules file for a service. A rules file can be shared by services running within the same ProKnow DICOM Agent installation.

CAUTION: Do not share a rules file across multiple ProKnow DICOM Agent installations that are uploading to the same ProKnow workspace when using the GeneratePatient rule for (0010,0020) Patient ID and (0010,0010) Patient’s Name or the GenerateUid rule for DICOM UID attributes. Because the ProKnow DICOM Agent database is not shared, different anonymized patient IDs and patient names will be generated for the same original patient ID and patient name and different anonymized UIDs will be generated for the same original UID. This will result in data not being properly associated.

SUGGESTION: If you do have multiple DICOM Agent installations uploading to the same ProKnow workspace (e.g., a network of computers at work using one DICOM Agent installation and all of its services, plus additional installations on personal computers you are running from home), then set up the rules file to product unique Patient IDs by using set prefixes or suffixes to be added to the rest of the ID strings.

Format

The rules files are XML files. You will edit each XML file to define your anonymization configuration and save as a rules file.

The best method to ensure correct format of the rules file is to download the example rules file from the Create Service or Edit Service dialogs. Then, create a copy and edit that new file according to your preferences. See Configuring Services for instructions on how to download the example rules file. It is important to preserve this format, including the labels, so that the file can be properly parsed by the application.

The format of the rules file will allow you to (1) define individual elements and their anonymization rules and (2) define the global rule for changing (e.g., shifting) date/time values for applicable elements.

Individual Elements

An XML rules file will contain a list of elements, one for each attribute to be anonymized. If you do not specify an element, then that element’s attributes will always be preserved, i.e., remain unchanged.

See the Table 1. Element Properties for descriptions of the element properties. Only required properties need to be present. The properties can appear in any order. For example, an element to remove the private attribute PET Patient ID look like this:

<Element>
  <PrivateCreator>GEMS_PETD_01</PrivateCreator>
  <Name>PET Patient ID</Name>
  <Tag>(0009,1002)</Tag>
  <ValueRepresentation>LO</ValueRepresentation>
  <Rule>Remove</Rule>
</Element>

Table 1: Element Properties

Name	Example: "Referring Physician's Name" Only used for error messages
Tag	Example: "(0008,0090)" Format is flexible (parentheses are optional, whitespace is optional)
ValueRepresentation	Must be one of the following: AE, AS, AT, CS, DA, DS, DT, FL, FD, IS, LO, LT, OB, OD, OF, OL, OV, OW, PN, SH, SL, SQ, SS, ST, SV, TM, UC, UI, UL, UN, UR, US, UT, UV Only used for validating anonymization configuration
Rule	See Table 2. Anonymization Rules in this document
Value	Always interpreted as a string value Required for Fixed and GeneratePatient rules
Private Creator	Required for private attributes (odd tag group). The value to which this should be set is the value the vendor provides for the associated (xxxx,0100) Private Creator attribute that appears in the same dataset where "xxxx" is the same tag group number.

Global Date/Time Shift

An XML rules file will also contain a specification of a global date/time shift method. This method will be applied to any attribute for which the Shift rule has been specified, which by definition must have a value representation (VR) of either date (DA), time (TM), or date/time (DT).

Using a global date/time shift rule will ensure a uniform shift of the applicable date/timestamps, preserving the temporal relationship of the associated data. Once used, changing this value may impact the temporal relationship between data previously anonymized and future data to be anonymized.

In the downloadable example rules file that you can use as a template, the global date/time shift will be located near the top of the default rules file (preceding the list of Elements). The default setting will be as follows:

+00000000000

The syntax of the value is "sDDDDDHHMMSS" where:

The "s" character is an optional sign ("+" or "-") indicating the direction of the shift. If omitted, a "+" will be assumed.
DDDDD is the zero-padded number of days to be shifted.
HH is the zero-padded number of hours to be shifted.
MM is the zero-padded number of minutes to be shifted.
SS is the zero-padded number of seconds to be shifted.

For example, a setting of

+10000101010

will result in shift forward (i.e., positive) in time of 10000 days, 10 hours, 10 minutes, and 10 seconds.

Anonymization Rules

Table 2: Anonymization Rules

Keep	Makes no changes
Remove	Removes the element from the dataset altogether Cannot be used for (0010,0020) Patient ID or (0010,0010) Patient's Name, as those must be present
Clear	Does not remove the element, but sets the element value to either an empty string or an empty byte array, as appropriate Cannot be used for (0010,0020) Patient ID or (0010,0010) Patient's Name, as those cannot be blank
Fixed	Sets the element value to the user-specified fixed value The VR must be one of the following: AE, AS, CS, DA, DS, DT, IS, LO, LT, PN, SH, ST, TM, UC, UI, UR, UT
GenerateUID	Sets a UID to a randomly generated new UID The VR must be the "UI" type Consistently maps an old UID to the same new UID across all services within the ProKnow DICOM Agent application The generated values will be, for all practical purposes, universally unique
GeneratePatient	Sets a Patient ID or Patient's Name to a unique value based on a user-defined value key. The key syntax includes a placeholder for incrementing numeric characters: The rule value must contain exactly one placeholder The placeholder syntax is curly braces surrounding one or more number signs, e.g., {########} Example: A value of "SiteXYZ{####}" generates SiteXYZ0000, SiteXYZ0001, SiteXYZ0002, etc. The tag must be (0010,0020) Patient ID or (0010,0010) Patient's Name Consistently maps an old Patient ID (Patient's Name) to the same new Patient ID (Patient's Name) across all services within the ProKnow DICOM Agent application Patient's Names are mapped in conjunction with the mapping of their corresponding Patient IDs, i.e., the Patient ID is the key for determining whether a mapping for a Patient ID and/or Patient's Name already exists. The generated values will be unique within the ProKnow DICOM Agent application for the specific tag, provided the placeholder has enough digits.
CopyPatientID	Sets a Patient's Name to the anonymized Patient ID value The tag must be (0010,0010) Patient's Name
Shift	Shifts a temporal value using the global date/time shift rule The VR must be one of the following: DA, TM, or DT

Verification of an Anonymization Configuration

CAUTION: Make sure to include an element for every DICOM attribute that may contain PHI/PII that you want to anonymize, including private DICOM attributes. It is important to verify that the rules file works for the variety of DICOM content that may be transmitted to ProKnow DICOM Agent.

To verify, it may help to do the following:

Use a DICOM browsing tool to examine each variety of DICOM object that will be transmitted to ProKnow DICOM Agent. Be sure to inspect attributes at the root level as well those contained within nested sequences. Make a list of all the attributes you wish to anonymize.
Define a rules file that anonymizes each attribute in your list with your preferred anonymization method.
After the rules file has been defined, set up a service that only stores the anonymized DICOM locally (e.g., does not yet upload to ProKnow). Send a number of dataset transmissions through the server to create the anonymized output that is saved locally. Use a DICOM browsing or compare tool to verify that all desired PHI/PII has been removed and the anonymized values are as expected.
Manually upload representative anonymized datasets to ProKnow to verify that the replaced values are acceptable, i.e., that the rules you used are valid for each attribute and not rejected as invalid DICOM.