openEHR logo

openEHR Base Types specification

Issuer: openEHR Specification Program

Release: latest

Status: TRIAL

Revision: [latest_issue]

Date: [latest_issue_date]

Keywords: openehr, identifiers, types

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 Completed

0.7.5

Rework date/time types; addition of types IDate, IDate_time, ITime, IIDuration. Added derived interval types.

T Beale

18 Jan 2017

0.7.0

Initial Writing. Taken from openEHR RM Release 1.0.3 Support Model

T Beale

20 May 2016

The Amendment history relevant to the original content in this specification can be found here.

Acknowledgements

Special thanks to Prof David Ingram, head of CHIME, who provided a vision and collegial working environment ever since the days of GEHR (1992).

1. Preface

1.1. Purpose

This document describes the openEHR Base Types, whose semantics are used by all other openEHR specifications.

The intended audience includes:

  • Standards bodies producing health informatics standards;

  • Research groups using openEHR, ISO 13606, archetypes and related technologies;

  • The open source healthcare community;

  • Solution vendors.

Prerequisite documents for reading this document include:

1.3. Status

This specification is in the TRIAL state. The development version of this document can be found at http://www.openehr.org/releases/BASE/latest/base_types.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. Previous Versions

This specification is based on the types orginally defined in the openEHR Support Information Model from Release 1.0.3 of the Reference Model. Some changes have been made as follows.

1.4.1. Interval types

The additional types Point_interval and Proper_interval have been added, to support the common need for a point value and a proper interval to be specified as substitutable types. The types Multiplicity_interval and Cardinality have been added, from the AOM2 specification.

1.4.2. Date/Time types

The date/time types have been adjusted to provide a fully coherent model that accounts for 'native' types and the ISO 8601-based types, whose representation is a String. This involved the addition of notional types IDate, ITime etc, which define pure interfaces to both native and ISO 8601 date/time types.

In the original Support IM specification, only the ISO 8601 types were defined. The addition of so-called native types Date, Time, Date_time and Duration enables these types to be used in other specifications as standing for the native system types, for example in the AOM2 specification.

2. Overview

The openEHR Base Types (org.openehr.base_types package) consists of generic foundational types used throughout the openEHR specifications, including assumed types defined outside of openEHR, e.g. by implementation formalisms. The package structure is illustrated below. Packages shown in light grey can be considered 'pseudo-packages', and are used to state types that are assumed to exist in implementation technologies, and as such are only minimally defined.

BASE base types packages
Figure 1. org.openehr.base_types package structure

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

The terminology and identification packages define basic time and terminology referencing types and semantics, sufficient to support the needs of other openEHR specifications.

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

The types defined in the pseudo-packages are important, because they provide names and minimal semantics used by all other openEHR specifications, and they also provide a mapping point into implementation technologies. For example, the type String is defined to mean the ordinary date concept found in all computing systems; the definition includes. Accordingly, within the openEHR specifications, the type name String

2.1. The Any Class

Within all object-oriented and most other modern programming and modelling environment exists an ultimate ancestor type to which all others conform. In this specification, we assume the type Any, which defines a bare minimum of operators, and stands for the real Any or Object type found in real technologies.

2.1.1. Any Class

Class

Any (abstract)

Description

Abstract supertype. Usually maps to a type like “Any” or “Object” in an object system. Defined here to provide the value and reference equality semantics.

Functions

Signature

Meaning

is_equal (other: Any): Boolean

Value equality.

infix = (other: Any): Boolean

instance_of (a_type: String): Any

Create new instance of a type.

type_of (an_object: Any): String

2.2. Leaf Types Overview

The sections below provide formal definitions of all the base types used in openEHR. The following diagram provides an aide memoire of the 'leaf' types among these, potentially useful to developers.

BASE base types leaf types
Figure 2. Leaf Types

3. Assumed Types

3.1. Overview

This section describes types assumed by all openEHR models. The intention in openEHR is twofold. Firstly, to ensure that openEHR software based on the models integrates is easy to implement in existing development technologies, and secondly, to make the minimum possible assumptions about types found in implementation formalisms, while making sufficient assumptions to enable openEHR models to be fully specified.

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

  • ISO 11404 (2003 revision) general purpose data types;

  • ISO 8601 (2004) date/time specification;

  • Major interoperability formalisms, including OMG IDL, W3C XML-schema;

  • Major typed programming languages, including Java, C#, C++, etc.

The ISO 11404 (2003) standard contains basic semantics of "general purpose data types" for information technology, and is used here as a normative basis for describing assumptions about types. The operations and properties described here are compatible with those used in ISO 11404, but not always the same, as 11404 does not use object-oriented functions. For example, the notional function has (x:T) (test for presence of a value in a set) defined on the type Set<T> below is not defined on the ISO 11404 Set type; instead, the function IsIn (x:T; s:Set<T>) is defined. However, in object-oriented formalisms, the function IsIn defined on a Set type would usually mean 'subset of'. In the interests of clarity for developers, an object-oriented style of functions and properties has been used here.

Two groups of assumed types are identified: primitive types, which are those built in to a formalism’s type system, 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 that 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.

3.2. Primitive Types

The following types consititute the minimum set of primitive types assumed by openEHR of an implementation formalism.

Type name
in openEHR
Description ISO 11404
Type

Octet

a type whose value is an 8-bit value.

Octet

Character

a type whose value is a member of an 8-bit character-set (ISO: "repertoire").

Character

Boolean

logical True/False values; usually physically represented as an integer, but need not be

Boolean

Integer

32-bit integers

Integer

Integer64

64-bit integers

Integer64

Real

32-bit real numbers in any interoperable representation, including single-width IEEE floating point

Real

Double

64-bit real numbers, in any interoperable representation including double-precision IEEE floating point.

Real

String

represents unicode-enabled strings

Character-String/Sequence

The figure below illustrates the built-in primitive types. Simple inheritance relationships are shown which facilitate the type descriptions below. Actual inheritance from or subsitutability for an Any class is not assumed, and is shown only for convenience (e.g. to indicate that the '=' operator is available on any type). The type Ordered_numeric is on the other hand is used to indicate assumed substitutability of numeric types, and is intended to be mapped to an equivalent type in a real type system (e.g. in Java, java.lang.Number). Data-oriented implementation type systems such as XML-schema do not have such operations.

BASE base types.primitive types
Figure 3. base_types.primitive_types package

3.2.1. Class Definitions

3.2.2. Numeric Class

Class

Numeric (abstract)

Description

Abstract notional parent class of numeric types, which are types which have various arithmetic and comparison operators defined.

Inherit

Any

Functions

Signature

Meaning

infix * (other: Numeric): Numeric

Product by `other'. Actual type of result depends on arithmetic balancing rules.

infix + (other: Numeric): Numeric

Sum with `other' (commutative). Actual type of result depends on arithmetic balancing rules.

infix - (other: Numeric): Numeric

Result of subtracting `other'. Actual type of result depends on arithmetic balancing rules.

3.2.3. Ordered Class

Class

Ordered (abstract)

Description

Abstract notional parent class of ordered, types i.e. types on which the ‘<‘ operator is defined.

Inherit

Any

Functions

Signature

Meaning

infix < (other: Ordered): Boolean

Arithmetic comparison. In conjunction with ‘=’, enables the definition of the operators ‘>’, ‘>=’, ‘<=’, ‘<>’. In real type systems, this operator might be defined on another class for comparability.

3.2.4. Ordered_Numeric Class

Class

Ordered_Numeric (abstract)

Description

Abstract notional parent class of ordered, numeric types, which are types with ‘<‘ and arithmetic operators defined.

Inherit

Ordered, Numeric

3.2.5. Boolean Class

Class

Boolean

Description

Class representing minimal interface of standard Boolean type.

Inherit

Any

Functions

Signature

Meaning

infix and (other: Boolean): Boolean
Post_de_Morgan: Result = not (not self or not other)
Post_commutative: Result = (other and self)

Logical conjunction

infix and_then (other: Boolean): Boolean
Post_de_Morgan: Result = not (not self or else not other)

Boolean semi-strict conjunction with other

infix or (other: Boolean): Boolean
Post_de_Morgan: Result = not (not self and not other)
Post_commutative: Result = (other or Current)
Post_consistent_with_semi_strict: Result implies (self or else other)

Boolean disjunction with other.

infix or_else (other: Boolean): Boolean
Post_de_Morgan: Result = not (not self and then not other)

Boolean semi-strict disjunction with `other'.

infix xor (other: Boolean): Boolean
Post_definition: Result = self or other) and not (self and other

Boolean exclusive or with `other'.

infix implies (other: Boolean): Boolean
Post_definition: Result = (not self or else other)

Boolean implication of `other' (semi-strict)

Invariant

Involutive_negation: is_equal (not (not self))

Non_contradiction: not (self and (not self))

Completeness: self or else (not self)

3.2.6. Integer Class

Class

Integer

Description

Class representing minimal interface of standard Integer type.

Inherit

Ordered_Numeric

3.2.7. Integer64 Class

Class

Integer64

Description

Class representing minimal interface of standard Integer64 type.

Inherit

Ordered_Numeric

3.2.8. Real Class

Class

Real

Description

Type used to represent decimal numbers. Corresponds to a single-precision floating point value in most languages.

Inherit

Ordered_Numeric

Functions

Signature

Meaning

floor: Integer

Return the greatest integer no greater than the value of this object.

3.2.9. String Class

Class

String

Description

Strings of characters, as used to represent textual data in any natural or formal language.

Inherit

Ordered

Functions

Signature

Meaning

infix + (other: String): String

Concatenation operator - causes ‘other’ to be appended to this string.

is_empty: Boolean

True if string is empty, i.e. equal to "".

is_integer: Boolean

True if string can be parsed as an integer.

as_integer: Integer

Return the integer corresponding to the integer value represented in this string.

3.3. Unicode

It is assumed in the openEHR specifications that Unicode is supported by the type String. Unicode is needed for all Asian, Arabic and other script languages, for both data values (particularly plain text and coded text) and for many predefined string attributes of the classes in the openEHR Reference Model. It encompasses all existing character sets. In openEHR, UTF-8 encoding is assumed.

4. Structure Types

4.1. Overview

The types described in this section are basic data structures mostly assumed to be standardly available in implementation technologies. The following types consititute the minimum set of structure types assumed by openEHR of an implementation environment.

Type name
in openEHR
Description ISO 11404
Type

Array<T>

physical container of items indexed by number

Array<T>

List<T>

container of items, implied order, non-unique membership

Sequence<T>

Set<T>

container of items, no order, unique membership

Set<T>

Hash<K:Ordered, V>

a table of values of any type V, keyed by values of any Ordered descendant K, typically String or Integer, but may be more complex types, e.g. a coded term type.

Table

Interval<T:Ordered>

Intervals of ordered primitive types, with open or closed upper and lower bounds.

Range<T>

The following UML diagram illustrates the base_types.structures package. As with the assumed primitive types, inheritance and abstract classes are used for convenience of the definitions in openEHR models, but are not assumed to exist in exactly the same way within implementation technologies. Hence, in an implementation, various workarounds or equivalences may be needed to obtain the defined semantics.

BASE base types.structures
Figure 4. base_types.structures package

4.2. Container Structures

Container types are shown on the left side of the diagram above. The openEHR specifications assume the existence of the classes Array, Set, List and Hash, and assumes a few of their semantics, e.g. the has() function. However they are not fully defined in this specification, since that is the business of implementation technologies.

4.2.1. Class Definitions

4.2.2. Aggregate Class

Class

Aggregate (abstract)

Description

Abstract ancestor of container types whose items are addressable in some way.

Inherit

Any

Functions

Signature

Meaning

has (v: T): Boolean

Test for membership of a value.

count: Integer

Number of items in container.

is_empty: boolean

True if container is empty.

4.2.3. List Class

Class

List

Description

Ordered container that may contain duplicates.

Inherit

Aggregate

Functions

Signature

Meaning

first: T

Return first element.

last: T

Return last element.

Invariant

First_validity: not is_empty implies first /= Void

Last_validity: not is_empty implies last /= Void

4.2.4. Set Class

Class

Set

Description

Unordered container that may not contain duplicates.

Inherit

Aggregate

4.2.5. Array Class

Class

Array

Description

Container whose storage is assumed to be contiguous.

Inherit

Aggregate

4.2.6. Hash Class

Class

Hash

Description

Type representing a keyed table of values. T is the value type, and U the type of the keys.

Inherit

Aggregate

Functions

Signature

Meaning

has_key (a_key: K): Boolean

Test for membership of a key.

item (a_key: K): V

Return item for key a_key'. Equivalent to ISO 11404 fetch operation.

4.3. Intervals

A second kind of structure, commonly needed in rich data is the interval. The definition of the Interval<T> class here is an intensional one, i.e. it states its members by implication from its limits, rather than enumerating them. To support the common need for defining times in models that could be either a fixed point in time or a time interval, the classes Point_interval<T> and Proper_interval<T> are provided. If Interval<X> is defined as the type of a feature in a class in an openEHR model, where X is some descendant of Ordered, then at runtime, either a Point_interval or Proper_interval may be attached.

In addition to the generic interval types, the derived types Multiplicity_interval and Cardinality are provided, for use in models to represent multiplicity, optionality, and cardinality.

4.3.1. Class Definitions

4.3.2. Interval Class

Class

Interval (abstract)

Description

Interval abstraction, featuring upper and lower limits that may be open or closed, included or not included. Interval of ordered items.

Inherit

Any

Attributes

Signature

Meaning

0..1

lower: T

lower bound.

1..1

lower_unbounded: boolean

lower boundary open (i.e. = -infinity)

1..1

upper_unbounded: boolean

upper boundary open (i.e. = +infinity)

1..1

lower_included: boolean

lower boundary value included in range if not lower_unbounded.

1..1

upper_included: boolean

upper boundary value included in range if not upper_unbounded.

Functions

Signature

Meaning

has (e): boolean

True if (lower_unbounded or lower_included and v >= lower) or v > lower and (upper_unbounded or upper_included and v <= upper or v < upper)

intersects (other: Interval): Boolean

True if there is any overlap between intervals represented by Current and `other'. True if at least one limit of other is strictly inside the limits of this interval.

contains (other: Interval): Boolean

True if current interval properly contains `other'? True if all points of `other' are inside the current interval.

upper: T

(effected)

is_equal (other: Any): Boolean

True if current object’s interval is semantically same as `other'.

Invariant

Lower_included_valid: lower_unbounded implies not lower_included

Upper_included_valid: upper_unbounded implies not upper_included

Limits_consistent: (not upper_unbounded and not lower_unbounded) implies lower <= upper

Limits_comparable: (not upper_unbounded and not lower_unbounded) implies lower.strictly_comparable_to (upper)

4.3.3. Point_interval Class

Class

Point_interval

Description

Type representing an Interval that happens to be a point value. Provides an efficient representation that is substitutable for Interval<T> where needed.

Inherit

Interval

Attributes

Signature

Meaning

1..1
(redefined)

lower_unbounded: boolean

lower boundary open (i.e. = -infinity)

1..1
(redefined)

upper_unbounded: boolean

upper boundary open (i.e. = +infinity)

1..1
(redefined)

lower_included: boolean

lower boundary value included in range if not lower_unbounded.

1..1
(redefined)

upper_included: boolean

upper boundary value included in range if not upper_unbounded.

Functions

Signature

Meaning

(effected)

upper: T

4.3.4. Proper_interval Class

Class

Proper_interval

Description

Type representing a 'proper' Interval, i.e. any two-sided or one-sided interval.

Inherit

Interval

Attributes

Signature

Meaning

0..1

upper: T

Upper bound.

4.3.5. Multiplicity_interval Class

Class

Multiplicity_interval

Description

Inherit

Proper_interval

Constants

Signature

Meaning

1..1

Multiplicity_range_marker: String = ".."

Marker to use in string form of interval between limits.

1..1

Multiplicity_unbounded_marker: char = '*'

Symbol to use to indicate upper limit unbounded.

Functions

Signature

Meaning

is_open: Boolean

True if this interval imposes no constraints, i.e. is set to 0..*

is_optional: Boolean

True if this interval expresses optionality, i.e. 0..1.

is_mandatory: Boolean

True if this interval expresses mandation, i.e. 1..1.

is_prohibited: Boolean

True if this interval is set to 0..0.

4.3.6. Cardinality Class

Class

Cardinality

Description

Express constraints on the cardinality of container objects which are the values of multiply-valued attributes, including uniqueness and ordering, providing the means to state that a container acts like a logical list, set or bag. The cardinality cannot contradict the cardinality of the corresponding attribute within the relevant reference model.

Attributes

Signature

Meaning

1..1

interval: Multiplicity_interval

The interval of this cardinality.

1..1

is_ordered: Boolean

True if the members of the container attribute to which this cardinality refers are ordered.

1..1

is_unique: Boolean

True if the members of the container attribute to which this cardinality refers are unique.

Functions

Signature

Meaning

is_bag: Boolean

True if the semantics of this cardinality represent a bag, i.e. unordered, non-unique membership.

is_list: Boolean

True if the semantics of this cardinality represent a list, i.e. ordered, non-unique membership.

is_set: Boolean

True if the semantics of this cardinality represent a set, i.e. unordered, unique membership.

5. Time Types

5.1. Overview

Two packages of time types are defined in this specification: the base_types.time package and the base_types.iso8601_time package. The first group are assumed to be available within the implementation environment, and normally correspond to either built-in types or standard library classes. The second set are conrete types based on the ISO 8601 time standard, which supports partial dates, times, and complex durations, all of which are needed in the biomedical and clinical domains. These classes have a String physical representation, and also inherit from the IDate etc classes.

The two packages are shown below.

BASE base types time
Figure 5. base_types.time and base_types/iso8601_time packages

5.2. Assumed Primitive Types

The classes are in the base_types.time package are divided into interface classes IDate etc, and concrete primitive types Date, Time etc, which are assumed to have some 'native' data representation such as a long integer or similar. The separation is a clarifying device for this specification. It is not assumed that the classes IDate etc literally exist in a given implementation environment.

5.2.1. Time_Definitions Class

Class

Time_Definitions

Description

Definitions for date/time classes. Note that the timezone limits are set by where the international dateline is. Thus, time in New Zealand is quoted using +12:00, not -12:00.

Constants

Signature

Meaning

1..1

Seconds_in_minute: Integer

1..1

Minutes_in_hour: Integer

1..1

Hours_in_day: Integer

1..1

Nominal_days_in_month: Real

Used for conversions of durations containing months to days and / or seconds.

1..1

Max_days_in_month: Integer

1..1

Days_in_year: Integer

1..1

Days_in_leap_year: Integer

1..1

Max_days_in_year: Integer

1..1

Nominal_days_in_year: Real

Used for conversions of durations containing years to days and / or seconds.

1..1

Days_in_week: Integer

1..1

Months_in_year: Integer

1..1

Min_timezone_hour: Integer

Minimum hour value of a timezone (note that the -ve sign is supplied in the ISO8601_TIMEZONE class).

1..1

Max_timezone_hour: Integer

Functions

Signature

Meaning

valid_year (y: Integer): Boolean
Post: Result = y >= 0

valid_month (m: Integer): Boolean
Post: Result = m >= 1 and m <= Months_in_year

valid_day (y: Integer, m: Integer, d: Integer): Boolean
Post: Result = d >= 1 and d <= days_in_month (m, y)

True if d >= 1 and d <= days_in_month (m, y)

valid_hour (h, m, s: Integer): Boolean
Post: Result = (h >= 0 and h < Hours_in_day) or (h = Hours_in_day and m = 0 and s = 0)

True if (h >= 0 and h < Hours_in_day) or (h = Hours_in_day and m = 0 and s = 0)

valid_minute (m: Integer): Boolean
Post: Result = m >= 0 and m < Minutes_in_hour

True if m >= 0 and m < Minutes_in_hour.

valid_second (s: Integer): Boolean
Post: Result = s >= 0 and s < Seconds_in_minute

True if s >= 0 and s < Seconds_in_minute .

valid_fractional_second (fs: Double): Boolean
Post: Result = fs >= 0.0 and fs < 1.0 .

True if fs >= 0.0 and fs < 1.0 .

5.2.2. Temporal Class

Class

Temporal (abstract)

Description

Abstract ancestor type of Date/Time types.

Inherit

Ordered, Time_Definitions

5.2.3. IDate Class

Class

IDate (abstract)

Description

Interface of an absolute point in time, as measured on the Gregorian calendar, and specified only to the day.

Inherit

Temporal

Functions

Signature

Meaning

year: Integer

Year.

month: Integer
Pre: not month_unknown

Month in year.

day: Integer
Pre: not day_unknown

Day in month.

timezone: ITimezone

Timezone; may be Void.

as_string: String

ISO8601 string for date/time, in format YYYYMMDDThhmmss[,sss][Z | ±hh[mm]] or in extended format YYYY-MM-DDThh:mm:ss[,sss][Z | ±hh[mm]] or a partial variant; see valid_iso8601_date_time() below.

5.2.4. ITime Class

Class

ITime (abstract)

Description

Defines the interface of an absolute point in time from an origin usually interpreted as meaning the start of the current day, specified to fractional seconds.

Inherit

Temporal

Functions

Signature

Meaning

hour: Integer

Hour in day, in 24-hour time.

minute: Integer

Minute in hour.

second: Integer

fractional_second: Real
Pre: not second_unknown

Fractional seconds.

timezone: ITimezone

Invariant

Hour_valid: valid_hour(hour, minute, second)

5.2.5. IDate_time Class

Class

IDate_time (abstract)

Description

Defines the interface of an absolute point in time, specified to fractional seconds.

Inherit

Temporal

Functions

Signature

Meaning

year: Integer

Year.

month: Integer
Pre: not month_unknown

Month in year.

day: Integer
Pre: not day_unknown

Day in month.

hour: Integer
Pre: not hour_unknown

Hour in day.

minute: Integer
Pre: not minute_unknown

Minute in hour.

second: Integer
Pre: not second_unknown

Second in minute.

fractional_second: Real

Fractional seconds.

timezone: ITimezone

Timezone; may be Void.

Invariant

Day_valid: valid_day(year, month, day)

Month_valid: valid_month (month)

Year_valid: valid_year (year)

Month_valid: valid_month (month)

Day_valid: valid_day(year, month, day)

Hour_valid: valid_hour (hour, minute, second)

5.2.6. IDuration Class

Class

IDuration (abstract)

Description

Defines the interface of a period of time corresponding to a difference between two timepoints.

Inherit

Temporal

Functions

Signature

Meaning

years: Integer

Number of years of nominal 365-day length.

months: Integer

days: Integer

Number of 24 hour days.

hours: Integer

Number of 60 minute hours.

minutes: Integer

Number of 60 second minutes.

seconds: Integer

Number of seconds.

fractional_seconds: Real

Fractional seconds.

weeks: Integer

Number of 7 day weeks.

to_seconds: Integer

Total number of seconds equivalent (including fractional) of entire duration.

Invariant

Years_valid: years >= 0

Months_valid: months >= 0

Weeks_valid: weeks >= 0

Days_valid: days >= 0

Hours_valid: hours >= 0

Minutes_valid: minutes >= 0

Seconds_valid: seconds >= 0

Fractional_second_valid: fractional_second >= 0.0 and fractional_second < 1.0

5.2.7. ITimezone Class

Class

ITimezone (abstract)

Description

Interface definition of a timezone.

Inherit

Temporal

Functions

Signature

Meaning

hour: Integer

Hour part of timezone - in the range 00 - 13.

minute: Integer

Minute part of timezone. Generally 00 or 30.

sign: Integer

Direction of timezone expresssed as +1 or -1.

Invariant

Min_hour_valid: sign = -1 implies hour > 0 and hour <= Min_timezone_hour

Max_hour_valid: sign = 1 implies hour > 0 and hour <= Max_timezone_hour

Minute_valid: not minute_unknown implies valid_minute (minute)

Sign_valid: sign = 1 or sign = -1

5.2.8. Date Class

Class

Date

Description

Assumed built-in primitive type representing a date.

Inherit

IDate

Attributes

Signature

Meaning

1..1

value: Integer

5.2.9. Time Class

Class

Time

Description

Assumed built-in primitive type representing a time.

Inherit

ITime

Attributes

Signature

Meaning

1..1

value: Integer

5.2.10. Date_time Class

Class

Date_time

Description

Assumed built-in primitive type representing a date/time

Inherit

IDate_time

Attributes

Signature

Meaning

1..1

value: Integer

5.2.11. Duration Class

Class

Duration

Description

Assumed built-in primitive type representing a duration.

Inherit

IDuration

Attributes

Signature

Meaning

1..1

value: Integer

5.2.12. Timezone Class

Class

Timezone

Description

Assumed built-in primitive type representing a timezone.

Inherit

ITimezone

5.3. ISO 8601 Types

The set of ISO 8601 based types define dates and times with a String representation (as per ISO 8601), and the ISO 8601 'partial' and 'extended' semantics. They are defined as descendents of the native types described above, and add the necessary elements required for ISO 8601.

ISO 8601 semantics not used in these types include:

  • "expanded" dates, which have year numbers of greater than 4 digits, and may be negative; in openEHR, only 4-digit year numbers are assumed;

  • the YYYY-WW-DD method of expressing dates (since this is imprecise and difficult to compute with due to variable week starting dates, and not required in health);

  • partial date/times with fractional minutes or hours, e.g. hh,hhh or mm,mm; in openEHR, only fractional seconds are supported;

  • the interval syntax. Intervals of date/times are supported in openEHR, but their syntax form is defined by ADL, and is standardised across all comparable types, not just dates and times.

Deviations from the published standard include the following:

  • durations are supposed to take the form of PnnW or PnnYnnMnnDTnnHnnMnnS, but in openEHR, the W (week) designator can be used in combination with the other designators, since it is very common to state durations of pregnancy as some combination of weeks and days.

  • partial variants of Iso8601_date_time can include missing hours, days and months, whereas ISO 8601:2004 (section 4.3.3 c) only allows missing seconds and minutes. The reasons for this deviation are:

    • the same deviation is used in HL7v2 and HL7v3 TS (timestamp) type, i.e. there are data in existing clinical systems matching this specification;

    • in a typed object model, this deviation is more sensible anyway; the ISO 8601 rule is most likely a limitation of the purely syntactic means of expression. In real systems where a timestamp/date-time is specified in a screen form, it makes sense to allow it to be as partial as possible, rather than artifically restricted to only missing seconds and minutes.

  • the time 24:00:00 (or 240000) is not allowed anywhere, whereas in ISO 8601:2004 it appears to be legal at least for times. This deviation is also appears to be used in HL7v2 and HL7v3 (where midnight is defined as the time 00:00:00), and is preferable to the documented standard, since a date/time with time of 24:00:00 is really the next day, i.e. the date part is then incorrect.

See [ISO_8601] and the official ISO standard for ISO 8601 details. Note that in the date, time and date_time formats shown below, 'Z' and 'T' are literals. In the duration class shown below, 'P', 'Y', 'M', 'W', 'D', 'H', 'S' and 'T' are literals.

5.3.1. Iso8601_type Class

Class

Iso8601_type (abstract)

Description

Abstract ancestor type of ISO 8601 types, defining interface for 'extended' and 'partial' concepts from ISO 8601.

Inherit

Ordered

Attributes

Signature

Meaning

1..1

value: String

Functions

Signature

Meaning

is_partial: Boolean

True if this date time is partial, i.e. if trailing end (right hand) value(s) is/are missing.

is_extended: Boolean

True if this ISO8601 string is in the 'extended' form, i.e. uses ‘-’ and / or ‘:’ separators.

5.3.2. Iso8601_date Class

Class

Iso8601_date

Description

Represents an ISO 8601 date, including partial and extended forms.

Inherit

Iso8601_type, IDate

Functions

Signature

Meaning

month_unknown: Boolean

Indicates whether month in year is unknown. If so, the date is of the form “YYYY”.

day_unknown: Boolean

Indicates whether day in month is unknown. If so, and month is known, the date is of the form “YYYY-MM” or “YYYYMM”.

valid_iso8601_date: Boolean

String is a valid ISO 8601 date, i.e. takes the complete form:

  • YYYYMMDD or the extended form:

  • YYYY-MM-DD or one of the partial forms:

  • YYYYMM

  • YYYY

or the equivalent extended form:

  • YYYY-MM

Where:

  • YYYY is the string form of any positive number in the range “0000” - “9999” (zero-filled to four digits)

  • MM is “01” - “12” (zero-filled to two digits)

  • DD is “01” - “31” (zero-filled to two digits)

The combinations of YYYY, MM, DD numbers must be correct with respect to the Gregorian calendar.

(effected)

is_partial: Boolean

True if this date is partial, i.e. if days or more is missing.

(effected)

is_extended: Boolean

True if this date uses ‘-’ separators.

(effected)

as_string: String

ISO8601 string for date, in format YYYYMMDD or YYYY-MM-DD, or a partial invariant. See valid_iso8601_date for validity.

Invariant

Year_valid: valid_year (year)

Month_valid: not month_unknown implies valid_month (month)

Day_valid: not day_unknown implies valid_day (year, month, day)

Partial_validity: month_unknown implies day_unknown

5.3.3. Iso8601_time Class

Class

Iso8601_time

Description

Represents an ISO 8601 time, including partial and extended forms.

Note
A small deviation to the ISO 8601:2004 standard in this class is that the time 24:00:00 is not allowed, for consistency with ISO8601_DATE_TIME.

Inherit

Iso8601_type, ITime

Functions

Signature

Meaning

minute_unknown: Boolean

Indicates whether minute is unknown. If so, the time is of the form “hh”.

second_unknown: Boolean

Indicates whether second is unknown. If so and month is known, the time is of the form “hh:mm” or “hhmm”.

is_decimal_sign_comma: Boolean

True if this time has a decimal part indicated by ‘,’ (comma) rather than ‘.’ (period).

valid_iso8601_time: Boolean

String is a valid ISO 8601 date, i.e. takes the form:

  • hhmmss[(,|.)s+][Z|±hh[mm]]

or the extended form:

  • hh:mm:ss[(,|.)s+][Z|±hh[:mm]]

or one of the partial forms:

  • hhmm or hh

or the extended form:

  • hh:mm

with an additional optional timezone indicator of:

  • Z or ±hh[mm] or ±hh[:mm] (extended form)

Where:

  • hh is “00” - “23” (0-filled to two digits)

  • mm is “00” - “59” (0-filled to two digits)

  • ss is “00” - “60” (0-filled to two digits)

  • [(,|.)s+] is an optional string consisting of a comma or decimal point followed by numeric string of 1 or more digits, representing a fractional second

  • Z is a literal meaning UTC (modern replacement for GMT), i.e. timezone +0000

as_string: String

ISO8601 string for time, i.e. in form: hhmmss[,sss][Z|±hh[mm]] or the extended form: hh:mm:ss[,sss][Z|±hh[mm]], or a partial invariant. See valid_iso8601_time for validity.

has_fractional_second: Boolean

True if the fractional_second part is signficant (i.e. even if = 0.0).

(effected)

is_partial: Boolean

True if this time is partial, i.e. if seconds or more is missing.

(effected)

is_extended: Boolean

True if this time uses ‘-’, ‘:’ separators.

Invariant

Hour_valid: valid_hour(hour, minute, second)

Minute_valid: not minute_unknown implies valid_minute (minute)

Second_valid: not second_unknown implies valid_second (second)

Fractional_second_valid: has_fractional_second implies (not second_unknown and valid_fractional_second (fractional_second))

Partial_validity: minute_unknown implies second_unknown

5.3.4. Iso8601_date_time Class

Class

Iso8601_date_time

Description

Represents an ISO 8601 date/time, including partial and extended forms.

Note that this class includes 2 deviations from ISO 8601:2004:

  • for partial date/times, any part of the date/time up to the month may be missing, not just seconds and minutes as in the standard;

  • the time 24:00:00 is not allowed, since it would mean the date was really on the next day.

Inherit

Iso8601_type, IDate_time

Functions

Signature

Meaning

month_unknown: Boolean

Indicates whether month in year is unknown.

day_unknown: Boolean

Indicates whether day in month is unknown.

minute_unknown: Boolean

Indicates whether minute in hour is known.

second_unknown: Boolean

Indicates whether minute in hour is known.

is_decimal_sign_comma: Boolean

True if this time has a decimal part indicated by ‘,’ (comma) rather than ‘.’ (period).

valid_iso8601_date_time (s: String): Boolean

String is a valid ISO 8601 date-time, i.e. takes the form:

  • YYYYMMDDThhmmss[(,|.)s+][Z|±hh[mm]]

or the extended form:

  • YYYY-MM-DDThh:mm:ss[(,|.)s+][Z|±hh[:mm]]

or one of the partial forms:

  • YYYYMMDDThhmm

  • YYYYMMDDThh

or the equivalent extended forms:

  • YYYY-MM-DDThh:mm

  • YYYY-MM-DDThh

(meanings as in DV_DATE, DV_TIME) and the values in each field are valid.

as_string: String

ISO8601 string for date/time, in format YYYYMMDDThhmmss[,sss][Z | ±hh[mm]] or in extended format YYYY-MM-DDThh:mm:ss[,sss][Z | ±hh[mm]] or a partial variant; see valid_iso8601_date_time() below.

has_fractional_second: Boolean

True if the fractional_second part is signficant (i.e. even if = 0.0).

(effected)

is_partial: Boolean

True if this date time is partial, i.e. if seconds or more is missing.

(effected)

is_extended: Boolean

True if this date/time uses ‘-’, ‘:’ separators.

Invariant

Year_valid: valid_year (year)

Month_valid: valid_month (month)

Day_valid: valid_day(year, month, day)

Hour_valid: valid_hour (hour, minute, second)

Minute_valid: not minute_unknown implies valid_minute(minute)

Second_valid: not second_unknown implies valid_second (second)

Fractional_second_valid: has_fractional_second implies (not second_unknown and valid_fractional_second (fractional_second))

Partial_validity_year: not month_unknown

Partial_validity_month: not month_unknown

Partial_validity_day: not day_unknown

Partial_validity_hour: not hour_unknown

Partial_validity_minute: minute_unknown implies second_unknown

5.3.5. Iso8601_duration Class

Class

Iso8601_duration

Description

Represents an ISO 8601 duration.

Inherit

Iso8601_type, IDuration

Functions

Signature

Meaning

is_decimal_sign_comma: Boolean

True if this time has a decimal part indicated by ',' (comma) rather than '.' (period).

valid_iso8601_duration (s: String): Boolean

String is a valid ISO 8601 duration, i.e. takes the form:

  • P[nnY][nnM][nnW][nnD][T[nnH][nnM][nnS]]

Where each nn represents a number of years, months, etc. nnW represents a number of 7-day weeks.

Note: allowing the W designator in the same expression as other designators is an exception to the published standard, but necessary in clinical information (typically for representing pregnancy duration).

as_string: String

ISO8601 string for duration, in format

  • P[nnY][nnM][nnW][nnD][T[nnH][nnM][nnS]]

(effected)

is_partial: Boolean

Returns False.

(effected)

is_extended: Boolean

Returns True.

Invariant

Years_valid: years >= 0

Months_valid: months >= 0

Weeks_valid: weeks >= 0

Days_valid: days >= 0

Hours_valid: hours >= 0

Minutes_valid: minutes >= 0

Seconds_valid: seconds >= 0

Fractional_second_valid: fractional_second >= 0.0 and fractional_second < 1.0

5.3.6. Iso8601_timezone Class

Class

Iso8601_timezone

Description

Represents a timezone as used in ISO 8601.

Inherit

Iso8601_type, ITimezone

Functions

Signature

Meaning

minute_unknown: Boolean

Indicates whether minute part known.

as_string: String

ISO8601 timezone string, in format:

  • Z | ±hh[mm]

where:

  • hh is “00” - “23” (0-filled to two digits)

  • mm is “00” - “59” (0-filled to two digits)

  • Z is a literal meaning UTC (modern replacement for GMT), i.e. timezone +0000

is_gmt: Boolean

True if timezone is UTC, i.e. +0000.

(effected)

is_partial: Boolean

True if this time zone is partial, i.e. if minutes is missing.

(effected)

is_extended: Boolean

True if this time-zone uses ‘:’ separators.

Invariant

Min_hour_valid: sign = -1 implies hour > 0 and hour <= Min_timezone_hour

Max_hour_valid: sign = 1 implies hour > 0 and hour <= Max_timezone_hour

Minute_valid: not minute_unknown implies valid_minute (minute)

Sign_valid: sign = 1 or sign = -1

5.4. Derived Interval Types

A number of useful types may be generated from the Date/time classes and the Interval classes. These are shown in blue on the following diagram.

BASE base types.time intervals
Figure 6. Useful time interval types

6. Terminology Types

6.1. Overview

One type is provided among the base_types package to represent a reference to a 'terminology code', i.e. a code within a 'terminology'. This is sometimes called a 'concept code' among terminology builders.

The assumption here is that the 'code' is a reference to a referenceable entity within a terminology or ontology, which may be:

  • a single 'term', for which a definition and potentially relationships (at least the IS-A relationship);

  • a 'value set' i.e. a set of single terms, possibly in a tree or other structure corresponding to relationships between the member terms;

  • any other terminological entity referencable with a code.

BASE base types.terminology
Figure 7. base_types.terminology package

6.1.1. Class Definitions

The Terminology_code class is defined below.

6.1.2. Terminology_code Class

Class

Terminology_code

Description

Logically primitive type representing a reference to a terminology concept, in the form of a terminology identifier, optional version, and a code or code string from the terminology.

Inherit

Any

Attributes

Signature

Meaning

1..1

terminology_id: String

The archetype environment namespace identifier used to identify a terminology. Typically a value like "snomed_ct" that is mapped elsewhere to the full URI identifying the terminology.

0..1

terminology_version: String

Optional string value representing terminology version, typically a date or dotted numeric.

1..1

code_string: String

A terminology code or post-coordinated code expression, if supported by the terminology. The code may refer to a single term, a value set consisting of multiple terms, or some other entity representable within the terminology.

0..1

uri: Uri

The URI reference that may be used as a concrete key into a notional terminology service for queries that can obtain the term text, definition, and other associated elements.

7. Functional Meta-types

7.1. Overview

A small number of meta-types are defined that correspond to functional programming primitives, otherwise known as 'closures', 'lambda expressions' and so on. These concepts are supported in most modern programming languages now, and the types defined here are intended to provide a minimal formal basis to enable other openEHR specification to defined function-related elements. Since UML does not contain native functional elements, the semantics here are approximated using normal class facilities.

The following illustrates the base_types.functional package.

BASE base types.functional
Figure 8. base_types.functional package

Two key abstractions are required, namely 'function as a type', and 'tuple', which enables arguments to be formalised. To provide a 'function' type, a 'routine' type is also required. For completeness, a 'procedure' type is also defined. The 'tuple' type is defined as a generic meta-type whose descendants may additionally define any number of generic parameter types, corresponding to a type list.

7.1.1. Class Definitions

7.1.2. ROUTINE Class

Class

ROUTINE

Description

Type representing a function with a return type and 0 or more arguments represented as a TUPLE.

7.1.3. FUNCTION Class

Class

FUNCTION

Description

Type representing a function with a return type and 0 or more arguments represented as a TUPLE.

Inherit

ROUTINE

7.1.4. PROCEDURE Class

Class

PROCEDURE

Description

Type representing a procedure with 0 or more arguments represented as a TUPLE.

Inherit

ROUTINE

7.1.5. TUPLE Class

Class

TUPLE

Description

Parent type of all TUPLE types.

7.1.6. TUPLE1 Class

Class

TUPLE1

Description

Inherit

TUPLE

7.1.7. TUPLE2 Class

Class

TUPLE2

Description

Inherit

TUPLE

8. Definitions Package

8.1. Overview

The base_types.definitions package shown below defines symbolic definitions used by the openEHR models.

BASE base types.definitions
Figure 9. base_types.definitions package

8.1.1. Class Definitions

8.1.2. BASIC_DEFINITIONS Class

Class

BASIC_DEFINITIONS

Description

Defines globally used constant values.

Constants

Signature

Meaning

1..1

CR: char = '\015'

Carriage return character.

1..1

LF: char = '\012'

Line feed character.

1..1

Any_type: String = "Any"

1..1

Regex_any_pattern: String = ".*"

1..1

Default_encoding: String = "UTF-8"

8.1.3. OPENEHR_DEFINITIONS Class

Class

OPENEHR_DEFINITIONS

Description

Inheritance class to provide access to constants defined in other packages.

Inherit

BASIC_DEFINITIONS

Attributes

Signature

Meaning

1..1

Local_terminology_id: String = "local"

Predefined terminology identifier to indicate it is local to the knowledge resource in which it occurs, e.g. an archetype

8.1.4. VALIDITY_KIND Enumeration

Enumeration

VALIDITY_KIND

Description

An enumeration of three values that may commonly occur in constraint models.

Use as the type of any attribute within this model, which expresses constraint on some attribute in a class in a reference model. For example to indicate validity of Date/Time fields.

Attributes

Signature

Meaning

mandatory

Constant to indicate mandatory presence of something.

optional

Constant to indicate optional presence of something.

prohibited

Constant to indicate disallowed presence of something.

8.1.5. VERSION_STATUS Enumeration

Enumeration

VERSION_STATUS

Description

Status of a versioned artefact, as one of a number of possible values: uncontrolled, prerelease, release, build.

Attributes

Signature

Meaning

alpha

Value representing a version which is ‘unstable’, i.e. contains an unknown size of change with respect to its base version. Rendered with the build number as a string in the form “N.M.P-alpha.B” e.g. “2.0.1-alpha.154”.

beta

Value representing a version which is ‘beta’, i.e. contains an unknown but reducing size of change with respect to its base version. Rendered with the build number as a string in the form “N.M.P-beta.B” e.g. “2.0.1-beta.154”.

release_candidate

Value representing a version which is ‘release candidate’, i.e. contains only patch-level changes on the base version. Rendered as a string as “N.M.P-rc.B” e.g. “2.0.1-rc.27”.

released

Value representing a version which is ‘released’, i.e. is the definitive base version. Rendered with the build number as a string in the form “N.M.P” e.g. “2.0.1”.

build

Value representing a version which is a build of the current base release. Rendered with the build number as a string in the form “N.M.P+B” e.g. “2.0.1+33”.

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 .