Archetype Object Model 2 (AOM2)
Issuer: openEHR Specification Program | |
---|---|
Release: AM Release-2.1.0 |
Status: STABLE |
Revision: [latest_issue] |
Date: [latest_issue_date] |
Keywords: EHR, ADL, AOM, health records, archetypes, constraint language, ISO 13606, openehr |
© 2004 - 2022 The openEHR Foundation | |
---|---|
The openEHR Foundation is an independent, non-profit foundation, facilitating the sharing of health records by consumers and clinicians via open specifications, clinical models and open platform implementations. |
|
Licence |
Creative Commons Attribution-NoDerivs 3.0 Unported. https://creativecommons.org/licenses/by-nd/3.0/ |
Support |
Issues: Problem Reports |
Amendment Record
Issue | Details | Raiser, Implementer | Completed |
---|---|---|---|
AM Release-2.1.0 |
|||
SPECAM-51. Move RM adaptation attributes from BMM to AOM profile. Add to section 10 the new meta-attributes |
T Beale |
||
SPECAM-48. Add VTPL validity rule for templates - consistency of languages for flattening. |
T Beale |
24 Jan 2018 |
|
SPECAM-49. Improve |
T Beale |
10 Jan 2018 |
|
SPECAM-46. |
P Bos, |
07 Jan 2018 |
|
SPECAM-47. Allow regularly structured primitive objects. Move |
J Coyle, |
07 Jan 2018 |
|
SPECPUB-6. Correct UML package nesting and paths in documents; rename |
T Beale |
27 Nov 2017 |
|
SPECAM-45. Correct specification details to do with |
P Bos, |
21 Nov 2017 |
|
SPECAM-43. Correct |
P Bos |
02 Nov 2017 |
|
SPECAM-42. Adjust references to BASE packages |
T Beale |
21 Sep 2017 |
|
AM Release-2.0.6 |
|||
2.0.6 |
Adjust |
T Beale |
15 Jun 2016 |
Correct ambiguity between ADL and AOM specs concerning duration fractional seconds - remove |
B Verhees |
10 Jun 2016 |
|
Add more precise specification of type matching under the 'Object Node Types' section, including for primitive types. Add |
T Beale |
08 Jun 2016 |
|
SPECAM-40. Correct VSONT validity rule to say that |
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 |
B Verhees |
18 May 2016 |
|
Remove references to openEHR RM. Add |
ISO TC215 |
||
Change Rules section to document re-use of new openEHR Expression Language and Model. |
T Beale |
11 May 2016 |
|
SPECBASE-4. Change order of type parameters in |
D Boscá |
13 Apr 2016 |
|
Correct |
B Verhees |
05 Apr 2016 |
|
2.0.5 |
Make |
T Beale |
18 Jan 2016 |
Add |
T Beale |
31 Aug 2015 |
|
2.0.0 |
Refactor |
T Beale |
04 Jan 2015 |
Remove |
T Beale, |
12 Nov 2014 |
|
Remove |
H Solbrig, |
08 Oct 2014 |
|
Correct spelling of |
S Garde, |
29 Sep 2014 |
|
Modified |
CIMI, |
18 Jul 2014 |
|
Convert |
I McNicoll, |
04 Jun 2014 |
|
Make |
D Moner |
07 Apr 2014 |
|
T Beale |
09 Mar 2014 |
||
Detailed Technical Review. |
H Solbrig |
21 Nov 2013 |
|
Remove |
H Solbrig |
20 Aug 2013 |
|
SPECAM-22. Limit |
T Beale, |
14 Jan 2013 |
|
SPECAM-32. Remove |
T Beale, |
15 Dec 2011 |
|
SPECAM-26. Add |
T Beale |
18 Aug 2010 |
|
SPECAM-8. Add specialisation semantics to ADL and AOM. Add various attributes and functions to
|
T Beale |
10 Dec 2009 |
|
SPECAM-1. Change Date, Time etc classes in AOM to |
T Beale |
20 Jul 2009 |
|
SPECAM-10. Convert |
T Beale |
||
SPECAM-5. Archetype slot regular expressions should cover whole identifier. Added |
A Flinton |
||
SPECAM-7. Make existence, occurrences and cardinality optional in AOM. |
S Heard |
||
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 |
C Ma, |
20 Nov 2008 |
SPEC-251. Allow both pattern and interval constraint on Duration in Archetypes. Add pattern attribute to |
S Heard |
||
R E L E A S E 1.0.1 |
|||
2.0.1 |
D Lloyd, |
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 |
R Chen |
||
SPEC-233: Define semantics for |
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 |
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 |
D Lloyd |
20 Jun 2005 |
SPEC-142. Update ADL grammar to support assumed values. Changed |
S Heard, |
||
SPEC-146: Alterations to am.archetype.description from CEN MetaKnow |
D Kalra |
||
SPEC-138. Archetype-level assertions. |
T Beale |
||
SPEC-157. Fix names of |
T Beale |
||
R E L E A S E 0.95 |
|||
0.5.1 |
Corrected documentation error - return type of |
D Lloyd |
20 Jan 2005 |
0.5 |
SPEC-110. Update ADL document and create AOM document.
Initial Writing. Taken from ADL document 1.2draft B. |
T Beale |
10 Nov 2004 |
Acknowledgements
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
-
Joey Coyle MD, PhD, Intermountain Healthcare, New York
-
Borut Fabjan, Program Manager, Better d.o.o., 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, Better d.o.o., 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).
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.
1.2. Related Documents
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 STABLE state. The development version of this document can be found at https://specifications.openehr.org/releases/AM/Release-2.1.0/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)
1.5. Feedback
Feedback may be provided on the technical mailing list.
Issues may be raised on the specifications Problem Report tracker.
To see changes made due to previously reported issues, see the AM component Change Request tracker.
1.6. Conformance
Conformance of a data or software artifact to an openEHR specification is determined by a formal test of that artifact against the relevant openEHR Implementation Technology Specification(s) (ITSs), such as an IDL interface or an XML-schema. Since ITSs are formal derivations from underlying models, ITS conformance indicates model conformance.
1.7. 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.8. Changes from Previous Versions
1.8.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 toterminology
; -
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.8.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 torules
, to better reflect its purpose. -
A template is now just an archetype.
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' typesbase.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
PackageThe 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. AOM2 Package Structure
The Archetype Object Model is defined by the package am.aom2
and subordinate packages, as illustrated in Figure 4.
2.3. Definition and Utility Classes
2.3.1. Overview
Various definitional constants are used in the AOM. These are defined in the aom2.definitions
package from the AM component and are shown below.
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 leader of ‘identifier’ codes, i.e. codes used to identify archteype nodes. |
1..1 |
Value_code_leader: |
String leader of ‘value’ codes, i.e. codes used to identify codes values, including value set members. |
1..1 |
Value_set_code_leader: |
String leader of ‘value set’ codes, i.e. codes used to identify value sets. |
1..1 |
Specialisation_separator: |
Character used to separate numeric parts of codes belonging to different specialisation levels. |
1..1 |
Code_regex_pattern: |
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: |
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: |
Code id used for C_PRIMITIVE_OBJECT nodes on creation. |
Functions |
Signature |
Meaning |
1..1 |
codes_conformant ( |
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. |
1..1 |
is_adl_code ( |
True if a_code is any kind of ADL archetype local code. |
1..1 |
is_id_code ( |
True if a_code is an 'id' code. |
1..1 |
is_value_code ( |
True if a_code is an 'at' code, i.e. a code representing a single terminology item. |
1..1 |
is_value_set_code ( |
True if a_code is an 'ac' code, i.e. a code referring to a terminologyvalue set. |
1..1 |
A code has been specialised if there is a non-zero code index anywhere above the last index e.g.
|
|
1..1 |
code_exists_at_level ( |
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 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
).
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.
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 8.
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.
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.
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.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 Figure 23.
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 6 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 11 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.
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.
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 12 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 Figure 12 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 13 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.
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 |
|
Attributes |
Signature |
Meaning |
0..1 |
parent_archetype_id: |
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: |
Identifier of this archetype. |
1..1 |
is_differential: |
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: |
Root node of the definition of this archetype. |
1..1 |
terminology: |
The terminology of the archetype. |
0..1 |
Rules relating to this archetype. Statements are expressed in first order predicate logic, and usually refer to at least two attributes. |
|
Functions |
Signature |
Meaning |
1..1 |
concept_code (): |
The concept code of the root object of the archetype, also standing for the concept of the archetype as a whole. |
1..1 |
Set of language-independent paths extracted from archetype. Paths obey Xpath-like syntax and are formed from alternations of |
|
1..1 |
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. |
|
1..1 |
specialisation_depth (): |
Specialisation depth of this archetype; larger than 0 if this archetype has a parent. Derived from terminology.specialisation_depth. |
1..1 |
is_specialised (): |
True if this archetype is a specialisation of another. |
Invariants |
Invariant_concept_valid: |
|
Invariant_specialisation_validity: |
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 |
||
Attributes |
Signature |
Meaning |
0..1 |
adl_version: |
ADL version if archetype was read in from an ADL sharable archetype. |
1..1 |
build_uid: |
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: |
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: |
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 |
||
Invariants |
Invariant_adl_version_validity: |
|
Invariant_rm_release: |
||
Description_validity: |
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: |
Reverse domain name namespace identifier. |
1..1 |
rm_publisher: |
Name of the Reference Model publisher. |
1..1 |
rm_package: |
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: |
Name of the root class of this archetype. |
1..1 |
concept_id: |
The short concept name of the archetype as used in the multi-axial archetype_hrid. |
1..1 |
release_version: |
The full numeric version of this archetype consisting of 3 parts, e.g. |
1..1 |
version_status: |
The status of the version, i.e. released, release_candidate etc. |
1..1 |
build_count: |
The build count since last increment of any version part. |
Functions |
Signature |
Meaning |
1..1 |
semantic_id (): |
The ‘interface’ form of the HRID, i.e. down to the major version. |
1..1 |
physical_id (): |
The ‘physical’ form of the HRID, i.e. with complete version information. |
1..1 |
version_id (): |
Full version identifier string, based on release_version and lifecycle, e.g. |
1..1 |
major_version (): |
Major version of this archetype, extracted from release_version. |
1..1 |
minor_version (): |
Minor version of this archetype, extracted from release_version. |
1..1 |
patch_version (): |
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: |
|
Inv_rm_package_validity: |
||
Inv_class_name_validity: |
||
Inv_concept_id_validity: |
||
Inv_release_version_validity: |
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 |
||
Attributes |
Signature |
Meaning |
0..1 |
overlays: |
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: |
3.6.5. TEMPLATE_OVERLAY Class
Class |
TEMPLATE_OVERLAY |
|
---|---|---|
Description |
A concrete form of the bare |
|
Inherit |
||
Invariants |
Inv_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 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 |
||
Attributes |
Signature |
Meaning |
0..1 |
component_terminologies: |
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: |
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 |
1..1 |
component_terminology ( |
|
Invariants |
Specialisation_validity: |
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.
The following validity rules apply to instances of TEMPLATE
:
VTPL: template and filler language consistency. All fillers of slots and external reference archetypes (i.e. 'use_archetype' inclusions) must contain the original_language
of the root template in their languages, in order for template flattening to be successful.
4. Constraint Model Package
4.1. Overview
Figure 14 and Figure 15 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.
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 definedC_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 aC_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.
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 Section 4.5.
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 theC_ATTRIBUTE
is constraining a multiply-valued (i.e. container) RM attribute or a single-valued one; -
existence
: whether the corresponding instance (defined by therm_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 16 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.
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"
matchesPERSON
, wherePERSON
inherits fromPARTY
in the relevant RM; -
rm_type_name
="Interval<Ordered>"
matches a dynamic type of data items ofInterval<Quantity>
,SimpleInterval<Ordered>
andSimpleInterval<Quantity>
whereQuantity
inherits fromOrdered
andSimpleInterval
inherits fromInterval
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 capability. 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 represented in ADL 'short' form are created with a fixed id-code ADL_CODE_DEFINITIONS.primitive_node_id
as the value of node_id
(see Section 2.3.3). For regularly structured C_PRIMITIVE_OBJECT
instances, a normal node identifier is required.
The primitive constraint for each primitive type may itself be complex. Its Reference Model (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 |
---|---|---|---|
|
|
|
Can represent one or two Boolean values, enabling the logical constraints 'true', 'false' and 'true or false' to be expressed. |
|
|
|
A list of possible string values, which may include regular expressions, which are delimited by '/' characters. |
|
|
Terminology constraint - |
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. |
|
Descendants of |
|
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. |
|
|
|
As for Ordered type, with T = |
|
|
|
As for Ordered type, with T = |
|
Descendants of |
|
As for ordered types, with T being an sub-type type of |
|
|
|
As for Temporal types with T = |
|
|
|
As for Temporal types with T = |
|
|
|
As for Temporal types with T = |
|
|
|
As for Temporal types with T = |
The RM primitive types listed above are assumed to exist (possibly with different names) within any RM used as the basis for creating archetypes. Where any do not exist - e.g. if there are no date/time types in a particular RM - no archetype constraints can be defined for such nodes. Where the types have different names, name mapping can be performed as described in Section 10.3 below.
This facility can be used to effect the following mappings from C_PRIMITIVE_OBJECT
descendants (C_STRING
, C_INTEGER
etc) to the types found in any particular RM.
-
String
variants: in addition to matchingString
,C_STRING
should matchStringN
andString_N
instances, to accommodate RM types such asString8
,String_32
etc; -
Integer
variants: in addition to matchingInteger
,C_INTEGER
should matchIntegerN
andInteger_N
, to accommodate RM types such asInteger_16
,Integer64
etc; -
Real
variants: in addition to matchingReal
,C_REAL
should matchRealN
andReal_N
andDouble
, to accommodate RM types such asReal_32
,Real64
andDouble
; -
Date_time
variants: typical names forDate_time
such asDateTime
,TimeStamp
etc should be mapped toC_DATE
.
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 thevalue_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 ofTERMINOLOGY_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.
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 22.
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.
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.
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 14 are reproduced below, with concrete types that may actually occur in archetypes shown in dark yellow / non-italic.
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 thanC_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 |
||||
Attributes |
Signature |
Meaning |
||
0..1 |
parent: |
Parent node, except in the case of the top of a tree, i.e. root |
||
0..1 |
soc_parent: |
Inverse relationship for |
||
Functions |
Signature |
Meaning |
||
1..1 |
is_prohibited (): |
True if this node is prohibited. Implemented in subtypes. |
||
1..1 |
True if the relative path a_path exists at this node. |
|||
1..1 |
path (): |
Path of this node relative to root of archetype. |
||
1..1 |
c_conforms_to ( |
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. Parameters
|
||
1..1 |
c_congruent_to ( |
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 Typically used to test if an inherited node locally contains any constraints. |
||
1..1 |
is_second_order_constrained (): |
True if there is a second order constraint such as a tuple constraint on this node. |
||
1..1 |
is_root (): |
True if this node is the root of the tree. |
||
1..1 |
is_leaf (): |
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 |
||
Attributes |
Signature |
Meaning |
1..1 |
rm_attribute_name: |
Reference model attribute within the enclosing type represented by a |
0..1 |
existence: |
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 |
Child |
|
0..1 |
differential_path: |
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 constraint of attribute, if a container attribute. |
1..1 |
is_multiple: |
Flag indicating whether this attribute constraint is on a container (i.e. multiply-valued) attribute. |
Functions |
Signature |
Meaning |
1..1 |
any_allowed (): |
True if there is no effective constraint on the children of the RM attribute to which this |
1..1 |
is_mandatory (): |
True if this |
1..1 |
rm_attribute_path (): |
Path of this attribute with respect to owning |
1..1 |
is_single (): |
True if this node logically represents a single-valued attribute. Evaluated as not is_multiple. |
1..1 |
c_congruent_to ( |
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 Typically used to test if an inherited node locally contains any constraints. |
1..1 |
c_conforms_to ( |
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. |
1..1 |
is_prohibited (): |
True if this |
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 |
||||
Attributes |
Signature |
Meaning |
||
1..1 |
rm_type_name: |
Reference model type that this node corresponds to. |
||
0..1 |
occurrences: |
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: |
Semantic identifier of this node, used to distinguish sibling nodes. All nodes must have a For |
||
0..1 |
is_deprecated: |
True if this node and by implication all sub-nodes are deprecated for use. |
||
0..1 |
sibling_order: |
Optional indicator of order of this node with respect to another sibling. Only meaningful in a specialised archetype for a |
||
Functions |
Signature |
Meaning |
||
1..1 |
specialisation_depth (): |
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 |
||
1..1 |
effective_occurrences (): |
|||
1..1 |
c_conforms_to ( |
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. Parameters
|
||
1..1 |
c_congruent_to ( |
True if constraints represented by this node contain no further redefinitions with respect to the node Typically used to test if an inherited node locally contains any constraints. |
||
1..1 |
True if this node Parameters
|
|||
1..1 |
node_id_conforms_to ( |
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. |
||
1..1 |
is_prohibited (): |
True if this |
4.5.4. SIBLING_ORDER Class
Class |
SIBLING_ORDER |
|
---|---|---|
Description |
Defines the order indicator that can be used on a Misuse: This type cannot be used on a |
|
Attributes |
Signature |
Meaning |
1..1 |
is_before: |
True if the order relationship is ‘before’, if False, it is ‘after’. |
1..1 |
sibling_node_id: |
Node identifier of sibling before or after which this node should come. |
Functions |
Signature |
Meaning |
1..1 |
is_after (): |
True if the order relationship is |
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 (agent rm_prop_mult (rm_type_name, rm_property_path: String): 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, 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, rm_property_path)
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. One possible RM model implementation is described in the {openehr_base_bmm}[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): Boolean
-- True if this node on its own (ignoring any subparts) expresses strictly 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, or a specialised version of any such node, redefined in the current archetype.
4.5.5. C_DEFINED_OBJECT Class
Class |
C_DEFINED_OBJECT (abstract) |
|
---|---|---|
Description |
Abstract parent type of |
|
Inherit |
||
Attributes |
Signature |
Meaning |
0..1 |
default_value: |
Default value set in a template, and present in an operational template. Generally limited to leaf and near-leaf nodes. |
Functions |
Signature |
Meaning |
1..1 |
any_allowed (): |
True if any value (i.e. instance) of the reference model type would be allowed. Redefined in descendants. |
1..1 |
True if |
|
1..1 |
prototype_value (): |
Generate a prototype value from this constraint object. |
1..1 |
has_default_value (): |
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 |
||
Attributes |
Signature |
Meaning |
0..1 |
attributes: |
List of constraints on attributes of the reference model type represented by this object. |
0..1 |
attribute_tuples: |
List of attribute tuple constraints under this object constraint, if any. |
Functions |
Signature |
Meaning |
1..1 |
any_allowed (): |
True if any value (i.e. instance) of the reference model type would be allowed. Redefined in descendants. |
4.5.7. C_ARCHETYPE_ROOT Class
Class |
C_ARCHETYPE_ROOT |
|
---|---|---|
Description |
A specialisation of 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 In an operational template, the node_id is converted to the |
|
Inherit |
||
Attributes |
Signature |
Meaning |
1..1 |
archetype_ref: |
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 |
||
Attributes |
Signature |
Meaning |
0..1 |
List of constraints defining other archetypes that could be included at this point. |
|
0..1 |
List of constraints defining other archetypes that cannot be included at this point. |
|
1..1 |
is_closed: |
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 |
1..1 |
any_allowed (): |
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 |
|||
Inherit |
||||
Attributes |
Signature |
Meaning |
||
1..1 |
target_path: |
Reference to an object node using archetype path notation. |
||
Functions |
Signature |
Meaning |
||
1..1 |
use_target_occurrences (): |
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. |
||
1..1 |
True if this node occurrences conforms to If Parameters
|
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. Instances of this type represented in ADL inline form, the |
|||
Inherit |
||||
Attributes |
Signature |
Meaning |
||
0..1 |
assumed_value: |
Value to be assumed if none sent in data. |
||
0..1 |
is_enumerated_type_constraint: |
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: |
Constraint represented by this object; redefine in descendants. |
||
Functions |
Signature |
Meaning |
||
1..1 |
has_assumed_value (): |
True if there is an assumed value. |
||
1..1 |
constrained_typename (): |
Generate name of native type that is constrained by this |
||
1..1 |
c_conforms_to ( |
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. Parameters
|
||
1..1 |
c_value_conforms_to ( |
True if this node expresses a value constraint that conforms to that of |
||
1..1 |
c_congruent_to ( |
True if constraints represented by this node contain no further redefinitions with respect to the node Typically used to test if an inherited node locally contains any constraints. |
||
1..1 |
c_value_congruent_to ( |
True if this node expresses the same value constraint as |
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): 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
precursor (other, rm_type_conformance_checker) and c_value_conforms_to (other)
end
c_value_conforms_to (other: like Current): Boolean
-- True if this node expresses a value constraint that conforms to that of `other'
deferred
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 := constrained_typename.is_case_insensitive_equal (other.constrained_typename) and
c_value_congruent_to (other)
end
c_value_congruent_to (other: like Current): Boolean
-- True if this node's value constraint is the same as that of `other'
deferred
end
4.5.11. C_BOOLEAN Class
Class |
C_BOOLEAN |
|
---|---|---|
Description |
Constraint on instances of |
|
Inherit |
||
Attributes |
Signature |
Meaning |
0..1 |
Boolean constraint - a list of Boolean values. |
|
0..1 |
assumed_value: |
Assumed Boolean value. |
1..1 |
default_value: |
Default Boolean value. |
Functions |
Signature |
Meaning |
1..1 |
prototype_value (): |
Prototype Boolean value. |
1..1 |
any_allowed (): |
True if any value (i.e. instance) of the reference model type would be allowed. Redefined in descendants. |
1..1 |
True if |
|
1..1 |
True if the items in |
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_value_conforms_to (other: like Current): Boolean
-- True if this node is a strict subset of `other'
do
Result := other.any_allowed or
constraint.count < other.constraint.count and
across constraint as val_csr all other.constraint.has (val_csr.item) end
end
c_value_congruent_to (other: like Current): Boolean
-- True if this node's value constraint is the same as that of `other'
do
Result := 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 |
|
Inherit |
||
Attributes |
Signature |
Meaning |
0..1 |
String constraint - a list of literal strings and / or regular expression strings delimited by the ‘/’ character. To represent no constraint, use an empty list, or alternatively, a regex 'any' pattern, i.e. |
|
1..1 |
default_value: |
Default String value. |
0..1 |
assumed_value: |
Assumed String value. |
Functions |
Signature |
Meaning |
1..1 |
prototype_value (): |
|
1..1 |
True if a_value is valid with respect to constraint expressed in concrete instance of this type. |
|
1..1 |
any_allowed (): |
True if any value (i.e. instance) of the reference model type would be allowed. Redefined in descendants. |
1..1 |
True if |
|
1..1 |
True if the items in |
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_value_conforms_to (other: like Current): Boolean
-- True if `constraint' is a strict subset of other.constraint
do
Result := other.any_allowed or
constraint.count < other.constraint.count and
across constraint as constraint_csr all
other.constraint.has (constraint_csr.item)
end
end
c_value_congruent_to (other: like Current): Boolean
-- True if this node's value constraint is the same as that of `other'
do
Result := 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<T> (abstract) |
|
---|---|---|
Description |
Abstract parent of primitive constrainer classes based on In its simplest form, the constraint accessor returns just a single point The next simplest form is a single proper |
|
Inherit |
||
Attributes |
Signature |
Meaning |
0..1 |
Constraint in the form of a List of Intervals of the parameter type T. Concrete types generated in descendants via template binding. |
|
Functions |
Signature |
Meaning |
1..1 |
any_allowed (): |
True if any value (i.e. instance) of the reference model type would be allowed. Redefined in descendants. |
1..1 |
True if |
|
1..1 |
True if the items in |
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_value_conforms_to (other: like Current): Boolean
-- True if this node is a strict subset of `other'
do
Result := other.any_allowed or
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
c_value_congruent_to (other: like Current): Boolean
-- True if this node is the same as `other'
do
Result := 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 |
||
Attributes |
Signature |
Meaning |
0..1 |
Formal constraint on To represent no constraint, use an empty list. |
4.5.15. C_REAL Class
Class |
C_REAL |
|
---|---|---|
Description |
Constraint on instances of Real. |
|
Inherit |
||
Attributes |
Signature |
Meaning |
0..1 |
Formal constraint on To represent no constraint, use an empty list. |
4.5.16. C_TEMPORAL Class
Class |
C_TEMPORAL<T> (abstract) |
|
---|---|---|
Description |
Purpose Abstract parent of |
|
Inherit |
||
Attributes |
Signature |
Meaning |
0..1 |
pattern_constraint: |
Optional alternative constraint in the form of a pattern based on ISO8601. See descendants for details. |
Functions |
Signature |
Meaning |
1..1 |
True if |
|
1..1 |
valid_pattern_constraint_replacement ( |
Return True if |
1..1 |
any_allowed (): |
True if any value (i.e. instance) of the reference model type would be allowed. Redefined in descendants. |
1..1 |
True if precursor() or else |
|
1..1 |
True if |
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_value_conforms_to (other: like Current): Boolean
-- True if this node is a strict subset of `other'
do
Result := precursor (other) and
other.pattern_constraint.is_empty or
not pattern_constraint.is_empty and then
valid_pattern_constraint_replacement (pattern_constraint, other.pattern_constraint)
end
c_value_congruent_to (other: like Current): Boolean
-- True if this node's value constraint is the same as that of `other'
do
Result := precursor (other) and
pattern_constraint ~ other.pattern_constraint
end
4.5.17. C_DATE Class
Class |
C_DATE |
|
---|---|---|
Description |
Constraint on instances of |
|
Inherit |
||
Attributes |
Signature |
Meaning |
0..1 |
Formal constraint on the assumed primitive For a pattern constraint or no constraint, use an empty list. |
|
Functions |
Signature |
Meaning |
1..1 |
month_validity (): |
Validity of month in constrained date. |
1..1 |
day_validity (): |
Validity of day in constrained date. |
1..1 |
timezone_validity (): |
Validity of timezone in constrained date. |
Invariants |
Pattern_validity: |
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 |
|
Inherit |
||
Attributes |
Signature |
Meaning |
0..1 |
Formal constraint on the assumed primitive For a pattern constraint or no constraint, use an empty list. |
|
Functions |
Signature |
Meaning |
1..1 |
minute_validity (): |
Validity of minute in constrained time. |
1..1 |
second_validity (): |
Validity of second in constrained time. |
1..1 |
millisecond_validity (): |
Validity of millisecond in constrained time. |
1..1 |
timezone_validity (): |
Validity of timezone in constrained date. |
Invariants |
Pattern_validity: |
4.5.19. C_DATE_TIME Class
Class |
C_DATE_TIME |
|
---|---|---|
Description |
Constraint on instances of assumed primitive type |
|
Inherit |
||
Attributes |
Signature |
Meaning |
0..1 |
constraint: |
Formal constraint on the assumed primitive For a pattern constraint or no constraint, use an empty list. |
Functions |
Signature |
Meaning |
1..1 |
month_validity (): |
Validity of month in constrained date. |
1..1 |
day_validity (): |
Validity of day in constrained date. |
1..1 |
timezone_validity (): |
Validity of timezone in constrained date. |
1..1 |
minute_validity (): |
Validity of minute in constrained time. |
1..1 |
second_validity (): |
Validity of second in constrained time. |
1..1 |
millisecond_validity (): |
Validity of millisecond in constrained time. |
Invariants |
Pattern_validity: |
4.5.20. C_DURATION Class
Class |
C_DURATION |
|
---|---|---|
Description |
Constraint on instances of assumed primitive type In official ISO 8601:2004, the ‘W’ (week) designator cannot be mixed in; allowing it is an openEHR-wide exception. The allowed patterns are: |
|
Inherit |
||
Attributes |
Signature |
Meaning |
0..1 |
Formal constraint on assumed primitive type For a pattern constraint or no constraint, use an empty list. |
|
Functions |
Signature |
Meaning |
1..1 |
years_allowed: (): |
True if years are allowed in the constrained Duration. |
1..1 |
months_allowed: (): |
True if months are allowed in the constrained Duration. |
1..1 |
weeks_allowed: (): |
True if weeks are allowed in the constrained Duration. |
1..1 |
days_allowed (): |
True if days are allowed in the constrained Duration. |
1..1 |
hours_allowed (): |
True if hours are allowed in the constrained Duration. |
1..1 |
minutes_allowed (): |
True if minutes are allowed in the constrained Duration. |
1..1 |
seconds_allowed (): |
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
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 |
||
Attributes |
Signature |
Meaning |
1..1 |
constraint: |
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 |
assumed_value: |
Assumed Terminology code value. |
1..1 |
default_value: |
|
Functions |
Signature |
Meaning |
0..1 |
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. |
|
0..1 |
For locally defined value sets within individual code bindings: return the term URI(s) substituted from bindings for local at-codes in |
|
0..1 |
value_set_resolved (): |
For locally defined value sets within individual code bindings: final set of external codes to which value set is resolved. |
1..1 |
valid_value ( |
True if a |
1..1 |
prototype_value (): |
A generated prototype value from this constraint object. |
1..1 |
any_allowed (): |
True if any value (i.e. instance) of the reference model type would be allowed. Redefined in descendants. |
1..1 |
c_value_conforms_to ( |
True if |
1..1 |
c_value_congruent_to ( |
True if |
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_value_conforms_to (other: like Current): Boolean
-- True if this node expresses a value constraint that conforms to that of `other'
local
this_vset, other_vset: like value_set_expanded
do
if other.any_allowed then
Result := True
elseif 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
c_value_congruent_to (other: like Current): Boolean
-- True if this node's value constraint is the same as that of `other'
local
this_vset, other_vset: like value_set_expanded
do
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
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: |
Members of this second order constrainer. Normally redefined in descendants. |
||
Functions |
Signature |
Meaning |
||
1..1 |
c_conforms_to ( |
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. Parameters
|
||
1..1 |
c_congruent_to ( |
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 |
|
Inherit |
||
Attributes |
Signature |
Meaning |
1..1 |
members: |
Object constraint members of this tuple group. |
Functions |
Signature |
Meaning |
1..1 |
c_conforms_to ( |
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. |
1..1 |
c_congruent_to ( |
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 |
||
Attributes |
Signature |
Meaning |
0..1 |
tuples: |
Tuple definitions. |
0..1 |
members: |
List of |
Functions |
Signature |
Meaning |
1..1 |
c_conforms_to ( |
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. |
1..1 |
c_congruent_to ( |
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 org.openehr.base.expressions
package described in the 'original' openEHR Expression Language, 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 Section 6. The AOM rules
package is illustrated below.
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 thematches
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.
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 |
||
Attributes |
Signature |
Meaning |
1..1 |
item: |
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 |
||
Attributes |
Signature |
Meaning |
1..1 |
item: |
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.
|
|
Inherit |
||
Attributes |
Signature |
Meaning |
1..1 |
path: |
The path to the archetype node. |
1..1 |
item: |
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.
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 24.
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 theid4
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 termid25.1
from the immediate parent, which itself specialises the termid25
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: |
|
1..1 |
original_language: |
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: |
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: |
Directory of term definitions as a two-level table. The outer hash keys are language codes, e.g. |
0..1 |
Directory of bindings to external terminology codes and value sets, as a two-level table. The outer hash keys are terminology ids, e.g. |
|
1..1 |
owner_archetype: |
Archetype that owns this terminology. |
0..1 |
Archetype-local value sets, each keyed by value-set id, i.e. an ac-code. |
|
0..1 |
terminology_extracts: |
Directory of extracts of external terminologies, as a two-level table. The outer hash keys are terminology ids, e.g. |
Functions |
Signature |
Meaning |
1..1 |
specialisation_depth (): |
Specialisation depth of this archetype. Unspecialised archetypes have depth 0, with each additional level of specialisation adding 1 to the specialisation_depth. |
1..1 |
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. |
|
0..1 |
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. |
|
0..1 |
List of all value set codes in the terminology defining value sets. These correspond to the “ac” codes in an ADL archetype. |
|
1..1 |
True if language |
|
1..1 |
True if there are bindings to terminology |
|
1..1 |
True if code |
|
1..1 |
term_definition ( |
Term definition for a code, in a specified language. |
1..1 |
term_binding ( |
Binding of constraint corresponding to |
1..1 |
List of terminologies to which term or constraint bindings exist in this terminology, computed from bindings. |
|
1..1 |
terminology_extract_term ( |
Return an |
1..1 |
has_terminology_extract ( |
True if there is a provided terminology extract present. |
1..1 |
List of languages in which terms in this terminology are available. |
|
Invariants |
Original_language_validity: |
|
concept_code_validity: |
||
Term_bindings_validity: |
||
Parent_archetype_valid: |
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: |
Code of source term of this relation. |
1..1 |
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 |
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: |
Code of this term. |
1..1 |
text: |
Short term text, typically for display. |
1..1 |
description: |
Full description text. |
0..1 |
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
andrm_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.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
inC_ATTRIBUTE
is valid with respect to RM (VCAEX); -
check that
cardinality
inC_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 onlyARCHETYPE_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.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 enclosingcardinality
(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 am.p_aom2
package 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.
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 Figure 6. 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.
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 witht_
; -
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.
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 |
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 |
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: |
Name of this profile, usually based on the publisher it pertains to e.g. "openEHR", "cdisc", etc. |
0..1 |
aom_rm_type_mappings: |
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 |
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:
|
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: |
Name of the AOM type being mapped to an RM type. |
1..1 |
target_class_name: |
Name of the RM type in the mapping. |
0..1 |
property_mappings: |
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: |
Name of property in source class. |
1..1 |
target_property_name: |
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.
10.6. Facilities for RM Visualisation
Various meta-attributes may be added to an AOM profile in order to affect the behaviour of archetyping tools and processing. These are not required for correct functioning of tools, but are typically needed to make models comprehensible. Without them, there will no difference between primitive types such as Any
, Integer
etc, business types (e.g. things like Person
, etc), and business-level data types (e.g. CodedText
, Quantity
etc).
------------------------------------------------------
-- archetyping
-- override archetype parent class from included schema
------------------------------------------------------
archetype_parent_class = <"CLASS_NAME">
archetype_data_value_parent_class = <"CLASS_NAME">
archetype_visualise_descendants_of = <"CLASS_NAME">
10.6.1. archetype_parent_class
The archetype_parent_class
attribute defines a base class from the Reference Model that provides archetyping capability in RM data structures. It is optional, and there need be no such class in the RM. In the openEHR and 13606 RMs, this class exists, (LOCATABLE
, and RECORD_COMPONENT
respectively). Defining it here has the effect in tools that the class tree under which archetypes are arranged contains only RM classes inheriting from this class, e.g. LOCATABLE
classes in the case of openEHR. If nothing is set here, all classes in the RM are assumed as candidates for archetypes.
This attribute, if defined, must be defined in the same schema that defines the referenced class.
10.6.2. archetype_data_value_parent_class
The archetype_data_value_parent_class
attribute defines a base class from the Reference Model whose descendants are considered to be 'logical data types' (i.e. of some higher level than the built-in primitive types String
, Integer
etc). This attribute is optional, even if the RM does have such a class, and is only used to help tooling provide more intelligent display, e.g. in statistical reports.
This attribute, if defined, must be defined in the same schema that defines the referenced class.
10.6.3. archetype_visualise_descendants_of
If archetype_parent_class
is not set, designate a class whose descendants should be made visible in tree and grid renderings of the archetype definition. For openEHR and CEN this class is normally the same as the archetype_parent_class
, i.e. LOCATABLE
and RECORD_COMPONENT
respectively. It is typically set for CEN, because archetype_parent_class
may not be stated, due to demographic types not inheriting from it.
The effect of this attribute in visualisation is to generate the most natural tree or grid-based view of an archetype definition, from the semantic viewpoint.
10.6.4. archetype_namespace
The attribute archetype_namespace
defines the package or packages that are considered the archetyping namespace used in archetype multi-axial ids. For example, in openEHR, an archetype is identified by an id of the form:
openEHR-EHR-OBSERVATION.some_obs.vN
The 'EHR' in the above is an 'RM package closure', i.e. the name of an RM package whose class closure by reachability provides the set of classes that may be archetyped in the 'EHR' namespace. The reason for this is somewhat subtle: consider that if you want archetypes based on classes defined directly within a package P, and you also define these archetypes that re-use other archetypes based on more basic types like openEHR’s CLUSTER
or similar (typically not defined in the head package), then you will inevitably have archetypes based on CLUSTER
only for use with EHR archetypes e.g. archetypes based on OBSERVATION
. However, you may well create archetypes based on CLUSTER
only for use with e.g. top-level archetypes from the demographic package. The archetype_namespace setting is used to define the root id namespaces for archetypes, allowing low-level archetypes to be designated for use with one or other high-level archetype. E.g. openEHR-EHR-CLUSTER.bp_position.v1
would be used only with openEHR-EHR-OBSERVATION.bp_measurement.vX
, or similar, and most likely not with any openEHR-DEMOGRAPHIC-XXXX.yyyy.vN
archetype. Note that in openEHR, there is nothing to prevent such cross-namespace reuse - it is just a design guideline.
This attribute, must be defined in the same schema that defines the referenced package(s).
References
Beale, T. (2000). Archetypes: Constraint-based Domain Models for Future-proof Information Systems. Retrieved from https://www.openehr.org/publications/archetypes/archetypes_beale_web_2000.pdf
Beale, T. (2002). Archetypes: Constraint-based Domain Models for Future-proof Information Systems. In K. Baclawski & H. Kilov (Eds.), Eleventh OOPSLA Workshop on Behavioral Semantics: Serving the Customer (pp. 16–32). Northeastern University, Boston. Retrieved from https://www.openehr.org/publications/archetypes/archetypes_beale_oopsla_2002.pdf