Expression Language (EL)

This document specifies the openEHR Expression Model (EOM) and an abstract syntax, denoted the openEHR Expression Language (oEL). The EOM defines the semantics of a first order predicate style logic that can be used to express assertions (for example in archetypes) and rulesfor example in decision support situations.

The intended audience includes:

Prerequisite documents for reading this document include:

Releated documents include:

The contents of this specification were separated out from the AOM2 specification in order to provide a common model of expressions and rules structures for AOM, GDL and other specifications requiring it.

This specification is in the TRIAL state. The development version of this document can be found at https://specifications.openehr.org/releases/LANG/latest/expression_language.html.

Known omissions or questions are indicated in the text with a 'to be determined' paragraph, as follows:

Feedback may be provided on the openEHR languages specifications forum.

Issues may be raised on the specifications Problem Report tracker.

To see changes made due to previously reported issues, see the BASE component Change Request tracker.

Conformance of a data or software artifact to an openEHR specification is determined by a formal test of that artifact against the relevant openEHR Implementation Technology Specification(s) (ITSs), such as an IDL interface or an XML-schema. Since ITSs are formal derivations from underlying models, ITS conformance indicates model conformance.

The openEHR Expression Language is based on a limited first-order predicate logic language. It has similarities with OMG’s OCL (Object Constraint Language), and to the assertion syntax used in the Object-Z language (Smith, 2000). See Sowa (2000), Hein (2002), Kilov & Ross (1994) for an explanation of predicate logic in information modelling. It also draws on the semantics and some of the syntax (particularly agent-related) of the Eiffel Language (ECMA-367). It is not exactly the same as any of these languages because:

Modern syntaxes that provide a more generic and minimal inspiration for the expression syntax described here include the Xpath syntax.

The semantic requirements are for expressions including arithmetic, boolean, and relational operators, functions, quantifier operators, operator precedence, parentheses, constant values, and certain kinds of variables. However, there is no support in the core specification for procedural semantics or most of the other complexities of full-blown programming languages.

The assumed execution model of the Expression language is that an EL text is evaluated by an evaluator against a data context, which determines the truth values of the expression(s). The data context typically includes data services such as the EHR, patient demographics, laboratory systems and so on - anything that is available computationally via some service. The text may contain symbols representing internal variables and bound variables, the latter of which map to entities in the data context.

No assumption is made about whether the data context used is complete or faithful to reality. Consequently, the expression universe is technically speaking an 'open world' in the sense of the open-world assumption. However, higher-level applications or components (or users) may have sufficient knowledge about the data as to be able to treat it in a closed world fashion, for example to treat absence of X as negation of X.

The Expression Language may be used to write single Boolean-valued expressions within another computational context, and in future, a multi-section self-standing EL text with a similar structure to an archetype. Expressions may be declarations, assignments or assertions. These are made up of expressions containing symbols which represent typed variables and constants. Variables are either bound or local, and are defined using $ names, e.g. $heart_rate as used in shell script and some other programming languages. A bound variable is mapped to a field in the data context. In the current version of the language, this is achieved by assignment statements that either assign a path in the data context to a symbolic variable (reading) or the reverse (writing back). In this sense, 'assignment' can be understood as associating a data context path with a named variable.

This section describes the openEHR Expression Language. In the various contexts where openEHR expressions are used, the syntax provides a foundation for concrete syntaxes supporting specific value-referencing mechanisms, as well as other types of rules, operands etc. The key features of the language are: variable declarations, assignments and expressions. Most of the semantics are in the expression part, which is based on first-order predicate logic with the addition of arithmetic and relational operators to enable the use of numeric elements. Expressions may contain constants, variable references, value references and functions.

The syntax style used here is generally so-called 'snake_case' rather than so-called 'CamelCase', in common with other openEHR specifications, but either may be used in real applications.

The Expression language is fully typed. The type system is the same as that used in other openEHR components, and supports the same set of basic types as described in the openEHR Foundation Types Specification, namely:

An EL text consists of statements, each of which may be a declaration, an assignment or an assertion.

Variables that are bound to entities in the data context function differently from local variables, since their availability is predicated on the existence of the relevant entities. For example, the variable $body_weight may be bound to a call that retrieves a patient heart rate from the EHR, via an appropriate API call. There is no guarantee that the value is available, so $body_weight may therefore be undefined in a sense not applicable to local variables. In a programming language, if a variable is not explicitly set, it has either the default value of the type (e.g. 0 for Integer) or a random value of the correct type. This behaviour is appropriate for local variables, but for bound variables that cannot be evaluated because the external entity does not exist, we want something like an exception to occur.

The approach used for EL is to allow bound variables to be used freely, as for local variables, but if a bound variable cannot be evaluated from the data context, an 'undefined value' exception should be generated, indicating which variable could not be evaluated. To impose more control, the predicate exists () can be used within an expression or assertion to ensure that one or more variables can be populated before proceeding with logic that depends on them, as follows:

To assert that a certain part of a larger data structure exists, the following assertion can be used.

Expressions constitute the main part of the Expressions language, and consist of a familiar typed, operator-based syntax common to many programming languages and logics. Formally, an expression is one of the following:

The expression package defines the Expression Object Model (EOM), a model of 'statements' and 'expressions' that can be used in various contexts in openEHR, including inside archetypes and in GDL guidelines. If the Expression Language or other syntax-based artefact is used, the model described here defines the parser output in the form of an expression tree. Other openEHR models designed for a particular purpose may reuse the expression package and further specialise some of its types specifically intended for extension.

The package structure of the expression package is shown below.

The main expression packages core and extension are illustrated below.

A group of statements to be used together is formally defined as one or more STATEMENTs in a STATEMENT_SET. There are three types of statements corresponding to the classes ASSERTION, VARIABLE_DECLARATION and ASSIGNMENT. Assertions consist of an expression tree structure that evaluates to a Boolean value. The root of the tree is a descendant of the class EXPR_ITEM that represents a Boolean-returning operator or value. An Assertion has an optional tag, enabling it to be named.

A VARIABLE_DECLARATION enables a named variable to be declared with a type, which must be one of the descendants of EXPR_DEF_TYPE.

The ASSIGNMENT class defines the usual operation of assigning a value (the source i.e. the notional right-hand side) to a variable, (the target, i.e. left-hand side). The source of an assignment can be any Expression or an EXTERNAL_QUERY, which are sub-types of EXPR_VALUE.

The expressions.types package is shown below.

The type system of the Expression formalism is defined via the type EXPR_TYPE_DEF and its descendants. All types have a type_name and a type_anchor, which is a variable of the coresponding primtive type from within the openEHR base_types package, i.e. Integer, Real, String, etc. The type anchor can be used for testing assignments within the implementation. A special type TYPE_DEF_OBJECT is included to enable a value reference (descendant of EXPR_VALUE_REF) to refer to a complex object, to which some expression operators can be applied, including equality and existence. The types system is extensible, as described below.