Introduction
The ImageServer software contains a sophisticated rules engine for defining various processing rules. The rules are defined individually for each server partition. Each rule has a specific type associated with it and a time when it is applied. The rules are typically applied when a study is initially processed by the server, when individual images are processed by the server, after studies have been archived, or when they have been restored back to an online state from an archive.
The rules can test against the values of DICOM tags encoded within the header of a DICOM file. Any DICOM tag that is contained within the root message can be specified in a rule. The names of DICOM tags are typically the names contained within the standard with any spaces and punctuation removed from the name, and the first character in any word contained in the name being capitalized. DICOM tags encoded within rules are verified when a rule is updated within the GUI and feedback will be given to the user if a tag specified is unknown.
Example Rule
The following is a simple auto-routing rule that routes all studies with the DICOM tag Modality set to a value of CT to the DICOM device with the AE Title CLEARCANVAS.
<rule id="CT Rule">
<condition expressionLanguage="dicom">
<equal test="$Modality" refValue="CT"/>
</condition>
<action>
<auto-route device="CLEARCANVAS"/>
</action>
</rule>
Each rule consists of conditions and actions. The conditions are the test to apply against a DICOM study or image. The actions are the actions to perform if the condition is met. In the above example, an equal test is done to compare the value of the DICOM tag Modality (0008,0060) against the value CT. The action in this example is to Auto-route the image to the DICOM device with the AE title CLEARCANVAS. More than one action can be specified for the rule.
The ImageServer web GUI verifies the contents of a rule, and will display an error message if the rule is encoded improperly. It will ensure that the rule is syntactically correct, and it will verify that only actions associated with the rule type are used.
Default Rules
The ImageServer also has the concept of Default rules. Default rules are only applied if no other rules of the same type apply to a study, and are applied by the rules engine as a last step. A default rule typically has an empty <condition/> element and a default action specified. The following example shows the default deletion rule automatically inserted for a new server partition:
<rule id="Default Delete">
<condition />
<action>
<study-delete time="10" unit="days" />
</action>
</rule>
Exempt Rules
The ImageServer also has the concept of Exempt rules. An Exempt rule defines that a study is exempt from a specific rule type, meaning the rule does not apply to the study. Exempt rules typically have a <no-op/> action defined for them.
You may be thinking what is the need for an Exempt rule, if you could simply create a normal rule with a <no-op/> action. When the rules engine applies a specific rule type to a study, Exempt rules are applied first to the study to determine if the study should be exempt. If a normal rule was defined with a <no-op/> action, the rules engine may find another rule that applies to the study before the Exempt rule is applied. Flagging a rule as an Exempt rule ensures that the rules engine will apply the rule first, before applying other rules.
Exempt rules and Default rules are often used in combination to apply rules to all studies except a few select ones. One good example of this use is with compression rules. The ImageServer automatically creates an Exempt rule to ensure studies that are already compressed do not have a new compression rule applied to them. The following example shows this exempt rule for compression:
<rule>
<condition expressionLanguage="dicom">
<or>
<equal test="$TransferSyntaxUid" refValue="1.2.840.10008.1.2.5" />
<equal test="$TransferSyntaxUid" refValue="1.2.840.10008.1.2.4.50" />
<equal test="$TransferSyntaxUid" refValue="1.2.840.10008.1.2.4.51" />
<equal test="$TransferSyntaxUid" refValue="1.2.840.10008.1.2.4.70" />
<equal test="$TransferSyntaxUid" refValue="1.2.840.10008.1.2.4.90" />
<equal test="$TransferSyntaxUid" refValue="1.2.840.10008.1.2.4.91" />
</or>
</condition>
<action>
<no-op />
</action>
</rule>
Rule Condition Operators
The following table defines the currently supported condition operators that can be used in the '<condition></condition>' element of the XML:
Example Operator |
Description |
<equal test="$Modality" refValue="CT"/> |
The equal operator tests if the value of a tag is equal to the refValue specified. |
<not-equal test="$Modality" refValue="CT"/> |
The not-equal operator tests if the value of a tag is not equal to the refValue specified. |
<and> |
The and operator forces a logical and to be performed with different operators specified within the <and></and>. Note that the or and and operators can be nested. |
<or> |
The or operator forces a logical or to be performed with different operators specified within the <or></or>. Note that the or and and operators can be nested. |
<greater-than test="$StudyTime" refValue="0800"/> |
The greater-than operator does a greater than test against the refValue specified. |
<less-than test="$StudyTime" refValue="1600"/> |
The less-than operator does a less than test against the refValue specified. |
<regex test="$PatientId" pattern="MSH"/> |
The regex operator allows specifications of a regular expression that is tested against the tag specified. The expression is evaluated as true if the pattern specified is found in the DICOM tag's value. |
<dicom-age-greater-than test=”$StudyDate” refValue=”5” units=”weeks”/> |
The dicom-age-greater-than operator checks if a DICOM date field is greater than the specified age. The units can be years, weeks, or days. |
<dicom-age-less-than test=”$PatientsBirthDate” refValue=”21” units=”years”/> |
The dicom-age-less-than operator checks if a DICOM date field is less than the specified age. The units can be years, weeks, or days. |
<not> |
The not operator does a logical not to the contents within the operator. Note that the <not> operator can be nested. |