Decision Language specification

The input section contains declarations of all subject variables used by a DLM. At a minimum, a subject variable declaration states the symbolic name and type of the variable in the manner typical of a typed programming language, as exemplified by the following:

Although a subject variable declaration appears to declare a simple property of a type such as a Quantity, in fact it creates an instance of a proxy object described below in Section 4, that provides access to snapshot values of the variable over time, as well as other smart facilities including null-value detection and range conversion, described in the sections below.

An important category of subject variable is the tracked variable, which enables the current value of a variable, with some lag, to be obtained automatically from the back-end system. The acceptable lag is indicated by the subordinate currency attribute, as a temporal duration. This specifies how recent the value obtained from the external world (the 'sample') must be to be valid from the point of view of the DLM. Currency may be understood as the converse of 'staleness', that is, a variable sample that must be say 1 hour or less old is understood as stale after 1 hour.

The use of the currency modifier establishes that a subject variable is a time-related sample of some kind (instantaneous, average, minimum, etc) of a real-world time-varying continuant quality (e.g. blood pressure) of an independent continuant entity (usually a person).

Since the various physiological and disease process that occur in a human body have significantly differing temporal rhythms, currency will vary widely for different subject variables, as per the following examples.

Variables for which no currency is stated may be understood as having the currency equal to the age of the subject.

Many tracked variables are quantitative, and a ubiquitous need within clinical guidelines and rules is to be able to refer to a continuous variable such as vital signs and most lab test values as being in a designated range. Such ranges may be the usual ones published e.g. the normal and high ranges for lipids in a cholesterol test for adults, or ranges defined by the DLM.

The ranges for a subject variable are declared in the following way:

The above declaration allows the use of the predefined range function, which returns the most precise range in which the value falls, in rule expressions such as the following:

Note that ranges may be defined in two ways:

In the latter case, determining that a patient has high blood pressure requires an expression of the form systolic_blood_pressure.in_range ({[high], [very_high], [critical_high]}), using a set argument.

Sometimes there are multiple ranges, usually due to alternative units systems. This is handled by the use of a discriminator on a number of range groups. The following shows an example.

To access a range within this structure, an expression of the form systolic_blood_pressure.in_range (["kPa"], [high]) is needed. This makes use of an overload of the in_range() function taking two keys. We can now see that the simpler form systolic_blood_pressure.in_range ([critical_high]) first chooses the first range group, and then extracts the required entry.

The above case reveals the general structure of the ranges property, with a formal type equivalent to Map <Terminology_code, Map <Interval <T>, Terminology_code>, where T is the declared type of the subject variable. In both the simple and discriminator cases, the entry |> 140|: [very_high] defines a [key, value] pair whose key is of type Interval <Real> and whose value is of type Terminology_code.

The DLM preconditions section is formally represented as a feature group called 'preconditions' whose members are limited to being a single BMM_FUNCTION containing the Boolean expression that appears in that section. The expression may reference only rules and input variables.

The DLM reference section is formally represented as a feature group called 'reference' whose members are limited to BMM constants.

The DLM input section is formally represented as a feature group called 'input' whose members are limited to BMM constants of a specific concrete type TRACKED_VARIABLE<T> and descendants, supplied by the proc.decision_language.concrete package.

The DLM rules section is formally represented as a feature group called 'rules' whose members are limited to BMM functions. A specific meta-type DLM_RULE is used in case extensions to the standard BMM_FUNCTION are required.

The variable definitions found in the input section of a DLM are designed to facilitate both intuitive DLM authoring and tracking of values over time from real data sources, typically health records, devices and so on. The generic class STATE_VARIABLE<T> and descendants provide a representation of a subject variable with a symbolic name. The generic type parameter is substituted with types used for representing atomic data values, including primitive types such as String, Integer etc, as well as types like Terminology_code, Quantity etc, as available in the models (type definitions) used by a DLM.

The class STATE_VARIABLE<T> models the simplest case: a variable that may be queried once for an execution run. This is sufficient for subject variables that are not time-dependent, and will not change during the execution, such as date_of_birth, sex, and Boolean variables such as is_type1_diabetic. The history attribute contains the variable value (normally only one sample), while the features is_available() and unavailable_reason() provide a way for missing data to be checked for.

For time-varying variables, the values must usually be tracked. The class TRACKED_STATE_VARIABLE<T> is is provided for this purpose, and adds the meta-attribute currency, a duration indicating the maximum age of the sample value to be useful or valid. The history attribute now contains variable samples over time. The function value() extracts the most recent available value, while is_available() is redefined to indicate whether a sufficiently recent value is available.

Many tracked variables are quantitative, and for these, extra facilities are provided via the class TRACKED_QUANTITATIVE_VARIABLE<T>, which adds the ranges facility described earlier in Section 3.8.3.

Variable declarations in DL syntax, as described in the language section above are in fact instantiations of the STATE_VARIABLE<T> or a descendant, potentially with constructor paramaters supplied. Consider the following declaration, shown earlier:

If we were to rewrite this in a more standard programming language, it might look like the following object instantiation, preceded by setup code (the syntax 'Type_name (args)' is used to represent an object creation using a constructor call in each case):

It will be appreciated that this is substantially more complex, and also arcane to a domain specialist. In the above, the part between the parentheses in the lower declaration corresponds to a call to a constructor of type TRACKED_QUANTITATIVE_VARIABLE with the signature (name: String, currency: Iso8601_duration, ranges: Map<Terminology_code, Interval<T>). From a formal point of view, such an instantiation creates an instance that will remain for the life of the DLM’s execution, in other words, a computed constant value. It is thus a meta-instance of the BMM meta-type BMM_CONSTANT, as shown in the DLM model above.

Each input variable declaration creates an object similar to the above, which may then be used during the execution of the DLM by calls made from the functions in the rules section. The simplest possible 'bare' reference of the variable name alone, i.e. systolic_blood_pressure in the example above, makes use of the default delegate feature of the BMM (BMM_FUNCTION) to invoke the value() function, avoiding the need to write systolic_blood_pressure.value(). However, all the features defined on TRACKED_VARIABLE and its descendants are indeed available for use in DLM code if needed. Thus, systolic_blood_pressure.in_range([high]) is a normal call on the systolic_blood_pressure instance of TRACKED_QUANTITATIVE_VARIABLE<Quantity>.