Overview

The openEHR Foundation Types (org.openehr.base.foundation_types package) consists of generic low level types assumed by and used throughout the openEHR components and specifications. The types described here are specified in order to establish the names and minimal semantics of typical standard classes, as used by all other openEHR specifications, and to provide a mapping point into implementation technologies.

The set of types chosen here is based on a common set derived from various published sources, including:

The package structure is illustrated below.

The primitive_types, structures and time packages describe types assumed by the openEHR specifcations to exist in any implementation technology, such as a programming language, schema language or database environment.

The functional package includes types enabling functional programming primitives to be expressed in the openEHR modelling environment, i.e. functions-as-objects and 'lambda' expressions.

The types are described in this specification are typically of two kinds: built-in types, which are those built in to a type system of the development language, and library types, which are assumed to be available in a (class) library defined in the formalism. Thus, the type Boolean is always assumed to exist in a formalism, while the type Array<T> is assumed to be available in a library. For practical purposes, these two categories do not matter too much - whether String is really a library class (the usual case) or an inbuilt type doesn’t make much difference to the programmer. They are shown separately here mainly as an explanatory convenience.

The assumptions that openEHR makes about existing types are documented below in terms of interface definitions. Each of these definitions contains only the assumptions required for the given type to be used in the openEHR Reference Model - it is not by any means a complete interface definition. The name and semantics of any function used here for an assumed type might not be identical to those found in some implementation technologies. Any mapping required should be stated in the relevant implementation technology specification (ITS). To give a concrete example, where the assumed Set<T> type defined below has an operation has (item: T): Boolean which is used throughout the openEHR specifications, Java has the method contains() on its Set<T> class. In a Java implementation, the contains() method should then be used throughout the openEHR classes as expressed in Java, in place of the has () method.