openEHR logo

Basic Meta-Model (BMM)

Issuer: openEHR Specification Program

Release: latest

Status: STABLE

Revision: [latest_issue]

Date: [latest_issue_date]

Keywords: reflection, meta-model, UML

© 2016 - 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

2.2.2

Improve and update introductory text in the Overview section.

E Sundvall,
T Beale

03 Nov 2017

2.2.1

Rename P_BMM_SIMPLE_TYPE_OPEN to P_BMM_OPEN_TYPE;
Remove BMM_CLASSIFIER.conformance_type_name;
Rename P_BMM_GENERIC_PARAMETER.create_bmm_generic_parameter_definition to create_bmm_generic_parameter;
Remove inheritance from P_BMM_PACKAGE_CONTAINER to P_BMM_MODEL_ELEMENT;
Make P_BMM_MODEL_ELEMENT abstract;
Correct P_BMM_ENUMERATION.items_names cardinality to multiple;
Constrain BMM_GENERIC_PARAMETER.name and P_BMM_GENERIC_PARAMETER.name to one character and upper case.

C Nanjo,
T Beale

02 Mar 2017

2.2.0

Rename BMM_CLASSIFIER.as_type_string to type_name and as_conformance_type_string to conformance_type_name.
Move and rename BMM_TYPE.as_display_type_string to BMM_CLASSIFIER.type_signature. Add redefinitions in relevant descendant classes.
Rename BMM_SIMPLE_TYPE_OPEN to BMM_OPEN_TYPE.
Add new class BMM_TYPE_ELEMENT in preparation for BMM 3 refactoring.
Remove class P_BMM_CLASSIFIER.
Add missed inheritance from P_BMM_PROPERTY to P_BMM_MODEL_ELEMENT.
Rename BMM_SCHEMA to BMM_MODEL.

T Beale

20 Jun 2016

Add missing inheritance from P_BMM_SCHEMA to BMM_SCHEMA_CORE.
Correct naming of bmm_xxx_definition, create_bmm_xxx_definition in P_BMM_XXX classes to bmm_xxx, create_bmm_xxx etc.

T Beale

18 Apr 2016

2.1.0

Initial writing based on ADL Workbench implementation.

T Beale

08 Feb 2016

Acknowledgements

Primary Author

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

Contributors

This specification has benefited from formal and informal input from the openEHR and wider health informatics community. The openEHR Foundation would like to recognise the following people for their contributions.

  • Patrick Langford, NeuronSong LLC, Utah, USA

  • Claude Nanjo MA African Studies., M Public Health, Cognitive Medical Systems Inc., California, USA

  • Harold Solbrig, Mayo Clinic, Rochester, USA

  • Erik Sundvall PhD, Linkoping University, Sweden

Trademarks

  • 'openEHR' is a registered trademark of the openEHR Foundation

  • 'Java' is a registered trademark of Oracle Corporation

  • 'OMG' and 'UML' are registered trademarks of the Object Management Group

  • 'MagicDraw' is a registered trademark of NoMagic Inc

  • 'Rational Software Architect' is a registered trademark of IBM Corporation.

1. Preface

1.1. Purpose

This document describes the Basic Meta-Model (BMM), a model of object models. It may be considered as an approximate replacement for the UML XMI. It is human-readable and writable, and supports generic types (open and closed), container types, and multiple inheritance.

1.2. Status

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

2. Overview

2.1. Introduction

One of the key needs in any open computing environment is a computable representation of its own models, for a number of purposes, including reasoning about them, performing validation and consistency checking, building software and generating documentation. This is particularly true of openEHR, where a further need is to be able to validate archetypes and templates with respect to the reference model, and also to validate runtime instance data against operational templates and the reference model.

A number of computable representations of the openEHR published models have been available in the past. Currently models are represented in two computable forms:

  • MagicDraw 18.5 or higher UML/XMI;

  • Basic Meta-Model (BMM) format, i.e. the format of this specification.

The primary use of the UML expression is for specification publishing. In this role, the internal UML is processed to generate correct signatures for class properties and functions, and can be used computably for other purposes, as long as care is taken with template and qualified attributes.

The BMM provides a standalone alternative to UML/XMI which correctly represents all types, including open and closed template types, and is human-readable. It was originally developed in 2012, when the state of UML tools and particularly XMI was poor, and a reliable format was needed for openEHR modelling tools.

Note
Other than for working with particular tools designed to use BMM, BMM is not a required formalism for implementing openEHR, and other methods of accessing models computably may be used, including UML and software implementations of the openEHR Reference Model.

2.2. Current State of the Art

One would expect that the ICT industry would have fully computable representations of models and diagramming solved, but it is not yet the case. UML 2.x and its associated serialisation format XMI 2.x should in theory mean that complete, interoperable machine expressions of object models would be available in all tools. It will probably eventually come to pass, but a number of obstacles remain to date:

  • the UML 2.x specifications are exceedingly complex (see OMG site for specifications; UML 2.1.2 'superstructure' = 738pp; UML 2.1.2 'infrastructure' = 224pp);

  • the XMI 2.x specification is correspondingly complex, which seems to have so far prevented reliable tool interoperability (recognised as a critical issue by OMG in 2015);

  • the Design By Contract (DbC) concept is supported via the use of OCL 2.0 constraints in class models, although there are semantic holes, e.g. proper semantics through inheritance;

  • for some, XML-schema represents a way of expressing object models, but in fact is not semantically suitable for this purpose, primarily due to its different inheritance model. It can be and is used (including in openEHR) as a derivative serialisation representation, but from the point of view of specification, it is deficient in having non-object-oriented inheritance semantics, no generic classes, no representation of non-data members, and only marginal support for design by contract.

Experience with various UML tools (up till 2015) highlighted the following problems:

  • poor support for OCL and design by contract in most tools;

  • variable support for generic (i.e. template) classes; even those tools that properly implement the UML 2.5 specification are still very hard to use for defining generic classes because of problems in the specification that remain unaddressed;

  • problems with qualified attributes, which are used to represent identifier references to objects rather than direct references;

  • variable support for XSD generation across tools, where the results are wildly wrong in some tools;

  • in some tools, it is impossible to define an abstract formal model - the only option is to select a particular programming language profile such as Java or C# and thus get locked into the limitations of those languages (messy type systems, weak inheritance semantics, language-specific notion of types such as Array<T>, List<T>, etc.).

Since 2015, the quality of UML tools has improved, and the XMI generated by some is more reliable. However, XMI generated by different tools is not the same for identical models, and some XMI importers offer numerous switches in order to process the XMI of another tool properly. XMI thus still needs to be processed with care.

Nevertheless, a small number of tools, including MagicDraw (currently used for representing openEHR models for the specifications) and Rational Software Architect (RSA), appear to implement UML 2.5 faithfully. This means that despite the limitations of UML 2.5 (as noted above), models expressed in it can be correctly interpreted and processed for purposes such as code generation.

Note
Other tools may well perform as well or better, and in any case, all tools change over time. No endorsement of a particular tool is intended here.

2.3. Design

The Basic Meta-Model supports the representation of object models in the data point of view. It is designed to enable both human authoring and machine extraction (e.g. from a UML tool or programming language classes) of textual schemas. This specification defines a BMM object model, i.e. the in-memory object structure of a BMM, and also an object model for a serialised schema form. The latter enables serialisation of a BMM into a concrete syntax such as ODIN, JSON or XML. In the future an abstract syntax serialisation may be developed in the style of OMG IDL (Interface Definition Language) or similar.

The BMM packages are as follows:

  • rm_access: the interface to most features including schema load/reload, generally used by an application as a reflection library;

  • core: the core BMM classes used for in-memory representation of an object model;

  • persistence: a simplified version of the core classes prefixed with P_BMM_, used for persistence and human authoring, which allow file (i.e. schema) inclusion and re-use.

The P_BMM_* classes perform two functions. Firstly, they are a modified and simplified version of the BMM_* classes that enable for example symbolic referencing via class names, syntactical type names to be used etc, rather than the full explosion of fine-grained objects that would result from a direct serialisation of BMM_* classes. This is what enables the P_BMM file format to be easily readable and editable by human users.

The second is that P_BMM files function as schemas that support schema inclusion and therefore re-use, in a similar manner to the XML schema languages. Thus, a single logical BMM model can be expressed as a number of P_BMM schema files which are actually P_BMM_* object serialisations. A schema reading component has to resolve the schema inclusions and ultimately BMM_* object instantiations to obtain the in-memory form of the model.

We thus talk of the P_BMM_* classes as a model of 'BMM schemas' and the BMM_* classes as a model of 'BMM models', where the latter is understood as the fully computable in-memory object structure with all name references resolved to object references.

The packages are illustrated below.

BASE bmm packages
Figure 1. Package Overview

The normal use of BMM is as follows:

  • create a P_BMM schema in the form of one or more files, using the P_BMM_ form of the model. This is easy to understand by using the example schema and/or copying other examples;

  • locate these files in a suitable place for use with a tool such as the openEHR ADL Workbench and LinkEHR.

2.4. Schema Format

BMM models are normally expressed as schema text files that support inclusion and re-use. The default file format has historically been openEHR ODIN syntax, and BMM tools to date support this format. However any common format that can express typed object models may be used, including JSON (with type markers), YAML, and XML. The examples shown in this specification are primarily in ODIN, but a tool implementing BMM may choose to serialise in and out of another preferred format.

2.5. A Note on Language

The elements of meta-models are sometimes named confusingly in the literature and within various programming language technologies. In this specification, we have used the following terms:

feature (of a class)

any stored or computed element of a class;

property

a stored class feature; also known as 'attribute';

routine

a computed class feature;

function

a routine that computes and returns a value; typically causes no side-effects in the object;

procedure

a routine that performs a computation; typically has side-effects;

generic (class or type)

a kind of class or type that has parameters of other types; known as 'template' type in some programming languages.

3. BMM in Use

BMM schemas as used in the openEHR ADL Workbench (AWB) provide an illustration of their use and visualisation. The following screenshot shows the BMM schema configuration dialog in the AWB, including some meta-data, validation status etc, and also the schema nesting structure.

awb schemas config
Figure 2. BMM schema configuration

The screenshot below shows a number of BMMs loaded into the AWB, including some of the packages and classes for the 'openehr_ehr_extract_1.1.0' model.

awb loaded bmm schemas
Figure 3. BMM schemas loaded

The following shows a single class in the inheritance-flattened properties view, otherwise known as the 'flat view' . The structure of the class as properties, types, multiplicities, inheritance etc are all provided by the in-memory BMM classes.

awb class properties
Figure 4. BMM class - properties view

The following shows a class in a 'closure' view, which is a computed reachability graph of a fully inheritance flattened class and all properties, including recursive references.

awb class closure
Figure 5. BMM class - closure view

One of the main uses of the BMM in the ADL Workbench and other similar tools is to provide a computable form of the information model ('reference model' in openEHR) for use with archetypes. The following shows an archetype for which each node has its RM class shown (in colour), and additionally, the inclusion of non-archetyped attributes from the classes of the archetype nodes.

archetype rm
Figure 6. ADL archetype with BMM class properties

4. RM Access Package

4.1. Overview

The rm_access package provides an interface for the application to load and access BMM schemas, and is shown below.

BASE bmm.rm access
Figure 7. RM Access Package

4.2. Class Definitions

4.2.1. REFERENCE_MODEL_ACCESS Class

Class

REFERENCE_MODEL_ACCESS

Description

Access to service interface to BMM object model.

Inherit

BMM_DEFINITIONS

Attributes

Signature

Meaning

0..1

schema_directories: List<String>

List of directories where all the schemas loaded here are found.

0..1

all_schemas: Hash<String,SCHEMA_DESCRIPTOR>

All schemas found and loaded from `schema_directory'. Keyed by schema_id, i.e.

  • model_publisher '' schema_name '' model_release

e.g. openehr_rm_1.0.3, openehr_test_1.0.1, iso_13606-1_2008. This is the same key as BMM_SCHEMA.schema_id. Does not include schemas that failed to parse (i.e. SCHEMA_ACCESS.passed = False)

0..1

valid_models: Hash<String,BMM_MODEL>

Top-level (root) schemas in use. Table is keyed by logical schema_name, i.e. model_publisher '_' model_name, e.g. "openehr_rm". Schemas containing different variants of same model (i.e. model_publisher + model_name) are considered duplicates.

Functions

Signature

Meaning

initialise_with_load_list (
a_schema_dirs: List<String>[1],
a_schema_load_list: List<String>[0..1]
)

Initialise with a specific schema load list, usually a sub-set of schemas that will be found in the directory `an_absolute_dir'.

initialise_all

reload_schemas

4.2.2. SCHEMA_DESCRIPTOR Class

Class

SCHEMA_DESCRIPTOR

Description

Descriptor for a BMM schema. Contains a meta-data table of attributes obtained from a mini-ODIN parse of the schema file.

Inherit

BMM_DEFINITIONS

Attributes

Signature

Meaning

0..1

p_schema: P_BMM_SCHEMA

Persistent form of model.

0..1

schema: BMM_MODEL

Computable form of model.

1..1

schema_id: String

Schema id, formed from:

  • meta_data(Metadata_model_publisher) '-' meta_data(metadata_schema_name) '-' meta_data(Metadata_model_release)

e.g. openehr_rm_1.0.3, openehr_test_1.0.1, iso_13606-1_2008.

1..1

meta_data: Hash<String, String>

Table of {key, value} pairs of schema meta-data, keys as follows:

  • "bmm_version",

  • "model_publisher",

  • "schema_name",

  • "model_release",

  • "schema_revision",

  • "schema_lifecycle_state",

  • "schema_description",

  • "schema_path"

0..1

includes: List<String>

Schema_ids of schemas included by this schema.

Functions

Signature

Meaning

is_top_level (): Boolean

True if this is a top-level schema, i.e. not included by some other schema.

is_bmm_compatible (): Boolean

True if the BMM version found in the schema (or assumed, if none) is compatible with that in this software.

load

Load schema into in-memory form.

validate

Validate entire schema.

validate_includes (
all_schemas_list: List<String>[0..1]
)

Validate includes list for this schema, to see if each mentioned schema exists in read schemas.

create_schema

Create `schema'.

5. Core Package

5.1. Overview

The core package, shown below, defines the main BMM model.

BASE bmm.core
Figure 8. RM Core Package

5.2. Semantics

5.2.1. Basics

Three top-level classes define basic abstract semantics for all other entities in the BMM: BMM_MODEL_ELEMENT, BMM_CLASSIFIER and BMM_TYPE. The first of these introduces features common to all elements of any BMM, such as documentation. The class BMM_CLASSIFIER is the abstract parent of anything that functions as the type of a property (viz: classes, types and generic parameters), while its descendant BMM_TYPE defines the semantics of types of instances, described below.

The BMM_CLASSIFIER class has a small number of important features that establish formally the meaning of various kinds of class names, type names etc, as follows:

  • type_name: the effective type of an entity; for simple classes, this will just be the class name (BMM_CLASS.name); for generic and container classes it will be generic name such as List<T>, Interval<T> etc; for feature types it will be the declared type, i.e. a simple name, an open type name (e.g. T) or a generic type name (e.g. Interval<Time>);

  • type_signature: a form of the type name that can be used as a fully-defined type signature, which for generic classes includes generic constrainer types, giving a signature such as Interval<T:Ordered>;

  • conformance_type_name: a reduced form of the type useful in some circumstances that is either a simple class name, the contained type for a container type (e.g. ELEMENT from the type List<ELEMENT>), and the root type from a generic type (e.g. Interval from Interval<T>).

In addition, concrete classes such as BMM_CLASS and BMM_PROPERTY have a simple name property, corresponding to the literal names of these entities.

5.2.2. Classes and Types

One of the foundational concepts in the BMM is a distinction between class and type, in common with the type systems of the modern forms of most object-oriented languages. Classes are definitional entities, while 'type' has two meanings: as the static (design time) type of a class feature (property or function result) and as the dynamic (run-time) type of the object referred to by or computed by that feature. At design time, the type of a property in a BMM model can be one of the following:

  • a BMM_SIMPLE_TYPE - corresponds to a simple class;

  • a BMM_OPEN_TYPE - corresponds to a generic parameter type from the class type definition, e.g. T, U etc;

  • a BMM_GENERIC_TYPE - a type generated by the use of a generic type with filled type parameters, e.g. Interval<Time>;

  • a BMM_CONTAINER_TYPE - a type generated by the use of a linear container type such as List<T>, Hash<T,U> with actual generic parameters.

In object-oriented type theory, the last two are really the same thing, but the BMM treats them slightly differently for reasons of clarity: a BMM_CONTAINER_TYPE can be thought of as a 1:N counterpart to a BMM_SIMPLE_TYPE, whereas BMM_GENERIC_TYPE is typically used for objects considered to be singular, but whose types are a product of a special container and one or more parameter types.

5.2.3. Inheritance

The BMM supports single and multiple inheritance, although it does not distinguish between different types of inheritance relation as some programming languages do. The evaluation of inheritance relations defined in a BMM schema results in an acyclic graph such that ancestors and descendants can be visualised for any class. The following screen shot shows the ancestors view of a class OBSERVATION.

awb class ancestors
Figure 9. BMM class - ancestors view

The next screenshot shows the descendants view of one of the ancestorsclasses of the same class.

awb class descendants
Figure 10. BMM class - descendants view

Multiple inheritance is typically used in the definition of classes that have a Liskov substitution inheritance relation as well as an implementation inheritance relation. The following shows a class DV_INTERVAL<T> multiply inheriting from Interval<T> and DATA_VALUE.

awb multiple inheritance
Figure 11. BMM class - descendants view

5.2.4. Classes and Properties

Class properties are defined using the generic class BMM_PROPERTY <T: BMM_TYPE>. This approach provides a direct way of expressing the semantics of property meta-types as listed above. The properties of a class can be understood in two forms. In an original model definition, each class definition states the features it introduces with respect to its inheritance parents. We can think of this list of properties as a differential set. In contrast, the effective set of properties for a class is the result of evaluating these lists of properties down the inheritance hierarchy to obtain the flat set of properties. The features properties and flat_properties defined on BMM_CLASS provide access to these two lists for any class.

5.3. Class Definitions

5.3.1. BMM_DEFINITIONS Class

Class

BMM_DEFINITIONS

Description

Definitions used by all BMM packages.

Constants

Signature

Meaning

1..1

Bmm_internal_version: String

Current internal version of BMM meta-model, used to determine if a given schema can be processed by a given implementation of the model.

1..1

Schema_name_delimiter: String = "::"

Delimiter used to separate schema id from package path in a fully qualified path.

1..1

Package_name_delimiter: String = "."

Delimiter used to separate package names in a package path.

1..1

Bmm_schema_file_extension: String = ".bmm"

Extension used for BMM files.

5.3.2. BMM_MODEL_ELEMENT Class

Class

BMM_MODEL_ELEMENT (abstract)

Description

Ancestor class of most BMM model elements.

Inherit

BMM_DEFINITIONS

Attributes

Signature

Meaning

0..1

documentation: String

Optional documentation of this element.

5.3.3. BMM_SCHEMA_CORE Class

Class

BMM_SCHEMA_CORE

Description

Core properties of BMM_SCHEMA.

Attributes

Signature

Meaning

1..1

rm_publisher: String

Publisher of model expressed in the schema. Persisted attribute.

1..1

rm_release: String

Release of model expressed in the schema as a 3-part numeric, e.g. "3.1.0" . Persisted attribute.

1..1

schema_name: String

Name of model expressed in schema; a 'schema' usually contains all of the packages of one 'model' of a publisher. A publisher with more than one model can have multiple schemas. Persisted attribute.

1..1

schema_revision: String

Revision of schema. Persisted attribute.

1..1

schema_lifecycle_state: String

Persisted attribute.

1..1

schema_author: String

Primary author of schema. Persisted attribute.

1..1

schema_description: String

Description of schema. Persisted attribute.

0..1

schema_contributors: List<String>

Contributing authors of schema. Persisted attribute.

0..1

archetype_parent_class: String

Name of a parent class used within the schema to provide archetype capability, enabling filtering of classes in RM visualisation. If empty, 'Any' is assumed. Persisted attribute.

0..1

archetype_data_value_parent_class: String

Name of a parent class of logical 'data types' used within the schema to provide archetype capability, enabling filtering of classes in RM visualisation. If empty, 'Any' is assumed. Persisted attribute.

0..1

archetype_rm_closure_packages: List<String>

List of top-level package paths that provide the RM 'model' part in achetype identifiers, e.g. the path "org.openehr.ehr" gives "EHR" in "openEHR-EHR". Within this namespace, archetypes can be based on any class reachable from classes defined directly in these packages.

Persisted attribute.

0..1

archetype_visualise_descendants_of: String

If archetype_parent_class is not set, designate a class whose descendants should be made visible in tree and grid renderings of the archetype definition. For openEHR and CEN this class is normally the same as the archetype_parent_class, i.e. LOCATABLE and RECORD_COMPONENT respectively. It is typically set for CEN, because archetype_parent_class may not be stated, due to demographic types not inheriting from it.

The effect of this attribute in visualisation is to generate the most natural tree or grid-based view of an archetype definition, from the semantic viewpoint.

Persisted attribute.

Functions

Signature

Meaning

schema_id (): String

Derived name of schema, based on model publisher, model name, model release.

5.3.4. BMM_MODEL Class

Class

BMM_MODEL

Description

Model of a BMM schema (along with what is inherited from BMM_SCHEMA_CORE).

Inherit

BMM_SCHEMA_CORE, BMM_PACKAGE_CONTAINER

Attributes

Signature

Meaning

0..1

class_definitions: Hash<String,BMM_CLASS>

All classes in this schema.

Functions

Signature

Meaning

primitive_types (): List<String>

List of keys in `class_definitions' of items marked as primitive types, as defined in input schema.

enumeration_types (): List<String>

List of keys in `class_definitions' of items that are enumeration types, as defined in input schema.

class_definition (
a_name: String[1]
): BMM_CLASS

Retrieve the class definition corresponding to `a_type_name' (which may contain a generic part).

enumeration_definition (
a_name: String[1]
): BMM_ENUMERATION

Retrieve the enumeration definition corresponding to `a_type_name'.

property_definition (): BMM_PROPERTY

Retrieve the property definition for `a_prop_name' in flattened class corresponding to `a_type_name'.

ms_conformant_property_type (
a_bmm_type_name: String[1],
a_bmm_property_name: String[1],
a_ms_property_name: String[1]
): Boolean

True if `a_ms_property_type' is a valid 'MS' dynamic type for `a_property' in BMM type `a_bmm_type_name'. 'MS' conformance means 'model-semantic' conformance, which abstracts away container types like List<>, Set<> etc and compares the dynamic type with the relation target type in the UML sense, i.e. regardless of whether there is single or multiple containment.

property_definition_at_path (): BMM_PROPERTY

Retrieve the property definition for `a_property_path' in flattened class corresponding to `a_type_name'.

all_ancestor_classes (
a_class: String[1]
): List<String>

Return all ancestor types of `a_class_name' up to root class (usually 'ANY', 'Object' or something similar). Does not include current class. Returns empty list if none.

type_conforms_to (
a_desc_type: String[1],
an_anc_type: String[1]
): Boolean

Check conformance of `a_desc_type' to `an_anc_type'; the types may be generic, and may contain open generic parameters like 'T' etc. These are replaced with their apporpriate constrainer types, or Any during the conformance testing process.

Conformance is found if:

  • [base class test] types are non-generic, and either type names are identical, or else `a_desc_type' has `an_anc_type' in its ancestors

  • both types are generic and pass base class test; number of generic params matches, and each generic parameter type, after 'open parameter' substitution, recursively passes `type_name_conforms_to' test

  • descendant type is generic and ancestor type is not, and they pass base classes test

5.3.5. BMM_PACKAGE_CONTAINER Class

Class

BMM_PACKAGE_CONTAINER

Description

Abstraction of a BMM model component that contains packages and classes.

Inherit

BMM_MODEL_ELEMENT

Attributes

Signature

Meaning

0..1

packages: Hash<String,BMM_PACKAGE>

Child packages; keys all in upper case for guaranteed matching.

Functions

Signature

Meaning

package_at_path (
a_path: String[1]
): BMM_PACKAGE

Package at the path `a_path'.

do_recursive_packages (
action: PROCEDURE[1]
)

Recursively execute `action', which is a procedure taking a BMM_PACKAGE argument, on all members of packages.

has_package_path (
a_path: String[1]
): Boolean

True if there is a package at the path `a_path'; paths are delimited with Package_name_delimiter.

5.3.6. BMM_PACKAGE Class

Class

BMM_PACKAGE

Description

Abstraction of a package as a tree structure whose nodes can contain other packages and classes.

Inherit

BMM_PACKAGE_CONTAINER

Attributes

Signature

Meaning

1..1

name: String

Name of this package. This name may be qualified if it is a top-level package.

0..1

classes: List<BMM_CLASS>

Classes listed as being in this package.

Functions

Signature

Meaning

root_classes (): List<BMM_CLASS>

Obtain the set of top-level classes in this package, either from this package itself or by recursing into the structure until classes are obtained from child packages. Recurse into each child only far enough to find the first level of classes.

path (): String

Full path of this package back to root package.

5.3.7. BMM_CLASSIFIER Class

Class

BMM_CLASSIFIER (abstract)

Description

Abstract idea of specifying a type either by definition or by reference.

Inherit

BMM_MODEL_ELEMENT

Functions

Signature

Meaning

type_name (): String

Formal string form of the type as per UML.

type_category (): String

Generate a type category of main target type from Type_category_xx values.

type_signature (): String

Signature form of the type, which for generics includes generic parameter constrainer types E.g. Interval<T:Ordered>

base_class (): BMM_CLASS

Main design class for this type, from which properties etc can be extracted.

flattened_type_list (): List<String>

Completely flattened list of type names, flattening out all generic parameters.

5.3.8. BMM_TYPE_ELEMENT Class

Class

BMM_TYPE_ELEMENT (abstract)

Description

Inherit

BMM_CLASSIFIER

5.3.9. BMM_TYPE Class

Class

BMM_TYPE (abstract)

Description

Abstract idea of specifying a type in some context. This is not the same as 'defining' a class. A type specification is essentially a reference of some kind, that defines the type of an attribute, or function result or argument. It may include generic parameters that might or might not be bound. See subtypes.

Inherit

BMM_TYPE_ELEMENT

Functions

Signature

Meaning

has_type_substitutions (): Boolean

Determine if there are any type substitutions.

type_substitutions (): List<String>

List of type substitutions if any available for this type within the current BMM model.

5.3.10. BMM_CLASS Class

Class

BMM_CLASS

Description

Definition of a class in an object model. A class is type that may be open or closed in terms of other types mentioned within.

Inherit

BMM_CLASSIFIER

Attributes

Signature

Meaning

1..1

name: String

Name of this class. Note that unlike UML, names of classes are just the root name, even if the class is generic.

0..1

ancestors: Hash<String,BMM_CLASS>

List of immediate inheritance parents.

1..1

package: BMM_PACKAGE

Package this class belongs to.

0..1

properties: Hash<String,BMM_PROPERTY>

List of attributes defined in this class.

1..1

source_schema_id: String

Reference to original source schema defining this class. Useful for UI tools to determine which original schema file to open for a given class for manual editing.

0..1

immediate_descendants: List<String>

List of immediate inheritance descendants.

1..1

is_abstract: Boolean

True if this class is abstract in its model.

1..1

is_primitive_type: Boolean

True if this class is designated a primitive type within the overall type system of the schema.

1..1

is_override: Boolean

True if this definition overrides a class of the same name in an included schema.

Functions

Signature

Meaning

all_ancestors (): List<String>

List of all inheritance parent class names, recursively.

all_descendants (): List<String>

Compute all descendants by following immediate_descendants.

suppliers (): List<String>

List of names of immediate supplier classes, including concrete generic parameters, concrete descendants of abstract statically defined types, and inherited suppliers. (Where generics are unconstrained, no class name is added, since logically it would be 'ANY' and this can always be assumed anyway). This list includes primitive types.

suppliers_non_primitive (): List<String>

Same as `suppliers' minus primitive types, as defined in input schema.

supplier_closure (): List<String>

List of names of all classes in full supplier closure, including concrete generic parameters; (where generics are unconstrained, no class name is added, since logically it would be 'ANY' and this can always be assumed anyway). This list includes primitive types.

package_path (): String

Fully qualified package name, of form: 'package.package'.

class_path (): String

Fully qualified class name, of form: 'package.package.CLASS' with package path in lower-case and class in original case.

flat_properties (): List<Hash<String, BMM_PROPERTY<BMM_TYPE>>>

List of all properties due to current and ancestor classes, keyed by property name.

(effected)

base_class (): BMM_CLASS
Post: Result = Current

Main design class for this type, from which properties etc can be extracted.

(effected)

type_name (): String

Formal string form of the type as per UML.

5.3.11. BMM_PROPERTY Class

Class

BMM_PROPERTY

Description

Model of a property definition within a class definition of an object model. Generic parameter takes care of variants.

Inherit

BMM_MODEL_ELEMENT

Attributes

Signature

Meaning

1..1

name: String

Name of this property in the model.

0..1

is_mandatory: Boolean

True if this propert is mandatory in its class.

0..1

is_computed: Boolean

True if this property is computed rather than stored in objects of this class.

1..1

type: T

Formal type of this property.

0..1

is_im_runtime: Boolean

True if this property is marked with info model 'im_runtime' property.

0..1

is_im_infrastructure: Boolean

True if this property was marked with info model 'im_infrastructure' flag.

Functions

Signature

Meaning

existence (): Multiplicity_interval

Interval form of 0..1, 1..1 etc, generated from is_mandatory.

display_name (): String

Name of this attribute to display in UI.

5.3.12. BMM_CONTAINER_PROPERTY Class

Class

BMM_CONTAINER_PROPERTY

Description

Subtype of BMM_PROPERTY that represents a container type based on one of the inbuilt types List <>, Set <>, Array <>.

Inherit

BMM_PROPERTY

Attributes

Signature

Meaning

0..1

cardinality: Multiplicity_interval

Cardinality of this container.

1..1
(redefined)

type: BMM_CONTAINER_TYPE

Functions

Signature

Meaning

(effected)

display_name (): String

Name of this attribute to display in UI.

5.3.13. BMM_SIMPLE_TYPE Class

Class

BMM_SIMPLE_TYPE

Description

Type reference to a single type i.e. not generic or container type.

Inherit

BMM_TYPE

Attributes

Signature

Meaning

1..1

base_class: BMM_CLASS

The target type; this converts to the first parameter in generic_parameters in BMM_GENERIC_TYPE.

Functions

Signature

Meaning

(effected)

type_name (): String

Return base_class.type_name.

5.3.14. BMM_OPEN_TYPE Class

Class

BMM_OPEN_TYPE

Description

Open type reference to a single type parameter, i.e. typically 'T', 'V', 'K' etc. The parameter must be in the type declaration of the owning BMM_class.

Inherit

BMM_TYPE

Attributes

Signature

Meaning

1..1

generic_constraint: BMM_GENERIC_PARAMETER

The generic constraint, which will be 'Any' if nothing set in original model.

Functions

Signature

Meaning

conformance_type_name (): String

Return generic_constraint.conformance_type_name.

5.3.15. BMM_CONTAINER_TYPE Class

Class

BMM_CONTAINER_TYPE

Description

Type reference that specifies containers with one generic parameter.

Inherit

BMM_TYPE

Attributes

Signature

Meaning

1..1

container_type: BMM_CLASS

The type of the container. This converts to the root_type in BMM_GENERIC_TYPE.

1..1

base_type: BMM_TYPE

The target type; this converts to the first parameter in generic_parameters in BMM_GENERIC_TYPE.

Functions

Signature

Meaning

(effected)

type_name (): String

Return full type name, e.g. 'List<ELEMENT>'.

5.3.16. BMM_GENERIC_TYPE Class

Class

BMM_GENERIC_TYPE

Description

Type reference based on a generic class, e.g. 'HashTable <List <Packet>, String>'

Inherit

BMM_TYPE

Attributes

Signature

Meaning

1..1

generic_parameters: List<BMM_TYPE>

Generic parameters of the root_type in this type specifier. The order must match the order of the owning class’s formal generic parameter declarations.

1..1

base_class: BMM_GENERIC_CLASS

The base class of this type.

Functions

Signature

Meaning

(effected)

type_name (): String

Return the full name of the type including generic parameters, e.g. 'DV_INTERVAL<T>', 'TABLE<List<THING>,String>'.

5.3.17. BMM_GENERIC_PARAMETER Class

Class

BMM_GENERIC_PARAMETER

Description

Definition of a generic parameter in a class definition of a generic type.

Inherit

BMM_TYPE_ELEMENT

Attributes

Signature

Meaning

1..1

name: String

Name of the parameter, e.g. 'T' etc. The name is limited to 1 character and upper-case.

0..1

conforms_to_type: BMM_CLASS

Optional conformance constraint that must be another valid class name.

0..1

inheritance_precursor: BMM_GENERIC_PARAMETER

If set, is the corresponding generic parameter definition in an ancestor class.

Functions

Signature

Meaning

flattened_conforms_to_type (): String

Get any ultimate type conformance constraint on this generic parameter due to inheritance.

effective_conforms_to_type (): BMM_CLASS

Generate ultimate conformance type, which is either from `conforms_to_type' or if not set, 'Any'.

(effected)

type_signature (): String

Signature form of the open type, including constrainer type if there is one, e.g. 'T:Ordered'.

Invariants

Inv_generic_name: name.count = 1 and name.is_upper

5.3.18. BMM_GENERIC_CLASS Class

Class

BMM_GENERIC_CLASS

Description

Definition of a generic class in an object model.

Inherit

BMM_CLASS

Attributes

Signature

Meaning

1..1

generic_parameters: Hash<String,BMM_GENERIC_PARAMETER>

List of generic parameter definitions, keyed by name of generic parameter; these are defined either directly on this class or by the addition of an ancestor class which is generic.

Functions

Signature

Meaning

(effected)

suppliers (): List<String>

Add suppliers from generic parameters.

(effected)

type_signature (): String

Signature form of the type, which for generics includes generic parameter constrainer types E.g. Interval<T:Ordered>

(effected)

type_name (): String

Formal string form of the type as per UML.

5.3.19. BMM_ENUMERATION Class

Class

BMM_ENUMERATION

Description

Definition of an enumeration type. In the BMM system, an 'enumeration' type is understood as an underlying basic type and a set of named constants of that type. It is designed so that the default type is Integer, and the default constants are numbered 0, 1, …​ Optional model elements can be specified to override the values and / or the type.

Inherit

BMM_CLASS

Attributes

Signature

Meaning

0..1

item_names: List<String>

The list of names of the enumeration. If no values are supplied, the integer values 0, 1, 2, …​ are assumed.

0..1

item_values: List<T>

Optional list of specific values. Must be 1:1 with `items_names' list.

1..1

underlying_type_name: String

Name of type any concrete BMM_ENUMERATION_* sub-type is based on, i.e. the name of type bound to 'T' in a declared use of this type.

5.3.20. BMM_ENUMERATION_STRING Class

Class

BMM_ENUMERATION_STRING

Description

String-based enumeration type.

Inherit

BMM_ENUMERATION

Attributes

Signature

Meaning

1..1
(redefined)

underlying_type_name: String = "STRING"

Name of type any concrete BMM_ENUMERATION_* sub-type is based on.

5.3.21. BMM_ENUMERATION_INTEGER Class

Class

BMM_ENUMERATION_INTEGER

Description

Integer-based enumeration type.

Inherit

BMM_ENUMERATION

Attributes

Signature

Meaning

1..1
(redefined)

underlying_type_name: String = "INTEGER"

Name of type any concrete BMM_ENUMERATION_* sub-type is based on.

6. Persistence Package

6.1. Overview

The persistence package, shown below, defines a simplified form of the main BMM model suitable for persisting and human authoring. The openEHR BMM schemas are authored in the P_BMM form of the BMM, using the openEHR ODIN syntax.

BASE bmm.persistence
Figure 12. RM Core Package

The general approach taken in this model is that attributes name bmm_xxx and of type BMM_XXX are derived from the persisted attributes of the P_BMM_XXX classes of this model. In other words, they are in-memory only references to reconstructed instances of BMM_XXX types.

6.2. Class Definitions

6.2.1. P_BMM_MODEL_ELEMENT Class

Class

P_BMM_MODEL_ELEMENT (abstract)

Description

Persistent form of BMM_MODEL_ELEMENT.

Attributes

Signature

Meaning

0..1

documentation: String

Optional documentation of this element.

6.2.2. P_BMM_PACKAGE_CONTAINER Class

Class

P_BMM_PACKAGE_CONTAINER

Description

Persisted form of a model component that contains packages.

Attributes

Signature

Meaning

1..1

packages: Hash<String, P_BMM_PACKAGE>

Package structure as a hierarchy of packages each potentially containing names of classes in that package in the original model.

6.2.3. P_BMM_SCHEMA Class

Class

P_BMM_SCHEMA

Description

Persisted form of BMM_SCHEMA.

Inherit

P_BMM_PACKAGE_CONTAINER, BMM_SCHEMA_CORE

Attributes

Signature

Meaning

1..1

bmm_version: String

Version of BMM model, enabling schema evolution reasoning. Persisted attribute.

0..1

primitive_types: List<P_BMM_CLASS>

Primitive type definitions. Persisted attribute.

0..1

class_definitions: List<P_BMM_CLASS>

Class definitions. Persisted attribute.

0..1

includes: Hash<String,BMM_INCLUDE_SPEC>

Inclusion list, in the form of a hash of individual include specifications, each of which at least specifies the id of another schema, and may specify a namespace via which types from the included schemas are known in this schema. Persisted attribute.

0..1

bmm_schema: BMM_MODEL

Generated by create_bmm_schema from persisted elements.

1..1

state: P_BMM_SCHEMA_STATE

Current processing state; value from P_BMM_SCHEMA_STATE.

Functions

Signature

Meaning

validate_created
Pre_state: state = P_BMM_PACKAGE_STATE.State_created

Do some basic validation post initial creation

  • check that package structure is regular:

    • only top-level packages can have qualified names

    • no top-level package name can be a direct parent or child of another (child package must be declared under the parent)

  • check that all classes are mentioned in the package structure

  • check that all models refer to valid packages

load_finalise
Pre_state: state = P_BMM_PACKAGE_STATE.State_validated_created

Finalisation work:

  • convert packages to canonical form, i.e. full hierarchy with no packages with names like aa.bb.cc

  • set up include processing list

merge (
other: P_BMM_SCHEMA[1]
)

Merge in class and package definitions from `other', except where the current schema already has a definition for the given type or package.

validate

Main validation prior to generation of BMM_SCHEMA; access to `all_schemas' allows errors to be allocated to correct schema.

create_bmm_schema
Pre_state: state = P_BMM_PACKAGE_STATE.State_includes_processed

Generate a BMM_SCHEMA object.

canonical_packages (): P_BMM_PACKAGE

Package structure in which all top-level qualified package names like xx.yy.zz have been expanded out to a hierarchy of BMM_PACKAGE objects.

6.2.4. P_BMM_SCHEMA_STATE Enumeration

Enumeration

P_BMM_SCHEMA_STATE

Description

Enumeration of processing states of a P_BMM_SCHEMA used by creation and validation routines in P_BMM_SCHEMA.

Attributes

Signature

Meaning

State_created

Initial state directly after materialisation.

State_validated_created

Initial validation pass after creation.

State_includes_pending

State of schema processing if there are still included schemas to process.

State_includes_processed

State when all included schemas have been processed.

6.2.5. BMM_INCLUDE_SPEC Class

Class

BMM_INCLUDE_SPEC

Description

Schema inclusion structure.

Attributes

Signature

Meaning

1..1

id: String

Full identifier of the included schema, e.g. "openehr_primitive_types_1.0.2".

6.2.6. P_BMM_PACKAGE Class

Class

P_BMM_PACKAGE

Description

Persisted form of a package as a tree structure whose nodes can contain more packages and/or classes.

Inherit

P_BMM_PACKAGE_CONTAINER, P_BMM_MODEL_ELEMENT

Attributes

Signature

Meaning

1..1

name: String

Name of the package from schema; this name may be qualified if it is a top-level package within the schema, or unqualified. Persistent attribute.

0..1

classes: List<String>

List of classes in this package. Persistent attribute.

0..1

bmm_package_definition: BMM_PACKAGE

BMM_PACKAGE created by create_bmm_package_definition.

Functions

Signature

Meaning

merge (
other: P_BMM_PACKAGE[1]
)

Merge packages and classes from other (from an included P_BMM_SCHEMA) into this package.

create_bmm_package_definition

Generate a BMM_PACKAGE_DEFINITION object and write it to bmm_package_definition.

6.2.7. P_BMM_TYPE Class

Class

P_BMM_TYPE (abstract)

Description

Persistent form of BMM_TYPE.

Inherit

P_BMM_MODEL_ELEMENT

Attributes

Signature

Meaning

0..1

bmm_type: BMM_TYPE

Result of create_bmm_type() call.

Functions

Signature

Meaning

create_bmm_type (
a_schema: BMM_MODEL[1],
a_class_def: BMM_CLASS[1]
)

Create appropriate BMM_ object; defined in descendants.

as_type_string (): String

Formal name of the type for display.

6.2.8. P_BMM_CLASS Class

Class

P_BMM_CLASS

Description

Definition of persistent form of BMM_CLASS for serialisation to ODIN, JSON, XML etc.

Inherit

P_BMM_MODEL_ELEMENT

Attributes

Signature

Meaning

1..1

name: String

Name of the class. Persisted attribute.

0..1

ancestors: List<String>

List of immediate inheritance parents. Persisted attribute.

0..1

properties: Hash<String,P_BMM_PROPERTY>

List of attributes defined in this class. Persistent attribute.

0..1

is_abstract: Boolean

True if this is an abstract type. Persisted attribute.

0..1

is_override: Boolean

True if this class definition overrides one found in an included schema.

0..1

generic_parameter_defs: Hash<String,P_BMM_GENERIC_PARAMETER>

List of generic parameter definitions. Persisted attribute.

1..1

source_schema_id: String

Reference to original source schema defining this class. Set during BMM_SCHEMA materialise. Useful for GUI tools to enable user to edit the schema file containing a given class (i.e. taking into account that a class may be in any of the schemas in a schema inclusion hierarchy).

0..1

bmm_class: BMM_CLASS

BMM_CLASS object build by create_bmm_class_definition and populate_bmm_class_definition.

1..1

uid: Integer

Unique id generated for later comparison during merging, in order to detect if two classes are the same. Assigned in post-load processing.

Functions

Signature

Meaning

is_generic (): Boolean
Post: Result := generic_parameter_defs /= Void

True if this class is a generic class.

create_bmm_class

Create bmm_class_definition.

populate_bmm_class (
a_bmm_schema: BMM_MODEL[1]
)

Add remaining model elements from Current to `bmm_class_definition'.

6.2.9. P_BMM_GENERIC_PARAMETER Class

Class

P_BMM_GENERIC_PARAMETER

Description

Persistent form of BMM_GENERIC_PARAMETER.

Inherit

P_BMM_MODEL_ELEMENT

Attributes

Signature

Meaning

1..1

name: String

Name of the parameter, e.g. 'T' etc. Persisted attribute. Name is limited to 1 character, upper case.

0..1

conforms_to_type: String

Optional conformance constraint - the name of a type to which a concrete substitution of this generic parameter must conform. Persisted attribute.

0..1

bmm_generic_parameter: BMM_GENERIC_PARAMETER

BMM_GENERIC_PARAMETER created by create_bmm_generic_parameter.

Functions

Signature

Meaning

create_bmm_generic_parameter (
a_bmm_schema: BMM_MODEL[1]
)

Create bmm_generic_parameter.

Invariants

Inv_generic_name: name.count = 1 and name.is_upper

6.2.10. P_BMM_PROPERTY Class

Class

P_BMM_PROPERTY (abstract)

Description

Persistent form of BMM_PROPERTY.

Inherit

P_BMM_MODEL_ELEMENT

Attributes

Signature

Meaning

1..1

name: String

Name of this property within its class. Persisted attribute.

0..1

is_mandatory: Boolean

True if this property is mandatory in its class. Persisted attribute.

0..1

is_computed: Boolean

True if this property is computed rather than stored in objects of this class. Persisted Attribute.

0..1

is_im_infrastructure: Boolean

True if this property is info model 'infrastructure' rather than 'data'. Persisted attribute.

0..1

is_im_runtime: Boolean

True if this property is info model 'runtime' settable property. Persisted attribute.

0..1

type_def: P_BMM_TYPE

Type definition of this property, if not a simple String type reference. Persisted attribute.

0..1

bmm_property: BMM_PROPERTY

BMM_PROPERTY created by create_bmm_property_definition.

Functions

Signature

Meaning

create_bmm_property (
a_bmm_schema: BMM_MODEL[1],
a_class_def: BMM_CLASS[1]
)

Create bmm_property_definition from P_BMM_ parts.

6.2.11. P_BMM_SIMPLE_TYPE Class

Class

P_BMM_SIMPLE_TYPE

Description

Persistent form of BMM_SIMPLE_TYPE.

Inherit

P_BMM_TYPE

Attributes

Signature

Meaning

1..1

type: String

Name of type - must be a simple class name.

0..1
(redefined)

bmm_type: BMM_SIMPLE_TYPE

Result of create_bmm_type() call.

6.2.12. P_BMM_OPEN_TYPE Class

Class

P_BMM_OPEN_TYPE

Description

Persistent form of BMM_OPEN_TYPE.

Inherit

P_BMM_TYPE

Attributes

Signature

Meaning

1..1

type: String

Simple type parameter as a single letter like 'T', 'G' etc.

0..1
(redefined)

bmm_type: BMM_OPEN_TYPE

Result of create_bmm_type() call.

6.2.13. P_BMM_GENERIC_TYPE Class

Class

P_BMM_GENERIC_TYPE

Description

Persistent form of BMM_GENERIC_TYPE.

Inherit

P_BMM_TYPE

Attributes

Signature

Meaning

1..1

root_type: String

Root type of this generic type, e.g. 'Interval' in 'Interval<Integer>'.

1..1

generic_parameter_defs: List<P_BMM_TYPE>

Generic parameters of the root_type in this type specifier if non-simple types. The order must match the order of the owning class’s formal generic parameter declarations. Persistent attribute.

0..1

generic_parameters: List<String>

Generic parameters of the root_type in this type specifier, if simple types. The order must match the order of the owning class’s formal generic parameter declarations. Persistent attribute.

0..1
(redefined)

bmm_type: BMM_GENERIC_TYPE

Result of create_bmm_type() call.

Functions

Signature

Meaning

generic_parameter_refs (): List<P_BMM_TYPE>

Generic parameters of the root_type in this type specifier. The order must match the order of the owning class’s formal generic parameter declarations

6.2.14. P_BMM_CONTAINER_TYPE Class

Class

P_BMM_CONTAINER_TYPE

Description

Persistent form of BMM_CONTAINER_TYPE.

Inherit

P_BMM_TYPE

Attributes

Signature

Meaning

1..1

container_type: String

The type of the container. This converts to the root_type in BMM_GENERIC_TYPE. Persisted attribute.

1..1

type_def: P_BMM_TYPE

Type definition of `type', if not a simple String type reference. Persisted attribute.

0..1

type: String

The target type; this converts to the first parameter in generic_parameters in BMM_GENERIC_TYPE. Persisted attribute.

0..1
(redefined)

bmm_type: BMM_CONTAINER_TYPE

Result of create_bmm_type() call.

Functions

Signature

Meaning

type_ref (): P_BMM_TYPE

The target type; this converts to the first parameter in generic_parameters in BMM_GENERIC_TYPE. Persisted attribute.

6.2.15. P_BMM_SINGLE_PROPERTY Class

Class

P_BMM_SINGLE_PROPERTY

Description

Persistent form of BMM_SINGLE_PROPERTY.

Inherit

P_BMM_PROPERTY

Attributes

Signature

Meaning

0..1

type: String

If the type is a simple type, then this attribute will hold the type name. If the type is a container or generic, then type_ref will hold the type definition. The resulting type is generated in type_def.

0..1

type_ref: P_BMM_SIMPLE_TYPE

Type definition of this property, if not a simple String type reference. Can be used in schema instead of `type', but less readable. Persisted attribute.

0..1
(redefined)

bmm_property: BMM_PROPERTY<BMM_SIMPLE_TYPE>

BMM_PROPERTY created by create_bmm_property_definition.

Functions

Signature

Meaning

type_def (): P_BMM_SIMPLE_TYPE

Generate `type_ref' from `type' and save.

6.2.16. P_BMM_SINGLE_PROPERTY_OPEN Class

Class

P_BMM_SINGLE_PROPERTY_OPEN

Description

Persistent form of a BMM_SINGLE_PROPERTY_OPEN.

Inherit

P_BMM_PROPERTY

Attributes

Signature

Meaning

0..1

type_ref: P_BMM_OPEN_TYPE

Type definition of this property, if not a simple String type reference. Persistent attribute.

0..1

type: String

Type definition of this property, if a simple String type reference. Really we should use `type_def' to be regular in the schema, but that makes the schema more wordy and less clear. So we use this persisted String value, and compute the `type_def' on the fly. Persisted attribute.

0..1
(redefined)

bmm_property: BMM_PROPERTY<BMM_OPEN_TYPE>

BMM_PROPERTY created by create_bmm_property_definition.

Functions

Signature

Meaning

type_def (): P_BMM_OPEN_TYPE

Generate `type_ref' from `type' and save.

6.2.17. P_BMM_GENERIC_PROPERTY Class

Class

P_BMM_GENERIC_PROPERTY

Description

Persistent form of BMM_GENERIC_PROPERTY.

Inherit

P_BMM_PROPERTY

Attributes

Signature

Meaning

0..1
(redefined)

type_def: P_BMM_GENERIC_TYPE

Type definition of this property, if not a simple String type reference. Persistent attribute.

0..1
(redefined)

bmm_property: BMM_PROPERTY<BMM_GENERIC_TYPE>

BMM_PROPERTY created by create_bmm_property_definition.

6.2.18. P_BMM_CONTAINER_PROPERTY Class

Class

P_BMM_CONTAINER_PROPERTY

Description

Persistent form of BMM_CONTAINER_PROPERTY.

Inherit

P_BMM_PROPERTY

Attributes

Signature

Meaning

0..1

cardinality: Interval<Integer>

Cardinality of this property in its class. Persistent attribute.

0..1
(redefined)

type_def: P_BMM_CONTAINER_TYPE

Type definition of this property, if not a simple String type reference. Persistent attribute.

0..1
(redefined)

bmm_property: BMM_CONTAINER_PROPERTY

BMM_PROPERTY created by create_bmm_property.

Functions

Signature

Meaning

(effected)

create_bmm_property (
a_bmm_schema: BMM_MODEL[1],
a_class_def: BMM_CLASS[1]
)

Create bmm_property_definition.

6.2.19. P_BMM_ENUMERATION Class

Class

P_BMM_ENUMERATION

Description

Persistent form of BMM_ENUMERATION attributes.

Inherit

P_BMM_CLASS

Attributes

Signature

Meaning

0..1

item_names: List<String>

0..1

item_values: List<Any>

0..1
(redefined)

bmm_class: BMM_ENUMERATION

BMM_CLASS object build by create_bmm_class_definition and populate_bmm_class_definition.

6.2.20. P_BMM_ENUMERATION_STRING Class

Class

P_BMM_ENUMERATION_STRING

Description

Persistent form of BMM_ENUMERATION_STRING.

Inherit

P_BMM_ENUMERATION

Attributes

Signature

Meaning

0..1
(redefined)

bmm_class: BMM_ENUMERATION_STRING

BMM_CLASS object build by create_bmm_class_definition and populate_bmm_class_definition.

6.2.21. P_BMM_ENUMERATION_INTEGER Class

Class

P_BMM_ENUMERATION_INTEGER

Description

Persistent form of an instance of BMM_ENUMERATION_INTEGER.

Inherit

P_BMM_ENUMERATION

Attributes

Signature

Meaning

0..1
(redefined)

bmm_class: BMM_ENUMERATION_INTEGER

BMM_CLASS object build by create_bmm_class_definition and populate_bmm_class_definition.

7. BMM Syntax

7.1. Overview

A BMM schema is normally written in the ODIN syntax, although any other serialisation supporting typed object models may be used, including JSON (with type markers), YAML, XML etc. The ODIN form is described here. The structures are direct ODIN serialisations of the P_BMM_XXX classes in the persistence package.

7.2. Header Items

The following shows the header items of a BMM schema, which correspond to the 'persistent' attributes of the class P_BMM_SCHEMA.

------------------------------------------------------
-- BMM version on which these schemas are based.
------------------------------------------------------
bmm_version = <"2.1">


------------------------------------------------------
-- schema identification
-- (schema_id computed as <rm_publisher>_<schema_name>_<rm_release>)
------------------------------------------------------
rm_publisher = <"openehr">
schema_name = <"adltest">
rm_release = <"1.0.2">

------------------------------------------------------
-- schema documentation
------------------------------------------------------
schema_revision = <"1.0.36">
schema_lifecycle_state = <"stable">
schema_description = <"openEHR schema to support test archetypes">

7.3. Inclusions

includes = <
    ["1"] = <
        id = <"openehr_basic_types_1.0.2">
    >
>

Three archetyping related attributes can be set below, but would not usually all in the same schema. Only the archetype_rm_closure_packages variable is needed in at least one schema, usually the top-most one.

archetype_parent_class defines a base class from the Reference Model that provides archetyping capability in RM data structures. It is optional, and there need be no such class in the RM. In the openEHR and 13606 RMs, this class exists, (LOCATABLE, and RECORD_COMPONENT respectively). Defining it here has the effect in tools that the class tree under which archetypes are arranged contains only RM classes inheriting from this class, e.g. LOCATABLE classes in the case of openEHR. If nothing is set here, all classes in the RM are assumed as candidates for archetypes. This attribute, if defined, must be defined in the same schema that defines the referenced class.

archetype_data_value_parent_class defines a base class from the Reference Model whose descendants are considered to be 'logical data types' (i.e. of some higher level than the built-in primitive types String, Integer etc). This attribute is optional, even if the RM does have such a class, and is only used to help tooling provide more intelligent display, e.g. in statistical reports.

This attribute, if defined, must be defined in the same schema that defines the referenced class.

If archetype_parent_class is not set, designate a class whose descendants should be made visible in tree and grid renderings of the archetype definition. For openEHR and CEN this class is normally the same as the archetype_parent_class, i.e. LOCATABLE and RECORD_COMPONENT respectively. It is typically set for CEN, because archetype_parent_class may not be stated, due to demographic types not inheriting from it. The effect of this attribute in visualisation is to generate the most natural tree or grid-based view of an archetype definition, from the semantic viewpoint.

archetype_rm_closure_packages defines the package or packages that are considered the archetyping namespace used in archetype multi-axial ids. For example, in openEHR, an archetype is identified by an id of the form openEHR-EHR-OBSERVATION.some_obs.vN. The 'EHR' in the above is an 'RM package closure', i.e. the name of an RM package whose class closure by reachability provides the set of classes that may be archetyped in the 'EHR' namespace. The reason for this is somewhat subtle: consider that if you want archetypes based on classes defined directly within a package P, and you also define these archetypes that re-use other archetypes based on more basic types like openEHR’s CLUSTER or similar (typically not defined in the head package), then you will inevitably have archetypes based on CLUSTER only for use with EHR archetypes e.g. archetypes based on OBSERVATION. However, you may well create archetypes based on CLUSTER only for use with e.g. top-level archetypes from the demographic package. The archetype_rm_closure_packages setting is used to define the root id namespaces for archetypes, allowing low-level archetypes to be designated for use with one or other high-level archetype. E.g. openEHR-EHR-CLUSTER.bp_position.v1 would be used only with openEHR-EHR-OBSERVATION.bp_measurement.vX, or similar, and most likely not with any openEHR-DEMOGRAPHIC-XXXX.yyyy.vN archetype. Note that in openEHR, there is nothing to prevent such cross-namespace reuse - it is just a design guideline. This attribute, must be defined in the same schema that defines the referenced package(s).

------------------------------------------------------
-- archetyping
-- override archetype parent class from included schema
------------------------------------------------------
archetype_parent_class = <"CLASS_NAME">
archetype_data_value_parent_class = <"CLASS_NAME">
archetype_visualise_descendants_of = <"CLASS_NAME">
archetype_rm_closure_packages = <"org.openehr.test_pkg", ...>

7.5. Package Definition

The packages definition should be self-explanatory: just name the classes and packages in a recursive fashion.

Note
only top-level package ids can be paths (i.e. contain the '.' character)
Note
only classes defined in the same schema can be referenced in the package section in that schema.
Note
make sure that the ODIN 'keys' are the same as the 'name' attributes in each block.
packages = <
    ["org.openehr.test_pkg"] = <
        name = <"org.openehr.test_pkg">
        classes = <"WHOLE", "SOME_TYPE", "BOOK", "CHAPTER", "ENTRY", "CAR", "CAR_BODY">
    >
>

7.6. Primitive Types

Definitions for primitive types in a BMM schema are just normal class definitions within a primitive_types block. Types that are included here are usually types corresonding to primitives in target programming languages, XML schema or other downstream technologies. These types can be be detected as primitive types by tools, but otherwise are processed in the same way as types defined in the main class_definitions group.

Note
unlike UML, all container types such as List<T>, Hash<V,K> etc are exlicit in a BMM schema, and consequently, such types are normally defined (including with generic parameters) in a BMM schema.
primitive_types = <
    ["Any"] = <
        name = <"Any">
        is_abstract = <True>
    >
    ["Ordered"] = <
        name = <"Ordered">
        is_abstract = <True>
        ancestors = <"Any", ...>
    >
>

7.7. Class Definitions

The main group of class definitions in a schema occurs within the class_definitions block. Each definition is a keyed ODIN object block correspnding to a serialised P_BMM_CLASS object, where the key is the class name. Since name is a BMM meta-model attribute, the class definition always contains its ODIN key.

The possible class-level meta-properties:

  • name - class name - any capitalisation can be used, usually one of CamelCase or so-called UPPER_SNAKE_CASE;

  • ancestors - states classes from which this class inherits, as an ODIN String list;

  • is_abstract - indicates that the class cannot be instantiated directly;

  • properties - ODIN block containing definitions consisting of P_BMM_PROPERTY descendants, keyed by property name.

7.7.1. Simple Classes

Simple classes are those whose type is the same as the class, as opposed to generic classes and enumerated types (see below).

class_definitions = <
    ["ITEM"] = <
        name = <"ITEM">
        ancestors = <"Any", ...>
        is_abstract = <True>
        properties = <
            -- properties here
        >
    >
    -- more classes here
>
7.7.1.1. Class properties

Class properties from the original model are expressed using ODIN object blocks keyed by property name. Since there are multiple possible descendants of P_BMM_PROPERTY, ODIN type markers must be used to indicate which subtypes is used in each case.

The possible BMM meta-properties of all property types are as follows:

  • name - String name of the property in its owning class in the model - use camelCase or snake_case as appropriate;

  • is_mandatory - Boolean flag indicating whether the property is mandatory within its class.

The following shows the class ELEMENT with two properties null_flavour and value of BMM meta-type P_BMM_SINGLE_PROPERTY, i.e. corresponding to a single-valued attribute from the original model.

    ["ELEMENT"] = <
        name = <"ELEMENT">
        ancestors = <"ITEM", ...>
        properties = <
            ["null_flavour"] = (P_BMM_SINGLE_PROPERTY) <
                name = <"null_flavour">
                type = <"DV_CODED_TEXT">
                is_mandatory = <True>
            >
            ["value"] = (P_BMM_SINGLE_PROPERTY) <
                name = <"value">
                type = <"DATA_VALUE">
            >
        >
    >
7.7.1.2. Container Properties

The following is a P_BMM_CONTAINER_PROPERTY definition for the model property items: List<ITEM> in the ELEMENT class. The type is expressed in the type_def part which indicates the type of the container, which must be defined elsewhere in the schema, typically in the primitive types. The optional cardinality meta-property indicates cardinality of the container, and is expressed as a ODIN range. The default is |0..*|.

    ["ELEMENT"] = <
        name = <"ELEMENT">
        ancestors = <"ITEM", ...>
        properties = <
            ["items"] = (P_BMM_CONTAINER_PROPERTY) <
                name = <"items">
                type_def = <
                    container_type = <"List">
                    type = <"ITEM">
                >
                cardinality = <|>=1|>
                is_mandatory = <True>
            >
        >
    >

7.7.2. Generic Classes

Generic classes are those that have one or more substitutable generic type parameters. Such classes are therefore type generators, since actual types are formed by substitution of concrete types (typically simple classes) for the formal type parameters. The following example shows a generic class Interval with generic_parameter_defs of T which is constrained to conform to the type Ordered. This structure defineds the type Interval<T→Ordered>, with the same meaning as UML and programming languages supporting generic (templated) types.

Generic classes will normally contain one or more properties whose formal type is the generic type parameter, i.e. the T in this example, as is the case below where the model properties lower and upper are both declared to be of type T. This declaration necessitates the use of the BMM meta-type P_BMM_SINGLE_PROPERTY_OPEN.

    ["Interval"] = <
        name = <"Interval">
        ancestors = <"Any", ...>
        generic_parameter_defs = <
            ["T"] = <
                name = <"T">
                conforms_to_type = <"Ordered">
            >
        >
        properties = <
            ["lower"] = (P_BMM_SINGLE_PROPERTY_OPEN) <
                name = <"lower">
                type = <"T">
            >
            ["upper"] = (P_BMM_SINGLE_PROPERTY_OPEN) <
                name = <"upper">
                type = <"T">
            >
        >
    >

Given the presence of generic classes in a BMM schema, derived generic types can be used as the type of properties in other classes, for which the BMM meta-type P_BMM_GENERIC_PROPERTY is used. The folowing example shows first a generic class DV_INTERVAL defined in a similar way to Interval above, and then a class SOME_TYPE containing the property qty_interval_attr whose model type is DV_INTERVAL<DV_QUANTITY>. In the latter type declaration, the DV_INTERVAL is the root_type and DV_INTERVAL the generic_parameter.

    ["DV_INTERVAL"] = <
        name = <"DV_INTERVAL">
        ancestors = <"Interval", "DATA_VALUE">
        generic_parameter_defs = <
            ["T"] = <
                name = <"T">
                conforms_to_type = <"DV_ORDERED">
            >
        >
    >

    ["SOME_TYPE"] = <
        name = <"SOME_TYPE">
        ancestors = <"Any", ...>
        properties = <
            ["qty_interval_attr"] = (P_BMM_GENERIC_PROPERTY) <
                name = <"qty_interval_attr">
                type_def = <
                    root_type = <"DV_INTERVAL">
                    generic_parameters = <"DV_QUANTITY">
                >
            >
        >
    >

Type declarations can also be nested types, for example and container followed by a generic type. In the following the careProvider attribute is declared to be of model type List<ResourceReference<Party>>. Any level of type nesting is allowed.

    ["Patient"] = <
        name = <"Patient">
        ancestors = <"Any", ...>
        properties = <
            ["careProvider"] = (P_BMM_CONTAINER_PROPERTY) <
                name = <"careProvider">
                type_def = <
                    container_type = <"List">
                    type_def = (P_BMM_GENERIC_TYPE) <
                        root_type = <"ResourceReference">
                        generic_parameters = <"Party">
                    >
                >
                cardinality = <|>=0|>
            >
        >
    >

The following property definition is based on the class REFERENCE_RANGE, and in this case, has a generic parameter type that is another generic type: DV_INTERVAL<DV_QUANTITY>. To express this, we use generic_parameter_defs instead of just generic_parameters to specify a type structure, rather than just a string type name. Note that generic_parameter_defs is a logical list in general, since there can always be more than one generic parameter, i.e. 'T', 'U' etc, even though it is most commonly just one. Accordingly, the usual ODIN keyed hash structure is used with each member being keyed by a generic parameter name, below ["T"].

    ["REFERENCE_RANGE"] = <
        name = <"REFERENCE_RANGE">
        ancestors = <"Any", ...>
        generic_parameter_defs = <
            ["T"] = <
                name = <"T">
                conforms_to_type = <"DV_ORDERED">
            >
        >
        properties = <
            ["range"] = (P_BMM_SINGLE_PROPERTY) <
                name = <"range">
                type = <"DV_INTERVAL">
                is_mandatory = <True>
            >
        >
    >

    ["RANGE_OF_INTERVAL_OF_QUANTITY"] = <
        name = <"RANGE_OF_INTERVAL_OF_QUANTITY">
        ancestors = <"Any", ...>
        properties = <
            ["range"] = (P_BMM_GENERIC_PROPERTY) <
                name = <"range">
                type_def = <
                    root_type = <"REFERENCE_RANGE">
                    generic_parameter_defs = <
                        ["T"] = (P_BMM_GENERIC_TYPE) <
                            root_type = <"DV_INTERVAL">
                            generic_parameters = <"DV_QUANTITY">
                        >
                    >
                >
            >
        >

The following example just does the same as the one above, but shows an (unrealistic) but legal case of multiple, mixed, nested generic parameters corresponding to the model property definition range: REFERENCE_RANGE<DV_INTERVAL<DV_QUANTITY>, Integer, List<DV_QUANTITY>, List<DV_INTERVAL<DV_QUANTITY>>>. The rules for expressing types is clearly illustrated:

  • use 'type' for simple string type refs; use type_def for structure types;

  • within P_BMM_GENERIC_TYPE, use generic_parameters for a list of string types;

  • use generic_parameter_defs for a list of complex type references.

    ["CRAZY_TYPE"] = <
        name = <"CRAZY_TYPE">
        ancestors = <"Any", ...>
        properties = <
            ["range"] = (P_BMM_GENERIC_PROPERTY) <
                name = <"range">
                type_def = <
                    root_type = <"REFERENCE_RANGE">
                    generic_parameter_defs = <
                        ["T"] = (P_BMM_GENERIC_TYPE) <
                            root_type = <"DV_INTERVAL">
                            generic_parameters = <"DV_QUANTITY">
                        >
                        ["U"] = (P_BMM_SIMPLE_TYPE) <
                            type = <"Integer">
                        >
                        ["V"] = (P_BMM_CONTAINER_TYPE) <
                            type = <"DV_QUANTITY">
                            container_type = <"List">
                        >
                        ["W"] = (P_BMM_CONTAINER_TYPE) <
                            type_def = (P_BMM_GENERIC_TYPE) <
                                root_type = <"DV_INTERVAL">
                                generic_parameters = <"DV_QUANTITY">
                            >
                            container_type = <"List">
                        >
                    >
                >
            >
        >
    >

7.7.3. Enumerated Types

In a BMM schema, enumerated types are treated as constrained forms of standard types with open ranges, currently only Integer and String. They are accordingly represented using class definitions of the meta-types P_BMM_ENUMERATION_INTEGER and P_BMM_ENUMERATION_STRING respectively. In either case, just names (items_names meta-property) or both names and values (item_values meta-property) can be specified.

The following example shows two variants of am enumerated type based on the Integer primitive type.

    ["PROPORTION_KIND"] = (P_BMM_ENUMERATION_INTEGER) <
        name = <"PROPORTION_KIND">
        ancestors = <"Integer", ...>
        item_names = <"pk_ratio", "pk_unitary", "pk_percent", "pk_fraction", "pk_integer_fraction">
    >

    ["PROPORTION_KIND_2"] = (P_BMM_ENUMERATION_INTEGER) <
        name = <"PROPORTION_KIND_2">
        ancestors = <"Integer", ...>
        item_names = <"pk_ratio", "pk_unitary", "pk_percent", "pk_fraction", "pk_integer_fraction">
        item_values = <0, 1001, 1002, 1003>
    >

The following example shows two similar examples based on String.

    ["MAGNITUDE_STATUS"] = (P_BMM_ENUMERATION_STRING) <
        name = <"MAGNITUDE_STATUS">
        ancestors = <"String", ...>
        item_names = <"le", "ge", "eq", "approx_eq">
        item_values = <"<=", ">=", "=", "~">
    >

    ["NAME_PART"] = (P_BMM_ENUMERATION_STRING) <
        name = <"NAME_PART">
        ancestors = <"String", ...>
        item_names = <"FIRST", "MIDDLE", "LAST">
    >

References

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. See https://www.iso.org/standard/40784.html.

  12. [ISO_13606-2] ISO 13606-2 - Electronic healthcare record communication - Part 2: Domain term list. See https://www.iso.org/standard/50119.html.

  13. [ISO_13606-3] ISO 13606-3 - Electronic healthcare record communication - Part 3: Distribution rules. See https://www.iso.org/standard/50120.html.

  14. [ISO_13606-4] ISO 13606-4 - Electronic Healthcare Record Communication standard Part 4: Messages for the exchange of information. See https://www.iso.org/standard/50121.html.

  15. [ISO_18308] Schloeffel P. (Editor). Requirements for an Electronic Health Record Reference Architecture. See https://www.iso.org/standard/52823.html.

  16. [ISO_20514] ISO. The Integrated Care EHR. See https://www.iso.org/standard/39525.html .

  17. [ISO_13940] ISO. Health informatics - System of concepts to support continuity of care. See https://www.iso.org/standard/58102.html.

  18. [ISO_22600] ISO. Health informatics - Privilege management and access control. See https://www.iso.org/standard/62653.html.

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 .