Overview

The openEHR Expression Language (EL) defines a syntax and grammar for the expressions whose meta-model is defined in the expression package in the openEHR Basic Meta-Model (BMM). As such it may be considered the default syntax. Other syntaxes or syntaxes are certainly possible, and other expression serialisation are possible, such as object graph serialisation into XML, JSON, YAML etc. Consequently, the BMM expression package should be considered the normative definition of openEHR EL. Not all openEHR implementations using BMM expressions need support it: they might for example only serialse in JSON or use purely graphical visualisation.

Within openEHR, the uses of EL include expressing the following:

  • pre-, post-conditions and class invariants in BMM model definition files;

  • rules in archetypes;

  • rules in openEHR Guideline Definition Language (GDL);

  • expressions within decision logic models (DLMs) designed for use with openEHR Task Planning.

It may also be used in any other suitable context.

Requirements

The semantic requirements including the usual arithmetic, boolean, and relational operators, functions, logical quantifiers, operator precedence, constant values, and variables. In addition, there is a need to support multi-lingual translations for symbolic variables, in a similar way to the openEHR Archetype Definition Language (ADL2).

Design Background

The openEHR Expression Language is based on a combination of first-order predicate logic, object-oriented structural concepts and functional computing. It has some similarities with OMG’s OCL (Object Constraint Language). It also draws on the semantics and some of the syntax (particularly agent-related) of the Eiffel Language (ECMA-367). See [1], [2], [3] for an explanation of predicate logic in information modelling.

It is not exactly the same as any of these languages because:

  • it has a different meta-model, namely the BMM expression meta-model;

  • the syntax is designed to be comprehensible to developers familiar with modern mainstream object-oriented and functional languages such as Java, C#, Python, TypeScript etc.

Following the BMM meta-model, EL treats all classical operators as surface syntax for underlying functions available on types. Thus, the '+' operator in the expression total + 1 is resolved to a function call on the type Integer: total.add(1). In a similar way, higher-order operators ranging over collections of items (e.g. for_all) are resolved to calls to functions assumed to be defined on container types (e.g. my_list.for_all(agent (v:T) ))

Key features of EL include:

  • strong typing;

  • void-safety;

  • standard operators including:

    • logical operators including universal and existential quantification;

    • arithmetic and relational comparison operators, including for date/time types;

    • parentheses for overriding operator precedence;

  • object-oriented qualification (dot notation);

  • decision structures, including:

    • binary choice operator (the so-called 'ternay operator' :? in C);

    • condition chains (if/then/else equivalent);

    • case tables;

  • functions and agents (lambdas).

Execution Model

The assumed execution model of the Expression language is that EL statements are evaluated by an evaluator against a data context, which determines the truth values of the expression(s). The data context is the origin for some or all of the variables mentioned in the expressions, which may be read from and written to. It may concretely be a retrieved data structure, or data via an API call to the EHR, demographics, laboratory system etc.

The data context may be specified in two ways. It may be inferrable from the artefact or computing context in which the EL statements appear, or it may be specified explicitly. In the former case, the EL instance is minimally a value-returning logical proposition such as systolic_pressure > 0, where the declaration of variables or properties such as systolic_pressure are inferred from e.g. a data binding, and any manifest values obey this EL specification. The implicit case is shown below.

EL design structure implicit
Figure 1. EL execution model - implicit context

In the explicit form, an EL expressions appear within a BMM model definition, or within a context that explicitly imports a BMM model.

EL design structure explicit
Figure 2. EL execution model - explicit context

In both cases, the result of parsing into computable form for evaluation must result in instance of the BMM EL meta-types.

References

  • [1] J. F. Sowa, Knowledge Representation: Logical, philosophical and Computational Foundations. California: Brooks/Cole, 2000.

  • [2] J. L. Hein, Discrete Structures, Logic and Computability, Second. Jones, 2002.

  • [3] H. Kilov and J. Ross, Information Modelling - an object-oriented approach. Prentice Hall, 1994.