Condition Editor

The Rhapsody database communication points and filters allow a statement to be executed conditionally. A conditional statement checks a user-defined condition before execution, and will only be run if the condition evaluates to true.

The Database Configuration Editor provides a condition editor to allow these conditions to be built up. To launch the Condition Editor, click the Configure Statement Conditions icon for the selected statement or stored procedure. The Condition Editor is then displayed:

Building Conditional Expressions

Conditional expressions are built using some built-in functions that are used to check conditions and compare values. They can be combined using the and operator and the or operator to produce complex expressions. Parentheses can be used to provide nesting of conditions and to change the evaluation order. By default, expressions joined by an and operator are evaluated before expressions joined by an or operator. Parentheses can be used to modify this.

An example of a complex conditional expression is as follows:

NotNull (@NK1[0]) and (NotNull(@NK1[0].NextOfKinName or NotNull(@NK1[0].Address[0]))

This conditional expression evaluates to true if NK1[0] exists, AND either NK1[0].NextOfKinName or NK1[0].Address exists.

Functions

The conditional expression evaluator in Rhapsody provides a number of standard functions that can be used to check conditions and compare values. The comparator functions perform a string comparison (number comparison is not supported). All function names are case-insensitive. These are described in the following table:

Function Name	Description
`Equals(parameter1, parameter2)`	This function performs a case-sensitive comparison of the two parameters. It returns true if the two parameters are equal, or false if they are not equal.
`EqualsIgnoreCase(parameter1, parameter2)`	This function performs a case-insensitive comparison of the two parameters. It returns true if the two parameters are equal, or false if they are not equal.
`NotEqual(parameter1, parameter2)`	This function performs a case-sensitive comparison of the two parameters. It returns false if the two parameters are equal, or true if they are not equal.
`NotEqualIgnoreCase(parameter1, parameter2)`	This function performs a case-insensitive comparison of the two parameters. It returns false if the two parameters are equal, or true if they are not equal.
`NotNull(parameter)`	This function tests whether a parameter is null or the empty string. It returns false if the parameter is null, or true if it is not null.
`Null(parameter)`	This function tests whether a parameter is null or the empty string. It returns true if the parameter is null, or false if it is not null.

Parameters can be of the following type:

Parameter Type	Usage	Example
Literal value	Encapsulate the literal value in single quotes.	`'some literal value'`
Message property	Insert a dollar sign (`$`) in front of the message property name.	`$myProperty`
A field within a message	Insert an at sign (`@`) in front of the full path to the message field.	`@PID.PatientName[0].FamilyName.Surname`
Column From a previous result set	Insert an at sign (`@`) in front of the column name.	`@PatientName`
Stored procedure output parameter	Insert a hash sign (`#`) in front of the parameter name.	`#newPatientId`
Message body as a string	Insert `$messageContent`.	`$messageContent`
XPath expression of a message field in an XML input	Insert a backquote (`) in front of the XPath expression.	`MSH/SendingApplication/UniversalID

Examples

Example Function	Description
`EQUALS(@MSH.SendingApplication.UniversalID, 'System A')`	Compares a field in an HL7 v2 message with a literal value. If the second parameter is a literal value, encapsulation in single quotes is not required. For example, `EQUALS(@MSH.SendingApplication.UniversalID, System A)`. However, for intelligibility, it is recommended you always encapsulate literals in single quotes.
`EQUALS($SendingApplication, 'System A')`	Compares a property with a literal value.
`EQUALS(@systemName, $system)`	Compares a column from a previous result set with a property. If the first parameter is the column value, the prefixing at sign (`@`) is not required. For example, as in `EQUALS(systemName, $system)`. However, for intelligibility, it is recommended you always prefix column values with @.
`EQUALS(#storedProc_out_system, 'System A')`	Compares a stored procedure output parameter with a literal.
EQUALS(#storedProc_out_system, `/MSH/SendingApplication/Name)	Compares a stored procedure output parameter with a field in an XML message.

Inserting Prior Results

At times a statement should only be executed if a particular result was returned from a previous database query. The Database Configuration Editor provides the ability to insert results generated from previous queries to make it easier to access these values. These are accessed from the Insert Prior Result toolbar button:

Selecting a prior result automatically inserts the appropriate value (with the correct prefix depending on its type) at the current cursor location in the text editor. When the Condition Editor is opened, available prior results for all previous statements are located and added to the menu.

The only types of available prior results are: declared output parameters for stored procedure calls, and any columns whose values are saved using result substitution.