openEHR logo

Expression Language and Model

Issuer: openEHR Specification Program

Release: latest

Status: DEVELOPMENT

Revision: [latest_issue]

Date: [latest_issue_date]

Keywords: openehr, expressions, rules

openEHR components
© 2003 - 2017 The openEHR Foundation

The openEHR Foundation is an independent, non-profit community organisation, facilitating the sharing of health records by consumers and clinicians via open-source, standards-based implementations.

Licence

image Creative Commons Attribution-NoDerivs 3.0 Unported. https://creativecommons.org/licenses/by-nd/3.0/

Support

Issues: https://openehr.atlassian.net/browse/SPECPR/
Web: http://www.openehr.org/

Amendment Record

Issue Details Raiser, Implementer Completed

1.0.1

Correct type of OP_DEF_EXISTS.evaluation_agent to FUNCTION<<Any>, Boolean>.

C Nanjo

31 May 2016

1.0.0

Initial writing. Taken from AOM2 2.0.6.

T Beale,
openEHR SEC

15 Feb 2016

Acknowledgements

Primary Author

  • Thomas Beale, Ars Semantica; openEHR Foundation Management Board.

1. Preface

1.1. Purpose

This document describes the openEHR Expression Language and Model, which provides the rudimentary structure for all forms of expression-based specifications in openEHR. It defines the semantics of first order predicate logic expressions, variable declarations and assignments.

The intended audience includes:

  • Standards bodies producing health informatics standards;

  • Academic groups using openEHR;

  • Solution vendors;

  • Medical informaticians and clinicians interested in health information.

Prerequisite documents for reading this document include:

Releated documents include:

1.3. Status

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 DEVELOPMENT state. The development version of this document can be found at http://www.openehr.org/releases/RM/latest/support.html.

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

TBD: (example To Be Determined paragraph)

Users are encouraged to comment on and/or advise on these paragraphs as well as the main content. Feedback should be provided either on the technical mailing list, or on the specifications issue tracker.

1.4. Conformance

Conformance of a data or software artifact to an openEHR Reference Model 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, automated derivations from the Reference Model, ITS conformance indicates RM conformance.

2. Overview

The openEHR Expression Language and Expression Object Model (EOM) define an extensible core formalism suitable for use in other expression- and rule-based formalisms and environments. The Expression Language is the abstract syntax counterpart to the Statement Object Model. The EOM should be considered the normative definition of the openEHR Expression formalism, and indeed not all implementations need support the language: they might for example only serialse in an 'object-dump' format or use purely graphical visualisation. However, the language described here still serves two purposes: providing at least one abstract formal serial form that is independent of any concrete format such as XML, RDF, JSON etc; and of providing a human-understandable notation for explaining the semantics of the EOM.

The formalism as defined here requires extensions for use, at a minimum to provide concrete value referencing. Extentions would also typically provide more operators, functions, leaf types and other features that are needed in specific circumstances.

Key features of the formalism include:

  • it supports variable declarations, assignments and expressions;

  • expressions are typed, using a set of primitive types to which every expression node must evaluate;

  • it supports all standard logical operators including universal and existential quantification, as well as user-defined operators;

  • it supports standard arithmetic and relational comparison operators, enabling the use of numerics;

  • parentheses for overridding operator precedence are supported;

  • it supports functions, including built-ins like current_date, standard functions like max() as well as user-defined functions.

2.1. Execution Model

The assumed execution model of the Expression formalism is that it defines statements in a statement set that are evaluated by a statement evaluator against one or more data contexts which determine the truth values of the statements. The data context provides the computable representation of those aspects of reality to which the statements refer. Thus, a statement that asserts that heartrate > 50 is making an assertion about values found in some data - i.e. heartrate is a path or other resolvable reference to a value in some data representing an actual heart rate.

It is thus the job of value references in expressions to reference values in the data context. The data context is not concretely defined in this specification, and must be specified in full languages based on this core formalism, which can be done in two places: by defining concrete value references, and by implementing the 'external query' facility to access data from services in the environment. The formalism as defined here is thus not complete on its own.

If the Statement set contains Assertions, they are treated as conditions that must evaluate to True to pass. If an assertion fails at execution time, an assertion violation is raised. If any assertion violations occur, the Statement set is said to have failed.

No assumption is implied 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.

2.2. Design Background

The openEHR Expression formalism is based on a limited first-order predicate logic language with extensions for numeric sub-expressions. It has similarities with OMG’s OCL (Object Constraint Language) syntax, and is also similar to the assertion syntax used in the [Object_Z] and [Eiffel] languages and tools for over a decade (see [Sowa], [Hein], [Kilov_Ross] for an explanation of predicate logic in information modelling). None of these languages has been used directly, for reasons including:

  • OCL has a complex type system connected to the UML meta-model, and includes some undecidable procedural semantics;

  • none have adequate variable referencing mechanisms, such as to paths and external queries;

  • they are too powerful, and would introduce unnecessary complexity.

There are also similarities with other languages developed in the health arena for expressing 'medical logic' (Arden [hl7_arden]), guidelines ([GLIF] and many others) and decision support (e.g. GELLO [hl7_gello]). These languages were not used either, for reasons including:

  • none have an easily extensible value referencing mechanism;

  • some are too procedural (Arden, GLIF);

  • current versions of some of these languages have been made specific to the HL7v3 RIM, a particular model of health information designed for message representation (GLIF 3.x, GELLO).

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

The design approach used here was thus to create a small concrete syntax allowing for a core subset of first-order predicate logic, and a corresponding object model representing the parse-tree form of the language.

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.

3. The Expression Language

3.1. Overview

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.

3.2. Typing

The Expression language is fully typed, with all types coming from a set of types consisting of primitive types plus an object reference type. The primitive types are shown below, along with typical literal values, which are expressed in the ODIN syntax.

Name Literal value Description

Boolean

True, False

Boolean value

Integer

10, -4, 1024

Integer value

Real

10.0, 0.345

Real value

Date

2004-08-12

ISO8601-format date

Date_time

2004-08-12T12:00:59

ISO8601-format date/time

Time

12:00:59

ISO8601-format time

Duration

P39W

ISO8601-format duration

String

"this is a string"

String

Uri

http://en.wikipedia.org/wiki/Everest

Uri in RFC3986 format [uri_syntax]

Terminology_code

[snomed_ct::2004950]

Terminology code reference

The special Object_ref type is reserved for creating references to arbitrary objects in the data context, to which some operations can be applied.

TBD: do we need Integer64 and Real64?

Automatic type promotion from Integer to Real applies to all integer and real values and expressions, in the same fashion as most programming languages.

3.3. Variable Declarations, References and Assignments

Variables may be declared within a statement set, consisting of a name of the form $var and a type. Multiple variables may be declared on the same line in the same way as in many programming languages. The following shows various declarations:

    $date_of_birth: Date
    $age_in_years: Integer

    $weight, $height, $bmi: Real

Variables are referenced within assignments and expressions using the same syntax, i.e. $var.

Typically declarations are used with assignments in the same way as in general purpose programming in mainstream languages. A variable can be assigned a number of kinds of things that are useful in statement sets, including constants, expressions and value-references. A declaration can be combined with an assignment. These are illustrated below.

    $Mph_to_kmh_factor: Real := 1.6                 -- literal assigmment to create a constant
    $speed_kmh, $speed_mph: Real                    -- variable declarations

    $speed_mph := /path/to/mph/data/value           -- (provided by an extension)
    $speed_kmh := $speed_mph * $Mph_to_kmh_factor   -- an assertion containing variable references

Above, the path /path/to/mph/data/value is assumed to be provided by an extension to the language, for example that enables archetype or XML data to be accessed.

3.4. Assertions

An assertion is a standalone expression, often with a tag, which enables the meaning of the expression to be understood in context. If a tag is supplied it is prepended with a colon. The following example states that the speed in kilometres of some node is related to the speed-in-miles by a factor of 1.6:

    speed_validity: $speed_kmh = $speed_mph * $Mph_to_kmh_factor

Note that the final statement here is a Boolean-returning equality expression, not an assignment. It is stating that the data items representing speed in miles per hour and km per hour are related by the conversion factor $Mph_to_kmh_factor, which was earlier defined to be 1.6. This is different from the last statement in the previous example, which assigns the result of a multiplication to the variable $speed_kph.

The above example could also have been achieved without variables, as follows:

    speed_validity: /path/to/kmh/data/value = /path/to/mph/data/value * 1.6

In both cases it represents an assertion that when evaluated may be violated, in which case the statement evaluator can generate an assertion violation which might be used to notify a user or do some other action.

TBD: alternative: could include the keyword check prior to assertion expression to make it clearer that the intention is to check that this condition holds; may also prevent confusion for readers used to languages where '=' is assignment.

3.5. Expressions

Expressions constitute the main part of the Expressions language, and consist of a familiar typed, tree-structured, operator-based syntax common to many programming languages and logics. The two element types are operators and operands, i.e. leaf nodes. Expressions may contain the following elements:

  • value references: i.e. references to data elements in the form of an archetype path;

  • literals: i.e. primitive values including the date/time types;

  • operators: arithmetic operators, relational operators, boolean operators, quantification operators;

  • functions: various built-in functions as well as user-defined functions.

In the Expression language, functions are treated as lead nodes in expressions, rather than expression nodes.

3.5.1. Operands (Leaf Nodes)

Operands in an assertion expression are typed and are of four kinds, as described in the following sub-sections.

3.5.1.1. Literal Values

Literal values are of any primitive type, and are expressed in the ODIN syntax. Examples are shown above under Typing.

3.5.1.2. Value References and Object References

Entities in the data context can be referred to in two ways. The concrete reference mechanism must be defined in an extension; here we assume it is some kind of path of the form /path/to/data/item. The first kind of reference is a value_reference, and is achieved by the use of the naked reference. The assumption is that the reference points to a data item of a primitive type, or one that can be interpreted or converted unambiguously to a primitive type by the statement evaluator. The 'type' of any value reference is thus always a primitive type. This enables referencing to normal leaf values in the data.

The other form of reference is an object reference. This enables a reference to an arbitrary object within the data to be created, and is done using the form @ref, e.g. @/path/to/data. The type of this is Object_ref within the expression type system, and the instance represents a reference, not a value. Certain operators such as exists and for_all can be used with object references. An object reference may be created to any data entity in the data context, including primitive values.

The following shows a value reference in the form of an archetype path followed by an object reference to the same location.

    /data[id2]/items[id3]/value[id35]/value     -- Date of initial onset; type = Date

    @/data[id2]/items[id3]/value[id35]/value    -- Object ref to 'date of initial onset' item;
                                                -- type = Object_ref

An object reference can be assigned to a variable in the normal way. This variable must have the type Object_ref. It can then be used in the normal way in expressions and assignments with operators that apply to object references. The following illustrates.

    $pregnancy_data: Object_ref := @/path/to/pregnancy/data
3.5.1.3. Functions

Functions are considered leaf entities in the Expression language, and can be of a built-in type or external (user-defined) type. All functions are considered to have a formal typed signature of the form:

    <Arg1-Type, Arg2-Type, ....>: Result-type

Thus the integer addition function add would have the signature <Integer, Integer>: Integer.

The following functions are assumed to be built in (how particular implementations achieve this may vary).

Name Textual Rendering Signature Meaning

Degree 0 functions (no arguments)

current_date

current_date

:Date

Current date

current_time

current_time

:Time

Current time

current_date_time

current_date_time

:Date_time

Curent date time

Degree N functions (N argument)

sum

sum (x, y, …​.)

<Real, …​>: Real

Equivalent to x + y + …​.

mean

mean (x, y, …​)

<Real, …​>: Real

The mean (average) value of x, y, …​

max

max (x, y, …​)

<Real, …​>: Real

The maximum value among x, y, …​

min

min (x, y, …​)

<Real, …​>: Real

The minimum value among x, y, …​

All of the above functions which take Real argument will take Integer arguments and automatically promote them to Real in the usual fashion.

Externally defined functions are described below under Extensions.

3.5.2. Operators

Expressions can include arithmetic, relational and boolean operators, plus the existential and universal quantifiers. The full operator set is shown below, along with textual and symbolic renderings. The latter are just standard Unicode symbols. Expression parsers should ideally support these symbols as operator equivalents in addition to the textual form, since it allows expressions to be expressed in a more compact and less language-independent way.

Identifier Textual
Rendering
Symbolic
Rendering
Meaning

Arithmetic Operators - Numeric result; descending precendence order

"exp"

^

Expontentiation

"times"

*

*

Multiplication

"divide"

/

/

Division

"mod"

%

%

Modulo (whole number) division

"plus"

+

+

Addition

"minus"

-

-

Subtraction

Relational Operators - Boolean result; equal precedence

"eq"

=

=

Equality relation between numerics

"ne"

!=

Inequality relation between numerics

"lt"

<

<

Less than relation between numerics

"le"

<=

Less than or equal relation between numerics

"gt"

>

>

Greater than relation between numerics

"ge"

>=

Greater than or equal relation between numerics

Logical Operators - Boolean result; descending precendence order

"not"

not, ~

∼, ¬

Negation, "not p"

"and"

and

Logical conjunction, "p and q"

"or"

or

Logical disjunction, "p or q"

"xor"

xor

Exclusive or, "only one of p or q"

"exists"

exists

Existential quantifier, "there exists …​"

"for_all"

for_all …​ in

∀ …​ ∈

Universal quantifier, "for all x in y P"

"implies"

implies

Material implication, "p implies q", or "if p then q"

Operator semantics that require further explanation are described below.

3.5.2.1. Logical Negation

All Boolean operators take Boolean operands and generate a Boolean result. The not operator can be applied as a prefix operator to all operators returning a Boolean result as well as a parenthesised Boolean expression.

3.5.2.2. Logical Quantifiers

The two standard logical quantifier operators are supported, exists, for_all. Both operators are used with respect to value references within the execution data context. The exists operator applied to a value reference (such as a path in an information structure) state that the value is present in the data context; the negated form states that it does not exist. The following simple example illustrates.

    $is_female implies exists @/path/to/data/about/pregnancies

    $is_female ⇒ ∃ @/path/to/data/about/pregnancies     -- symbolic form

The same may be achieved using variables.

    $pregnancy_data: Object_ref := @/path/to/data/about/pregnancies

    $is_female implies exists $pregnancy_data

    $is_female ⇒ ∃ $pregnancy_data     -- symbolic form

Similarly, the for_all operator is applied to value references representing sets and lists, such as referred to by a path to a multiply-valued attribute.

    $pregnancy_data: Object_ref := @/path/to/data/about/pregnancies

    $no_premature_births := for_all $p in $pregnancy_data $p/term > P36W

    $no_premature_births := ∀ $p ∈ $pregnancy_data $p/term > P36W     -- symbolic form
3.5.2.3. Precedence and Parentheses

The precendence of operators follows the order shown in the operator tables above. To change precedence, parentheses can be used in the fashion typical of most programming languages, as shown below.

    $at_risk := $weight > 120 and ( $is_smoker or $is_hypertensive)

3.6. Other Statement Elements

3.6.1. External Queries

An expression referring to an externally defined query, possibly including arguments, may be defined using the variable declaration syntax. The general pattern is as follows:

    $varname: Type
    $varname := query (context, query_name, arg1, arg2, ...)

Examples include:

    $date_of_birth: ISO8601_DATE
    $has_diabetes, $is_female: Boolean

    $date_of_birth := query ("ehr", "date_of_birth")
    $has_diabetes := query ("ehr", "has_diagnosis", "[snomed_ct::1234567]")
    $is_female := query ("ehr", "is_female")

Any number of arguments can be included.

3.7. Extensions

3.7.1. Operators

3.7.2. Functions

3.8. Natural Language Issues

TBD: whether we do anything about the language dependence of expression variables.

4. The Expressions Package

4.1. Overview

The expressions 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 expressions package and further specialise some of its types specifically intended for extension.

The package structure of the expressions package is shown below.

BASE expressions packages
Figure 1. Statement Package

4.2. Core Package

The main expressions packages core and extension are illustrated below.

BASE expressions
Figure 2. Statement Package

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.

4.2.1. Expressions

Expressions are fully described statement values that may be evaluated internally (as compared to an external query) and are defined by the EXPR_XXX classes. The Expression classes model a typical evaluation tree each of whose nodes is either a leaf or an operator node. The semantics of Expressions are described in the Expressions sub-section in the Language section.

In this model, 'functions' are treated as leaf nodes rather than tree nodes, which would be more typical of a functional language meta-model. The leaf node approach used here treats functions as black boxes requiring an evaluation method, enabling the main expression tree to be evaluated by use of a standard set of operators whose semantics can be safely built in.

Operator semantics are defined by the class OPERATOR_DEF, which includes the two attributes name and symbols which define the name of the operator and its allowable symbols respectively.

TBD: could potentially separate 'text symbols' and 'math symbols' to enable rendering in different ways.

The OPERATOR_DEF_BUILTIN class defines a hook for implementing built-in operators, i.e. those that will be executed by fixed code within the statement evaluator, e.g. a case statement or similar that uses the implementation language native operators.

4.2.2. Other Statement Elements

4.2.2.1. External Query

An EXTERNAL_QUERY is a type of expression representing a call to an external service which obtains a value for it. This enables information items from the exterior computational environment to be treated as abstract typed values within expressions.

4.2.3. Class Descriptions

4.2.3.1. STATEMENT_SET Class

Class

STATEMENT_SET

Description

A container for a specific set of statements intended to be used together.

Attributes

Signature

Meaning

0..1

statement: List<STATEMENT>

The member statements of this statement set.

0..1

name: String

Optional name of this rule set.

Functions

Signature

Meaning

execution_result: Boolean

Execution result of the whole rule set. Determined by the and-ing of result values of Assertions in the rule set.

4.2.3.2. STATEMENT Class

Class

STATEMENT (abstract)

Description

Abstract concept of any statement in a block of rule statements.

4.2.3.3. ASSERTION Class

Class

ASSERTION

Description

Structural model of a typed first order predicate logic assertion, in the form of an expression tree, including optional variable definitions.

Inherit

STATEMENT

Attributes

Signature

Meaning

0..1

tag: String

Expression tag, used for differentiating multiple assertions.

0..1

string_expression: String

String form of expression, in case an expression evaluator taking String expressions is used for evaluation.

1..1

expression: EXPR_ITEM

Root of expression tree.

1..1

execution_result: Boolean

Execution result of this assertion.

4.2.3.4. VARIABLE_DECLARATION Class

Class

VARIABLE_DECLARATION

Description

Definition of a named variable that can be used in an expression.

Inherit

STATEMENT

Attributes

Signature

Meaning

1..1

name: String

Name of the variable.

1..1

type: EXPR_TYPE_DEF

Primitive type of the variable, enabling its use to be type-checked in expressions.

4.2.3.5. ASSIGNMENT Class

Class

ASSIGNMENT

Description

Abstract ancestor of types representing the assignment statement, which does not produce a value in the way that operators such as '=', 'and' etc do. An assignment associates a named variable with an expression.

Inherit

STATEMENT

Attributes

Signature

Meaning

1..1

target: VARIABLE_DECLARATION

The target variable on the notional left-hand side of this assignment.

1..1

source: EXPR_VALUE

Source right hand side) of the assignment.

4.2.3.6. EXPR_VALUE Class

Class

EXPR_VALUE (abstract)

Description

Any kind of statement element that can be evaluated. The type will either be supplied in descendant types or else will be inferred by an assignment statement linked to a typed variable.

Functions

Signature

Meaning

value: Any

The computed value of this node as a result of the nodes below it, for operator nodes, or else statically set or otherwise derived values.

4.2.3.7. EXTERNAL_QUERY Class

Class

EXTERNAL_QUERY

Description

Definition of a variable whose value is derived from a query run on a data context in the operational environment. Typical uses of this kind of variable are to obtain values like the patient date of birth, sex, weight, and so on. It could also be used to obtain items from a knowledge context, such as a drug database.

Inherit

EXPR_VALUE

Attributes

Signature

Meaning

1..1

context: String

Optional name of context. This allows a basic separation of query types to be done in more sophisticated environments. Possible values might be “patient”, “medications” and so on. Not yet standardised.

1..1

query_id: String

Identifier of query in the external context, e.g. “date_of_birth”. Not yet standardised.

0..1

query_args: List<String>

Optional arguments to query. Not yet standardised.

4.2.3.8. EXPR_ITEM Class

Class

EXPR_ITEM (abstract)

Description

Abstract parent of all typed expression tree items.

Inherit

EXPR_VALUE

Functions

Signature

Meaning

type: EXPR_TYPE_DEF

The primitive type of this node, which must be determined by redefinitions in concrete classes.

4.2.3.9. EXPR_OPERATOR Class

Class

EXPR_OPERATOR (abstract)

Description

Abstract parent of operator types.

Inherit

EXPR_ITEM

Attributes

Signature

Meaning

0..1

precedence_overridden: Boolean

True if the natural precedence of operators is overridden in the expression represented by this node of the expression tree. If True, parentheses should be introduced around the totality of the syntax expression corresponding to this operator node and its operands.

1..1

operator_def: OPERATOR_DEF

Operator definition.

0..1

symbol: String

The symbol actually used in the rule, or intended to be used for serialisation. Must be a member of operator_def.symbols.

4.2.3.10. EXPR_UNARY_OPERATOR Class

Class

EXPR_UNARY_OPERATOR

Description

Unary operator expression node.

Inherit

EXPR_OPERATOR

Attributes

Signature

Meaning

1..1

operand: EXPR_ITEM

Operand node.

4.2.3.11. EXPR_BINARY_OPERATOR Class

Class

EXPR_BINARY_OPERATOR

Description

Binary operator expression node.

Inherit

EXPR_OPERATOR

Attributes

Signature

Meaning

1..1

left_operand: EXPR_ITEM

Left operand node.

1..1

right_operand: EXPR_ITEM

Right operand node.

4.2.3.12. OPERATOR_DEF Class

Class

OPERATOR_DEF (abstract)

Description

Abstract definition of an operator for use in the Rules evaluator.

Attributes

Signature

Meaning

1..1

identifier: String

Unique identifier of this operator within the rules system.

Functions

Signature

Meaning

symbols: List<String>

One or more symbols used to express the operator in textual form. This may include any unicode character.

4.2.3.13. OPERATOR_DEF_BUILTIN Class

Class

OPERATOR_DEF_BUILTIN

Description

Builtin operator pseudo-type. An implementation will typically use the 'identifer' attribute to determine which piece of internal code to execute to evaluate the operator.

Inherit

OPERATOR_DEF, BUILTIN_OPERATORS

Invariant

Valid_operator: op_table.has (name)

4.2.3.14. BUILTIN_OPERATORS Class

Class

BUILTIN_OPERATORS

Description

Singleton accessor object for list of builtin operators.

Constants

Signature

Meaning

1..1

op_table: Hash<String, List<String>>

List of built-in operators in the form of a keyed table of List<String>, where the latter represents one or more lexical symbols used for the operator, e.g. "+", and the key is the operator identifier, e.g. "plus".

Implementations may choose to populate this table with all operators defined in the core specifications, or only partially, in which case operators not in the table are implemented using the closure/agent approach for externally defined operators.

4.2.3.15. EXPR_LEAF Class

Class

EXPR_LEAF (abstract)

Description

Expression tree leaf item representing one of:

  • a manifest constant of any primitive type;

  • a path referring to a value in the archetype;

  • a constraint;

  • a variable reference.

Inherit

EXPR_ITEM

Attributes

Signature

Meaning

0..1

item: Any

The reference item from which the value of this node can be computed.

4.2.3.16. EXPR_LITERAL Class

Class

EXPR_LITERAL

Description

Literal value expression tree leaf item. This can represent a literal value of any primitive type included in the PRIMITIVE_TYPE enumeration.

Inherit

EXPR_LEAF

Attributes

Signature

Meaning

1..1
(redefined)

item: Any

A statically set constant value of a primitive type.

4.2.3.17. EXPR_VARIABLE_REF Class

Class

EXPR_VARIABLE_REF

Description

Expression tree leaf item representing a reference to a declared variable.

Inherit

EXPR_LEAF

Attributes

Signature

Meaning

1..1
(redefined)

item: VARIABLE_DECLARATION

The variable referred to.

4.2.3.18. EXPR_VALUE_REF Class

Class

EXPR_VALUE_REF (abstract)

Description

Abstract parent type of concrete types enabling access to values in a specific information structure. This type provides an extension point for specific syntaxes to connect a generic rule structure to a data source.

Inherit

EXPR_LEAF

4.2.3.19. EXPR_FUNCTION Class

Class

EXPR_FUNCTION

Description

Node representing a function with 0 or more arguments.

Inherit

EXPR_LEAF

Attributes

Signature

Meaning

0..1

arguments: List<EXPR_ITEM>

Arguments of this function, which can be from 0 to any number. Functions with no arguments are typically used to represent real world varying values like 'current time' and so on.

1..1

function_def: FUNCTION_DEF

4.2.3.20. FUNCTION_DEF Class

Class

FUNCTION_DEF (abstract)

Description

Ancestor type for types that define a function for use in the Rules evaluator.

Attributes

Signature

Meaning

1..1

identifier: String

Unique identifier of this function within the Rules system.

4.2.3.21. FUNCTION_DEF_BUILTIN Class

Class

FUNCTION_DEF_BUILTIN

Description

Builtin function pseudo-type. An implementation will typically use the 'identifer' attribute to determine which piece of internal code to execute to evaluate the function.

Inherit

FUNCTION_DEF, BUILTIN_FUNCTIONS

Invariant

Valid_function: func_table.has (name)

4.2.3.22. BUILTIN_FUNCTIONS Class

Class

BUILTIN_FUNCTIONS

Description

Singleton accessor object for list of builtin functions.

Constants

Signature

Meaning

1..1

func_table: Hash<String, List<String>>

List of built-in functions in the form of a keyed table of List<String>, where the latter represents one or more lexical symbols used for the function, e.g. "max", and the key is the function identifier, e.g. "max".

Implementations may choose to populate this table with all functions defined in the core specifications, or only partially, in which case functions not in the table are implemented using the closure/agent approach for externally defined functions.

4.3. Extension Package

The Extension package contains classes that provide extension points to the Expression formalism. These are of three kinds:

  • value references;

  • externally defined operators;

  • externally defined functions.

4.3.1. Value References

Value references are defined by creating descandants of the EXPR_VALUE_REF class. These typically contain a reference to a data object, or an identifier that can be resolved to a value via a resolver.

4.3.2. Operators and Functions

Externally defined operators and functions are defined as the separate types OPERATOR_DEF_EXTERNAL and FUNCTION_DEF_EXTERNAL resepectively. They could in theory be defined with a single class, however the use of two classes express the distinction between operators and functions used in the openEHR Expression language.

TBD: this model in its current form treats functions and operators as separate, to allow some convenience in simple implementation of standard operators. But Theoretically, operators are just 1-arg or 2-arg functions, and the extensions could be defined by treating them as functions. However operators also usually have a symbol form, whereas we are assuming a function’s symbol is just its identifier. Also, functions can in general have variable numbers of arguments, and complex implementations. Do we want to implement operators that way?

The OPERATOR_DEF_EXTERNAL class inherits the identifier and symbols features from OPERATOR_DEF, and adds an execution_agent, which is a function object that can compute the operator, given appropriate arguments. The extention part of the UML model above shows how tihs facility can be used to define two operators that would normally be implemented as built-ins, and and exists.

TBD: this is shown as being done with a class per operator, but in fact it only requires instances of OPERATOR_DEF_EXTERNAL which have the appropriate identifiers, symbols and avaluation agent. Should we just define it this way?

The approach to adding custom functions is the same as with operators.

4.3.3. Class Descriptions

4.3.3.1. OPERATOR_DEF_EXTERNAL Class

Class

OPERATOR_DEF_EXTERNAL (abstract)

Description

Ancestor of concrete operator definition types. Adds an optional execution agent, typically implemented by closures / lambdas/ agents in languages supporting functional programming.

Inherit

OPERATOR_DEF

Attributes

Signature

Meaning

1..1

evaluation_agent: FUNCTION

4.3.3.2. OP_DEF_EXAMPLE Class

Class

OP_DEF_EXAMPLE

Description

Example custom operator definition as a class, for an operator whose identifier is 'xxx' and for which the symbols "xxx" and "%" can be used, and with a two-argument numeric signature.

Inherit

OPERATOR_DEF_EXTERNAL

Attributes

Signature

Meaning

0..1

symbols: List<String> = "xxx", "%"

1..1
(redefined)

identifier: String = "xxx"

1..1
(redefined)

evaluation_agent: FUNCTION<<Numeric,Numeric>,Numeric>

4.3.3.3. OP_DEF_AND Class

Class

OP_DEF_AND

Description

Illustrative class showing what the normally built-in logical 'and' operator looks like as an external definition.

Inherit

OPERATOR_DEF_EXTERNAL

Attributes

Signature

Meaning

0..1

symbols: List<String> = "and","∧"

1..1
(redefined)

identifier: String = "and"

1..1
(redefined)

evaluation_agent: FUNCTION<<Boolean,Boolean>,Boolean>

4.3.3.4. OP_DEF_EXISTS Class

Class

OP_DEF_EXISTS

Description

Illustrative class showing what the normally built-in logical 'exists' operator looks like as an external definition.

Inherit

OPERATOR_DEF_EXTERNAL

Attributes

Signature

Meaning

0..1

symbols: List<String> = "exists", "∃"

1..1
(redefined)

identifier: String = "exists"

1..1
(redefined)

evaluation_agent: FUNCTION<<Any>,Boolean>

4.3.3.5. FUNCTION_DEF_EXTERNAL Class

Class

FUNCTION_DEF_EXTERNAL (abstract)

Description

Ancestor class of externally defined function types.

Inherit

FUNCTION_DEF

Attributes

Signature

Meaning

1..1

evaluation_agent: FUNCTION

4.3.3.6. FUNCTION_DEF_EXAMPLE Class

Class

FUNCTION_DEF_EXAMPLE

Description

Example of an externally defined function of signature:

func (v: Numeric): Numeric

Inherit

FUNCTION_DEF_EXTERNAL

Attributes

Signature

Meaning

1..1
(redefined)

identifier: String = "funny"

1..1
(redefined)

evaluation_agent: FUNCTION<<Numeric>,Numeric>

4.4. Typing

The expressions.types package is shown below.

BASE expressions.types
Figure 3. Statement.types Package

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.

4.4.1. Class Descriptions

4.4.1.1. EXPR_TYPE_DEF Class

Class

EXPR_TYPE_DEF (abstract)

Description

Ancestor class for type definitions known in the openEHR Expression formalism.

Attributes

Signature

Meaning

1..1

type_name: String

Natural language type name of this type as used in abstract rules syntax variable declarations.

1..1

type_anchor: Any

Attribute of the openEHR primitive type (or Any) corresponding to this type definition meta-type.

4.4.1.2. TYPE_DEF_BOOLEAN Class

Class

TYPE_DEF_BOOLEAN

Description

Rules meta-type representing the primitive type Boolean.

Inherit

EXPR_TYPE_DEF

Attributes

Signature

Meaning

1..1
(redefined)

type_name: String = "Boolean"

1..1
(redefined)

type_anchor: Boolean

4.4.1.3. TYPE_DEF_INTEGER Class

Class

TYPE_DEF_INTEGER

Description

Rules meta-type representing the primitive type Integer.

Inherit

EXPR_TYPE_DEF

Attributes

Signature

Meaning

1..1
(redefined)

type_name: String = "Integer"

1..1
(redefined)

type_anchor: Integer

4.4.1.4. TYPE_DEF_REAL Class

Class

TYPE_DEF_REAL

Description

Rules meta-type representing the primitive type Real.

Inherit

EXPR_TYPE_DEF

Attributes

Signature

Meaning

1..1
(redefined)

type_name: String = "Real"

1..1
(redefined)

type_anchor: Real

4.4.1.5. TYPE_DEF_DATE Class

Class

TYPE_DEF_DATE

Description

Rules meta-type representing the primitive type Date.

Inherit

EXPR_TYPE_DEF

Attributes

Signature

Meaning

1..1
(redefined)

type_name: String = "Date"

1..1
(redefined)

type_anchor: IDate

4.4.1.6. TYPE_DEF_DATE_TIME Class

Class

TYPE_DEF_DATE_TIME

Description

Rules meta-type representing the primitive type Date_time.

Inherit

EXPR_TYPE_DEF

Attributes

Signature

Meaning

1..1
(redefined)

type_name: String = "Date_time"

1..1
(redefined)

type_anchor: IDate_time

4.4.1.7. TYPE_DEF_TIME Class

Class

TYPE_DEF_TIME

Description

Rules meta-type representing the primitive type Time.

Inherit

EXPR_TYPE_DEF

Attributes

Signature

Meaning

1..1
(redefined)

type_name: String = "Time"

1..1
(redefined)

type_anchor: ITime

4.4.1.8. TYPE_DEF_DURATION Class

Class

TYPE_DEF_DURATION

Description

Rules meta-type representing the primitive type Duration.

Inherit

EXPR_TYPE_DEF

Attributes

Signature

Meaning

1..1
(redefined)

type_name: String = "Duration"

1..1
(redefined)

type_anchor: IDuration

4.4.1.9. TYPE_DEF_STRING Class

Class

TYPE_DEF_STRING

Description

Rules meta-type representing the primitive type String.

Inherit

EXPR_TYPE_DEF

Attributes

Signature

Meaning

1..1
(redefined)

type_name: String = "String"

1..1
(redefined)

type_anchor: String

4.4.1.10. TYPE_DEF_URI Class

Class

TYPE_DEF_URI

Description

Rules meta-type representing the primitive type Uri.

Inherit

EXPR_TYPE_DEF

Attributes

Signature

Meaning

1..1
(redefined)

type_name: String = "Uri"

1..1
(redefined)

type_anchor: Integer

4.4.1.11. TYPE_DEF_TERMINOLOGY_CODE Class

Class

TYPE_DEF_TERMINOLOGY_CODE

Description

Rules meta-type representing the primitive type Terminology_code.

Inherit

EXPR_TYPE_DEF

Attributes

Signature

Meaning

1..1
(redefined)

type_name: String = "Terminology_code"

1..1
(redefined)

type_anchor: Terminology_code

4.4.1.12. TYPE_DEF_OBJECT_REF Class

Class

TYPE_DEF_OBJECT_REF

Description

Rules meta-type representing the type Object_ref, which is assumed to by the type of any non-primitive reference target within a rule.

Inherit

EXPR_TYPE_DEF

Attributes

Signature

Meaning

1..1
(redefined)

type_name: String = "Object_ref"

Appendix A: Syntax Specification

The grammar and lexical specification for the standard Expression syntax is shown below in ANTLR4 form.

Note
this is still the old ADL grammar - the Antlr4 file has to be upgraded.  
//
//  description: Antlr4 grammar for openEHR Rules core syntax.
//  author:      Thomas Beale <thomas.beale@openehr.org>
//  support:     openEHR Specifications PR tracker <https://openehr.atlassian.net/projects/SPECPR/issues>
//  copyright:   Copyright (c) 2016 openEHR Foundation
//  license:     Apache 2.0 License <http://www.apache.org/licenses/LICENSE-2.0.html>
//

grammar base_expressions;

//
//  ============== Parser rules ==============
//

assertion: ( identifier ':' )? boolean_expr ;

//
// Expressions evaluating to boolean values
//

boolean_expr: boolean_expr boolean_binop boolean_leaf
    | boolean_leaf
    ;

boolean_leaf:
      boolean_literal
    | '(' boolean_expr ')'
    | arithmetic_relop_expr
    | SYM_NOT boolean_leaf
    ;

boolean_binop:
    | SYM_AND
    | SYM_XOR
    | SYM_OR
    | SYM_IMPLIES
    ;

boolean_literal:
      SYM_TRUE
    | SYM_FALSE
    ;

//
// Expressions evaluating to arithmetic values
//

arithmetic_relop_expr: arithmetic_arith_expr relational_binop arithmetic_arith_expr ;

arithmetic_leaf:
      integer_value
    | real_value
    | '(' arithmetic_arith_expr ')'
    | '-' arithmetic_leaf
    ;

arithmetic_arith_expr: arithmetic_arith_expr arithmetic_binop arithmetic_leaf
    | arithmetic_arith_expr '^'<assoc=right> arithmetic_leaf
    | arithmetic_leaf
    ;

relational_binop:
      SYM_EQ
    | SYM_NE
    | SYM_GT
    | SYM_LT
    | SYM_LE
    | SYM_GE
    ;

arithmetic_binop:
      '/'
    | '*'
    | '+'
    | '-'
    ;

References

Publications

  1. [Anderson_1996] Ross Anderson. Security in Clinical Information Systems. Available at http://www.cl.cam.ac.uk/users/rja14/policy11/policy11.html.

  2. [Baretto_2005] Barretto S A. Designing Guideline-based Workflow-Integrated Electronic Health Records. 2005. PhD dissertation, University of South Australia. Available at http://www.cis.unisa.edu.au/~cissab/Barretto_PhD_Thesis_Revised_FINAL.pdf.

  3. [Beale_2000] Beale T. Archetypes: Constraint-based Domain Models for Future-proof Information Systems. 2000. Available at http://www.openehr.org/files/resources/publications/archetypes/archetypes_beale_web_2000.pdf .

  4. [Beale_2002] Beale T. Archetypes: Constraint-based Domain Models for Future-proof Information Systems. Eleventh OOPSLA Workshop on Behavioral Semantics: Serving the Customer (Seattle, Washington, USA, November 4, 2002). Edited by Kenneth Baclawski and Haim Kilov. Northeastern University, Boston, 2002, pp. 16-32. Available at http://www.openehr.org/files/resources/publications/archetypes/archetypes_beale_oopsla_2002.pdf .

  5. [Beale_Heard_2007] Beale T, Heard S. An Ontology-based Model of Clinical Information. 2007. pp760-764 Proceedings MedInfo 2007, K. Kuhn et al. (Eds), IOS Publishing 2007. See http://www.openehr.org/publications/health_ict/MedInfo2007-BealeHeard.pdf.

  6. [Booch_1994] Booch G. Object-Oriented Analysis and Design with applications. 2nd ed. Benjamin/Cummings 1994.

  7. [Browne_2005] Browne E D. Workflow Modelling of Coordinated Inter-Health-Provider Care Plans. 2005. PhD dissertation, University of South Australia. Available at http://www.openehr.org/publications/workflow/t_browne_thesis_abstract.htm.

  8. [Cimino_1997] Cimino J J. Desiderata for Controlled Medical vocabularies in the Twenty-First Century. IMIA WG6 Conference, Jacksonville, Florida, Jan 19-22, 1997.

  9. [Eiffel] Meyer B. Eiffel the Language (2nd Ed). Prentice Hall, 1992.

  10. [Elstein_1987] Elstein AS, Shulman LS, Sprafka SA. Medical problem solving: an analysis of clinical reasoning. Cambridge, MA: Harvard University Press 1987.

  11. [Elstein_Schwarz_2002] Elstein AS, Schwarz A. Evidence base of clinical diagnosis: Clinical problem solving and diagnostic decision making: selective review of the cognitive literature. BMJ 2002;324;729-732.

  12. [Fowler_1997] Fowler M. Analysis Patterns: Reusable Object Models. Addison Wesley 1997

  13. [Fowler_Scott_2000] Fowler M, Scott K. UML Distilled (2nd Ed.). Addison Wesley Longman 2000.

  14. [Gray_reuter_1993] Gray J, Reuter A. Transaction Processing Concepts and Techniques. Morgan Kaufmann 1993.

  15. [Hein_2002] Hein J L. Discrete Structures, Logic and Computability (2nd Ed). Jones and Bartlett 2002.

  16. [Hnìtynka_2004] Hnìtynka P, Plášil F. Distributed Versioning Model for MOF. Proceedings of WISICT 2004, Cancun, Mexico, A volume in the ACM international conference proceedings series, published by Computer Science Press, Trinity College Dublin Ireland, 2004.

  17. [Ingram_1995] Ingram D. The Good European Health Record Project. Laires, Laderia Christensen, Eds. Health in the New Communications Age. Amsterdam: IOS Press; 1995; pp. 66-74.

  18. [Kifer_Lausen_Wu_1995] Kifer M, Lausen G, Wu J. Logical Foundations of Object-Oriented and FrameBased Languages. JACM May 1995. See See ftp://ftp.cs.sunysb.edu/pub/TechReports/kifer/flogic.pdf.

  19. [Kilov_1994] Kilov H, Ross J. Information Modelling - an object-oriented approach. Prentice Hall 1994.

  20. [Maier_2000] Maier M. Architecting Principles for Systems-of-Systems. Technical Report, University of Alabama in Huntsville. 2000. Available at http://www.infoed.com/Open/PAPERS/systems.htm

  21. [Martin] Martin P. Translations between UML, OWL, KIF and the WebKB-2 languages (For-Taxonomy, Frame-CG, Formalized English). May/June 2003. Available at http://www.webkb.org/doc/model/comparisons.html as at Aug 2004.

  22. [Meyer_OOSC2] Meyer B. Object-oriented Software Construction, 2nd Ed. Prentice Hall 1997

  23. [Müller_2003] Müller R. Event-oriented Dnamic Adaptation of Workflows: Model, Architecture, and Implementation. 2003. PhD dissertation, University of Leipzig. Available at http://www.openehr.org/publications/workflow/t_mueller_thesis_abstract.htm.

  24. [Object_Z] Smith G. The Object Z Specification Language. Kluwer Academic Publishers 2000. See http://www.itee.uq.edu.au/~smith/objectz.html .

  25. [GLIF] Lucila Ohno-Machado, John H. Gennari, Shawn N. Murphy, Nilesh L. Jain, Samson W. Tu, Diane E. Oliver, Edward Pattison-Gordon, Robert A. Greenes, Edward H. Shortliffe, and G. Octo Barnett. The GuideLine Interchange Format - A Model for Representing Guidelines. J Am Med Inform Assoc. 1998 Jul-Aug; 5(4): 357–372.

  26. [Rector_1994] Rector A L, Nowlan W A, Kay S. Foundations for an Electronic Medical Record. The IMIA Yearbook of Medical Informatics 1992 (Eds. van Bemmel J, McRay A). Stuttgart Schattauer 1994.

  27. [Rector_1999] Rector A L. Clinical terminology: why is it so hard? Methods Inf Med. 1999 Dec;38(4-5):239-52. Available at http://www.cs.man.ac.uk/~rector/papers/Why-is-terminology-hard-single-r2.pdf .

  28. [Richards_1998] Richards E G. Mapping Time - The Calendar and its History. Oxford University Press 1998.

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

  30. [Sottile_1999] Sottile P.A., Ferrara F.M., Grimson W., Kalra D., and Scherrer J.R. The holistic healthcare information system. Toward an Electronic Health Record Europe. 1999. Nov 1999; 259-266.

  31. [Van_de_Velde_Degoulet_2003] Van de Velde R, Degoulet P. Clinical Information Systems: A Component-Based Approach. 2003. Springer-Verlag New York.

  32. [Weed_1969] Weed LL. Medical records, medical education and patient care. 6 ed. Chicago: Year Book Medical Publishers Inc. 1969.

Resources

General

  1. [cov_contra] Wikipedia. Covariance and contravariance. See https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science) .

e-Health Standards

  1. [Corbamed_PIDS] Object Management Group. Person Identification Service. March 1999. See http://www.omg.org/spec/PIDS/ .

  2. [Corbamed_LQS] Object Management Group. Lexicon Query Service. March 1999. http://www.omg.org/spec/LQS/ .

  3. [hl7_cda] HL7 International. HL7 version Clinical Document Architecture (CDA). Available at http://www.hl7.org.uk/version3group/cda.asp.

  4. [HL7v3_ballot2] HL7 International. HL7 version 3 2nd Ballot specification. Available at http://www.hl7.org.

  5. [HL7v3_data_types] Schadow G, Biron P. HL7 version 3 deliverable: Version 3 Data Types. (2nd ballot 2002 version).

  6. [hl7_v3_rim] HL7 International. HL7 v3 RIM. See http://www.hl7.org .

  7. [hl7_arden] HL7 International. HL7 Arden Syntax. See http://www.hl7.org/Special/committees/Arden/index.cfm .

  8. [hl7_gello] HL7 International. GELLO Decision Support Language. http://www.hl7.org/implement/standards/product_brief.cfm?product_id=5 .

  9. [IHTSDO_URIs] IHTSDO. SNOMED CT URI Standard. http://ihtsdo.org/fileadmin/user_upload/doc/download/doc_UriStandard_Current-en-US_INT_20140527.pdf?ok.

  10. [NLM_UML_list] National Library of Medicine. UMLS Terminologies List. http://www.nlm.nih.gov/research/umls/metaa1.html.

  11. [ISO_13606-1] ISO 13606-1 - Electronic healthcare record communication - Part 1: Extended architecture. CEN TC251 Health Informatics Technical Committee. Available at http://www.iso.org/iso/catalogue_detail.htm?csnumber=40784 .

  12. [ISO_13606-2] ISO 13606-2 - Electronic healthcare record communication - Part 2: Domain term list. CEN TC251 Health Informatics Technical Committee. Available at http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=50119 .

  13. [ISO_13606-3] ISO 13606-3 - Electronic healthcare record communication - Part 3: Distribution rules. CEN TC251 Health Informatics Technical Committee.

  14. [ISO_13606-4] ISO 13606-4 - Electronic Healthcare Record Communication standard Part 4: Messages for the exchange of information. CEN TC251 Health Informatics Technical Committee.

  15. [ISO_18308] Schloeffel P. (Editor). Requirements for an Electronic Health Record Reference Architecture. (ISO TC 215/SC N; ISO/WD 18308). International Standards Organisation, Australia, 2002.

  16. [ISO_20514] ISO. The Integrated Care EHR. See http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=39525 .

e-Health Projects

  1. [EHCR_supA_14] Dixon R, Grubb P A, Lloyd D, and Kalra D. Consolidated List of Requirements. EHCR Support Action Deliverable 1.4. European Commission DGXIII, Brussels; May 2001 59pp Available from http://www.chime.ucl.ac.uk/HealthI/EHCR-SupA/del1-4v1_3.PDF.

  2. [EHCR_supA_35] Dixon R, Grubb P, Lloyd D. EHCR Support Action Deliverable 3.5: "Final Recommendations to CEN for future work". Oct 2000. Available at http://www.chime.ucl.ac.uk/HealthI/EHCRSupA/documents.htm.

  3. [EHCR_supA_24] Dixon R, Grubb P, Lloyd D. EHCR Support Action Deliverable 2.4 "Guidelines on Interpretation and implementation of CEN EHCRA". Oct 2000. Available at http://www.chime.ucl.ac.uk/HealthI/EHCR-SupA/documents.htm.

  4. [EHCR_supA_31_32] Lloyd D, et al. EHCR Support Action Deliverable 3.1&3.2 “Interim Report to CEN”. July 1998. Available at http://www.chime.ucl.ac.uk/HealthI/EHCR-SupA/documents.htm.

  5. [GEHR_del_4] Deliverable 4: GEHR Requirements for Clinical Comprehensiveness. GEHR Project 1992. Available at http://www.openehr.org/files/resources/related_projects/gehr/gehr_deliverable-4.pdf .

  6. [GEHR_del_7] Deliverable 7: Clinical Functional Specifications. GEHR Project 1993.

  7. [GEHR_del_8] Deliverable 8: Ethical and legal Requirements of GEHR Architecture and Systems. GEHR Project 1994. Available at http://www.openehr.org/files/resources/related_projects/gehr/gehr_deliverable-8.pdf .

  8. [GEHR_del_19_20_24] Deliverable 19,20,24: GEHR Architecture. GEHR Project 30/6/1995. Available at http://www.openehr.org/files/resources/related_projects/gehr/gehr_deliverable-19_20_24.pdf .

  9. [GeHR_AUS] Heard S, Beale T. The Good Electronic Health Record (GeHR) (Australia). See http://www.openehr.org/resources/related_projects#gehraus .

  10. [GeHR_Aus_gpcg] Heard S. GEHR Project Australia, GPCG Trial. See http://www.openehr.org/resources/related_projects#gehraus .

  11. [GeHR_Aus_req] Beale T, Heard S. GEHR Technical Requirements. See http://www.openehr.org/files/resources/related_projects/gehr_australia/gehr_requirements.pdf .

  12. [Synapses_req_A] Kalra D. (Editor). The Synapses User Requirements and Functional Specification (Part A). EU Telematics Application Programme, Brussels; 1996; The Synapses Project: Deliverable USER 1.1.1a. 6 chapters, 176 pages.

  13. [Synapses_req_B] Grimson W. and Groth T. (Editors). The Synapses User Requirements and Functional Specification (Part B). EU Telematics Application Programme, Brussels; 1996; The Synapses Project: Deliverable USER 1.1.1b.

  14. [Synapses_odp] Kalra D. (Editor). Synapses ODP Information Viewpoint. EU Telematics Application Programme, Brussels; 1998; The Synapses Project: Final Deliverable. 10 chapters, 64 pages. See http://discovery.ucl.ac.uk/66235/ .

  15. [synex] University College London. SynEx project. http://www.chime.ucl.ac.uk/HealthI/SynEx/ .

General Standards

  1. [OCL] The Object Constraint Language 2.0. Object Management Group (OMG). Available at http://www.omg.org/cgi-bin/doc?ptc/2003-10-14 .

  2. [IEEE_828] IEEE. IEEE 828-2005: standard for Software Configuration Management Plans.

  3. [ISO_8601] ISO 8601 standard describing formats for representing times, dates, and durations. See https://en.wikipedia.org/wiki/ISO_8601.

  4. [ISO_2788] ISO. ISO 2788 Guide to Establishment and development of monolingual thesauri.

  5. [ISO_5964] ISO. ISO 5964 Guide to Establishment and development of multilingual thesauri.

  6. [Perl_regex] Perl.org. Perl Regular Expressions. Available at http://perldoc.perl.org/perlre.html .

  7. [rfc_2396] Berners-Lee T. Universal Resource Identifiers in WWW. Available at http://www.ietf.org/rfc/rfc2396.txt. This is a World-Wide Web RFC for global identification of resources. In current use on the web, e.g. by Mosaic, Netscape and similar tools. See http://www.w3.org/Addressing for a starting point on URIs.

  8. [rfc_2440] RFC 2440: OpenPGP Message Format. See http://www.ietf.org/rfc/rfc2440.txt and http://www.ietf.org/internet-drafts/draft-ietf-openpgp-rfc2440bis-18.txt

  9. [rfc_3986] RFC 3986: Uniform Resource Identifier (URI): Generic Syntax. IETF. See http://www.ietf.org/rfc/rfc3986.txt .

  10. [rfc_4122] RFC 4122: A Universally Unique IDentifier (UUID) URN Namespace. IETF. See http://www.ietf.org/rfc/rfc4122.txt .

  11. [rfc_2781] IETF. RFC 2781: UTF-16, an encoding of ISO 10646 See http://tools.ietf.org/html/rfc2781.

  12. [rfc_5646] IETF. RFC 5646. Available at http://tools.ietf.org/html/rfc5646.

  13. [sem_ver] Semantic Versioning. http://semver.org .

  14. [Xpath] W3C Xpath 1.0 specification. 1999. Available at http://www.w3.org/TR/xpath.

  15. [uri_syntax] Uniform Resource Identifier (URI): Generic Syntax, Internet proposed standard. January 2005. see http://www.ietf.org/rfc/rfc3986.txt .

  16. [w3c_owl] W3C. OWL - the Web Ontology Language. See http://www.w3.org/TR/2003/CR-owl-ref-20030818/ .

  17. [w3c_xpath] W3C. XML Path Language. See http://w3c.org/TR/xpath .