openEHR logo

Archetype Object Model 2 (AOM2) Specification

Issuer: openEHR Specification Program

Release: latest

Status: TRIAL

Revision: [latest_issue]

Date: [latest_issue_date]

Keywords: EHR, ADL, AOM, health records, archetypes, constraint language, 13606

openEHR components
© 2004 - 2017 The openEHR Foundation

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

Licence

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

Support

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

Amendment Record

Issue Details Raiser, Implementer Completed

2.0.7

SPECAM-43Correct C_TERMINOLOGY_CODE.c_conforms_to to handle no parent value-set (Corrects SPECPR-243)

P Bos

02 Nov 2017

SPECAM-42Adjust references to BASE packages foundation_types, base_types and resource types.

T Beale

21 Sep 2017

AM Release-2.0.6

2.0.6

Adjust C_ATTRIBUTE.any_allowed to have the post-condition Result = children.is_empty and not is_prohibited.

T Beale

15 Jun 2016

Correct ambiguity between ADL and AOM specs concerning duration fractional seconds - remove C_DURATION.fractional_seconds_allowed (SPECPR-188).

B Verhees

10 Jun 2016

Add more precise specification of type matching under the 'Object Node Types' section, including for primitive types. Add rm_primitive_type_equivalences property to AOM_PROFILE to accommodate primitive type matching rules.

T Beale

08 Jun 2016

SPECAM-40. Correct VSONT validity rule to say that C_COMPLEX_OBJECT redefinition by C_PRIMITIVE_OBJECT is not valid.

T Beale

02 Jun 2016

Fix typo in section 6.2.1 to do with id-code redefinition in specialised archetype.

C Nanjo

30 May 2016

Rename ARCHETYPE_TERMINOLOGY.parent_archetype to owner_archetype. (reported in SPECPR-193).

B Verhees

18 May 2016

Remove references to openEHR RM. Add assumed_types package to make spec standalone;
Change reference to openEHR language codes to ISO 639 codes.

ISO TC215

Change Rules section to document re-use of new openEHR Expression Language and Model.
Change the types constrained by C_DATE etc to Date etc, instead of ISO8601_DATE.
Update occurrences inferencing rules in section 4.

T Beale

11 May 2016

SPECBASE-4. Change order of type parameters in Hash<V,K> type to Hash<K,V>.

D Boscá

13 Apr 2016

Correct ASSERTION.variables association to refer to VARIABLE_DECLARATION.
Add RULE_ELEMENT class table to specification (reported in SPECPR-160)
Correct CARDINALITY.is_set documentation (reported in SPECPR-147).
Add missing type of String to ARCHETYPE_TERM.code. (reported in SPECPR-162).

B Verhees

05 Apr 2016

2.0.5

Make AUTHORED_RESOURCE.uid and AUTHORED_ARCHETYPE.build_uid UUIDs rather than any kind of UID.

T Beale

18 Jan 2016

Add P_ serialisation model and template sections.

T Beale

31 Aug 2015

2.0.0

Refactor ARCHETYPE and ARCHETYPE_TERMINOLOGY models, in order to simplify: remove differential and flat forms of classes.
Split ARCHETYPE into two classes, with AUTHORED_ARCHETYPE as a new class that inherits from AUTHORED_RESOURCE .

T Beale

04 Jan 2015

Remove VDSSR , VSUNC ; add VDSSID , VARXID . Replace +u (unstable) version modifier with semver.org standard -alpha. Remove overview material to new Archetypes: Technical Overview specification.

T Beale,
I McNicoll,
S Garde

12 Nov 2014

Remove ARCHETYPE.provenance_id attribute.

H Solbrig,
T Beale

08 Oct 2014

Correct spelling of licence to international English; rename ARCHETYPE.urn to provenance_id.

S Garde,
I McNicoll

29 Sep 2014

Modified C_ARCHETYPE_ROOT to have an id-code in all cases.
Add error VSONPO , VSONPT: specialised archetype object node prohibited occurrences validity.
Added support for constraints on enumerated types.

CIMI,
P Langford,
T Beale

18 Jul 2014

Convert ARCHETYPE.uid to urn: URN.
Rename ARCHETYPE.commit_number to build_count .

I McNicoll,
S Garde,
T Beale

04 Jun 2014

Make VACMCL a warning WACMCL .

D Moner

07 Apr 2014

Renamed ARCHETYPE_INTERNAL_REF to C_OBJECT_PROXY .
SPECAM-9. Renamed ontology section to terminology and simplified.
Remove CONSTRAINT_REF, C_REFERENCE_OBJECT types;
SPECAM-2. Introduce new archetype structured identification system;
SPECAM-28. Add IHTSDO standard terminology URIs to ADL and AOM.

T Beale
H Solbrig

09 Mar 2014

Detailed Technical Review.

H Solbrig

21 Nov 2013

Remove C_DOMAIN_TYPE ;
SPECAM-27. Merge C_PRIMITIVE_OBJECT and C_PRIMITIVE;
Add support for tuple constraints, replacing ADL 1.4 special Ordinal and Quantity constrainer types;
Add new primitive type C_TERMINOLOGY_CODE .
Added VSONIF, removed VSONCI (dup of VSONI).

H Solbrig
T Beale

20 Aug 2013

SPECAM-22. Limit assumed_value to C_PRIMITIVE_OBJECT.

T Beale,
R Chen

14 Jan 2013

SPECAM-32. Remove C_SINGLE_ATTRIBUTE and C_MULTIPLE_ATTRIBUTE classes.

T Beale,
S Garde,
S Kobayashi,
D Moner,
T Beale

15 Dec 2011

SPECAM-26. Add any_allowed function to ARCHETYPE_SLOT.

T Beale

18 Aug 2010

SPECAM-8. Add specialisation semantics to ADL and AOM. Add various attributes and functions to ARCHETYPE_CONSTRAINT descendant classes.

  • move C_PRIMITIVE.assumed_value to attribute slot in UML

  • rename C_DEFINED_OBJECT.default_value function to prototype_value

  • correct assumed_value definition to be like prototype_value; remove its entry from all of the C_PRIMITIVE subtypes

  • convert BOOLEAN flag representation of patterns to functions and add a String data member for the pattern value, thus matching the XSDs and ADL

  • add ARCHETYPE.is_template attribute.

  • add ARCHETYPE.is_component attribute.

  • allow computed as well as stored attributes.

  • make ONTOLOGY.terminologies_available computed.

T Beale

10 Dec 2009

SPECAM-1. Change Date, Time etc classes in AOM to ISO8601_DATE , ISO8601_TIME etc from Support IM.

T Beale

20 Jul 2009

SPECAM-10. Convert Interval<Integer> to MULTIPLICITY_INTERVAL to simplify specification and implementation.

T Beale

SPECAM-5. Archetype slot regular expressions should cover whole identifier. Added C_STRING.is_pattern .

A Flinton

SPECAM-7. Make existence, occurrences and cardinality optional in AOM.

S Heard

SPECAM-16. Add validity rules to ARCHETYPE_TERMINOLOGY .
SPECAM-11. ARCHETYPE_CONSTRAINT adjustments.
SPECAM-17. Add template object model to AM.

  • Add is_exhaustive attribute to ARCHETYPE_SLOT .

  • Add is_template attribute to ARCHETYPE .

  • Add terminology_extracts to ARCHETYPE_TERMINOLOGY .

T Beale

R E L E A S E     1.0.2

2.0.2

SPEC-257. Correct minor typos and clarify text. Correct reversed definitions of is_bag and is_set in CARDINALITY class.

C Ma,
R Chen,
T Cook

20 Nov 2008

SPEC-251. Allow both pattern and interval constraint on Duration in Archetypes. Add pattern attribute to C_DURATION class.

S Heard

R E L E A S E     1.0.1

2.0.1

SPEC-200. Correct Release 1.0 typographical errors. Table for missed class ASSERTION_VARIABLE added. Assumed_value assertions corrected; standard_representation function corrected. Added missed adl_version , concept rename from SPEC-153.

D Lloyd,
P Pazos,
R Chen,
C Ma

20 Mar 2007

SPEC-216: Allow mixture of W, D etc in ISO8601 Duration (deviation from standard).

S Heard

SPEC-219: Use constants instead of literals to refer to terminology in RM.

R Chen

SPEC-232. Relax validity invariant on CONSTRAINT_REF .

R Chen

SPEC-233: Define semantics for occurrences on ARCHETYPE_INTERNAL_REF .

K Atalag

SPEC-234: Correct functional semantics of AOM constraint model package.

T Beale

SPEC-245: Allow term bindings to paths in archetypes.

S Heard

R E L E A S E     1.0

2.0

SPEC-153. Synchronise ADL and AOM attribute naming. SPEC-178. Add Template Object Model to AM. Text changes only. SPEC-167. Add AUTHORED_RESOURCE class. Remove description package to resource package in Common IM.

T Beale

10 Nov 2005

R E L E A S E     0.96

0.6

SPEC-134. Correct numerous documentation errors in AOM. Including cut and paste error in TRANSLATION_DETAILS class in Archetype package. Corrected hyperlinks in Section 2.3.

D Lloyd

20 Jun 2005

SPEC-142. Update ADL grammar to support assumed values. Changed C_PRIMITIVE and C_DOMAIN_TYPE .

S Heard,
T Beale

SPEC-146: Alterations to am.archetype.description from CEN MetaKnow

D Kalra

SPEC-138. Archetype-level assertions.

T Beale

SPEC-157. Fix names of OPERATOR_KIND class attributes

T Beale

R E L E A S E     0.95

0.5.1

Corrected documentation error - return type of ARCHETYPE_CONSTRAINT . has_path
add optionality markers to Primitive types UML diagram.
Removed erroneous aggregation marker from ARCHETYPE_ONTOLOGY . parent_archetype and ARCHETYPE_DESCRIPTION . parent_archetype .

D Lloyd

20 Jan 2005

0.5

SPEC-110. Update ADL document and create AOM document.
Includes detailed input and review from:

  • DSTC

  • CHIME, Uuniversity College London

  • Ocean Informatics

Initial Writing. Taken from ADL document 1.2draft B.

T Beale
A Goodchild
Z Tun
T Austin
D Kalra
N Lea
D Lloyd
S Heard
T Beale

10 Nov 2004

Acknowledgements

Primary Author

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

Contributors

This specification and its sibling Archetype Definition Language specification have benefited from wide 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.

  • Koray Atalag, MD, PhD, Sen. Researcher, National Institute for Health Innovation (NIHI), New Zealand

  • Linda Bird PhD, IHTSDO, Australia

  • Pieter Bos, Software Engineer, Nedap, Netherlands

  • Diego Boscá, IBIME, Technical University Valencia, VeraTech for Health, Spain

  • Rong Chen MD, PhD, Cambio Healthcare Systems, Sweden

  • Borut Fabjan, Program Manager, Marand, Slovenia

  • Sebastian Garde PhD, Ocean Informatics, UK

  • Peter Gummer, Ocean Informatics, Australia

  • Sam Heard MD, Ocean Informatics, Australia

  • Stan Huff MD, Intermountain Healthcare, UT, USA

  • David Ingram PhD, Emeritus Professor of Health Informatics, UCL, UK

  • Dipak Kalra MD, PhD, Professor Health Informatics, CHIME, UCL, UK

  • Shinji Kobayashi PhD, Kyoto University EHR research unit, Japan

  • Bostjan Lah, Architect, Marand, Slovenia

  • Patrick Langford, NeuronSong LLC, Utah, USA

  • David Lloyd, CHIME, UCL (ret), UK

  • Chunlan Ma PhD, MD, Ocean Informatics, Australia

  • Ian McNicoll MD, FreshEHR, UK

  • David Moner, IBIME, Technical University Valencia, VeraTech for Health, Spain

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

  • Pablo Pazos Gutierrez, Tarmac IT, CaboLabs, Uruguay

  • Harold Solbrig, Mayo Clinic, Rochester, USA

  • Erik Sundvall PhD, Linkoping University, Sweden

  • Alessandro Torrisi, Code24, The Netherlands

  • Bert Verhees, ROSA Software, The Netherlands

Supporters

The work reported in this paper has been funded by the following organisations:

  • Ars Semantica, UK

  • UCL (University College London) - Centre for Health Informatics and Multiprofessional Education (CHIME)

  • Ocean Informatics.

Special thanks to David Ingram, Emeritus Professor of Health Informatics at UCL, who provided a vision and collegial working environment ever since the days of GEHR (1992).

Trademarks

  • 'openEHR' is a trademark of the openEHR Foundation

  • 'Java' is a registered trademark of Oracle Corporation

  • 'Microsoft' is a trademark of the Microsoft Corporation

1. Preface

1.1. Purpose

This document contains the normative description of openEHR Archetype and Template semantics (originally described in [Beale_2000] and [Beale_2002]), in the form of an object model. The model presented here can be used as a basis for building software that represents archetypes and templates, independent of their persistent representation. Equally, it can be used to develop the output side of parsers that process archetypes in a linguistic format, such as the openEHR Archetype Definition Language (ADL) , XML and so on.

It is recommended in any case that the ADL specification be read in conjunction with this document, since it contains a detailed explanation of the semantics of archetypes, and many of the examples are more obvious in ADL, regardless of whether ADL is actually used with the object model presented here or not.

The release of AOM described in this specification corresponds to the 2.x version of the archetype formalism.

The intended audience includes:

  • Standards bodies producing health informatics standards;

  • Research groups using openEHR, ISO 13606, and other EHR or EHR exchange architectures;

  • The open source healthcare community;

  • EHR solution vendors;

  • Medical informaticians and clinicians interested in health information.

Prerequisite documents for reading this document include:

Related documents include:

1.3. Nomenclature

In this document, the term 'attribute' denotes any stored property of a type defined in an object model, including primitive attributes and any kind of relationship such as an association or aggregation. XML 'attributes' are always referred to explicitly as 'XML attributes'.

We also use the word 'archetype' in a broad sense to designate what are commonly understood to be 'archetypes' (specifications of clinical data groups / data constraints) and 'templates' (data sets based on archetypes, since at a technical level, an ADL/AOM 2 template is in fact just an archetype. Accordingly, statements about 'archetypes' in this specification can be always understood to also apply to templates, unless otherwise indicated.

1.4. Status

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

Various tools exist for creating and processing archetypes. The ADL Workbench is a reference compiler, visualiser and editor. The openEHR ADL/AOM tools can be downloaded from the website . Source projects can be found at the openEHR Github project.

1.6. Changes from Previous Versions

1.6.1. Release 1.5 to 2.0 (Document version 2.1.2 - )

The changes in release 2 of the ADL/AOM formalism are designed to make the formalism more computable with respect to terminology, and enable more rigorous validation and flattening operations.

The changes are as follows.

  • Introduction of new internal coding scheme, consisting of id-codes, at-codes and ac-codes;

  • Replace string archetype identifier with multi-part, namespaced identifier;

  • Addition of explicit value-sets in terminology section, replacing in-line value sets in the definition section;

  • Renaming archetype ontology section to terminology;

  • Expression of all external term bindings as URIs following IHTSDO format;

  • Introduction of 'tuple' constraints to replace openEHR custom constrainer types for covarying attributes within Quantity, Ordinal structures;

  • Re-engineering of all primitive constrainer types, i.e. C_STRING , C_DATE etc;

  • Removal of the openEHR Archetype Profile specification.

1.6.2. Release 1.4 to 1.5 (Document version 2.0 to 2.1.1)

The changes in release 1.5 are made to better facilitate the representation of specialised archetypes. The key semantic capability for specialised archetypes is to be able to support a differential representation, i.e. to express a specialised archetype only in terms of the changed or new elements in its defnition, rather than including a copy of unchanged elements. Doing the latter is clearly unsustainable in terms of change management.

The changes are as follows.

  • Full specialisation support: the addition of an attribute to the C_ATTRIBUTE class, allowing the inclusion of a path that enables specialised archetype redefinitions deep within a structure;

  • Addition of node-level annotations;

  • Structural simplification of archetype ontology section;

  • The name of the invariant section has been changed to rules, to better reflect its purpose.

  • A template is now just an archetype.

1.6.3. Release 0.6 to 1.4

Changes made from Release 1.3 to 1.4:

  • added a new attribute adl_version : String to the ARCHETYPE class;

  • changed name of ARCHETYPE . concept_code attribute to concept .

2. Model Overview

The model described here is a pure object-oriented model that can be used with archetype parsers and software that manipulates archetypes and templates in memory. It is typically the output of a parser of any serialsed form of archetypes.

2.1. Used BASE Component Packages

The AOM is dependent on various packages from the the openEHR BASE component. The first of these is the base.foundation_types package, which defines the various 'leaf' types assumed by the AOM as well as other utility types and basic data structures, such as the Interval<T> type. These types are documented in the openEHR Foundation Types specification and reproduced below for convenience.

BASE foundation types leaf types
Figure 1. base.foundation_types - 'leaf' types
BASE foundation types.interval
Figure 2. base.foundation_types.interval Package
Note
the above types do not constitute a formal part of this specification. Any implementation of the AOM will typically have to use concrete versions of these types found within languages and/or libraries.

In addition, various definitions from the base.base_types.definitions package are reused, which are shown below.

BASE base types.definitions
Figure 3. base.base_types.definitions Package

The enumeration type VALIDITY_KIND is provided in order to define standard values representing mandatory, optional, or disallowed in any model. It is used in this model in classes such as C_DATE , C_TIME and C_DATE_TIME. The VERSION_STATUS enumeration type serves a similar function within various AOM types.

Other classes used from the BASE Component include the base.resource package, which includes the class AUTHORED_RESOURCE and subordinate classes. These are shown by inclusion in the AOM Archetype package diagram below.

Finally, classes from the BASE Component base.expressions package is used by the rules part of the AOM. This is documented in the relevant section below.

2.2. AOM Package Structure

The Archetype Object Model is defined as the package am.archetype , as illustrated in Figure Package Overview. It is shown in the context of the am.archetype packages.

AOM packages
Figure 4. Package Overview

2.3. Definition and Utility Classes

2.3.1. Overview

Various definitional constants are used in the AOM. These are defined in the aom.definitions package from the AM component and are shown below.

AOM definitions
Figure 5. Definition Package

2.3.2. Class Definitions

2.3.3. ADL_CODE_DEFINITIONS Class

Class

ADL_CODE_DEFINITIONS

Description

Definitions relating to the internal code system of archetypes.

Constants

Signature

Meaning

1..1

Id_code_leader: String = "id"

String leader of ‘identifier’ codes, i.e. codes used to identify archteype nodes.

1..1

Value_code_leader: String = "at"

String leader of ‘value’ codes, i.e. codes used to identify codes values, including value set members.

1..1

Value_set_code_leader: String = "ac"

String leader of ‘value set’ codes, i.e. codes used to identify value sets.

1..1

Specialisation_separator: char = '.'

Character used to separate numeric parts of codes belonging to different specialisation levels.

1..1

Code_regex_pattern: String = "(0|[1-9][0-9]*)(\.(0|[1-9][0-9]*))*"

Regex used to define the legal numeric part of any archetype code. Corresponds to the simple pattern of dotted numbers, as used in typical multi-level numbering schemes.

1..1

Root_code_regex_pattern: String = "^id1(\.1)*$"

Regex pattern of the root id code of any archetype. Corresponds to codes of the form id1, id1.1, id1.1.1 etc..

1..1

Primitive_node_id: String = "id9999"

Code id used for C_PRIMITIVE_OBJECT nodes on creation.

Functions

Signature

Meaning

codes_conformant (
a_child_code: String[1],
a_parent_code: String[1]
): Boolean

True if a_child_code conforms to a_parent_code in the sense of specialisation, i.e. is a_child_code the same as or more specialised than a_parent_code.

is_adl_code (
a_code: String[1]
): Boolean
Post: Result = is_id_code (a_code) or else is_value_code (a_code) or else is_value_set_code (a_code)

True if a_code is any kind of ADL archetype local code.

is_id_code (
a_code: String[1]
): Boolean
Post: Result = a_code.starts_with (Id_code_leader)

True if a_code is an 'id' code.

is_value_code (
a_code: String[1]
): Boolean
Post: Result = a_code.starts_with (Value_code_leader)

True if a_code is an 'at' code, i.e. a code representing a single terminology item.

is_value_set_code (
a_code: String[1]
): Boolean
Post: Result = a_code.starts_with (Value_set_code_leader)

True if a_code is an 'ac' code, i.e. a code referring to a terminologyvalue set.

is_redefined_code (
a_code: String[1]
): Boolean

A code has been specialised if there is a non-zero code index anywhere above the last index e.g.

  • at0.0.1 → False

  • at1.0.1 → True

code_exists_at_level (
a-code: String[1],
a_level: Integer[1]
): Boolean

Is `a_code' valid at level `a_level' or less, i.e. if we remove its trailing specialised part corresponding to specialisation below `a_level', and then any trailing '.0' pieces, do we end up with a valid code? If so it means that the code corresponds to a real node from `a_level' or higher.

3. The Archetype Package

3.1. Overview

The top-level model of archetypes and templates (all variant forms) is illustrated in the Figure below. The model defines a standard structural representation of an archetype. Archetypes authored as independent entities are instances of the class AUTHORED_ARCHETYPE which is a descendant of AUTHORED_RESOURCE and ARCHETYPE. The first of the two parent classes provides a standardised model of descriptive meta-data, language information, annotations and revision history for any resource, and is documented in the openEHR Resource Model. The resource classes are shown included in the diagram below. The second parent class defines the core structure of any kind of archetype, including definition, terminology, optional rules part, along with a 'semantic identifier' (ARCHETYPE.archetype_id).

AOM archetype
Figure 6. Archetype Package

The AUTHORED_ARCHETYPE class adds identifying attributes, flags and descriptive meta-data, and is the ancestor type for two further specialisations - TEMPLATE and OPERATIONAL_TEMPLATE . The TEMPLATE class defines the notion of a 'templated' archetype, i.e. an archetype containing fillers/references (ADL’s use_archetype statements), typically designed to represent a data set. To enable this, it may contain 'overlays', private archetypes that specialise one or more of the referenced / filler archetypes it uses. Overlays are instances of the TEMPLATE_OVERLAY class, have no meta-data of their own, but are otherwise computationally just like any other archetype.

The OPERATIONAL_TEMPLATE class represents the fully flattened form of a template, i.e. with all fillers and references substituted and overlays processed, to form what is in practical terms, a single custom-made 'operational' artefact, ready for transformation to downstream artefacts. Because an operational template includes one or more other archetype structures inline, it also includes their terminologies, enabling it to be treated as a self-standing artefact.

3.2. Archetype Identification

3.2.1. Human-Readable Identifier (HRID)

All archetype variants based on ARCHETYPE have a human-readable, structured identifier defined by the ARCHETYPE_HRID class. This identifier places the artefact in a multi-dimensional space based on a namespace, its reference model class and its informational concept. This class defines an atomised representation of the identifier, enabling variant forms to be used as needed. Its various parts can be understood from the following diagram, which also shows the computed semantic_id and physical_id forms.

archetype hrid structure
Figure 7. Archetype HRID Structure

For specialised archetypes, the parent_archetype_id is also required. This is a string reference to an archetype, and is normally the 'interface' form of the id, i.e. down to the major version only. In some circumstances, it is useful to include the minor and patch version numbers as well.

An important aspect of identification relates to the rules governing when when the HRID namespace changes or is retained, with respect to when 'moves' or 'forks' occur. Its value is always the same as one of the original_namespace and custodian_namespace properties inherited from AUTHORED_RESOURCE.description (or both, in the case where they are the same). A full explanation of the identification system and rules is given in the openEHR Archetype Identification specification.

3.2.2. Machine Identifiers

Two machine identifiers are defined for archetypes. The ARCHETYPE.uid attribute defines a machine identifier equivalent to the human readable ARCHETYPE.archetype_id.semantic_id , i.e. ARCHETYPE_HRID up to its major version, and changes whenever the latter does. It is defined as optional but to be practically useful would need to be mandatory for all archetypes within a custodian organisation where this identifier was in use. It could in principle be synthesised at any time for a custodian that decided to implement it.

The ARCHETYPE.build_uid attribute is also optional, and if used, is intended to provide a unique identifier that corresponds to any change in version of the artefact. At a minimum, this means generating a new UUID for each change to:

  • ARCHETYPE.archetype_id.release_version;

  • ARCHETYPE.archetype_id.build_count;

  • ARCHETYPE.description.lifecycle_state.

For every change made to an archetype inside a controlled repository (for example, addition or update of meta-data fields), this field should be updated with a new UUID value, generated in the normal way.

3.3. Top-level Meta-data

The following items correspond to syntax elements that may appear in parentheses in the first line of an ADL archetype.

3.3.1. ADL Version

The ARCHETYPE.adl_version attribute in ADL 1.4 was used to indicate the ADL release used in the archetype source file from which the AOM structure was created (the version number comes from the revision history of the ADL specification. In the current and future AOM and ADL specifications, the meaning of this attribute is generalised to mean 'the version of the archetype formalism' in which the current archetype is expressed. For reasons of convenience, the version number is still taken from the ADL specification, but now refers to all archetype-related specifications together, since they are always updated in a synchronised fashion.

3.3.2. Reference Model Release

The ARCHETYPE.rm_release attribute designates the release of the reference model on which the archetype is based, in the archetype’s current version. This means rm_release can change with new versions of the archetype, where re-versioning includes upgrading the archetype to a later RM release. However, such upgrading still has to obey the basic rule of archetype compatibility: later minor, patch versions and builds cannot create data that is not valid with respect to the prior version.

This should be in the same semver.org 3-part form as the ARCHETYPE_HRID.release_version property, e.g. "1.0.2". This property does not indicate conformance to any particular reference model version(s) other than the named one, since most archetypes can easily conform to more than one. More minimal archetypes are likely to technically conform to more old and future releases than more complex archteypes.

3.3.3. Generated Flag

The ARCHETYPE.is_generated flag is used to indicate that an archetype has been machine-generated from another artefact, e.g. an older ADL version (say 1.4), or a non-archetype artefact. If true, it indicates to tools that the current archetype can potentially be overwritten, and that some other artefact is considered the primary source. If manual authoring occurs, this attribute should be set to False.

3.4. Governance Meta-data

Various meta-data elements are inherited from the AUTHORED_RESOURCE class, and provide the natural language description of the archetype, authoring and translation details, use, misuse, keywords and so on. There are three distinct parts of the meta-data: governance, authorship, and descriptive details.

3.4.1. Governance Meta-data Items

Governance meta-data is visible primarily in the RESOURCE_DESCRIPTION class, inherited via AUTHORED_RESOURCE, and consists of items relating to management and intellectual property status of the artefact. A typical form of these is shown in the screenshot in Figure Governance Meta-data.

metadata governance
Figure 8. Governance Meta-data
3.4.1.1. Package

The optional resource_package_uri property enables the recording of a reference to a package of archetypes or other resources, to which this archetype is considered to below. Its value may be in the form of "text <URL>".

3.4.1.2. Lifecycle_state

The description.lifecycle_state is an important property of an archetype, which is used to record its state in a defined lifecycle. The lifecycle state machine and versioning rules are explained fully in the openEHR Archetype Identification specification. Here we simply note that the value of the property is a coded term corresponding to one of the macro-state names on the diagram, i.e. 'unmanaged', 'in_development', and so on.

3.4.1.3. Original_namespace and Original_publisher

These two optional properties indicate the original publishing organisation, and its namespace, i.e. the original publishing environment where the artefact was first imported or created. The original_namespace property is normally the same value as archetype_id.namespace,unless the artefact has been forked into its current custodian, in which case archetype_id.namespace will be the same as custodian_namespace.

3.4.1.4. Custodian_namespace and Custodian_organisation

These two optional properties state a formal namespace, and a human-readable organisation identifier corresponding to the current custodian, i.e. maintainer and publisherof the artefact, if there is one.

3.4.1.5. Intellectual Property Items

There are three properties in the class that RESOURCE_DESCRIPTION relate to intellectual property (IP). Licence is a String field for recording of the licence (US: 'license') under which the artefact can be used. The recommended format is as follows:

licence name <reliable URL to licence statement>

The copyright property records the copyright applying to the artefact, and is normally in the standard form '(c) name' or '(c) year name'. The special character © may also be used (UTF-8 0xC2A9).

3.4.2. Authorship Meta-data

Authorship meta-data consists of items such as author name, contributors, and translator information, and is visualised in the figure below.

metadata authoring
Figure 9. Authoring Meta-data
3.4.2.1. Original Author

The RESOURCE_DESCRIPTION.original_author property defines a simple list of name/value pairs via which the original author can be documented. Typical key values include "name", "organi[zs]ation", "email" and `"date"`".

3.4.2.2. Contributors

The RESOURCE_DESCRIPTION.other_contributors property is a simple list of strings, one for each contributor. The recommended format of the string is one of:

first names last name, organisation
first names last name, organisation <contributor email address>
first names last name, organisation <organisation email address>
3.4.2.3. Languages and Translation

The AUTHORED_RESOURCE.original_language and TRANSLATION_DETAILS class enable the original language of authoring and information relating to subsequent translations to be expressed. TRANSLATION_DETAILS.author allows each translator to be represented in the same way as the original_author , i.e. a list of name/values.

3.4.2.4. Version_last_translated

The version_last_translated property is used to record a copy of the archetype_id.physical_id for each language, when the translation was carried out. This enables maintainers to know when new translations are needed for some or all languages. This String property records the full version identifier (i.e. ARCHETYPE.archetype_id.version_id) at the time of last translation, enabling tools to determine if and when translations may be out of date.

3.4.3. Descriptive Meta-data

Various descriptive meta-data may be provided for an archetype in multiple translations in the RESOURCE_DESCRIPTION_ITEM class, using one instance for each translation language, as shown in the figure below.

metadata details
Figure 10. Descriptive Meta-data
3.4.3.1. Purpose

The purpose item is a String property for recording the intended design concept of the artefact.

3.4.3.2. Use and Misuse

The use and misuse properties enable specific uses and misuses to be documented. The latter normally relate to common errors of use, or apparently reasonable but wrong assumptions about use.

3.4.3.3. Keywords

The keywords property is a list of Strings designed to record search keywords for the artefact.

3.4.3.4. Resources

The original_resource_uri property is used to record one or more references to resources in each particular language.

TBD: This property does not appear to have ever been used, and it may not be useful, since 'resources' are not typically available for each language.

3.5. Structural Definition

3.5.1. Common Structural Parts

The archetype definition is the main definitional part of an archetype and is an instance of a C_COMPLEX_OBJECT . This means that the root of the constraint structure of an archetype always takes the form of a constraint on a non-primitive object type.

The terminology section of an archetype is represented by its own classes, and is what allows archetypes to be natural language- and terminology-neutral. It is described in detail in the Terminology Package.

An archetype may include one or more rules. Rules are statements expressed in a subset of predicate logic, which can be used to state constraints on multiple parts of an object. They are not needed to constrain single attributes or objects (since this can be done with an appopriate C_ATTRIBUTE or C_OBJECT ), but are necessary for constraints referring to more than one attribute, such as a constraint that 'systolic pressure should be >= diastolic pressure' in a blood pressure measurement archetype. They can also be used to declare variables, including external data query results, and make other constraints dependent on a variable value, e.g. the gender of the record subject.

Lastly, annotations and revision history sections, inherited from the AUTHORED_RESOURCE class, can be included as required. The annotations section is of particular relevance to archetypes and templates, and is used to document individual nodes within an archetype or template, and/or nodes in reference model data, that may not be constrained in the archetype, but whose specific use in the archetyped data needs to be documented. In the former case, the annotations are keyed by an archetype path, while in the latter case, by a reference model path.

3.5.2. Structural Variants

The model in Figure Archetype Package defines the structures of a number of variants of the 'archetype' idea. All concrete instances are instances of one of the concrete descendants of ARCHETYPE. Figure Source Archetype Structure illustrates the typical object structure of a source archetype - the form of archetype created by an authoring tool - represented by a DIFFERENTIAL_ARCHETYPE instance. Mandatory parts are shown in bold.

AOM source archetype structure
Figure 11. Source Archetype Structure

Source archetypes can be specialised, in which case their definition structure is a partial overlay on the flat parent, or 'top-level', in which case the definition structure is complete. C_ARCHETYPE_ROOT instances may only occur representing direct references to other archetypes - 'external references'.

A flat archetype is generated from one or more source archetypes via the flattening process described in the next chapter of this specification, (also in the ADL specification). This generates a FLAT_ARCHETYPE from a DIFFERENTIAL_ARCHETYPE instance. The main two changes that occur in this operation are a) specialised archetype overlays are applied to the flat parent structure, resulting in a full archetype structure, and b) internal references (use_nodes) are replaced by their expanded form, i.e. a copy of the subtrees to which they point.

AOM source template structure
Figure 12. Source Template Structure

This form is used to represent the full 'operational' structure of a specialised archetype, and has two uses. The first is to generate backwards compatible ADL 1.4 legacy archetypes (always in flat form); the second is during the template flattening process, when the flat forms of all referenced archetypes and templates are ultimately combined into a single operational template.

Figure Source Template Structure illustrates the structure of a source template, i.e instances of TEMPLATE. A source template is an archetype containing C_ARCHETYPE_ROOT objects representing slot fillers - each referring to an external archetype or template, or potentially an overlay archetype.

Another archetype variant, also shown in Source Template Structure is the template overlay, i.e. an instance of TEMPLATE_OVERLAY. These are purely local components of templates, and include only the definition and terminology. The definition structure is always a specialised overlay on something else, and may not contain any slot fillers or external references, i.e. no C_ARCHETYPE_ROOT objects. No identifier, adl_version, languages or description are required, as they are considered to be propagated from the owning root template. Accordingly, template overlays act like a simplified specialised archetype. Template overlays can be thought of as being similar to 'anonymous' or 'inner' classes in some object-oriented programming languages.

Figure Operational Template Structure illustrates the resulting operational template, or compiled form of a template. This is created by building the composition of referenced archetypes and/or templates and/or template overlays, in their flattened form, to generate a single 'giant' archetype. The root node of this archetype, along with every archetype/template root node within, is represented using a C_ARCHETYPE_ROOT object. An operational template also has a component_terminologies property containing the ontologies from every constituent archetype, template and overlay.

AOM operational template structure
Figure 13. Operational Template Structure

More details of template development, representation and semantics are described in the next section.

3.6. Class Descriptions

3.6.1. ARCHETYPE Class

Class

ARCHETYPE (abstract)

Description

The ARCHETYPE class defines the core formal model of the root object of any archetype or template. It includes only basic identification information, and otherwise provides the structural connections from the Archetype to its constituent parts, i.e. definition (a C_COMPLEX_OBJECT), terminology (ARCHEYTPE_TERMINOLOGY) and so on. It is the parent class of all concrete types of archetype.

Attributes

Signature

Meaning

0..1

parent_archetype_id: String

Archetype reference of the specialisation par-ent of this archetype, if applicable. May take the form of an archetype interface identifier, i.e. the identifier up to the major version only, or can be deeper.

1..1

archetype_id: ARCHETYPE_HRID

Identifier of this archetype.

1..1

is_differential: Boolean

Flag indicating whether this archetype is differential or flat in its contents. Top-level source archetypes have this flag set to True.

1..1

definition: C_COMPLEX_OBJECT

Root node of the definition of this archetype.

1..1

terminology: ARCHETYPE_TERMINOLOGY

The terminology of the archetype.

0..1

rules: List<STATEMENT>

Rules relating to this archetype. Statements are expressed in first order predicate logic, and usually refer to at least two attributes.

Functions

Signature

Meaning

concept_code (): String
post-condition: Result.is_equal (definition.node_id)

The concept code of the root object of the archetype, also standing for the concept of the archetype as a whole.

physical_paths (): List<String>

Set of language-independent paths extracted from archetype. Paths obey Xpath-like syntax and are formed from alternations of C_OBJECT.node_id and C_ATTRIBUTE.rm_attribute_name values.

logical_paths (
lang: String[1]
): List<String>

Set of language-dependent paths extracted from archetype. Paths obey the same syntax as physical_paths, but with node_ids replaced by their meanings from the ontology.

specialisation_depth (): Integer
post-condition: Result = terminology.specialisation_depth

Specialisation depth of this archetype; larger than 0 if this archetype has a parent. Derived from terminology.specialisation_depth.

is_specialised (): Boolean
post-condition: Result implies parent_archetype_hrid /= Void

True if this archetype is a specialisation of another.

Invariants

Invariant_concept_valid: terminology.has_term_code (concept_code)

Invariant_specialisation_validity: is_specialised implies specialisation_depth > 0

3.6.2. AUTHORED_ARCHETYPE Class

Class

AUTHORED_ARCHETYPE

Description

Root object of a standalone, authored archetype, including all meta-data, description, other identifiers and lifecycle.

Inherit

ARCHETYPE, AUTHORED_RESOURCE

Attributes

Signature

Meaning

0..1

adl_version: String

ADL version if archetype was read in from an ADL sharable archetype.

1..1

build_uid: UUID

Unique identifier of this archetype artefact instance. A new identifier is assigned every time the content is changed by a tool. Used by tools to distinguish different revisions and/or interim snapshots of the same artefact.

1..1

rm_release: String

Semver.org compatible release of the most recent reference model release on which the archetype in its current version is based. This does not imply conformance only to this release, since an archetype may be valid with respect to multiple releases of a reference model.

1..1

is_generated: Boolean

If True, indicates that this artefact was machine-generated from some other source, in which case, tools would expect to overwrite this artefact on a new generation. Editing tools should set this value to False when a user starts to manually edit an archetype.

1..1

other_meta_data: Hash<String, String>

Invariants

Invariant_adl_version_validity: valid_version_id (adl_version)

Invariant_rm_release: valid_version_id (rm_release)

Description_validity: description /= Void

3.6.3. ARCHETYPE_HRID Class

Class

ARCHETYPE_HRID

Description

Human_readable structured identifier (HRID) for an archetype or template.

Attributes

Signature

Meaning

0..1

namespace: String

Reverse domain name namespace identifier.

1..1

rm_publisher: String

Name of the Reference Model publisher.

1..1

rm_package: String

Name of the package in whose reachability graph the rm_class class is found (there can be more than one possibility in many reference models).

1..1

rm_class: String

Name of the root class of this archetype.

1..1

concept_id: String

The short concept name of the archetype as used in the multi-axial archetype_hrid.

1..1

release_version: String

The full numeric version of this archetype consisting of 3 parts, e.g. "1.8.2". The archetype_hrid feature includes only the major version.

1..1

version_status: VERSION_STATUS

The status of the version, i.e. released, release_candidate etc.

1..1

build_count: String

The build count since last increment of any version part.

Functions

Signature

Meaning

semantic_id (): String

The ‘interface’ form of the HRID, i.e. down to the major version.

physical_id (): String

The ‘physical’ form of the HRID, i.e. with complete version information.

version_id (): String

Full version identifier string, based on release_version and lifecycle, e.g. "1.8.2-rc.4".

major_version (): String

Major version of this archetype, extracted from release_version.

minor_version (): String

Minor version of this archetype, extracted from release_version.

patch_version (): String

Patch version of this archetype, extracted from release_version. Equivalent to patch version in patch version in semver.org sytem.

Invariants

Inv_rm_publisher_validity: not rm_publisher.is_empty

Inv_rm_package_validity: not rm_package.is_empty

Inv_class_name_validity: not rm_class.is_empty

Inv_concept_id_validity: not concept_id.is_empty

Inv_release_version_validity: valid_version (release_version)

3.6.4. TEMPLATE Class

Class

TEMPLATE

Description

Class representing source template, i.e. a kind of archetype that may include template overlays, and may be restricted by tools to only defining mandations, prohibitions, and restrictions on elements already defined in the flat parent.

Inherit

AUTHORED_ARCHETYPE

Attributes

Signature

Meaning

0..1

overlays: List<TEMPLATE_OVERLAY>

Overlay archetypes, i.e. partial archetypes that include full definition and terminology, but logically derive all their meta-data from from the owning template.

Invariants

Inv_is_specialised: is_specialised

3.6.5. TEMPLATE_OVERLAY Class

Class

TEMPLATE_OVERLAY

Description

A concrete form of the bare ARCHETYPE class, used to represent overlays in a source template. Overlays have no meta-data of their own, and are instead documented by their owning template.

Inherit

ARCHETYPE

Invariants

Inv_is_specialised: is_specialised

3.6.6. OPERATIONAL_TEMPLATE Class

Class

OPERATIONAL_TEMPLATE

Description

Root object of an operational template. An operational template is derived from a TEMPLATE definition and the ARCHETYPEs and/or TEMPLATE_OVERLAYs mentioned by that template by a process of flattening, and potentially removal of unneeded languages and terminologies.

An operational template is used for generating and validating RM-canonical instance data, and also as a source artefact for generating other downstream technical artefacts, including XML schemas, APIs and UI form definitions.

Inherit

AUTHORED_ARCHETYPE

Attributes

Signature

Meaning

0..1

component_terminologies: Hash<String, ARCHETYPE_TERMINOLOGY>

Compendium of flattened terminologies of archetypes externally referenced from this archetype, keyed by archetype identifier. This will almost always be present in a template.

0..1

terminology_extracts: Hash<String,ARCHETYPE_TERMINOLOGY>

Directory of term definitions as a two-level table. The outer hash keys are term codes, e.g. "at4", and the inner hash key are term attribute names, e.g. "text", "description" etc.

Functions

Signature

Meaning

component_terminology (
an_id: String[1]
): ARCHETYPE_TERMINOLOGY

Invariants

Specialisation_validity: is_specialised

3.7. Validity Rules

The following validity rules apply to all varieties of ARCHETYPE object:

VARAV: ADL version validity. The adl_version top-level meta-data item must exist and consist of a valid 3-part version identifier.

VARRV: RM release validity. The rm_release top-level meta-data item must exist and consist of a valid 3-part version identifier.

VARCN: archetype concept validity. The node_id of the root object of the archetype must be of the form id1{.1}*, where the number of .1 components equals the specalisation depth, and must be defined in the terminology.

VATDF: value code validity. Each value code (at-code) used in a term constraint in the archetype definition must be defined in the term_definitions part of the terminology of the flattened form of the current archetype.

VACDF: constraint code validity. Each value set code (ac-code) used in a term constraint in the archetype definition must be defined in the term_definitions part of the terminology of the current archetype.

VATDA: value set assumed value code validity. Each value code (at-code) used as an assumed_value for a value set in a term constraint in the archetype definition must exist in the value set definition in the terminology for the identified value set.

VETDF: external term validity. Each external term used within the archetype definition must exist in the relevant terminology (subject to tool accesibility; codes for inaccessible terminologies should be flagged with a warning indicating that no verification was possible).

VOTM: terminology translations validity. Translations must exist for term_definitions and constraint_definitions sections for all languages defined in the description / translations sections.

VOKU: object key unique. Within any keyed list in an archetype, including the desription, terminology, and annotations sections, each item must have a unique key with respect to its siblings.

VARDT: archetype definition typename validity. The typename mentioned in the outer block of the archetype definition section must match the type mentioned in the first segment of the archetype id.

VRANP: annotation path valid. Each path mentioned in an annotation within the annotations section must either be a valid archetype path, or a 'reference model' path, i.e. a path that is valid for the root class of the archetype.

VRRLP: rule path valid. Each path mentioned in a rule in the rules section must be found within the archetype, or be an RM-valid extension of a path found within the archetype.

The following validity rules apply to instances of ARCHETYPE and subtypes other than TEMPLATE_OVERLAY:

VARID: archetype identifier validity. The archetype must have an identifier that conforms to the openEHR specification for archetype identifiers.

VDEOL: original language specified. An original_language section containing the meta-data of the original authoring language must exist.

VARD: description specified. A description section containing the main meta-data of the archetype must exist.

The following rules apply to specialised archetypes, for which ARCHETYPE.is_specialised returns True.

VASID: archetype specialisation parent identifier validity. The archetype identifier stated in the specialise clause must be the identifier of the immediate specialisation parent archetype.

VALC: archetype language conformance. The languages defined in a specialised archetype must be the same as or a subset of those defined in the flat parent.

VACSD: archetype concept specialisation depth. The specialisation depth of the archetypes must be one greater than the specialisation depth of the parent archetype.

VATCD: archetype code specialisation level validity. Each archetype term ('at' code) and constraint code ('ac' code) used in the archetype definition section must have a specialisation level no greater than the specialisation level of the archetype.

4. Constraint Model Package

4.1. Overview

Figure constraint_model Package and Figure constraint_model.primitive Package illustrate the object model of constraints used in an archetype definition. This model is completely generic, and is designed to express the semantics of constraints on instances of classes which are themselves described in any orthodox object-oriented formalism, such as UML. Accordingly, the major abstractions in this model correspond to major abstractions in object-oriented formalisms, including several variations of the notion of 'object' and the notion of 'attribute'. The notion of 'object' rather than 'class' or 'type' is used because archetypes are about constraints on data (i.e. 'instances', or 'objects') rather than models, which are constructed from 'classes'. In this document, the word 'attribute' refers to any data property of a class, regardless of whether regarded as a 'relationship' (i.e. association, aggregation, or composition) or 'primitive' (i.e. value) attribute in an object model.

AOM constraint model top
Figure 14. constraint_model Package

The definition part of an archetype is an instance of a C_COMPLEX_OBJECT and consists of alternate layers of object and attribute constrainer nodes, each containing the next level of nodes. At the leaves are primitive object constrainer nodes constraining primitive types such as String , Integer etc. There are also nodes that represent internal references to other nodes, constraint reference nodes that refer to a text constraint in the constraint binding part of the archetype terminology, and archetype constraint nodes, which represent constraints on other archetypes allowed to appear at a given point. The full list of concrete node types is as follows:

  • C_COMPLEX_OBJECT : any interior node representing a constraint on instances of some non-primitive type, e.g. OBSERVATION , SECTION ;

  • C_ATTRIBUTE : a node representing a constraint on an attribute (i.e. UML 'relationship' or 'primitive attribute') in an object type;

  • C_PRIMITIVE_OBJECT : a node representing a constraint on a primitive (built-in) object type;

  • C_COMPLEX_OBJECT_PROXY : a node that refers to a previously defined C_COMPLEX_OBJECT node in the same archetype. The reference is made using a path;

  • ARCHETYPE_SLOT : a node whose statements define a constraint that determines which other archetypes can appear at that point in the current archetype. It can be thought of like a keyhole, into which few or many keys might fit, depending on how specific its shape is. Logically it has the same semantics as a C_COMPLEX_OBJECT , except that the constraints are expressed in another archetype, not the current one.

  • C_ARCHETYPE_ROOT : stands for the root node of an archetype; enables another archetype to be referenced from the present one. Used in both archetypes and templates.

The constraints define which configurations of reference model class instances are considered to conform to the archetype. For example, certain configurations of the classes PARTY , ADDRESS , CLUSTER and ELEMENT might be defined by a Person archetype as allowable structures for 'people with identity, contacts, and addresses'. Because the constraints allow optionality, cardinality and other choices, a given archetype usually corresponds to a set of similar configurations of objects.

AOM constraint model bottom
Figure 15. constraint_model.primitive Package

The type-name nomenclature C_XXX used here is intended to be read as "constraint on objects of type XXXX ", i.e. a C_COMPLEX_OBJECT is a "constraint on a complex object (defined by a complex reference model type)". These type names are used below in the formal model.

4.2. Semantics

The effect of the model is to create archetype definition structures that are a hierarchical alternation of object and attribute constraints. This structure can be seen by inspecting an ADL archetype, or by viewing an archetype in an AOM-based tool such as the openEHR ADL workbench, and is a direct consequence of the object-oriented principle that classes consist of properties, which in turn have types that are classes. (To be completely correct, types do not always correspond to classes in an object model, but it does not make any difference here). The repeated object/attribute hierarchical structure of an archetype provides the basis for using paths to reference any node in an archetype. Archetype paths follow a syntax that is a directly convertible in and out of the W3C Xpath syntax.

4.2.1. All Node Types

Some properties are defined for all node types, described in the following sections.

4.2.1.1. Path Functions

The path feature computes the path to the current node from the root of the archetype, while the has_path function indicates whether a given path can be found in an archetype.

4.2.1.2. Conformance Functions

All node types include two functions that formalise the notion of conformance of a specialised archetype to a parent archetype. Both functions take an argument which must be a corresponding node in a parent archetype, not necessarily the immediate parent. A 'corresponding' node is one found at the same or a congruent path. A congruent path is one in which one or more at-codes have been redefined in the specialised archetype.

The c_conforms_to function returns True if the node on which it is called is a valid specialisation of the 'other' node. The c_congruent_to function returns True if the node on which it is called is the same as the other node, with the possible exception of a redefined at-code. The latter may happen due to the need to restrict the domain meaning of node to a meaning narrower than that of the same node in the parent. The formal semantics of both functions are given in the section See Class Definitions.

4.2.1.3. Any_allowed

The any_allowed function defined on some node types indicates that any value permitted by the reference model for the attribute or type in question is allowed by the archetype; its use permits the logical idea of a completely "open" constraint to be simply expressed, avoiding the need for any further substructure.

4.2.2. Attribute Nodes

Constraints on reference model attributes, including computed attributes (represented by functions with no aguments in most programming languages), are represented by instances of C_ATTRIBUTE . The expressible constraints include:

  • is_multiple: a flag that indicates whether the C_ATTRIBUTE is constraining a multiply-valued (i.e. container) RM attribute or a single-valued one;

  • existence: whether the corresponding instance (defined by the rm_attribute_name attribute) must exist;

  • child objects: representing allowable values of the object value(s) of the attribute.

In the case of single-valued attributes (such as Person.date_of_birth) the children represent one or more alternative object constraints for the attribute value.

For multiply-valued attributes (such as Person.contacts: List<Contact>), a cardinality constraint on the container can be defined. The constraint on child objects is essentially the same except that more than one of the alternatives can co-exist in the data. Figure C_ATTRIBUTE variants illustrates the two possibilities.

The appearance of both existence and cardinality constraints in C_ATTRIBUTE deserves some explanation, especially as the meanings of these notions are often confused in object-oriented literature. An existence constraint indicates whether an object will be found in a given attribute field, while a cardinality constraint indicates what the valid membership of a container object is. Cardinality is only required for container objects such as List<T> , Set<T> and so on, whereas existence is always possible. If both are used, the meaning is as follows: the existence constraint says whether the container object will be there (at all), while the cardinality constraint says how many items must be in the container, and whether it acts logically as a list, set or bag. Both existence and cardinality are optional in the model, since they are only needed to override the settings from the reference model.

c attributes
Figure 16. C_ATTRIBUTE variants

4.2.3. Object Node Types

The following sections apply to all object nodes in an archetype, i.e. instances of any descendant of C_OBJECT.

4.2.3.1. Rm_type_name and Reference Model Type Matching

Every object node has an rm_type_name attribute that states the RM type to be matched by that node in the archetype. The value of rm_type_name is understood as a constraint on the dynamic type of data instances of the stated Reference Model type. It is either a class name from the RM, or a generic type constructed from RM class names, as described in the Reference model type matching section of the ADL2 specification.

The RM type stated in an archetype object node is understood to be a static type constraint. Accordingly, it will match an instance of any RM subtype of the stated type, as long as the inheritance relationship is stated in the RM definition. This holds both for sub-classes, and subtypes of generic types, in a covariant fashion. The following matching will thus succeed:

  • rm_type_name = "PARTY" matches PERSON, where PERSON inherits from PARTY in the relevant RM;

  • rm_type_name = "Interval<Ordered>" matches a dynamic type of data items of Interval<Quantity>, SimpleInterval<Ordered> and SimpleInterval<Quantity> where Quantity inherits from Ordered and SimpleInterval inherits from Interval in the relevant RM.

There are some special rules that apply to primitive type matching that enable 'logical' primitive type names in archetypes to match multiple 'concrete' variants that occur in some reference models and programming type systems. These are described in detail below.

4.2.3.2. Node_id and Paths

The node_id attribute in the class C_OBJECT, inherited by all subtypes, is of key importance in the archetype constraint model. It has two functions:

  • it allows archetype object constraint nodes to be individually identified, and in particular, guarantees sibling node unique identification;

  • it provides a code to which a human-understanding terminology definition can be attached, as well as potentially a terminology binding.

The existence of node_ids in an archetype allows archetype paths to be created, which refer to each node. Every node in the archetype needs a node_id , but only node_ids for nodes under container attributes must have a terminology definition. For nodes under single-valued attributes, the terminology definition is optional (and typically not supplied), since the meaning is given by the reference model attribute definition.

Note that instances of C_PRIMITIVE_OBJECT have a constant node_id (see below) and thus do not require node identifiers to be supplied in syntax or serial forms that are converted to AOM structural form.

4.2.3.3. Sibling Ordering

Within a specialised archetype, redefined or added object nodes may be defined under a container attribute. Since specialised archetypes are in differential form, i.e. only redefined or added nodes are expressed, not nodes inherited unchanged, the relative ordering of siblings can’t be stated simply by the ordering of such items within the relevant list within the differential form of the archetype. An explicit ordering indicator is required if indeed order is specific. The C_OBJECT.sibling_order attribute provides this possibility. It can only be set on a C_OBJECT descendant within a multiply-valued attribute, i.e. an instance of C_ATTRIBUTE for which the cardinality is ordered.

4.2.3.4. Node Deprecation

It is possible to mark an instance of any defined node type as deprecated, meaning that by preference it should not be used, and that there is an alternative solution for recording the same information. Rules or recommendations for how deprecation should be handled are outside the scope of the archetype proper, and should be provided by the governance framework under which the archetype is managed.

4.2.4. Defined Object Nodes (C_DEFINED_OBJECT)

The C_DEFINED_OBJECT subtype corresponds to the category of C_OBJECTs that are defined in an archetype by value, i.e. by inline definition. Four properties characterise C_DEFINED_OBJECT s as follows.

4.2.4.1. Valid_value

The valid_value function tests a reference model object for conformance to the archetype. It is designed for recursive implementation in which a call to the function at the top of the archetype definition would cause a cascade of calls down the tree. This function is the key function of an 'archetype-enabled kernel' component that can perform runtime data validation based on an archetype definition.

4.2.4.2. Prototype_value

This function is used to generate a reasonable default value of the reference object being constrained by a given node. This allows archteype-based software to build a 'prototype' object from an archetype which can serve as the initial version of the object being constrained, assuming it is being created new by user activity (e.g. via a GUI application). Implementation of this function will usually involve use of reflection libraries or similar.

4.2.4.3. Default_value

This attribute allows a user-specified default value to be defined within an archetype. The default_value object must be of the same type as defined by the prototype_value function, pass the valid_value test. Where defined, the prototype_value function would return this value instead of a synthesised value.

4.2.5. Reference Objects

The types ARCHETYPE_SLOT and C_COMPLEX_OBJECT_PROXY are used to express, respectively, a 'slot' where further archetypes can be used to continue describing constraints; a reference to a part of the current archetype that expresses exactly the same constraints needed at another point.

4.2.6. Complex Objects (C_COMPLEX_OBJECT)

Along with C_ATTRIBUTE, C_COMPLEX_OBJECT is the key structuring type of the constraint_model package, and consists of attributes of type C_ATTRIBUTE , which are constraints on the attributes (i.e. any property, including relationships) of the reference model type. Accordingly, each C_ATTRIBUTE records the name of the constrained attribute (in rm_attr_name) , the existence and cardinality expressed by the constraint (depending on whether the attribute it constrains is a multiple or single relationship), and the constraint on the object to which this C_ATTRIBUTE refers via its children attribute (according to its reference model) in the form of further C_OBJECTs .

4.2.7. Primitive Types (C_PRIMITIVE_OBJECT descendants)

Constraints on primitive types are defined by the classes inheriting from C_PRIMITIVE_OBJECT , i.e. C_STRING , C_INTEGER and so on. The primitive types are represented in such a way as to accommodate both 'tuple' constraints and logically unary constraints, using a tuple array whose members are each a primitive constraint corresponding to each primitive type. Tuple constraints are second order constraints, described below, enable covarying constraints to be stated. In the unary case, the constraint is the first member of a tuple array.

C_PRIMITIVE_OBJECT instances are created with a fixed id-code ADL_CODE_DEFINITIONS.primitive_node_id as the value of node_id (see ADL_CODE_DEFINITIONS Class). For this reason, no node identifier needs to be supplied in a syntax or serialised form of an archetype, including ADL.

The primitive constraint for each primitive type may itself be complex. Its RM type is given by the type of the constraint accessor in each C_PRIMITIVE_OBJECT descendant and is summarised in the following table.

AOM type RM Primitive type AOM Primitive constrainer type Explanation

C_BOOLEAN

Boolean

List <Boolean>

Can represent one or two Boolean values, enabling the logical constraints 'true', 'false' and 'true or false' to be expressed.

C_STRING

String

List <String>

A list of possible string values, which may include regular expressions, which are delimited by '/' characters.

C_TERMINOLOGY_CODE

Terminology_code

Terminology constraint -
[acN] or [atN]

A string containing either a single at-code or a single ac-code. In the latter case, the constraint refers to either a locally defined value set or (via a binding) an external value set.

C_ORDERED

Descendants of
Ordered

List <Interval<T>>

Can represent a single value (which is a point interval), a list of values (list of point intervals), a list of intervals, which may be mixed proper and point intervals.

C_INTEGER

Integer

List <Interval<Integer>>

As for Ordered type, with T = Integer

C_REAL

Real

List <Interval<Real>>

As for Ordered type, with T = Real

C_TEMPORAL

Descendants of
Temporal

List <Interval<T→Temporal>>
OR
String (ADL pattern)

As for ordered types, with T being an sub-type type of Temporal, an ancestor of the assumed Date/time primitive types., with the addition of a second type constraint - a pattern based on ISO8601 syntax.

C_DATE

Date

List <Interval<Date>>
OR
String (ADL pattern)

As for Temporal types with T = Date

C_TIME

Time

List <Interval<Time>>
OR
String (ADL pattern)

As for Temporal types with T = Time

C_DATE_TIME

Date_time OR DateTime

List <Interval<Date_time>>
OR
String (ADL pattern)

As for Temporal types with T = Date_time

C_DURATION

Duration

List <Interval<Duration>>
OR
String (ADL pattern)

As for Temporal types with T = Duration

Note in the above that the C_DATE_TIME AOM type is assumed by default to apply to data items of the RM types DateTime and Date_time, including any variations in case.

In order to accommodate concrete type variants that are used in common type systems, the following RM type matching should be considered to occur by default:

  • String variants: in addition to matching String, C_STRING should match StringN and String_N instances, to accommodate RM types such as String8, String_32 etc;

  • Integer variants: in addition to matching Integer, C_INTEGER should match IntegerN and Integer_N, to accommodate RM types such as Integer_16, Integer64 etc;

  • Real variants: in addition to matching Real, C_REAL should match RealN and Real_N and Double, to accommodate RM types such as Real_32, Real64 and Double.

A way of configuring this on a per-RM basis is described in the section RM Primitive Type Equivalences below.

4.2.7.1. Assumed_value

The assumed_value attribute is useful for archetypes containing any optional constraint. and provides an ability to define a value that can be assumed for a data item for which no data is found at execution time. If populated, it can contain a single at-code that must be in the local value set referred to by the ac-code in the constraint attribute.

For example, an archetype for the concept 'blood pressure measurement' might contain an optional protocol section containing a data point for patient position, with choices 'lying', 'sitting' and 'standing'. Since the section is optional, data could be created according to the archetype which does not contain the protocol section. However, a blood pressure cannot be taken without the patient in some position, so clearly there is an implied value for patient position. Amongst clinicians, basic assumptions are nearly always made for such things: in general practice, the position could always safely be assumed to be "sitting" if not otherwise stated; in the hospital setting, "lying" would be the normal assumption. The assumed_value feature of archetypes allows such assumptions to be explicitly stated so that all users/systems know what value to assume when optional items are not included in the data.

Note that the notion of assumed values is distinct from that of 'default values'. The latter notion is that of a default 'pre-filled' value that is provided (normally in a local context by a template) for a data item that is to be filled in by the user, but which is typically the same in many cases. Default values are thus simply an efficiency mechanism for users. As a result, default values do appear in data, while assumed values don’t.

4.2.8. Terminology Constraints (C_TERMINOLOGY_CODE)

The C_TERMINOLOGY_CODE type entails some complexity and merits further explanation. This is the only constrainer type whose constraint semantics are not self-contained, but located in the archetype terminology and/or in external terminologies.

A C_TERMINOLOGY_CODE instance in an archetype is simple: it can only be one of the following constraints:

  • a single ac-code, referring to either a value-set defined in the archetype terminology or bound to an external value set or ref set;

    • in this case, an additional at-code may be included as an assumed value; the at-code must come from the locally defined value set;

  • a single at-code, repesenting a single possible value.

Note
The second case in theory could be done using an ac-code referring to a value set containing a single value, but there seems little value in this extra verbiage, and little cost in providing the single-member value set short cut.

In addition, a C_TERMINOLOGY_CODE instance can reconstitute the internal value set via access to the archetype terminology (this has to be set up within the implementation). If bindings are evaluated, the external form of a value set can potentially be obtained as well. The utility of this is to be able to evaluate and cache certain external 'ref sets' when evaluating the Operational Template.

4.2.8.1. Terminology Code Resolution

When an archetype is deployed in the form of an operational template, the internally defined value sets, and any bindings are processed in stages in order to obtain the final terminology codes from which the user should choose. The C_TERMINOLOGY_CODE class provides a number of functions to formalise this as follows.

  • value_set_expanded: List<String>: this function converts an ac-code to its corresponding set of at-codes, as defined in the value_sets section of the archetype.

  • value_set_substituted: List<URI>: where bindings exist to he value set at-codes, this function converts each code to its corresponding binding target, i.e. a URI.

  • value_set_resolved: List<TERMINOLOGY_CODE>: this function converts the list of URIs to final terms, including with textual rubrics, i.e. a list of TERMINOLOGY_CODEs.

These functions would normally be implemented as 'lambdas' or 'agents', in order to obtain access to the target terminologies.

Note
Since an archetype might not contain external terminology bindings for all (or even any) of its terminological constraints, a 'resolved' archetype will usually contain at-codes in its cADL definition. These at-codes would be treated as real coded terms in any implementation that was creating data, and as a consequence, archetype at-codes could occur in real data, as described in the the Terminology Integration section of the ADL specification.

4.2.9. Constraints on Enumeration Types

Enumeration types in the reference model are assumed to have semantics expected in UML, and mainstream programming languages, i.e. to be a distinct type based on a primitive type, normally Integer or String. Each such type consists of a set of values from the domain of its underlying type, thus, a set of Integer, String or other primitive values. Each of these values is assumed to be named in the manner of a symbolic constant. Although stricly speaking UML doesn’t require an enumerated type to be based on an underlying primitive type, programming languages do, hence the assumption here that values from the domain of such a type are involved.

A constraint on an enumerated type therefore consists of an AOM instance of a C_PRIMITIVE descendant, almost always C_INTEGER or C_STRING . The flag is_enumerated_type_constraint defined on C_PRIMITIVE indicates that a given C_PRIMITIVE is a constrainer for an enumerated type.

Since C_PRIMITIVEs don’t have type names in ADL, the type name is inferred by any parser or compiler tool that deserialises an archetype from ADL, and stored in the rm_type attribute inherited from C_OBJECT . An example is shown below of a type enumeration.

enumerated type constraint
Figure 17. Enumerated Constraint

A parser that deserialises from an object dump format such as ODIN, JSON or XML will not need to do this.

The form of the constraint itself is simply a series of Integer, String or other primitive values, or an equivalent range or ranges. In the above example, the ADL equivalent of the pk_percent, pk_fraction constraint on a field of type PROPORTION_KIND is in fact just \{2, 3}, and it is visualised by lookup to show the relevant symbolic names.

4.3. Second Order Constraints

All of the constraint semantics described above can be considered 'first order' in the sense that they define how specific object/attribute/object hierarchies are defined in the instance possibility space of some part of a reference model.

Some constraints however do not fit directly within the object/attribute/object hierarchy scheme, and are considered 'second order constraints' in the archetype formalism. The 'rule' constraints ('invariants' in ADL/AOM 1.4) constitute one such group. These constraints are defined in terms of first order predicate logic statements that can refer to any number of constraint nodes within the main hierarchy. These are described in Figure Rules Package.

Another type of second order constraint can be 'attached' to the object/attribute/object hierarchy in order to further limit structural possibilities. Although these constraints could also theoretically be expressed as rules, they are supported by direct additions to the main constraint model since they can be easily and intuitively represented inline in ADL and corresponding AOM structures.

4.3.1. Tuple Constraints

Tuple constraints are designed to account for the very common need to constrain the values of more than one RM class attribute together. This effectively treats the attributes in question as a tuple, and the corresponding object constraints are accordingly modelled as tuples as well. A detailed explanation of tuples can be found in the ADL2 specification’s section on second order constraints. Additions to the main constraint model to support tuples are shown below.

AOM constraint model tuple
Figure 18. Tuple Constraint Model

In this model, the type C_ATTRIBUTE_TUPLE groups the co-constrained C_ATTRIBUTEs under a C_COMPLEX_OBJECT. Currently the concrete type is limited to being C_PRIMITIVE_OBJECT to reduce complexity, and since it caters for all known examples of tuple constraints. In principle, any C_DEFINED_OBJECT could be allowed, and this may change in the future.

The tuple constraint type replaces all domain-specific constraint types defined in ADL/AOM 1.4, including C_DV_QUANTITY and C_DV_ORDINAL.

These additions allow standard constraint structures (i.e. C_ATTRIBUTE / C_COMPLEX_OBJECT / C_PRIMITIVE_OBJECT hierarchies) to be 'annotated', while leaving the first order structure intact. The following example shows an archetype instance structure in which a notional ORDINAL type is constrained. The logical requirement is to constrain a ORDINAL to one of three instance possibilities, each of which consists of a pair of values for the attributes value and symbol, of type Integer and TERMINOLOGY_CODE respectively. Each of these three instance constraints should be understood as an alternative for the single valued owning attribute, ELEMENT .value. Tuple constraints achieve the requirement to express the constraints as pairs not just as allowable alternatives at the final leaf level, which would incorrectly allowing any mixing of the Integer and code values.

AOM ordinal tuple example
Figure 19. Tuple Constraint Example AOM Instances
tuple example data
Figure 20. Tuple Constraint Example Data

4.3.2. Assertions

Assertions are also used in ARCHETYPE_SLOTs , in order to express the 'included' and 'excluded' archetypes for the slot. In this case, each assertion is an expression that refers to parts of other archetypes, such as its identifier (e.g. 'include archetypes with short_concept_name matching xxxx '). Assertions are modelled here as a generic expression tree of unary prefix and binary infix operators. Examples of archetype slots in ADL syntax are given in the openEHR ADL specification.

4.4. AOM Type Substitutions

The C_OBJECT types defined in Figure constraint_model Package are reproduced below, with concrete types that may actually occur in archetypes shown in dark yellow / non-italic.

c object substitutions
Figure 21. C_Object Substitutions

Within a specialised archetype, nodes that redefine corresponding nodes in the parent are normally of the same C_OBJECT type (we can think of this as a 'meta-type', since the RM type is the 'type' in the information model sense), but in some cases may also be of different C_OBJECT types.

The rules for meta-type redefinition are as follows:

  • A node of each meta-type can be redefined by a node of the same meta-type, with narrowed / added constraints;

  • ARCHETYPE_SLOT can be redefined by:

    • one or more C_ARCHETYPE_ROOT nodes taken together, considered to define a 'filled' version of the slot;

    • an ARCHETYPE_SLOT , in order to close the slot.

  • A C_ARCHETYPE_ROOT node can be redefined by:

    • A C_ARCHETYPE_ROOT , where the archetype_ref of the redefining node is a specialisation of that mentioned in the parent node.

  • A 'terminal' C_COMPLEX_OBJECT node containing no constraint other than RM type, node_id and possibly occurrences (i.e. having no substructure), can be redefined by a constraint of any other AOM type other than C_PRMITIVE_OBJECT.

The 'terminal' C_COMPLEX_OBJECT can be understood as a placeholder node primarily defined for the purpose of stating RM type and meaning (id-code).

4.5. Class Definitions

4.5.1. ARCHETYPE_CONSTRAINT Class

Class

ARCHETYPE_CONSTRAINT (abstract)

Description

Abstract parent of all constraint model types. Defines conformance and congruence function signatures.

Inherit

ADL_CODE_DEFINITIONS

Attributes

Signature

Meaning

0..1

parent: ARCHETYPE_CONSTRAINT

Parent node, except in the case of the top of a tree, i.e. root C_COMPLEX_OBJECT of an archetype definition.

0..1

soc_parent: C_SECOND_ORDER

Inverse relationship for ARCHETYPE_CONSTRAINT node owned by C_SECOND_ORDER.members attribute.

Functions

Signature

Meaning

is_prohibited (): Boolean

True if this node is prohibited. Implemented in subtypes.

has_path (
a_path: String[1]
): boolean

True if the relative path a_path exists at this node.

path (): String

Path of this node relative to root of archetype.

c_conforms_to (
other: ARCHETYPE_CONSTRAINT[1]
): Boolean

True if constraints represented by this node, ignoring any sub-parts, are narrower or the same as other. Typically used during validation of special-ised archetype nodes.

c_congruent_to (
other: ARCHETYPE_CONSTRAINT[1]
): Boolean

True if constraints represented by this node contain no further redefinitions with respect to the node other, with the exception of node_id redefnition in C_OBJECT nodes.

Typically used to test if an inherited node locally contains any constraints.

is_second_order_constrained (): Boolean
Post: soc_parent /= Void or else (parent /= Void and then parent.is_second_order_constrained)

True if there is a second order constraint such as a tuple constraint on this node.

is_root (): Boolean

True if this node is the root of the tree.

is_leaf (): Boolean

True if this node is a terminal node in the tree structure, i.e. having no child nodes.

4.5.2. C_ATTRIBUTE Class

Class

C_ATTRIBUTE

Description

Abstract model of constraint on any kind of attribute in a class model.

Inherit

ARCHETYPE_CONSTRAINT

Attributes

Signature

Meaning

1..1

rm_attribute_name: String

Reference model attribute within the enclosing type represented by a C_OBJECT.

0..1

existence: Multiplicity_interval

Constraint settable on every attribute, regardless of whether it is singular or of a container type, which indicates whether its target object exists or not (i.e. is mandatory or not). Only set if it overrides the underlying reference model or parent archetype in the case of specialised archetypes.

0..1

children: List<C_OBJECT>

Child C_OBJECT nodes. Each such node represents a constraint on the type of this attribute in its reference model. Multiples occur both for multiple items in the case of container attributes, and alternatives in the case of singular attributes.

0..1

differential_path: String

Path to the parent object of this attribute (i.e. doesn’t include the name of this attribute). Used only for attributes in differential form, specialised archetypes. Enables only the re-defined parts of a specialised archetype to be expressed, at the path where they occur.

0..1

cardinality: Cardinality

Cardinality constraint of attribute, if a container attribute.

1..1

is_multiple: Boolean

Flag indicating whether this attribute constraint is on a container (i.e. multiply-valued) attribute.

Functions

Signature

Meaning

any_allowed (): Boolean
Post: Result := children.is_empty and not is_prohibited

True if there is no effective constraint on the children of the RM attribute to which this C_ATTRIBUTE refers.

is_mandatory (): Boolean
Post: Result = existence /= Void and then existence.is_mandatory

True if this C_ATTRIBUTE has an existence constraint of 1..1, i..e. mandation.

rm_attribute_path (): String

Path of this attribute with respect to owning C_OBJECT, including differential path where applicable.

is_single (): Boolean

True if this node logically represents a single-valued attribute. Evaluated as not is_multiple.

(effected)

c_congruent_to (
other: ARCHETYPE_CONSTRAINT[1]
): Boolean
Post: Result = existence = Void and is_single and other.is_single) or (is_multiple and other.is_multiple and cardinality = Void

True if constraints represented by this node contain no further redefinitions with respect to the node other, with the exception of node_id redefnition in C_OBJECT nodes.

Typically used to test if an inherited node locally contains any constraints.

(effected)

c_conforms_to (
other: ARCHETYPE_CONSTRAINT[1]
): Boolean
Post: Result = existence_conforms_to (other) and is_single and other.is_single) or else (is_multiple and cardinality_conforms_to (other)

True if constraints represented by this node, ignoring any sub-parts, are narrower or the same as other. Typically used during validation of special-ised archetype nodes.

(effected)

is_prohibited (): Boolean
Post: Result = existence /= Void and then existence.is_prohibited

True if this C_ATTRIBUTE has an existence constraint of 0..0, i.e. prohibition.

4.5.2.1. Conformance Semantics

The following functions formally define the conformance of a C_ATRIBUTE node in a specialised archetype to the corresponding node in a parent archetype, where 'corresponding' means a node found at the same or a congruent path.

c_conforms_to (other: like Current): Boolean
        -- True if this node on its own (ignoring any subparts) expresses the same or narrower constraints as `other'.
        -- Returns False if any of the following is incompatible:
        --	 * cardinality
        --	 * existence
    require
        other /= Void
    do
        Result := existence_conforms_to (other) and
            ((is_single and other.is_single) or else
            (is_multiple and cardinality_conforms_to (other)))
    end

c_congruent_to (other: like Current): Boolean
		-- True if this node on its own (ignoring any subparts) expresses no additional constraints than `other'.
    require
        other /= Void
    do
        Result := existence = Void and ((is_single and other.is_single) or
                (is_multiple and other.is_multiple and cardinality = Void))
    end

existence_conforms_to (other: like Current): Boolean
		-- True if the existence of this node conforms to other.existence
    require
        other_exists: other /= Void
    do
        if existence /= Void and other.existence /= Void then
            Result := other.existence.contains (existence)
        else
            Result := True
        end
    end

cardinality_conforms_to (other: like Current): Boolean
		-- True if the cardinality of this node conforms to other.cardinality, if it exists
    require
        other_exists: other /= Void
    do
        if cardinality /= Void and other.cardinality /= Void then
            Result := other.cardinality.contains (cardinality)
        else
            Result := True
        end
    end
4.5.2.2. Validity Rules

The validity rules are as follows:

VCARM: attribute name reference model validity: an attribute name introducing an attribute constraint block must be defined in the underlying information model as an attribute (stored or computed) of the type which introduces the enclosing object block.

VCAEX: archetype attribute reference model existence conformance: the existence of an attribute, if set, must conform, i.e. be the same or narrower, to the existence of the corresponding attribute in the underlying information model.

VCAM: archetype attribute reference model multiplicity conformance: the multiplicity, i.e. whether an attribute is multiply- or single-valued, of an attribute must conform to that of the corresponding attribute in the underlying information model.

VDIFV: archetype attribute differential path validity: an archetype may only have a differential path if it is specialised..

The following validity rule applies to redefinition in a specialised archetype:

VDIFP: specialised archetype attribute differential path validity: if an attribute constraint has a differential path, the path must exist in the flat parent, and also be valid with respect to the reference model, i.e. in the sense that it corresponds to a legal potential construction of objects.

VSANCE: specialised archetype attribute node existence conformance: the existence of a redefined attribute node in a specialised archetype, if stated, must conform to the existence of the corresponding node in the flat parent archetype, by having an identical range, or a range wholly contained by the latter.

VSAM: specialised archetype attribute multiplicity conformance: the multiplicity, i.e. whether an attribute is multiply- or single-valued, of a redefined attribute must conform to that of the corresponding attribute in the parent archetype.

The following validity rules apply to single-valued attributes, i.e when C_ATTRIBUTE.is_multiple is False:

VACSO: single-valued attribute child object occurrences validity: the occurrences of a child object of a single-valued attribute cannot have an upper limit greater than 1.

The following validity rules apply to container attributes, i.e when C_ATTRIBUTE.is_multiple is True:

VACMCU: cardinality/occurrences upper bound validity: where a cardinality with a finite upper bound is stated on an attribute, for all immediate child objects for which an occurrences constraint is stated, the occurrences must either have an open upper bound (i.e. n..*) which is interpreted as the maximum value allowed within the cardinality, or else a finite upper bound which is ⇐ the cardinality upper bound.

VACMCO: cardinality/occurrences orphans: it must be possible for at least one instance of one optional child object (i.e. an object for which the occurrences lower bound is 0) and one instance of every mandatory child object (i.e. object constraints for which the occurrences lower bound is >= 1) to be included within the cardinality range.

VCACA: archetype attribute reference model cardinality conformance: the cardinality of an attribute must conform, i.e. be the same or narrower, to the cardinality of the corresponding attribute in the underlying information model.

The following validity warnings apply to container attributes, i.e when C_ATTRIBUTE.is_multiple is True:

WACMCL: cardinality/occurrences lower bound validity: where a cardinality with a finite upper bound is stated on an attribute, for all immediate child objects for which an occurrences constraint is stated, the sum of occurrences lower bounds should be lower than the cardinality upper limit.

The following validity rule applies to cardinality redefinition in a specialised archetype:

VSANCC: specialised archetype attribute node cardinality conformance: the cardinality of a redefined (multiply-valued) attribute node in a specialised archetype, if stated, must conform to the cardinality of the corresponding node in the flat parent archetype by either being identical, or being wholly contained by the latter.

4.5.3. C_OBJECT Class

Class

C_OBJECT (abstract)

Description

Abstract model of constraint on any kind of object node.

Inherit

ARCHETYPE_CONSTRAINT

Attributes

Signature

Meaning

1..1

rm_type_name: String

Reference model type that this node corresponds to.

0..1

occurrences: Multiplicity_interval

Occurrences of this object node in the data, under the owning attribute. Upper limit can only be greater than 1 if owning attribute has a cardinality of more than 1. Only set if it overrides the parent archetype in the case of specialised archetypes, or else the occurrences inferred from the underlying reference model existence and/or cardinality of the containing attribute.

1..1

node_id: String

Semantic identifier of this node, used to dis-tinguish sibling nodes. All nodes must have a node_id; for nodes under a container C_ATTRIBUTE, the id must be an id-code must be defined in the archetype terminology. For valid structures, all node ids are id-codes. For C_PRIMITIVE_OBJECTs, it will have the special value Primitive_node_id.

0..1

is_deprecated: Boolean

True if this node and by implication all sub-nodes are deprecated for use.

0..1

sibling_order: SIBLING_ORDER

Optional indicator of order of this node with respect to another sibling. Only meaningful in a specialised archetype for a C_OBJECT within a C_ATTRIBUTE with is_multiple = True.

Functions

Signature

Meaning

specialisation_depth (): Integer

Level of specialisation of this archetype node, based on its node_id. The value 0 corresponds to non-specialised, 1 to first-level specialisation and so on. The level is the same as the number of ‘.’ characters in the node_id code. If node_id is not set, the return value is -1, signifying that the specialisation level should be determined from the nearest parent C_OBJECT node having a node_id.

effective_occurrences (): Multiplicity_interval

occurrences_conforms_to (
other: C_OBJECT[1]
): Boolean

True if this node occurrences conforms to other.occurrences; `other' is assumed to be in a flat archetype.

Parameters
other

C_OBJECT from a flat parent archetype.

node_id_conforms_to (
other: C_OBJECT[1]
): Boolean
Post: Result = codes_conformant (node_id, other.node_id)

True if this node id conforms to other.node_id, which includes the ids being identical; other is assumed to be in a flat archetype.

(effected)

c_conforms_to (
other: ARCHETYPE_CONSTRAINT[1]
): Boolean

True if constraints represented by this node, ignoring any sub-parts, are narrower or the same as other. Typically used during validation of special-ised archetype nodes.

(effected)

c_congruent_to (
other: ARCHETYPE_CONSTRAINT[1]
): Boolean

True if constraints represented by this node contain no further redefinitions with respect to the node other, with the exception of node_id redefnition in C_OBJECT nodes.

Typically used to test if an inherited node locally contains any constraints.

(effected)

is_prohibited (): Boolean
Post: Result = occurrences /= Void and then occurrences.is_prohibited

True if this C_OBJECT node is prohibited, i.e. if its occurrences is 0..0.

4.5.4. SIBLING_ORDER Class

Class

SIBLING_ORDER

Description

Defines the order indicator that can be used on a C_OBJECT within a container attribute in a specialised archetype to indicate its order with respect to a sibling defined in a higher specialisation level.

Misuse: This type cannot be used on a C_OBJECT other than one within a container attribute in a specialised archetype.

Attributes

Signature

Meaning

1..1

is_before: Boolean

True if the order relationship is ‘before’, if False, it is ‘after’.

1..1

sibling_node_id: String

Node identifier of sibling before or after which this node should come.

Functions

Signature

Meaning

is_after (): Boolean

True if the order relationship is after, computed as the negation of is_before.

4.5.4.1. Occurrences inferencing rules

The notion of 'occurrences' does not exist in an object model that might be used as the reference model on which archteypes are based, because it is a class model. However, archetypes commonly constrain the occurrences of object nodes under a container attribute, indicating how many objects conforming to a specific object constraint node might exist.

There are various circumstances where it is useful to know the effective occurrences of an archetype object node. One is in validation, in order to determine validity of occurrences constraints; another is in archetype editor tools. Similarly, in an operational template, an occurrences constraint is required on all child object nodes of container attributes. Most such constraints come from the source template(s) and archetypes, but often there will be nodes with no occurrences set. In these cases, the occurrences constraint is inferred from the archetype and the reference model according to the following algorithm, where c_object represents any object node in an archetype.

effective_occurrences (rm_prop_mult: FUNCTION [args: TUPLE[rm_type_name: STRING, rm_property_path: STRING], result: MULTIPLICITY_INTERVAL]): MULTIPLICITY_INTERVAL
        -- evaluate effective occurrences, using the RM when no occurrences constraint or parent node
        -- cardinality exists.
        -- In this case, the upper limit of the RM's owning attribute is used to provide a value.
        -- `rm_prop_mult' is a function object that knows how to compute effective object multiplicity
        -- by looking at the owning RM property.
    local
        occ_lower: INTEGER
    do
        if occurrences /= Void then
            Result := occurrences

        elseif parent /= Void then
            if parent.existence /= Void then
                occ_lower := parent.existence.lower
            end
            if parent.cardinality /= Void then
                if parent.cardinality.interval.upper_unbounded then
                    create Result.make_upper_unbounded (occ_lower)
                else
                    create Result.make_bounded (occ_lower, parent.cardinality.interval.upper)
                end
            elseif parent.parent /= Void then
                Result := rm_prop_mult (parent.parent.rm_type_name, parent.parent.rm_attribute_path)
            else
                create Result.make_upper_unbounded (occ_lower)
            end
        else
            create Result.make_open
        end
    end

In the above, rm_prop_mult is a reference to a function within an RM schema representation, which has the following logic:

object_multiplicity (rm_type_name: STRING, rm_property_path: STRING): MULTIPLICITY_INTERVAL
        -- compute the effective object multiplicity of objects at rm_property_path within type rm_type_name
        -- from the Reference Model
    do
        rm_property_def := get_rm_property_def (rm_type_name: STRING, rm_property_path: STRING)
        if rm_property_def.is_container then
            if rm_property_def.cardinality.upper_unbounded then
                create Result.make_upper_unbounded (0)
            else
                create Result.make_bounded (0, rm_property_def.cardinality.upper)
            end
        else
            Result := rm_property_def.existence
        end
    end

How this is concretely implemented depends on the modelling environment. Once possible RM model implementation is described in the openEHR Basic meta-model (BMM) specification.

4.5.4.2. Conformance semantics

The following functions formally define the conformance of a C_OBJECT node in a specialised archetype to the corresponding node in a parent archetype, where 'corresponding' means a node found at the same or a congruent path.

c_conforms_to (other: like Current; agent rm_types_conformant (a_type, other_type: String)): Boolean
        -- True if this node on its own (ignoring any subparts) expresses the same or narrower constraints
        -- as `other'.
        -- `other' is typically from the flat parent archetype.
        -- Returns True only when the following is True:
        --	 * rm_type_name is the same or a subtype of rm_type_name of other;
        --	 * occurrences is same (= Void) or a sub-interval
        --	 * node_id is the same, or redefined to a legal code at the level of the owning archetype
        -- `rm_types_conformant' is an agent (lambda) that can test an RM type's conformance to another RM type
    require
        other /= Void
        rm_types_conformant /= Void
    do
        Result := node_id_conforms_to (other) and
            occurrences_conforms_to (other) and
            (rm_type_name.is_case_insensitive_equal (other.rm_type_name) or else
            rm_types_conformant (rm_type_name, other.rm_type_name))
    end

c_congruent_to (other: like Current): Boolean
        -- True if this node on its own (ignoring any subparts) expresses no constraints in addition
        -- to `other', other than possible redefinition of the node id, which doesn't matter, since
        -- this won't get lost in a compressed path.
        -- Current and `other' are typically from flat archetypes being compared to generate a diff.
        -- Used to determine if path segments can be compressed.
        -- Returns True if:
        --	 * rm_type_name is identical
        --	 * occurrences is Void or else identical to other.occurrences
        -- 	 * sibling_order is Void or else identical to other.sibling_order
        --	 * node_id is identical or else is the only child that overlays the parent node
    require
        other /= Void
    do
        Result := rm_type_name.is_case_insensitive_equal (other.rm_type_name) and
            (occurrences = Void or else (other.occurrences /= Void and then
                occurrences.is_equal (other.occurrences))) and
            (sibling_order = Void or else (other.sibling_order /= Void and then
                sibling_order.is_equal (other.sibling_order))) and
            node_reuse_congruent (other)
    end

occurrences_conforms_to (other: like Current): Boolean
    require
        other_exists: other /= Void
    do
        if occurrences /= Void and other.occurrences /= Void then
            Result := other.occurrences.contains (occurrences)
        else
            Result := True
        end
    end

node_id_conforms_to (other: like Current): Boolean
    require
        other_exists: other /= Void
    do
        Result := codes_conformant (node_id, other.node_id)
    end

node_reuse_congruent (other: like Current): BOOLEAN
        -- True if this node is the sole re-using node of the corresponding node in the flat
    do
        Result := node_id_conforms_to (other) and
            (is_root or else
            attached parent and then parent.child_reuse_count (other.node_id) = 1)
    end
4.5.4.3. Validity Rules

The validity rules for all C_OBJECTs are as follows:

VCORM object constraint type name existence: a type name introducing an object constraint block must be defined in the underlying information model.

VCORMT object constraint type validity: a type name introducing an object constraint block must be the same as or conform to the type stated in the underlying information model of its owning attribute.

VCOCD object constraint definition validity: an object constraint block consists of one of the following (depending on subtype): an 'any' constraint; a reference; an inline definition of sub-constraints, or nothing, in the case where occurrences is set to {0}.

VCOID object node identifier validity: every object node must have a node identifier.

VCOSU object node identifier validity: every object node must be unique within the archetype.

The following validity rules govern C_OBJECTs in specialised archetypes.

VSONT specialised archetype object node meta-type conformance: the meta-type of a redefined object node (i.e. the AOM node type such as C_COMPLEX_OBJECT etc) in a specialised archetype must be the same as that of the corresponding node in the flat parent, with the following exceptions: a C_COMPLEX_OBJECT with no child attributes may be redefined by a node of any AOM type except C_PRIMITIVE_OBJECT; a C_COMPLEX_OBJECT_PROXY, may be redefined by a C_COMPLEX_OBJECT; an ARCHTEYPE_SLOT may be redefined by C_ARCHETYPE_ROOT (i.e. 'slot-filling'). See also validity rules VDSSID and VARXID.

VSONCT specialised archetype object node reference type conformance: the reference model type of a redefined object node in a specialised archetype must conform to the reference model type in the corresponding node in the flat parent archetype by either being identical, or conforming via an inheritance relationship in the relevant reference model.

Deprecated: VSONIR specialised archetype redefined object node identifier condition: the node identifier of an object node in a specialised archetype that is a redefinition of a node in the flat parent must be redefined if any of reference model type, node identifier definition in the terminology, or occurrences of the immediate object constraint is redefined, with the exception of occurrences being redefined to {0}, i.e. exclusion.

Deprecated: VSONI specialised archetype redefined object node identifier validity: if an object node in a specialised archetype is a redefinition of a node in the flat parent according to VSONIR, and the parent node carries a node identifier, it must carry a node identifier specalised at the level of the child archetype. Otherwise it must carry the same node identifier (or none) as the corresponding parent node.

VSONIN specialised archetype new object node identifier validity: if an object node in a specialised archetype is a new node with respect to the flat parent, and it carries a node identifier, the identifier must be a 'new' node identifier, specalised at the level of the child archetype.

VSONIF specialised archetype object node identifier validity in flat siblings: the identification (or not) of an object node in a specialised archetype must be valid with respect to any sibling object nodes in the flattened parent (see VACMI).

VSONCO specialised archetype redefine object node occurrences validity: the occurrences of a redefined object node in a specialised archetype, if stated, must conform to the occurrences in the corresponding node in the flat parent archetype by either being identical, or being wholly contained by the latter.

VSONPT specialised archetype prohibited object node AOM type validity: the occurrences of a redefined object node in a specialised archetype, may only be prohibited (i.e. {0}) if the matching node in the parent is of the same AOM type.

VSONPI specialised archetype prohibited object node AOM node id validity: a redefined object node in a specialised archetype with occurrences matching {0} must have exactly the same node_id as the node in the flat parent being redefined.

VSONPO specialised archetype object node prohibited occurrences validity: the occurrences of a new (i.e. having no corresponding node in the parent flat) object node in a specialised archetype, if stated, may not be 'prohibited', i.e. {0}, since prohibition only makes sense for an existing node.

VSSM specialised archetype sibling order validity: the sibling order node id code used in a sibling marker in a specialised archetype must refer to a node found within the same container in the flat parent archetype.

4.5.5. C_DEFINED_OBJECT Class

Class

C_DEFINED_OBJECT (abstract)

Description

Abstract parent type of C_OBJECT subtypes that are defined by value, i.e. whose definitions are actually in the archetype rather than being by reference.

Inherit

C_OBJECT

Attributes

Signature

Meaning

0..1

default_value: Any

Default value set in a template, and present in an operational template. Generally limited to leaf and near-leaf nodes.

Functions

Signature

Meaning

valid_value (
a_value: Any[1]
): Boolean

True if a_value is valid with respect to constraint expressed in concrete instance of this type.

prototype_value (): Any

Generate a prototype value from this constraint object.

has_default_value (): Boolean

True if there is an assumed value.

4.5.6. C_COMPLEX_OBJECT Class

Class

C_COMPLEX_OBJECT

Description

Constraint on complex objects, i.e. any object that consists of other object constraints.

Inherit

C_DEFINED_OBJECT

Attributes

Signature

Meaning

0..1

attributes: List<C_ATTRIBUTE>

List of constraints on attributes of the reference model type represented by this object.

0..1

attribute_tuples: List<C_ATTRIBUTE_TUPLE>

List of attribute tuple constraints under this object constraint, if any.

Functions

Signature

Meaning

any_allowed (): Boolean

True if any value (i.e. instance) of the reference model type would be allowed. Redefined in descendants.

4.5.6.1. Validity Rules

The validity rules for C_COMPLEX_OBJECTs are as follows:

VCATU attribute uniqueness: sibling attributes occurring within an object node must be uniquely named with respect to each other, in the same way as for class definitions in an object reference model.

4.5.7. C_ARCHETYPE_ROOT Class

Class

C_ARCHETYPE_ROOT

Description

A specialisation of C_COMPLEX_OBJECT whose node_id attribute is an archetype identifier rather than the normal internal node code (i.e. id-code).

Used in two situations. The first is to represent an 'external reference' to an archetype from within another archetype or template. This supports re-use. The second use is within a template, where it is used as a slot-filler.

For a new external reference, the node_id is set in the normal way, i.e. with a new code at the specialisation level of the archetype. For a slot-filler or a redefined external reference, the node_id is set to a specialised version of the node_id of the node being specialised, allowing matching to occur during flattening.

In all uses within source archetypes and templates, the children attribute is Void.

In an operational template, the node_id is converted to the archetype_ref, and the structure contains the result of flattening any template overlay structure and the underlying flat archetype.

Inherit

C_COMPLEX_OBJECT

Attributes

Signature

Meaning

1..1

archetype_ref: String

Reference to archetype is being used to fill a slot or redefine an external reference. Typically an 'interface' archetype id, i.e. identifier with partial version information.

4.5.7.1. Validity Rules

The following validity rules apply to C_ARCHETYPE_ROOT objects:

VARXNC external reference node identifier validity: if the external reference object is a redefinition of either a slot node, or another external reference node, the node_id of the object must conform to (i.e. be the same or a child of) the node_id of the corresponding parent node.

VARXAV external reference node archetype reference validity: if the reference object is a redefinition of another external reference node, the archetype_ref of the object must match a real archetype that has as an ancestor the archetype matched by the archetype reference mentioned in the corresponding parent node.

VARXTV external reference type validity: the reference model type of the reference object archetype identifier must be identical, or conform to the type of the slot, if there is one, in the parent archetype, or else to the reference model type of the attribute in the flat parent under which the reference object appears in the child archetype.

VARXR external reference refers to resolvable artefact: the archetype reference must refer to an artefact that can be found in the current repository.

The following validity rules apply to a C_ARCHETYPE_ROOT that specialises a ARCHETYPE_SLOT in the flat parent archetype:

VARXS external reference slot conformance: where an archetype reference redefines an archetype slot in the flat parent, it must conform to the archetype slot node by being of a reference model type from the same reference model as the current archetype.

VARXID external reference slot filling id validity: an external reference node defined as a filler for a slot in the parent archetype must have a node id that is a specialisation of that of the slot.

4.5.8. ARCHETYPE_SLOT Class

Class

ARCHETYPE_SLOT

Description

Constraint describing a slot' where another archetype can occur.

Inherit

C_OBJECT

Attributes

Signature

Meaning

0..1

includes: List<ASSERTION>

List of constraints defining other archetypes that could be included at this point.

0..1

excludes: List<ASSERTION>

List of constraints defining other archetypes that cannot be included at this point.

1..1

is_closed: Boolean

True if this slot specification in this artefact is closed to further filling either in further specialisations or at runtime. Default value False, i.e. unless explicitly set, a slot remains open.

Functions

Signature

Meaning

any_allowed (): Boolean

True if no constraints stated, and slot is not closed.

4.5.8.1. Validity Rules

The validity rules for ARCHETYPE_SLOTs are as follows:

VDFAI archetype identifier validity in definition. Any archetype identifier mentioned in an archetype slot in the definition section must conform to the published openEHR specification for archetype identifiers.

VDSIV archetype slot 'include' constraint validity. The 'include' constraint in an archetype slot must conform to the slot constraint validity rules.

VDSEV archetype slot 'exclude' constraint validity. The 'exclude' constraint in an archetype slot must conform to the slot constraint validity rules.

The slot constraint validity rules are as follows:

if includes not empty and = any then
    not (excludes empty or /= any) ==> VDSEV Error
elseif includes not empty and /= any then
    not (excludes empty or = any) ==> VDSEV Error
elseif excludes not empty and = any then
    not (includes empty or /= any) ==> VDSIV Error
elseif excludes not empty and /= any then
    not (includes empty or = any) ==> VDSIV Error
end

The following validity rules apply to ARCHETYPE_SLOTs defined as the specialisation of a slot in the parent archetype:

VDSSID slot redefinition child node id: a slot node in a specialised archetype that redefines a slot node in the flat parent must have an identical node id.

VDSSM specialised archetype slot definition match validity. The set of archetypes matched from a library of archetypes by a specialised archetype slot definition must be a proper subset of the set matched from the same library by the parent slot definition.

VDSSP specialised archetype slot definition parent validity. The flat parent of the specialisation of an archetype slot must be not be closed (is_closed = False).

VDSSC specialised archetype slot definition closed validity. In the specialisation of an archetype slot, either the slot can be specified to be closed (is_closed = True) or the slot can be narrowed, but not both.

4.5.9. C_COMPLEX_OBJECT_PROXY Class

Class

C_COMPLEX_OBJECT_PROXY

Description

A constraint defined by proxy, using a reference to an object constraint defined elsewhere in the same archetype. Note that since this object refers to another node, there are two objects with available occurrences values. The local occurrences value on a COMPLEX_OBJECT_PROXY should always be used; when setting this from a serialised form, if no occurrences is mentioned, the target occurrences should be used (not the standard default of {1..1}); otherwise the locally specified occurrences should be used as normal. When serialising out, if the occurrences is the same as that of the target, it can be left out.

Inherit

C_OBJECT

Attributes

Signature

Meaning

1..1

target_path: String

Reference to an object node using archetype path notation.

Functions

Signature

Meaning

use_target_occurrences (): Boolean
Post: Result = (occurrences = Void)

True if target occurrences are to be used as the value of occurrences in this object; by the time of runtime use, the target occurrences value has to be set into this object.

(effected)

occurrences_conforms_to (
other: C_OBJECT[1]
): Boolean

True if this node occurrences conforms to other.occurrences; other is assumed to be in a flat archetype.

If other is a C_COMPLEX_OBJECT, then always True, since if occurrences defined on proxy node, it is an override of the occurrences on the target, and it doesn’t have to conform to anything except the containing attribute’s cardinality. However, if other is also a C_COMPLEX_OBJECT then the override is of another use_node, and normal occurrences apply

Parameters
other

C_OBJECT from a flat parent archetype.

4.5.9.1. Validity Rules

The following validity rules applies to internal references:

VUNT use_node reference model type validity: the reference model type mentioned in an C_COMPLEX_OBJECT_PROXY node must be the same as or a super-type (according to the reference model) of the reference model type of the node referred to.

VUNP use_node path validity: the path mentioned in a use_node statement must refer to an object node defined elsewhere in the same archetype or any of its specialisation parent archetypes, that is not itself an internal reference node, and which carries a node identifier if one is needed at the reference point.

The following validity rule applies to the redefinition of an internal reference in a specialised archetype:

VSUNT use_node specialisation parent validity: a C_COMPLEX_OBJECT_PROXY node may be redefined in a specialised archetype by another C_COMPLEX_OBJECT_PROXY (e.g. in order to redefine occurrences), or by a C_COMPLEX_OBJECT structure that legally redefines the target C_COMPLEX_OBJECT node referred to by the reference.

4.5.10. C_PRIMITIVE_OBJECT Class

Class

C_PRIMITIVE_OBJECT (abstract)

Description

Parent of types representing constraints on primitive types.

Inherit

C_DEFINED_OBJECT

Attributes

Signature

Meaning

0..1

assumed_value: Any

Value to be assumed if none sent in data.

0..1

is_enumerated_type_constraint: Boolean

True if this object represents a constraint on an enumerated type from the reference model, where the latter is assumed to be based on a primitive type, generally Integer or String.

1..1

constraint: Any

Constraint represented by this object; redefine in descendants.

Functions

Signature

Meaning

has_assumed_value (): Boolean

True if there is an assumed value.

constrained_typename (): String

Generate name of native type that is constrained by this C_XXX type. For most types, it is the C_XXX typename without the C_, i.e. XXX. E.g. C_INTEGERInteger. For the date/time types the mapping is different.

4.5.10.1. Validity Rules

Validity rules applying to all C_PRIMITIVE_OBJECT types are as follows:

VOBAV object node assumed value validity: the value of an assumed value must fall within the value space defined by the constraint to which it is attached.

4.5.10.2. Conformance semantics

The following functions formally define the conformance of a node of a C_PRIMITIVE_OBJECT descendant type in a specialised archetype to a corresponding node in a parent archetype, where 'corresponding' means a node found at the same or a congruent path and of the same AOM type.

c_conforms_to (other: like Current; agent rm_types_conformant (a_type, other_type: String)): Boolean
        -- True if this node on its own (ignoring any subparts) expresses the same or narrower constraints
        -- as `other'. Returns True only when the following is True:
        --   * occurrences conforms
        --   * `rm_type_name' is identical to that in `other'
        -- `rm_types_conformant' is an agent (lambda) that can test an RM type's conformance to another RM type
    require
        other /= Void
        rm_types_conformant /= Void
    do
        Result := occurrences_conforms_to (other) and rm_type_name.is_case_insensitive_equal (other.rm_type_name)
    end

c_congruent_to (other: like Current): Boolean
        -- True if this node on its own (ignoring any subparts) expresses no constraints in addition to `other'
    require
        other /= Void
    do
		Result := rm_typename.is_case_insensitive_equal (other.rm_typename)
    end

4.5.11. C_BOOLEAN Class

Class

C_BOOLEAN

Description

Constraint on instances of Boolean. Both attributes cannot be set to False, since this would mean that the Boolean value being constrained cannot be True or False.

Inherit

C_PRIMITIVE_OBJECT

Attributes

Signature

Meaning

0..1
(redefined)

constraint: List<Boolean>

Boolean constraint - a list of Boolean values.

0..1
(redefined)

assumed_value: Boolean

Assumed Boolean value.

1..1
(redefined)

default_value: Boolean

Default Boolean value.

Functions

Signature

Meaning

(effected)

prototype_value (): Boolean

Prototype Boolean value.

4.5.11.1. Conformance semantics

The following functions formally define the conformance of a C_BOOLEAN node in a specialised archetype to a corresponding node in a parent archetype, where 'corresponding' means a node found at the same or a congruent path and of the same AOM type.

c_conforms_to (other: like Current; agent rm_types_conformant (a_type, other_type: String)): Boolean
        -- True if this node on its own (ignoring any subparts) expresses the same or narrower constraints
        -- as `other'. Returns True only when the following is True:
        --   * C_PRIMITIVE_OBJECT conditions are met and
        --   * every `constraint' value is in `other.constraint'
        -- `rm_types_conformant' is an agent (lambda) that can test an RM type's conformance to another RM type
    require
        other /= Void
        rm_types_conformant /= Void
    do
        Result := precursor (other, rm_type_conformance_checker) and  -- precursor is from C_PRIMITIVE_OBJECT
            constraint.count < other.constraint.count and
            across constraint as val_csr all other.constraint.has (val_csr.item) end
    end

c_congruent_to (other: like Current): Boolean
        -- True if this node on its own (ignoring any subparts) expresses no constraints in addition to `other'
    require
        other /= Void
    do
        Result := precursor (other) and   -- precursor is from C_PRIMITIVE_OBJECT
            constraint.count = other.constraint.count and
            across constraint as val_csr all other.constraint.has (val_csr.item) end
    end

4.5.12. C_STRING Class

Class

C_STRING

Description

Constraint on instances of String.

Inherit

C_PRIMITIVE_OBJECT

Attributes

Signature

Meaning

1..1
(redefined)

constraint: List<String>

String constraint - a list of literal strings and / or regular expression strings delimited by the ‘/’ character.

1..1
(redefined)

default_value: String

Default String value.

0..1
(redefined)

assumed_value: String

Assumed String value.

Functions

Signature

Meaning

(effected)

prototype_value (): String

(effected)

valid_value (
a_value: String[1]
): Boolean

True if a_value is valid with respect to constraint expressed in concrete instance of this type.

TBD: there is an argument for only allowing a single String value rather than a list, where the value is aways a regex since {"platypus", "kangaroo", "wombat"} can be expressed as {/platypus|kangaroo|wombat/}. See also ADL spec.

4.5.12.1. Conformance semantics

The following functions formally define the conformance of a C_STRING node in a specialised archetype to a corresponding node in a parent archetype, where 'corresponding' means a node found at the same or a congruent path and of the same AOM type.

c_conforms_to (other: like Current; agent rm_types_conformant (a_type, other_type: String)): Boolean
        -- True if this node on its own (ignoring any subparts) expresses the same or narrower constraints
        -- as `other'. Returns True only when the following is True:
        --   * C_PRIMITIVE_OBJECT conditions are met and
        --   * every `constraint' string or pattern is in `other.constraint'
        -- `rm_types_conformant' is an agent (lambda) that can test an RM type's conformance to another RM type
    require
        other /= Void
        rm_types_conformant /= Void
    do
        Result := precursor (other, rm_type_conformance_checker) and -- precursor is from C_PRIMITIVE_OBJECT
            constraint.count < other.constraint.count and
            across constraint as constraint_csr all other.constraint.has (constraint_csr.item) end
end

c_congruent_to (other: like Current): Boolean
        -- True if this node on its own (ignoring any subparts) expresses no constraints in addition to `other'
    require
        other /= Void
    do
        Result := precursor (other) and -- precursor is from C_PRIMITIVE_OBJECT
            constraint.count = other.constraint.count and then
            across constraint as str_csr all
                other.constraint.i_th (str_csr.cursor_index).is_equal (str_csr.item)
            end
    end

4.5.13. C_ORDERED Class

Class

C_ORDERED (abstract)

Description

Abstract parent of primitive constrainer classes based on Ordered base types, i.e. types like Integer, Real, and the Date/Time types. The model constraint is a List of Intervals, which may include point Intervals, and acts as a efficient and formally tractable representation of any number of point values and/or contiguous intervals of an ordered value domain.

In its simplest form, the constraint accessor returns just a single point Interval<T> object, representing a single value.

The next simplest form is a single proper Interval <T> (i.e. normal two-sided or half-open interval). The most complex form is a list of any combination of point and proper intervals.

Inherit

C_PRIMITIVE_OBJECT

Attributes

Signature

Meaning

0..1
(redefined)

constraint: List<Interval>

Constraint in the form of a List of Intervals of the parameter type T. Concrete types generated in descendants via template binding.

4.5.13.1. Conformance semantics

The following functions formally define the conformance of a node of a C_ORDERED descendant type in a specialised archetype to a corresponding node in a parent archetype, where 'corresponding' means a node found at the same or a congruent path and of the same AOM type.

c_conforms_to (other: like Current; agent rm_types_conformant (a_type, other_type: String)): Boolean
        -- True if this node on its own (ignoring any subparts) expresses the same or narrower constraints
        -- as `other'. Returns True only when the following is True:
        --   * C_PRIMITIVE_OBJECT conditions are met and
        --   * every interval constraint (if amy exist) is inside at least one interval in other.constraint
        -- `rm_types_conformant' is an agent (lambda) that can test an RM type's conformance to another RM type
    require
        other /= Void
        rm_types_conformant /= Void
    do
        if precursor (other, rm_types_conformant) and -- precursor is from C_PRIMITIVE_OBJECT
            across constraint as ivl_csr all
                across other.constraint as other_ivl_csr some other_ivl_csr.item.contains (ivl_csr.item) end
            end
        end
    end

c_congruent_to (other: like Current): Boolean
        -- True if this node on its own (ignoring any subparts) expresses no constraints in addition to `other'
    require
        other /= Void
    do
        Result := precursor (other) and  -- precursor is from C_PRIMITIVE_OBJECT
            constraint.count = other.constraint.count and
            across constraint as ivl_csr all
                ivl_csr.item.is_equal (other.constraint.i_th (ivl_csr.cursor_index))
            end
    end

4.5.14. C_INTEGER Class

Class

C_INTEGER

Description

Constraint on instances of Integer.

Inherit

C_ORDERED

Attributes

Signature

Meaning

1..1
(redefined)

constraint: List<Interval<Integer>>

Formal constraint on Integer, in the form of List<Interval<Integer>>.

4.5.15. C_REAL Class

Class

C_REAL

Description

Constraint on instances of Real.

Inherit

C_ORDERED

Attributes

Signature

Meaning

1..1
(redefined)

constraint: List<Interval<Real>>

Formal constraint on Real, in the form of List<Interval<Real>>.

4.5.16. C_TEMPORAL Class

Class

C_TEMPORAL (abstract)

Description

Purpose Abstract parent of C_ORDERED types whose base type is an ISO date/time type.

Inherit

C_ORDERED

Attributes

Signature

Meaning

0..1

pattern_constraint: String

Optional alternative constraint in the form of a pattern based on ISO8601. See descendants for details.

Functions

Signature

Meaning

valid_pattern_constraint (
a_pattern: String[1]
): Boolean

True if a_pattern is a valid constraint. Define in concrete descendants.

valid_pattern_constraint_replacement (
a_pattern: String[1],
an_other_pattern: String[1]
): Boolean

Return True if a_pattern can be replaced by an_other_pattern in a specialised constraint. Define in concrete subtypes.

4.5.16.1. Conformance semantics

The following functions formally define the conformance of a node of a C_TEMPORAL descendant type in a specialised archetype to a corresponding node in a parent archetype, where 'corresponding' means a node found at the same or a congruent path and of the same AOM type.

c_conforms_to (other: like Current; agent rm_types_conformant (a_type, other_type: String)): Boolean
        -- True if this node on its own (ignoring any subparts) expresses the same or narrower constraints
        -- as `other'. Returns True only when the following is True:
        --   * C_ORDERED conditions are met and
        --   * every interval in `constraint' (if amy exist) is inside an interval in `other.constraint'
        --   * if `pattern_constraint' exists, it is the same or a valid replacement of that in `other'.
        -- `rm_types_conformant' is an agent (lambda) that can test an RM type's conformance to another RM type
    require
        other /= Void
        rm_types_conformant /= Void
    do
        if precursor (other, rm_types_conformant) then -- precursor is from C_ORDERED
            if not pattern_constraint.is_empty and not other.pattern_constraint.is_empty then
                Result := valid_pattern_constraint_replacement (pattern_constraint, other.pattern_constraint)
            else
                Result := pattern_constraint.is_empty and other.pattern_constraint.is_empty
            end
        end
    end

c_congruent_to (other: like Current): Boolean
        -- True if this node on its own (ignoring any subparts) expresses no constraints in addition to `other'
    require
        other /= Void
    do
        if precursor (other) then -- precursor is from C_ORDERED
            if not pattern_constraint.is_empty and not other.pattern_constraint.is_empty then
                Result := pattern_constraint.is_equal (other.pattern_constraint)
            else
                Result := pattern_constraint.is_empty and other.pattern_constraint.is_empty
            end
        end
    end

4.5.17. C_DATE Class

Class

C_DATE

Description

Constraint on instances of Date in the form either of a set of validity values, or else date ranges based on the C_ORDERED list constraint. There is no validity flag for year, since it must always be by definition mandatory in order to have a sensible date at all. Syntax expressions of instances of this class include "YYYY-??-??" (date with optional month and day).

Inherit

C_TEMPORAL

Attributes

Signature

Meaning

0..1
(redefined)

constraint: List<Interval<IDate>>

Formal constraint on an assumed primitive Date type, in the form of List of Interval<Date>, i.e. one or more intervals of Date.

Functions

Signature

Meaning

month_validity (): VALIDITY_KIND

Validity of month in constrained date.

day_validity (): VALIDITY_KIND

Validity of day in constrained date.

timezone_validity (): VALIDITY_KIND

Validity of timezone in constrained date.

Invariants

Pattern_validity: pattern /= Void implies valid_iso8601_date_constraint_pattern(pattern)

4.5.18. C_TIME Class

Class

C_TIME

Description

Constraint on instances of assumed primitive type Time in the form either of a set of validity values, or else date ranges based on the C_ORDERED list constraint. There is no validity flag for hour, since it must always be by definition mandatory in order to have a sensible time at all. Syntax expressions of instances of this class include “HH:??:xx” (time with optional minutes and seconds not allowed).

Inherit

C_TEMPORAL

Attributes

Signature

Meaning

0..1
(redefined)

constraint: List<Interval<ITime>>

Formal constraint on assumed primitive type Time, in the form of a List of Interval<Time>, i.e. one or more intervals of Time.

Functions

Signature

Meaning

minute_validity (): VALIDITY_KIND

Validity of minute in constrained time.

second_validity (): VALIDITY_KIND

Validity of second in constrained time.

millisecond_validity (): VALIDITY_KIND

Validity of millisecond in constrained time.

timezone_validity (): VALIDITY_KIND

Validity of timezone in constrained date.

Invariants

Pattern_validity: pattern /= Void implies valid_iso8601_time_constraint_pattern (pattern)

4.5.19. C_DATE_TIME Class

Class

C_DATE_TIME

Description

Constraint on instances of assumed primitive type Date_time. There is no validity flag for year, since it must always be by definition mandatory in order to have a sensible date/time at all. Syntax expressions of instances of this class include "YYYY-MM-DDT??:??:??" (date/time with optional time) and "YYYY-MMDDTHH:MM:xx" (date/time, seconds not allowed).

Inherit

C_TEMPORAL

Attributes

Signature

Meaning

0..1
(redefined)

constraint: List<Interval<IDate_time>>

Formal constraint on assumed primitive type Date_time, in the form of List of Interval<Date_time>, i.e. one or more intervals of Date_time.

Functions

Signature

Meaning

month_validity (): VALIDITY_KIND

Validity of month in constrained date.

day_validity (): VALIDITY_KIND

Validity of day in constrained date.

timezone_validity (): VALIDITY_KIND

Validity of timezone in constrained date.

minute_validity (): VALIDITY_KIND

Validity of minute in constrained time.

second_validity (): VALIDITY_KIND

Validity of second in constrained time.

millisecond_validity (): VALIDITY_KIND

Validity of millisecond in constrained time.

Invariants

Pattern_validity: pattern /= Void implies valid_iso8601_date_time_constraint_pattern(pattern)

4.5.20. C_DURATION Class

Class

C_DURATION

Description

Constraint on instances of assumed primitive type Duration, which is assumed to have the same parts as the ISO8601 duration string. Thus, constraints are of the form "PWD" (weeks and/or days), "PDTHMS" (days, hours, minutes, seconds) and so on.

In official ISO 8601:2004, the ‘W’ (week) designator cannot be mixed in; allowing it is an openEHR-wide exception. The allowed patterns are: P[Y|y][M|m][D|d][T[H|h][M|m][S|s]] and P[W|w].

Inherit

C_TEMPORAL

Attributes

Signature

Meaning

0..1
(redefined)

constraint: List<Interval<IDuration>>

Formal constraint on assumed primitive type Duration, in the form of List of Interval<Duration>, i.e. one or more intervals of Duration.

Functions

Signature

Meaning

years_allowed: (): Boolean

True if years are allowed in the constrained Duration.

months_allowed: (): Boolean

True if months are allowed in the constrained Duration.

weeks_allowed: (): Boolean

True if weeks are allowed in the constrained Duration.

days_allowed (): Boolean

True if days are allowed in the constrained Duration.

hours_allowed (): Boolean

True if hours are allowed in the constrained Duration.

minutes_allowed (): Boolean

True if minutes are allowed in the constrained Duration.

seconds_allowed (): Boolean

True if seconds are allowed in the constrained Duration.

4.5.21. C_TERMINOLOGY_CODE Class

Class

C_TERMINOLOGY_CODE

Description

Constrainer type for instances of Terminology_code. The constraint attribute can contain:

  • a single at-code

  • a single ac-code, representing a value-set that is defined in the archetype terminology

If there is an assumed value for the ac-code case above, the assumed_value attribute contains a single at-code, which must come from the list of at-codes defined as the internal value set for the ac-code.

Inherit

C_PRIMITIVE_OBJECT

Attributes

Signature

Meaning

1..1
(redefined)

constraint: String

Type of individual constraint - a single string that can either be a local at-code, or a local ac-code signifying a locally defined value set. If an ac-code, assumed_value may contain an at-code from the value set of the ac-code.

0..1
(redefined)

assumed_value: Terminology_code

Assumed Terminology code value.

1..1
(redefined)

default_value: Terminology_code

Functions

Signature

Meaning

value_set_expanded (): List<String>

Effective set of at-code values corresponding to an ac-code for a locally defined value set. Not defined for ac-codes that have no local value set.

value_set_substituted (): List<Uri>

For locally defined value sets within individual code bindings: return the term URI(s) substituted from bindings for local at-codes in value_set_expanded.

value_set_resolved (): List<Terminology_code>

For locally defined value sets within individual code bindings: final set of external codes to which value set is resolved.

(effected)

valid_value (
a_value: Terminology_code[1]
): Boolean

True if a value is valid with respect to constraint expressed in concrete instance of this type.

(effected)

prototype_value (): Terminology_code

A generated prototype value from this constraint object.

4.5.21.1. Conformance semantics

The following functions formally define the conformance of a C_TERMINOLOGY_CODE node in a specialised archetype to a corresponding node in a parent archetype, where 'corresponding' means a node found at the same or a congruent path and of the same AOM type.

c_conforms_to (other: like Current; agent rm_types_conformant (a_type, other_type: String)): Boolean
        -- True if this node on its own (ignoring any subparts) expresses the same or narrower constraints
        -- as `other'. Returns True only when the following is True:
        --   * C_PRIMITIVE_OBJECT conditions are met and
        --   * the value set represented by `constraint' is subsumed under that of `other.constraint'
        -- `rm_types_conformant' is an agent (lambda) that can test an RM type's conformance to another RM type
    require
        other /= Void
        rm_types_conformant /= Void
    do
        if precursor (other, rm_type_conformance_checker) then  -- precursor is from C_PRIMITIVE_OBJECT
            if is_valid_value_set_code (constraint) and is_valid_value_set_code (other.constraint) then
                -- firstly, check if the other value-set is empty, which means there is no value-set,
                -- i.e. no constraint, which means that this object's value set automatically conforms.
                other_vset := other.value_set_expanded
                if not other_vset.is_empty then
                    this_vset := value_set_expanded
                    Result := codes_conformant (constraint, other.constraint) and then
                        across this_vset as vset_csr all other_vset.has (vset_csr.item) end
                else
                    Result := True
                end
            else
                Result := codes_conformant (constraint, other.constraint)
            end
        end
    end

c_congruent_to (other: like Current): Boolean
        -- True if this node on its own (ignoring any subparts) expresses no constraints in addition
        -- to `other'
    require
        other /= Void
    do
        if precursor (other) then  -- precursor is from C_PRIMITIVE_OBJECT
            if is_valid_value_set_code (constraint) and is_valid_value_set_code (other.constraint) then
                this_vset := value_set_expanded
                other_vset := other.value_set_expanded
                Result := constraint.is_equal (other.constraint) and then
                    this_vset.count = other_vset.count and then
                        across this_vset as vset_csr all other_vset.has (vset_csr.item) end
            else
                Result := constraint.is_equal (other.constraint)
            end
        end
    end

4.5.22. C_SECOND_ORDER Class

Class

C_SECOND_ORDER (abstract)

Description

Abstract parent of classes defining second order constraints.

Attributes

Signature

Meaning

0..1

members: List<ARCHETYPE_CONSTRAINT>

Members of this second order constrainer. Normally redefined in descendants.

Functions

Signature

Meaning

c_conforms_to (
other: C_SECOND_ORDER[1]
): Boolean

True if constraints represented by this node, ignoring any sub-parts, are narrower or the same as other. Typically used during validation of specialised archetype nodes.

c_congruent_to (
other: C_SECOND_ORDER[1]
): Boolean

True if constraints represented by this node contain no further redefinitions with respect to the node other. Typically used to test if an inherited node locally contains any constraints.

4.5.23. C_PRIMITIVE_TUPLE Class

Class

C_PRIMITIVE_TUPLE

Description

Class representing a single object tuple instance in a tuple constraint. Each such instance is a vector of object constraints, where each member (each C_PRIMITIVE_OBJECT) corresponds to one of the C_ATTRIBUTEs referred to by the owning C_ATTRIBUTE_TUPLE.

Inherit

C_SECOND_ORDER

Attributes

Signature

Meaning

1..1
(redefined)

members: List<C_PRIMITIVE_OBJECT>

Object constraint members of this tuple group.

Functions

Signature

Meaning

(effected)

c_conforms_to (
other: C_SECOND_ORDER[1]
): Boolean

True if constraints represented by this node, ignoring any sub-parts, are narrower or the same as other. Typically used during validation of specialised archetype nodes.

(effected)

c_congruent_to (
other: C_SECOND_ORDER[1]
): Boolean

True if constraints represented by this node contain no further redefinitions with respect to the node other. Typically used to test if an inherited node locally contains any constraints.

4.5.24. C_ATTRIBUTE_TUPLE Class

Class

C_ATTRIBUTE_TUPLE

Description

Object representing a constraint on an atttribute tuple, i.e. a group of attributes that are constrained together. Typically used for representing co-varying constraints like {units, range} constraints.

Inherit

C_SECOND_ORDER

Attributes

Signature

Meaning

0..1

tuples: List<C_PRIMITIVE_TUPLE>

Tuple definitions.

0..1
(redefined)

members: List<C_ATTRIBUTE>

List of C_ATTRIBUTEs forming the definition of the tuple.

Functions

Signature

Meaning

(effected)

c_conforms_to (
other: C_SECOND_ORDER[1]
): Boolean

True if constraints represented by this node, ignoring any sub-parts, are narrower or the same as other. Typically used during validation of specialised archetype nodes.

(effected)

c_congruent_to (
other: C_SECOND_ORDER[1]
): Boolean

True if constraints represented by this node contain no further redefinitions with respect to the node other. Typically used to test if an inherited node locally contains any constraints.

5. The Rules Package

5.1. Overview

The AOM rules package builds upon a subset of the BASE::org::openehr::expressions package described in the openEHR Expression Language specification, and adds a small number of classes to express leaf reference types specific to archetypes. This enables expressions to be declared within archetypes that:

  • use archetype paths as value references, and;

  • include C_PRIMITIVE_OBJECT constraints as Boolean-valued sub-expressions.

A special case of the latter is the C_STRING leaf constraint type, which is used to represent archetype slot constraints in instances of the ARCHETYPE_SLOT class (includes and excludes attributes).

The general use of expressions in an archetype is in the rules section, where both variable declarataions and assertions are used to express object constraints ranging across multiple nodes, i.e. constraints that can’t be expressed 'inline' within the main definition section structure. In both of these places, their role is to constrain something inside the current archetype.

Constraints on external resources such as terminologies are expressed in the constraint binding part in the archetype terminology, described in the Terminology Package section. The AOM rules package is illustrated below.

AOM rules
Figure 22. Rules Package

5.2. Semantics

Archetype assertions are expressions which may contain the following elements:

  • constants:

    • primitive values: including the date/time types;

    • constraints operands, i.e. C_PRIMITIVE_OBJECT instances, used as arguments to the matches operator;

    • archetype id constraints, i.e. C_STRING instances representing possible archetype identifiers, used in slot constraints.

  • any of the expression operators, i.e.:

    • arithmetic operators: +, *, -, /, ^ (exponent), % (modulo division)

    • relational operators: >, <, >=, <=, =, !=;

    • boolean operators: not, and, or, xor;

    • quantifiers applied to container variables: for_all, exists;

  • functions e.g. basic arithmetic, trigonometric and other functions;

  • the following additional semantics:

    • references to archetyped values in data, specified by archetype paths.

Variables, assignments, and external queries as described in the openEHR Expression Language are not allowed.

5.3. Class Descriptions

The following classes augment the core model described in the openEHR Expression Language specification.

5.3.1. EXPR_CONSTRAINT Class

Class

EXPR_CONSTRAINT

Description

Expression tree leaf item representing a constraint on a primitive type, expressed in the form of a concrete subtype of C_PRIMITIVE_OBJECT.

Inherit

EXPR_LITERAL

Attributes

Signature

Meaning

1..1
(redefined)

item: C_PRIMITIVE_OBJECT

The constraint.

5.3.2. EXPR_ARCHETYPE_ID_CONSTRAINT Class

Class

EXPR_ARCHETYPE_ID_CONSTRAINT

Description

Expression tree leaf item representing a constraint on an archetype identifier.

Inherit

EXPR_CONSTRAINT

Attributes

Signature

Meaning

1..1
(redefined)

item: C_STRING

A C_STRING representing a regular expression for matching Archetype identifiers.

5.3.3. EXPR_ARCHETYPE_REF Class

Class

EXPR_ARCHETYPE_REF

Description

Expression tree leaf item representing a reference to a value found in data at a location specified by a path in the archetype definition.

  • A path referring to a value in the archetype (paths with a leading ‘/’ are in the definition section.

  • Paths with no leading ‘/’ are in the outer part of the archetype, e.g. “archetype_id/value” refers to the String value of the archetype_id attribute of the enclosing archetype.

Inherit

EXPR_VALUE_REF

Attributes

Signature

Meaning

1..1

path: String

The path to the archetype node.

1..1
(redefined)

item: ARCHETYPE_CONSTRAINT

6. Terminology Package

6.1. Overview

All local terminology as well as terminological and terminology binding elements of an archetype are represented in the terminology section of an archetype, whose semantics are defined by the archetype.terminology package, shown below.

AOM terminology
Figure 23. Terminology Package

An archetype terminology consists of the following elements.

  • term_definitions: a mandatory structure consisting of lists of term definitions defined local to the archetype, one list for each language of translation, as well as the original language of definition. The entries in this table include:

    • Some or all id-codes. One of these is a code of the form 'id1', 'id1.1', 'id1.1.1' etc, denoting the concept of the archetype as a whole. This particular code is recorded in the concept_code attribute and is used as the id-code on the root node in the archetype definition. Not all id-codes are required to be in the term_definitions structure - for nodes that are children of single-valued attribute, a term definition is optional (and not typically defined).

    • at-codes used to define value terms and inline value sets/ All at-codes will appear within a C_TERMINOLOGY_CODE constraint object within the archetype. All at-codes must have a definition in the term_definitions.

    • ac-codes used to define external value set references. All ac-codes must have a definition in the term_definitions.

  • term_bindings: an optional structure consisting of list of terms and bindings, one list for each external terminology (i.e. the terminology or ontology being 'bound to'). Each 'binding' is a URI to a target. For a binding of an id-code or an at-code, the target will be a single term, and for an ac-code, it will designate a ref-set or value set.

  • value_sets: optional structure defining value-set relationships for locally defined value sets. Each value set is identified by an ac-code and has as members one or more at-codes.

  • terminology_extracts: an optional structure containing extracts from external terminologies such as SNOMED CT, ICDx, or any local terminology. These extracts include the codes and preferred term rubrics, enabling the terms to be used for both display purposes. This structure is normally only used for templates, enabling small value sets for which no external reference set or subset is defined to be captured locally in the template.

Depending on whether the archetype is in differential or flat form, an instance of the ARCHETYPE_TERMINOLOGY class contains terms, constraints, bindings and terminology extracts that were respectively either introduced in the owning archetype, or all codes and bindings obtained by compressing an archetype lineage through inheritance. A typical instance structure of ARCHETYPE_TERMINOLOGY is illustrated in Figure Terminology Instance Structure.

terminology instance structure
Figure 24. Terminology Instance Structure

6.2. Semantics

6.2.1. Specialisation Depth

Any given archetype occurs at some point in a lineage of archetypes related by specialisation, where the depth is reflected by the specialisation_depth function. An archetype which is not a specialisation of another has a specialisation_depth of 0. Term and constraint codes introduced in the terminology of specialised archetypes (i.e. which did not exist in the terminology of the parent archetype) are defined in a strict way, using '.' (period) markers. For example, an archetype of specialisation depth 2 will use term definition codes like the following:

  • id0.0.1 - a new term introduced in this archetype, which is not a specialisation of any previous term in any of the parent archetypes;

  • id4.0.1 - a term which specialises the id4 term from the top parent. An intervening .0 is required to show that the new term is at depth 2, not depth 1;

  • id25.1.1 - a term which specialises the term id25.1 from the immediate parent, which itself specialises the term id25 from the top parent.

This systematic definition of codes enables software to use the structure of the codes to more quickly and accurately make inferences about term definitions up and down specialisation hierarchies. Constraint codes on the other hand do not follow these rules, and exist in a flat code space instead.

6.3. Class Descriptions

6.3.1. ARCHETYPE_TERMINOLOGY Class

Class

ARCHETYPE_TERMINOLOGY

Description

Local terminology of an archetype. This class defines the semantics of the terminology of an archetype.

Attributes

Signature

Meaning

1..1

is_differential: Boolean

1..1

original_language: String

Original language of the terminology, as set at archetype creation or parsing time; must be a code in the ISO 639-1 2 character language code-set.

1..1

concept_code: String

Term code defining the meaning of the archetype as a whole, and always used as the at-code on the root node of the archetype. Must be defined in the term_definitions property.

1..1

term_definitions: Hash<String, Hash<String, ARCHETYPE_TERM>>

Directory of term definitions as a two-level table. The outer hash keys are language codes, e.g. "en", "de", while the inner hash keys are term codes, e.g. "id17", "at4".

0..1

term_bindings: Hash <String, Hash<String, Uri>>

Directory of bindings to external terminology codes and value sets, as a two-level table. The outer hash keys are terminology ids, e.g. "SNOMED_CT", and the inner hash keys are constraint codes, e.g. "at4", "ac13" or paths. The indexed DV_URI objects represent references to externally defined resources, either terms, ontology concepts, or terminology subsets / ref-sets.

1..1

owner_archetype: ARCHETYPE

Archetype that owns this terminology.

0..1

value_sets: Hash<String, VALUE_SET>

Archetype-local value sets, each keyed by value-set id, i.e. an ac-code.

0..1

terminology_extracts: Hash<String, Hash<String, ARCHETYPE_TERM>>

Directory of extracts of external terminologies, as a two-level table. The outer hash keys are terminology ids, e.g. "SNOMED_CT", while the inner hash keys are term codes or code-phrases from the relevant terminology, e.g. "10094842".

Functions

Signature

Meaning

specialisation_depth (): Integer

Specialisation depth of this archetype. Unspecialised archetypes have depth 0, with each additional level of specialisation adding 1 to the specialisation_depth.

id_codes (): List<String>

List of all id codes in the terminology., i.e. the “id” codes in an ADL archetype, which are the node_ids on C_OBJECT descendants.

value_codes (): List<String>

List of all value term codes in the terminology, i.e. the “at” codes in an ADL archetype, which are used as possible values on terminological constrainer nodes.

value_set_codes (): List<String>

List of all value set codes in the terminology defining value sets. These correspond to the “ac” codes in an ADL archetype.

has_language (
a_lang: String[1]
): Boolean

True if language a_lang is present in archetype terminology.

has_terminology (
a_terminology_id: String[1]
): boolean

True if there are bindings to terminology a_terminology_id present. True if terminology `a_terminology' is present in archetype ontology.

has_term_code (
a_code: String[1]
): boolean

True if code a_code defined in this terminology.

term_definition (
a_lang: String[1],
a_code: String[1]
): ARCHETYPE_TERM
Pre: has_term-definition (a_lang, a_code)

Term definition for a code, in a specified language.

term_binding (
a_terminology: String[1],
a_code: String[1]
): Uri
Pre: has_term_binding (a_terminology_id, a_code)

Binding of constraint corresponding to a_code in target external terminology a_terminology_id, as a string, which is usually a formal query expression.

terminologies_available (): List<String>

List of terminologies to which term or constraint bindings exist in this terminology, computed from bindings.

terminology_extract_term (
a_terminology_id: String[1],
a_code: String[1]
): ARCHETYPE_TERM
Pre: has_terminology_extract (a_terminology_id) and has_terminology_extract_code (a_code)

Return an ARCHETYPE_TERM from specified terminology extract, for specified term code.

has_terminology_extract (
a_terminology_id: String[1]
): Boolean

True if there is a provided terminology extract present.

languages_available (): List<String>

List of languages in which terms in this terminology are available.

Invariants

Original_language_validity: code_set (Code_set_id_languages).has_concept_id (original_language)

concept_code_validity: id_codes.has (concept_code)

Term_bindings_validity: bindings /= void implies not bindings.is_empty

Parent_archetype_valid: parent_archetype.terminology = Current

6.3.2. TERMINOLOGY_RELATION Class

Class

TERMINOLOGY_RELATION (abstract)

Description

Class whose instances represent any kind of 1:N relationship between a source term and 1-N target terms.

Attributes

Signature

Meaning

1..1

id: String

Code of source term of this relation.

1..1

members: List<String>

List of target terms in this relation.

6.3.3. VALUE_SET Class

Class

VALUE_SET

Description

Representation of a flat value set within the archetype terminology.

Inherit

TERMINOLOGY_RELATION

6.3.4. ARCHETYPE_TERM Class

Class

ARCHETYPE_TERM

Description

Representation of any coded entity (term or constraint) in the archetype ontology.

Attributes

Signature

Meaning

1..1

code: String

Code of this term.

1..1

text: String

Short term text, typically for display.

1..1

description: String

Full description text.

0..1

other_items: Hash<String, String>

Hash of keys and corresponding values for other items in a term, e.g. provenance. Hash of keys ("text", "description" etc) and corresponding values.

6.3.4.1. Validity Rules

The following validity rules apply to instances of this class in an archetype:

VTVSID: value-set id defined. The identifying code of a value set must be defined in the term definitions of the terminology of the current archetype.

VTVSMD: value-set members defined. The member codes of a value set must be defined in the term definitions of the terminology of the flattened form of the current archetype.

VTVSUQ: value-set members unique. The member codes of a value set must be unique within the value set.

VTSD specialisation level of codes. Term or constraint code defined in archetype terminology must be of the same specialisation level as the archetype (differential archetypes), or the same or a less specialised level (flat archetypes).

VTLC: language consistency. Languages consistent: all term codes and constraint codes exist in all languages.

VTTBK: terminology term binding key valid. Every term binding must be to either a defined archetype term ('at-code') or to a path that is valid in the flat archetype.

VTCBK: terminology constraint binding key valid. Every constraint binding must be to a defined archetype constraint code ('ac-code').

7. Validation and Transformation Semantics

This section provides a guide for validation, flattening and diffing, based on the ADL workbench reference compiler. The sequence of processing a given archetype A in the Workbench is as follows:

  • evaluate specialisation lineage of A

    • process each parent in order from the top

  • evaluate supplier archetypes of A (those related by use_archetype statements)

    • process suppliers, recursively

  • parse A

  • AOM phase 1 validation - standalone validation

  • if passed, and A is specialised:

    • AOM phase 2 validation - validate against flat parent

    • flatten A against flat parent

    • AOM phase 3 validation - validation performed on flat form of A.

7.1. Validation

Validation is best implemented in a multi-pass fashion, with more basic kinds of errors being check first. The ADL Workbench implements three validation phases as described below.

7.1.1. Phase 1 - Basic Integrity

The following validation can be performed on an archetype mostly without reference to its parent, if it is specialised.

7.1.1.1. Basic checks
  • check match of root RM type with RM type mentioned in identifier (VARDT);

  • valid root id code for specialistion level (VARCN);

  • any missing mandatory parts, e.g. terminology section (STCNT);

  • check that specialisation depth is one greater than specialisation depth of parent (VACSD);

7.1.1.2. AUTHORED_ARCHETYPE meta-data checks
  • check original language in main part of archetype is available in terminology section (VOLT);

  • check adl_version and rm_release version id formats (VARAV, VARRV);

  • check that languages defined in translations section are in the archetype terminology (VOTM);

7.1.1.3. Definition Structure Validation
  • check that differential paths only found in specialised archetypes (VDIFV);

  • check that differential paths in specialised archetypes exist in flat parent (VDIFP);

7.1.1.4. Basic Terminology Validation
  • validate terminology code formats and speialisation depths (VATCV, VTSD);

  • validate terminology languages - check all at-codes and ac-codes found in all languages (VTLC);

  • validate terminology bindings - check that all terms and paths mentioned in bindings exist in terminology and definition (VTTBK, VTCBK, VETDF);

  • validate terminology value_sets - check that every code in terminology value set definitions is in the terminology, with no duplications (VTVSID, VTVSMD, VTVSUQ);

7.1.1.5. Various Structure Validation
  • check slot definition validity (VDSEV);

  • check C_ARCHETYPE_ROOT validity (VARXRA, VARXTV);

7.1.1.6. Code Validation
  • check that all codes mentioned in definition are defined in terminology (VTSD, VATID);

  • validate C_TERMINOLOGY_CODE objects (VATCD, VATDF, VACDF, VATDA);

7.1.1.7. Validate Annotations
  • for each language, ensure that annotations paths are valida (VRANP);

  • ensure that annotations are proper translations of each other.

7.1.2. Phase 2 - Validation of Specialised Archetype Against Flat Parent

7.1.2.1. Validate Against Reference Model

The following checks require a computational representation of the reference model to be available.

  • check that type and attribute names exist in RM (VCORM, VCARM);

  • check that enumeration type constraints use valid literal values (VCORMENV, VCORMENU, VCORMEN);

  • validate any allowed type substitutions (VCORMT);

  • check that existence in C_ATTRIBUTE is valid with respect to RM (VCAEX);

  • check that cardinality in C_ATTRIBUTE is valid with respect to RM (VCACA);

  • check mismatch of -arity of C_ATTRIBUTE in archetype and RM (VCAM).

7.1.2.2. Validate Specialised Definition

The following checks are made on a specialised definition with respect to its flat parent.

  • check that node differential path can and does exist in parent (VSONPT, VSONIN);

  • check that SIBLING_ORDER is valid in flat parent (VSSM);

  • on C_ATTRIBUTE nodes

    • check conformance of existence to flat parent (VSANCE);

    • check conformance of cardinality to flat parent (VSANCC);

  • on C_ARCHETYPE_ROOT:

    • check that archetype_ref archetype ID matches parent slot constraint (VARXS);

    • check that archetype_ref archetype ID exists in current library of archetypes (VARXR);

    • filler id specialisation depth is wrong (VARXID);

  • ensure ARCHETYPE_SLOT in child redefines only ARCHETYPE_SLOT in parent (VDSSID);

  • for node C_COMPLEX_OBJECT_PROXY in parent, check that proxy path exists (VSUNT);

  • otherwise, AOM types of child and parent node must be identical (VSONT).

For passing nodes, check:

  • evaluate c_conforms_to() function:

    • RM type non-conformance (VSONCT);

    • occurrences non-conformance (VSONCO);

    • node id non-conformance value mismatch (VSONI);

    • invalid leaf object value redefinition (VPOV, VUNK);

    • tuple validation against parent node (VTPNC, VTPIN).

7.1.2.3. Validate Rules
  • ensure RM types and paths mentioned in rules are valid against flat parent archetype and RM (VRRLPRM, VRRLPAR).

7.1.3. Phase 3 - Validation of Flat Form

These validations are carried out after successful generation of the flat form of the current archetype.

  • ensure C_COMPLEX_OBJECT_PROXY paths actually exist in current flat form (VUNP);

  • ensure object node occurrences valid with respect to enclosing cardinality (VACMCO).

7.2. Flattening

Flattening is conceptually a simple operation - the overlaying of a differential child archetype onto a flat parent . Concretely, it is a somewhat sophisticated operation, since it has to take into account a number of specifics allowed by ADL and the AOM, including:

  • differential paths, including ones that contain overridden id-codes;

  • nodes in the child can override nodes of different AOM types in the parent in specific circumstances;

  • sibling ordering markers;

  • overlays with cloning: where more than one child specialisation node exists for a single parent complex structure, the parent structure will be cloned before each overlay;

  • deletions (existence matches {0}, occurrences matches {0}).

  • proxy reference targets are expanded inline if the child archetype overrides them.

The algorithm used in the ADL Workbench provide a reasonable template for achieving proper flattening of AOM archetypes and templates.

7.3. Diffing

Diffing is the reverse of flattening, and is primarily used to support editing operations. The basis of visual editing of an archetype is the flat form of the parent, with the user permitted to make modifications that are conformant with the flat parent. The Diffing operation is used to extract the resulting differential form archetype from the final state of visual editing.

The algorithm used in the ADL Workbench provides a reasonable template for achieving diffing of AOM archetypes.

8. Serialisation Model

This section describes an adjusted version of the AOM that is used for serialising archetypes to formats other than ADL. The classes in this model are nearly 1:1 with AOM classes, but with names prefixed with P_, for 'persistent'. Without using this model, an archetype can be serialised to an 'object dump' format such as ODIN, JSON, YAML, XML etc, but the output will be voluminous. The effect of this model is to reduce the size of the output, potentially by a factor of two or more. Human readability is also greatly improved, which is of increasing importance with the direct use of XML and JSON by programmers.

Size reduction and readability is achieved mainly by mapping repetitive structural items to shorter string forms that are more readable, but still machine-processible.

The ‘P_’ model is shown below in two parts.

The translations from the AOM effected by the P_ classes are as follows:

  • all multiplicities, including existence, cardinality, and occurrences are converted to the standard UML string form such as '0..1', '0..*' etc, rather than the 8 or so lines of output that would occur in direct machine serialisation;

  • codes are converted from structured form (TERMINOLOGY_CODE class) to string form;

  • UID identifiers are converted from structured form to string form.

P AOM upper
Figure 25. Serialisation AOM (upper)
P AOM lower
Figure 26. Serialisation AOM (lower)

9. Templates

Within the Archetype formalism, a template is used to aggregate and refine archetypes, to produce a structure corresponding to a particular data set. Templates thus provide a way to use archetypes for specific purposes, while the archetypes contain possible data items, not linked to specific purposes. See the ADL2 specification, Templates section for a detailed description of template semantics.

Templates are formally defined as specialised archetypes, via the TEMPLATE and TEMPLATE_OVERLAY classes shown in Archetype Package. This means that all the formal characteristics of a template are defined by the openEHR Archetype Object Model (AOM) and Archetype Definition Language (ADL) specifications apply to templates. This includes the meta-data (inherited from the AUTHORED_RESOURCE class), specialisation semantics (templates can be specialised into other templates), terminology section (allowing multi-lingual local term definitions and external terminology bindings) as well as the rules and annotations sections.

Since a template is a specialised archetype, it cannot change the semantics of archetypes it specialises, since it obeys the same rules as any other specialised archetype. Accordingly, all data created due to the use of templates are guaranteed to conform to the referenced archetypes, as well as the underlying reference model.

However, the mode of use of the AOM and ADL in a template is slightly different from the typical archetype. Firstly, the following features are commonly used in templates but not generally in archetypes:

  • slot-filling - achieved by specialisation, as described in the ADL specification;

  • specifying {0..0} constraints to remove elements not needed from the referenced archetypes;

  • specifying {1..1} constraints to mandate elements from the referenced archetypes;

  • setting default values;

  • addition of terminology bindings to specific terminology ref-sets.

Secondly, specialisation in templates is usually only of existing nodes defined in the flat parent, i.e. no new nodes are added. If new data nodes are required in the template context, appropriate specialised archetypes should be created to define them, prior to use in the final template.

These variations are not formally required by the ADL/AOM formalism, but are intended to be realised instead by tooling that recognises archetypes and templates via the leading ADL keyword (ADL files) or serialisation type marker (other serialisation types). This approach simpifies life for tool builders, since a single standardised compiler will always compile any archetype or template.

Because a template generally refers to a number of archetypes due to slot-filling - i.e. the root archetype plus component archetypes mentioned as slot-fillers - and also usually defines further constraints on the root and component archetypes, the referenced entities end up being of three types:

  • a published archetype, used as is;

  • a published template, used as is;

  • a private template-local template overlay.

The first two of these are explicitly identified and published artefacts, and can usually be obtained as files in any of the available serialisation syntaxes. The template overlay is somewhat like the 'private' or anonymous class definition available in some programming languages, and is obtainable either as a separate file associated with the root template, or within the template source file.

9.1. An Example

In order to better explain the template artefact structure, an example is described below. Assume the logical structure required is as shown below. This shows three archetypes of specific RM types, that should be chained together by slot-filling at specific paths, to form a final template. The template also adds further constraints via overlays.

  • org.openehr::openEHR-EHR-COMPOSITION.encounter_report.v1 / content[id5]

    • org.openehr::openEHR-EHR-SECTION.vital_signs_headings.v1 / items [id2]

      • org.openehr::openEHR-EHR-EVALUATION.problem_description.v1

The actual template structure needed to achieve this is shown below. The archetype org.openehr::openEHR-EHR-COMPOSITION.encounter_report.v1 is shown at the top right. This is templated (i.e. specialised) by the template uk.nhs.clinical::openEHR-EHR-COMPOSITION.t_encounter_report.v1 at the top left. The template performs the job of filling the id5 slot in the root archetype by specialising the slot. The specialised version adds a filler object (designated with the C_ARCHETYPE_ROOT instance) and also overrides the original ARCHETYPE_SLOT instance to close the slot to any further filling, either by further templating or at runtime.

AOM template example 1
Figure 27. Template source structure example

The filler object specifies in its archetype_ref attribute the artefact being used to fill the slot (shown on the diagram as an ellipsis, for brevity). Here it is not simply the archetype org.openehr::openEHR-EHR-SECTION.vital_signs_headings.v1, but a specialised form of this archetype, defined as a local template overlay, whose identifier is uk.nhs.clinical::openEHR-EHR-SECTION.t_encounter_report-vital_signs_headings-0001.v1.

The same kind of redefinition occurs within this SECTION template overlay. The id7 slot node from the original archetype (org.openehr::openEHR-EHR-SECTION.vital_signs_headings.v1) is redefined by the C_ARCHETYPE_ROOT node in the template overlay. The overlay would normally add other constraints of its own - typically removing unwanted items and mandating other items from the specialisation parent archetypes - not shown here.

The source template is thus constructed of two artefacts, namely:

  • the 'template', i.e. the template root;

  • an internal 'template overlay' component.

These are connected together in the flattening operation as part of Operational Template generation; at that point, the C_COMPLEX_OBJECT root node of the template overlay (lower left) is overlaid on the id5.1 C_ARCHETYPE_ROOT node of the template, forming a single large archetype structure.

It is not always the case that the components of a template must be internal. Within the template environment, lower level reference model classes may be templated in their own right, and such templates simply reused in the new template being constructed. In this case, the outer template may contain both its own internal template components, and other templates.

9.2. Template Identifiers

Templates are identified using normal ADL multi-axial identifiers and GUIDs, just as for archetypes. However, to make them easier for tools and humans to see, some simple conventions are suggested for the concept part of the identifier, as follows.

  • template: use a concept identifier based on the archetype prepended with t_;

  • template_overlay: use a concept identifier consisting of the concatenation of:

    • the root template identifier (incuding the t_);

    • the concept identifier of the specialisation parent archetype of the overlay;

    • a final _N, where 'N' is an integer.

The following are examples.

uk.nhs.clinical::openEHR-EHR-COMPOSITION.t_encounter_report.v1.0.0  -- root template

uk.nhs.clinical::openEHR-EHR-EVALUATION.t_encounter_report-problem_description-1.v1.0.0   -- overlay
uk.nhs.clinical::openEHR-EHR-EVALUATION.t_encounter_report-medications-2.v1.0.0           -- overlay
uk.nhs.clinical::openEHR-EHR-EVALUATION.t_encounter_report-care_plan-3.v1.0.0             -- overlay

This approach defines a short concept identifier which obeys the formal rule that concept identifiers must be unique within a namespace and RM type, is human-readable, and most importantly, is tool-generatable.

10. Reference Model Adaptation

So far ADL has been presented as an abstract formal language that defines legal information structures based on a reference model (RM). In real world applications, we need to consider where reference models come from, and the question of harmonising or otherwise integrating archetypes based on different but related RMs.

One of the common problems in most domains is that competing reference models exist, typically defined by standards bodies such as ISO, CEN, ASTM, and/or other open standards bodies such as W3C and OASIS. For a given topic, e.g. 'cancer study trials' or 'Electronic Health Record' there can often be multiple information models that could be used as a basis for archetyping. Due to political pressures, national requiremenents or preferences and variety of other non-technical factors, it is quite likely that archetypes will be authored within a domain based on multiple competing reference models that are reasonably similar without being easily machine inter-convertible.

Since archetypes are generally authored by domain experts, the entities they represent tend to come from a homogeneous model space, with reference models being a technical detail that may not even be visible to the archetype author. Nevertheless, due to the above-mentioned factors, authors in different localities or jurisdictions may have no choice but to model the same entity, for example 'complete blood count' based on two or more different reference models.

This creates a potential problem of competing libraries of archetypes trying to model the same information entities in slightly different but incompatible ways. This tends to needlessly split groups of domain modellers into disparate communities, when in fact they are modelling the same things.

In order to alleviate some of the problems caused by this situation, some of the measures described below, which are outside the AOM proper, can be applied to enable archetypes and RMs treated to be treated more uniformly.

10.1. AOM Profile Configuration

These adaptations can be formalised in a configuration object that is an instance of the class AOM_PROFILE, illustrated below. This is only one way such information can be represented, and alternatives could be used.

AOM PROFILE
Figure 28. aom_profile Package

10.1.1. Class Definitions

10.1.2. AOM_PROFILE Class

Class

AOM_PROFILE

Description

Profile of common settings relating to use of reference model(s) and terminology for a given archetype developing organisation.

Attributes

Signature

Meaning

0..1

aom_rm_type_substitutions: Hash<String, String>

Allowed type substitutions: Actual RM type names keyed by AOM built-in types which can subsitute for them in an archetype. E.g. <value = "String", key = "ISO8601_DATE"> means that if RM property TYPE.some_property is of type String, an ISO8601_DATE is allowed at that position in the archetype.

0..1

aom_lifecycle_mappings: Hash<String, String>

List of mappings of lifecycle state names used in archetypes to AOM lifecycle state names. value = AOM lifecycle state; key = source lifecycle state.

1..1

profile_name: String

Name of this profile, usually based on the publisher it pertains to e.g. "openEHR", "cdisc", etc.

0..1

aom_rm_type_mappings: Hash<String,AOM_TYPE_MAPPING>

Mappings from AOM built-in types to actual types in RM: whenever the type name is encountered in an archetype, it is mapped to a specific RM type.

0..1

rm_primitive_type_equivalences: Hash<String, String>

Equivalences of RM primitive types to in-built set of primitive types. Used to determine which AOM C_PRIMITIVE_OBJECT descendant is used for a primitive type. Typical entries:

  • value key

  • "Real" "Double"

  • "Integer" "Integer64"

10.1.3. AOM_TYPE_MAPPING Class

Class

AOM_TYPE_MAPPING

Description

Data object expressing a mapping between two types.

Attributes

Signature

Meaning

1..1

source_class_name: String

Name of the AOM type being mapped to an RM type.

1..1

target_class_name: String

Name of the RM type in the mapping.

0..1

property_mappings: Hash<String,AOM_PROPERTY_MAPPING>

List of mappings of properties of this type to another type.

10.1.4. AOM_PROPERTY_MAPPING Class

Class

AOM_PROPERTY_MAPPING

Description

Data object expressing a mapping between two class properties.

Attributes

Signature

Meaning

1..1

source_property_name: String

Name of property in source class.

1..1

target_property_name: String

Name of property in target class.

10.1.5. Configuration File

Instances of the above classes can be expressed in an ODIN format file, as a convenient way of defining configuration for tools. Examples of such files used for the openEHR ADL Workbench tool can be found in the Github project for the tool.

10.2. Mapping RM Entities to AOM Entities

One adjustment that can be made is to indicate equivalences between RM entities and AOM built-in types. This can be illustrated by a common situation in health, where multiple RMs have concretely different models of the 'coded term' notion. Semantically, these are all the same, and the correspond to the AOM built-in type TERMINOLOGY_CODE. However, there is nothing that can be stated in an ADL archetype that can indicate this relationship, with the result that ADL tools can’t infer that a certain type, e.g. openEHR’s CODE_PHRASE or ISO 13606’s CODED_TEXT are equivalents of the TERMINOLOGY_CODE type in the AOM.

The mapping is achieved by using the aom_rm_type_mappings property of the AOM_PROFILE type, which enables equivalences between complex classes and properties to be described.

The following example shows parts of two AOM profile files, illustrating two different mappings of RM types for 'coded text' to the AOM TERMINOLOGY_CODE class. The following extract is from the openEHR AOM profile file for the ADL Workbench.

--
-- mappings from AOM built-in types used for openEHR RM types
--
aom_rm_type_mappings = <
	["TERMINOLOGY_CODE"] = <
		source_class_name = <"TERMINOLOGY_CODE">
		target_class_name = <"CODE_PHRASE">
		property_mappings = <
			["terminology_id"] = <
				source_property_name = <"terminology_id">
				target_property_name = <"terminology_id">
			>
			["code_string"] = <
				source_property_name = <"code_string">
				target_property_name = <"code_string">
			>
		>
	>
>

The following extract is from the {cimi_home}[CIMI] AOM profile file for the ADL Workbench. This defines a mapping from the CIMI RM class CODED_TEXT to the AOM class TERMINOLOGY_CODE.

--
-- mappings from AOM built-in types used for CIMI RM types
--

aom_rm_type_mappings = <
	["TERMINOLOGY_CODE"] = <
		source_class_name = <"TERMINOLOGY_CODE">
		target_class_name = <"CODED_TEXT">
		property_mappings = <
			["terminology_id"] = <
				source_property_name = <"terminology_id">
				target_property_name = <"terminology_id">
			>
			["code_string"] = <
				source_property_name = <"code_string">
				target_property_name = <"code">
			>
		>
	>
>

The value of creating these mappings is that they inform tooling that constraints on the types CODE_PHRASE in openEHR archetypes, and CODED_TEXT in CIMI archetypes are to be understood as equivalent to contraints on the primitive AOM type TERMINOLOGY_CODE. This can be detected by the tool, and computed with, for example, with specific visualisation. Without this configuration, the archetype constraints are still correct, but the ADL tooling doesn’t treat them as different from any other RM complex type.

Using class and property mappings can enable more sophisticated archetype comparison and potentially even harmonisation, as well as more intelligent data comparison.

10.3. RM Primitive Type Equivalences

The primitive constrainer types of the AOM, i.e. descendants of C_PRIMITIVE_OBJECT correspond to a small abstract set of primitive types, as shown in the table Primitive Types. The implied list of RM abstract primitive types is Boolean, Integer, Real, Date, Date_time, Time, Duration, String, and Terminology_code. However, real reference models may be based on typical programming languages, and therefore include types like Double, Integer64, and even numerous variants on String, Integer etc, such as String_8, String32 and so on.

In order to prevent a similar explosion of AOM primitive types, the AOM profile enables equivalences between these latter types (which typically differ for each RM) and the abstract set to be stated, using the rm_primitive_type_equivalences property of AOM_PROFILE. An example is shown below.

rm_primitive_type_equivalences = <
	["Double"] = <"Real">                      -- treat RM type Double as if it where Real
	["Integer64"] = <"Integer">                -- treat RM type Integer64 as if it were Integer
	["ISO8601_DATE"] = <"Date">                -- treat RM type ISO8601_Date as if it were Date
	["ISO8601_DATE_TIME"] = <"Date_time">
	["ISO8601_TIME"] = <"Time">
	["ISO8601_DURATION"] = <"Duration">
>

The following CADL fragment provides an example.

    ELEMENT[id5] occurrences matches {0..1} matches {	-- Systolic
        value matches {
            DV_QUANTITY[id1054] matches {
                property matches {[at1055]}
                magnitude matches {|0.0..<1000.0|}  -- **** parses as AOM C_REAL, but is Double in RM
                precision matches {0}
                units matches {"mm[Hg]"}
            }
        }
    }

10.4. RM Type Substitutions

Occasionally there are type mismatches between the RM type and the AOM type we would like to use, or has been used in an archetype. For example, the RM may have a String attribute in some class that represents an ISO 8601 date. It is possible to use the AOM constrainer type C_DATE instead of C_STRING, to obtain more a meaningful constraint.

Another use is where the archetype has been written with an integer constrant (i.e. a C_INTEGER) but the RM has a Real or Double type in the corresponding place. This can also be accommodated.

These differences can be corrected by using the aom_type_substitutions configuration table defined in the AOM_PROFILE class. The following is an example of using this facility to enable primitive type matching for openEHR archetypes.

--
-- allowed substitutions from AOM built-in primitive types to openEHR RM types
--

aom_rm_type_substitutions = <
	["ISO8601_DATE"] = <"String">
	["ISO8601_DATE_TIME"] = <"String">
	["ISO8601_TIME"] = <"String">
	["ISO8601_DURATION"] = <"String">
	["INTEGER"] = <"Double">
>

The effect of these mappings is that literal values in an archetype that parse as the left hand side type (ISO8601_DATE etc) etc will be silently mapped to the right hand RM type (String etc). The following example shows a native ISO Duration field that is mapped to an RM String value.

    INTERVAL_EVENT[id1043] occurrences matches {0..1} matches {	-- 24 hour average
        width matches {
            DV_DURATION[id1064] matches {
                value matches {PT24H}  -- **** parses as AOM ISO8601_DURATION, but is String in RM
            }
        }
    }

10.5. AOM Lifecycle State Mappings

Another kind of useful mapping adjustment that can help to make tools process archetypes in a more homogeneous way is to do with the AOM life-cycle states, which are standardised in the openEHR Archetype Identification specification. These states denote the state of a whole archetype in its authoring life cycle. Historically however there were no standard names, with the consequence that various archetype tools implement their own local lifecycle state names. To adjust for this the aom_lifecycle_mappings property in the AOM_PROFILE class can be used. These mappings have the effect of replacing the current value of the lifecycle_state property of the RESOURCE_DESCRIPTION instance of a parsed archetype with an openEHR standard state name. A typical example of the description section of an archetype with a local lifecycle state name is below.

description
    original_author = <
        ["name"] = <"Dr J Joyce">
        ["organisation"] = <"NT Health Service">
        ["date"] = <2003-08-03>
    >
    lifecycle_state =  <"AuthorDraft"> -- **** should be 'unmanaged'
    resource_package_uri =  <".....">

The following example shows typical mappings of customs lifecycle state names to the openEHR standard state names.

-- allowed substitutions from source RM lifecycle states to AOM lifecycle states
-- States on the value side (right hand side) must be the AOM states:
--
--	"unmanaged"
--	"in_development"
--		"draft"
--		"in_review"
--		"suspended"
--	"release_candidate"
--	"published"
--	"deprecated"
--		"obsolete"
--		"superseded"

--

aom_lifecycle_mappings = <
	["AuthorDraft"] = <"unmanaged">
	["Draft"] = <"in_development">
	["TeamReview"] = <"in_development">
	["Team Review"] = <"in_development">
	["ReviewSuspended"] = <"in_development">
	["Review Suspended"] = <"in_development">
	["Reassess"] = <"published">
	["Published"] = <"published">
	["Rejected"] = <"rejected">
>

Normally this kind of change should be written into the archetype, so that it is upgraded to the standard form. Tools should offer this possibility, including in batch/bulk mode.

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. 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 .