Editors: T Bealea | ||
---|---|---|
Revision: 2.0.1 | Pages: 59 | Date of issue: 20 Mar 2007 |
a. Ocean Informatics
Keywords: EHR, ADL, health records, archetypes, constraints
EHR Extract | ||||||
---|---|---|---|---|---|---|
EHR | Demographic | Integration | Template OM | |||
Composition | openEHR Archetype Profile | |||||
Security | Common | Archetype OM | ADL | |||
Data Structures | ||||||
Data Types | ||||||
Support |
© 2004-2007 The openEHR Foundation.
The openEHR Foundation is an independent, non-profit community, facilitating the sharing of health records by consumers and clinicians via open-source, standards-based implementations.
Founding | David Ingram, Professor of Health Informatics, |
---|---|
Chairman | CHIME, University College London |
Founding | Dr P Schloeffel, Dr S Heard, Dr D Kalra, D Lloyd, T Beale |
Members | |
email: info@openEHR.org web: http://www.openEHR.org |
Rev 2.0.1
© Copyright openEHR Foundation 2001 - 2007 All Rights Reserved
Date of Issue: 20 Mar 2007 Page 2 of 59 Editors:T Beale
© 2004-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
Rev 2.0.1
Amendment Record
Issue | Details | Raiser | Completed |
---|---|---|---|
R E L E A S E 1.0.1 | |||
2.0.1 | CR-000200. Correct Release 1.0 typographical errors. Table for missed class ASSERTION_VARIABLE added. Assumed_value assertions corrected; standard_representation function corrected. Added missed adl_version, concept rename from CR-000153. CR-000216: Allow mixture of W, D etc in ISO8601 Duration (deviation from standard). CR-000219: Use constants instead of literals to refer to terminology in RM. CR-000232. Relax validity invariant on CONSTRAINT_REF. CR-000233: Define semantics for occurrences on ARCHETYPE_INTERNAL_REF. CR-000234: Correct functional semantics of AOM constraint model package. CR-000245: Allow term bindings to paths in archetypes. | D Lloyd, P Pazos, R Chen, C Ma S Heard R Chen R Chen K Atalag T Beale S Heard | 20 Mar 2007 |
R E L E A S E 1.0 | |||
2.0 | CR-000153. Synchronise ADL and AOM attribute naming. CR-000178. Add Template Object Model to AM. Text changes only. CR-000167. Add AUTHORED_RESOURCE class. Remove description package to resource package in Common IM. | T Beale T Beale T Beale | 10 Nov 2005 |
R E L E A S E 0.96 | |||
0.6 | CR-000134. Correct numerous documentation errors in AOM. Including cut and paste error in TRANSLATION_DETAILS class in Archetype package. Corrected hyperlinks in Section 2.3. CR-000142. Update ADL grammar to support assumed values. Changed C_PRIMITIVE and C_DOMAIN_TYPE. CR-000146: Alterations to am.archetype.description from CEN MetaKnow CR-000138. Archetype-level assertions. CR-000157. Fix names of OPERATOR_KIND class attributes | D Lloyd S Heard, T Beale D Kalra T Beale T Beale | 20 Jun 2005 |
R E L E A S E 0.95 | |||
0.5.1 | Corrected documentation error -return type of ARCHETYPE_CONSTRAINT.has_path; add optionality markers to Primitive types UML diagram. Removed erroneous aggregation marker from ARCHETYPE_ONTOLOGY.parent_archetype and ARCHETYPE_DESCRIPTION.parent_archetype. | D Lloyd | 20 Jan 2005 |
0.5 | CR-000110. Update ADL document and create AOM document. Includes detailed input and review from: - DSTC - CHIME, Uuniversity College London - Ocean Informatics Initial Writing. Taken from ADL document 1.2draft B. | T Beale A Goodchild Z Tun T Austin D Kalra N Lea D Lloyd S Heard T Beale | 10 Nov 2004 |
Editors:T Beale Page 3 of 59 Date of Issue: 20 Mar 2007
© 2004-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
Rev 2.0.1
Microsoft is a trademark of the Microsoft Corporation
Date of Issue: 20 Mar 2007 Page 4 of 59 Editors:T Beale
© 2004-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
Rev 2.0.1
1 Introduction.............................................................................. 7
1.5.1 What is an Archetype?.....................................................................7
1.7 Changes from Previous Versions ...........................................................8
2 The Archetype Object Model.................................................. 9
2.3.1 Archetypes as Objects....................................................................10
2.3.2 The Archetype Ontology ...............................................................11
2.3.3 Archetype Specialisation ...............................................................12
2.3.4 Archetype Composition.................................................................12
3 The Archetype Package......................................................... 13
3.2.1 ARCHETYPE Class ......................................................................14
3.2.2 VALIDITY_KIND Class ...............................................................16
4 Constraint Model Package.................................................... 17
4.2.2 Attribute Node Types.....................................................................17
4.2.3 Object Node Types ........................................................................19
4.3.1 ARCHETYPE_CONSTRAINT Class...........................................22
4.3.2 C_ATTRIBUTE Class ...................................................................23
4.3.3 C_SINGLE_ATTRIBUTE Class...................................................23
4.3.4 C_MULTIPLE_ATTRIBUTE Class..............................................23
4.3.5 CARDINALITY Class ..................................................................24
4.3.6 C_OBJECT Class ..........................................................................25
4.3.7 C_DEFINED_OBJECT Class .......................................................25
4.3.8 C_COMPLEX_OBJECT Class .....................................................26
4.3.9 C_PRIMITIVE_OBJECT Class ....................................................27
4.3.10 C_DOMAIN_TYPE Class.............................................................27
4.3.11 C_REFERENCE_OBJECT Class .................................................27
4.3.12 ARCHETYPE_SLOT Class ..........................................................28
4.3.13 ARCHETYPE_INTERNAL_REF Class.......................................28
4.3.14 CONSTRAINT_REF Class...........................................................29
Editors:T Beale Page 5 of 59 Date of Issue: 20 Mar 2007
© 2004-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
Rev 2.0.1
5 The Assertion Package .......................................................... 31
5.3.1 ASSERTION Class ....................................................................... 32
5.3.2 EXPR_ITEM Class ....................................................................... 32
5.3.3 EXPR_LEAF Class.......................................................................33
5.3.4 EXPR_OPERATOR Class ............................................................33
5.3.5 EXPR_UNARY_OPERATOR Class ............................................ 34
5.3.6 EXPR_BINARY_OPERATOR Class ........................................... 34
5.3.7 ASSERTION_VARIABLE Class..................................................35
5.3.8 OPERATOR_KIND Class.............................................................36
6 The Primitive Package........................................................... 39
6.2.1 C_PRIMITIVE Class .................................................................... 40
6.2.2 C_BOOLEAN Class .....................................................................40
6.2.3 C_STRING Class .......................................................................... 41
6.2.4 C_INTEGER Class .......................................................................41
6.2.5 C_REAL Class .............................................................................. 42
6.2.6 C_DATE Class .............................................................................. 42
6.2.7 C_TIME Class...............................................................................43
6.2.8 C_DATE_TIME Class................................................................... 44
6.2.9 C_DURATION Class .................................................................... 47
7 Ontology Package .................................................................. 49
7.3.1 ARCHETYPE_ONTOLOGY Class .............................................50
7.3.2 ARCHETYPE_TERM Class......................................................... 52
A Domain-specific Extension Example.................................... 53
A.2 Scientific/Clinical Computing Types .................................................. 53
B Using Archetypes with Diverse Reference Models ............. 55
B.2 Clinical Computing Use ...................................................................... 55
C References............................................................................... 57
Date of Issue: 20 Mar 2007 Page 6 of 59 Editors:T Beale
© 2004-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
Archetype Object Model Introduction Rev 2.0.1
This document contains the definitive statement of archetype semantics, in the form of an object model for archetypes. The model presented here can be used as a basis for building software that processes archetypes, 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) [4] , XML-instance and so on. As a specification, it can be treated as an API for archetypes.
It is recommended that the openEHR ADL document [4] 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.
Prerequisite documents for reading this document include:
• The openEHR Architecture Overview Related documents include:
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’.
This document is under development, and is published as a proposal for input to standards processes and implementation works.
This document is available at http://svn.openehr.org/specification/TAGS/Release 1.0.1/publishing/architecture/am/aom.pdf.
The latest version of this document can be found at http://svn.openehr.org/specifica tion/TRUNK/publishing/architecture/am/aom.pdf.
Blue text indicates sections under active development.
Archetypes are constraint-based models of domain entities, or what some might call “structured business rules”. Each archetype describes configurations of data instances whose classes are described in a reference model; the instance configurations are considered to be valid exemplars of a particular
Editors:T Beale Page 7 of 59 Date of Issue: 20 Mar 2007
© 2004-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
Introduction Archetype Object Model Rev 2.0.1
domain concept. Thus, in medicine, an archetype might be designed to constrain configurations of instances of a simple node/arc information model, that express a “microbiology test result” or a “physical examination”. Archetypes can be composed, specialised, and templated for local use. The archetype concept has been described in detail by Beale [1], [2]. Most of the detailed formal seman tics are described in the openEHR Archetype Definition Language [4] . The openEHR archetype framework is described in terms of Archetype Definitions and Principles [4] and an Archetype Sys tem [5] .
The object model described in this document relates to linguistic forms of archetypes as shown in FIGURE 1. The model (upper right in the figure) is the object-oriented semantic equivalent of the ADL the Archetype Definition Language BNF language definition, and, by extension, any formal transformation of it. Instances of the model (lower right on the figure) are themselves archetypes, and correspond one-to-one with archetype documents expressed in ADL or a related language.
archetype language
Archetype object
definition (EBNF)
XML-schema
IDL
other concrete
formalisms
FIGURE 1 Relationship of Archetype Object Model to Archetype Languages
Various tools exist for creating and processing archetypes. The openEHR tools are available in source and binary form from the website ( http://www.openEHR.org ).
As part of the changes carried out to ADL version 1.3, the archetype object model specified here is revised, also to version 2.0, to indicate that ADL and the AOM can be regarded as 100% synchronised specifications.
Date of Issue: 20 Mar 2007 Page 8 of 59 Editors:T Beale
© 2004-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
Archetype Object Model The Archetype Object Model Rev 2.0.1
An underpinning principle of openEHR is the use of archetypes and templates, which are formal models of domain content, and are used to control data structure and content during creation, modificatoin and querying. The elements of this architecture are twofold.
The purpose of ADL is to provide an abstract syntax for textually expressing archetypes and templates. The AOM defines the object model equivalent, in terms of a UML model. It is a generic model, meaning that it can be used to express archetypes for any reference model in a standard way. ADL and the AOM are brought together in an ADL parser: a tool which can read ADL archetype texts, and whose parse-tree (resulting in-memory object representation) is instances of the AOM. The TOM defines the object model of templates, which are themselves used to put archetypes together into local information structures, usually corresponding to screen forms.
The purpose of the openEHR Archetype Profile is to define which classes and attributes of the openEHR RM can be sensibly archetyped, and to provide custom archetype classes.
The openEHR Archetype Object Model is defined as the package am.archetype, as illustrated in FIGURE 2 . It is shown in the context of the openEHR am.archetype packages.
FIGURE 2 openehr.am.archetype Package
Editors:T Beale Page 9 of 59 Date of Issue: 20 Mar 2007
© 2004-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
The Archetype Object Model Archetype Object Model Rev 2.0.1
The model described here is a pure object-oriented model that can be used with archetype parsers and software that manipulates archetypes. It is independent of any particular linguistic expression of an archetype, such as ADL or OWL, and can therefore be used with any kind of parser.
It is dependent on the openEHR Support model (assumed types and identifiers), as small number of the openEHR Data types IM, and the AUTHORED_RESOURCE classes from the openEHR Common IM.
FIGURE 3 illustrates various processes that can be responsible for creating an archetype object structure, including parsing, database retrieval and GUI editing. A parsing process that would typically turn a syntax expression of an archetype (ADL, XML, OWL) into an object one. The input file is converted by a parser into an object parse tree, shown on the right of the figure, whose types are specified in this document. Database retrieval will cause the reconstruction of an archetype in memory from a structured data representation, such as relational data, object data or XML. Direct in-memory editing by a user with a GUI archetype editor application will cause on-the-fly creation and destruction of parts of an archetype during the editing session, which would eventually cause the archetype to be stored in some form when the user decides to commit it.
After initial parsing, the in-memory representation is then validated by the semantic checker of the ADL parser, which can verify numerous things, such as that term codes referenced in the definition section are defined in the ontology section. It can also validate the classes and attributes mentioned in the archetype against a specification for the relevant information model (e.g. in XMI or some equivalent)
information model specification
description
archetype
binding
key
C_attribute (single)
constraint_ref
use_reference
C_complex_object
C_primitive_object
archetype_slot
C_attribute (container)
FIGURE 3 Archetype Parsing Process
Date of Issue: 20 Mar 2007 Page 10 of 59 Editors:T Beale
© 2004-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
Archetype Object Model The Archetype Object Model Rev 2.0.1
As shown in the figure, the definition part of the in-memory archetype consists of alternate layers of object and attribute constrainer nodes, each containing the next level of nodes. 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. 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 ontology, 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. ENTRY, 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: an node representing a constraint on a primitive (built-in) object type;
Archetype_internal_ref: a node that refers to a previously defined object node in the same archetype. The reference is made using a path;
Constraint_ref: a node that refers to a constraint on (usually) a text or coded term entity, which appears in the ontology section of the archetype, and in ADL, is referred to with an “acNNNN” code. The constraint is expressed in terms of a query on an external entity, usually a terminology or ontology;
Archetype_slot: a node whose statements define a constraint that determines which other archetypes can appear at that point in the current archetype. It can be thought of like a keyhole, into which few or many keys might fit, depending on how specific its shape is. Logically it has the same semantics as a C_COMPLEX_OBJECT, except that the constraints are expressed in another archetype, not the current one.
The typename nomenclature “C_complex_object”, “C_primitive_object”, “C_attribute” used here is intended to be read as “constraint on xxxx”, i.e. a “C_complex_object” is a “constraint on a complex object (defined by a complex reference model type)”. These typenames are used below in the formal model.
There are no linguistic entities at all in the definition part of an archetype, with the possible exception of constraints on text items which might have been defined in terms of regular expression patterns or fixed strings. All linguistic entities are defined in the ontology part of the archetype, in such a way as to allow them to be translated into other languages in convenient blocks. As described in the openEHR ADL document, there are four major parts in an archetype ontology: term definitions, constraint definitions, term bindings and constraint bindings. The former two define the meanings of various terms and textual constraints which occur in the archetype; they are indexed with unique identifiers which are used within the archetype definition body. The latter two ontology sections describe the mappings of terms used internally to external terminologies. Due to the well-known problems with terminologies (described in some detail in the openEHR ADL document, and also by
e.g. Rector [6] and others), mappings may be partial, incomplete, approximate, and occasionally, exact.
Editors:T Beale Page 11 of 59 Date of Issue: 20 Mar 2007
© 2004-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
The Archetype Object Model Archetype Object Model Rev 2.0.1
Archetypes can be specialised. The formal rules of specialisation are described in the openEHR Archetype Semantics document (forthcoming), but in essence are easy to understand. Briefly, an archetype is considered a specialisation of another archetype if it mentions that archetype as its parent, and only makes changes to its definition such that its constraints are ‘narrower’ than those of the parent. Any data created via the use of the specialised archetype is thus conformant both to it and its parent. This notion of specialisation corresponds to the idea of ‘substitubility’, applied to data.
Every archetype has a ‘specialisation depth’. Archetypes with no specialisation parent have depth 0, and specialised archetypes add one level to their depth for each step down a hierarchy required to reach them.
It the interests of re-use and clarity of modelling, archetypes can be composed to form larger structures semantically equivalent to a single large archetype. Composition allows two things to occur: for archetypes to be defined according to natural ‘levels’ or encapsulations of information, and for the reuse of smaller archetypes by a multitude of others. Archetype slots are the means of composition, and are themselves defined in terms of constraints.
Date of Issue: 20 Mar 2007 Page 12 of 59 Editors:T Beale
© 2004-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
Archetype Object Model The Archetype Package Rev 2.0.1
The model of an archetype, illustrated in FIGURE 4, is straightforward at an abstract level, mimick ing the structure of an archetype document as defined in the openEHR Archetype Definition Language (ADL) document. An archetype is a modelled as a particular kind of AUTHORED_RESOURCE, and as such, includes descriptive meta-data, language information and revision history. The ARCHETYPE class adds identifying information, a definition - expressed in terms of constraints on instances of an object model, and an ontology. The archetype definition, the ‘main’ part of an archetype, is an
AUTHORED_RESOURCE
(rm.common.resource)
FIGURE 4 openehr.am.archetype Package
instance of a C_COMPLEX_OBJECT, which is to say, the root of the constraint structure of an archetype always takes the form of a constraint on a non-primitive object type. The last section of an archetype, the ontology, is represented by its own class, and is what allows the archetypes to be natural language- and terminology-neutral.
A utility class, VALIDITY_KIND is also included in the Archetype package. This class contains one integer attribute and three constant definitions, and is intended to be used as the type of any attribute in this constraint model whose value is logically ‘mandatory’, ‘optional’, or ‘disallowed’. It is used in this model in the classes C_Date, C_Time and C_Date_Time.
Editors:T Beale Page 13 of 59 Date of Issue: 20 Mar 2007
© 2004-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
The Archetype Package Archetype Object Model Rev 2.0.1
3.2.1 ARCHETYPE Class
CLASS | ARCHETYPE | |
---|---|---|
Purpose | Archetype equivalent to ARCHETYPED class in Common reference model. Defines semantics of identfication, lifecycle, versioning, composition and specialisation. | |
Inherit | AUTHORED_RESOURCE | |
Attributes | Signature | Meaning |
0..1 | adl_version: String | ADL version if archteype was read in from an ADL sharable archetype. |
1..1 | archetype_id: ARCHETYPE_ID | Multi-axial identifier of this archetype in archetype space. |
0..1 | uid: HIER_OBJECT_ID | OID identifier of this archetype. |
1..1 | concept: String | The normative meaning of the archetype as a whole, expressed as a local archetype code, typically “at0000”. |
0..1 | parent_archetype_id: ARCHETYPE_ID | Identifier of the specialisation parent of this archetype. |
1..1 | definition: C_COMPLEX_OBJECT | Root node of this archetype |
1..1 | ontology: ARCHETYPE_ONTOLOGY | The ontology of the archetype. |
0..1 | invariants: Set<ASSERTION> | Invariant statements about this object. Statements are expressed in first order predicate logic, and usually refer to at least two attributes. |
Functions | Signature | Meaning |
1..1 | version: String previous_version: String | Version of this archetype, extracted from id. Version of predecessor archetype of this archetype, if any. |
0..1 | ||
1..1 | short_concept_name: String | The short concept name of the archetype extracted from the archetype_id. |
concept_name (a_lang: String): String | The concept name of the archetype in language a_lang; corresponds to the term definition of the concept attribute in the archetype ontology. |
Date of Issue: 20 Mar 2007 Page 14 of 59 Editors:T Beale
Archetype Object Model The Archetype Package Rev 2.0.1
CLASS | ARCHETYPE | ||
---|---|---|---|
1..1 | physical_paths: Set<String> | Set of language-independent paths extracted from archetype. Paths obey Xpath-like syntax and are formed from alternations of C_OBJECT.node_id and C_ATTRIBUTE.rm_attribute_name values. | |
logical_paths (a_lang: String): Set<String> | Set of language-dependent paths extracted from archetype. Paths obey the same syntax as physical_paths, but with node_ids replaced by their meanings from the ontology. | ||
1..1 | is_specialised: Boolean ensure Result implies parent_archetype_id /= Void | True if this archetype is a specialisation of another. | |
1..1 | specialisation_depth: Integer ensure Result = ontology. specialisation_depth | Specialisation depth of this archetype; larger than 0 if this archetype has a parent. Derived from ontology.specialisation_depth. | |
node_ids_valid: Boolean | True if every node_id found on a C_OBJECT node is found in ontology.term_codes. | ||
internal_references_valid: Boolean | True if every ARCHETYPE_INTERNAL_REF. target_path refers to a legitimate node in the archetype definition. | ||
constraint_references_valid: Boolean | True if every CONSTRAINT_REF.reference found on a C_OBJECT node in the archetype definition is found in ontology.constraint_codes. | ||
is_valid: Boolean ensure not (node_ids_valid and internal_references_valid and constraint_references_valid) implies not Result | True if the archetype is valid overall; various tests should be used, including checks on node_ids, internal references, and constraint references. |
Editors:T Beale Page 15 of 59 Date of Issue: 20 Mar 2007
© 2004-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
The Archetype Package Archetype Object Model
Rev 2.0.1
archetype_id_validity: archetype_id /= Void concept_valid: ontology.has_term_code(concept_code) uid_validity: uid /= Void implies not uid.is_empty version_validity: version /= Void and then version.is_equal(archetype_id.version_id) original_language_valid: original_language /= void and then language /= Void and then code_set(Code_set_id_languages).has_code(original_language) description_exists: description /= Void definition_exists: definition /= Void ontology_exists: ontology /= Void Specialisation_validity: is_specialised implies specialisation_depth > 0 Invariants_valid: invariants /= Void implies not invariants.is_empty
3.2.2 VALIDITY_KIND Class
CLASS | VALIDITY_KIND | |
---|---|---|
Purpose | An enumeration of three values which may commonly occur in constraint models. | |
Use | Use as the type of any attribute within this model, which expresses constraint on some attribute in a class in a reference model. For example to indicate validity of Date/Time fields. | |
Attributes | Signature | Meaning |
1..1 | const mandatory: Integer = 1001 | Constant to indicate mandatory presence of something |
1..1 | const optional: Integer = 1002 | Constant to indicate optional presence of something |
1..1 | const disallowed: Integer = 1003 | Constant to indicate disallowed presence of something |
1..1 | value: Integer | Actual value |
Functions | Signature | Meaning |
valid_validity (a_validity: Integer): Boolean ensure a_validity >= mandatory and a_validity <= disallowed | Function to test validity values. | |
Invariant | Validity: valid_validity(value) |
Date of Issue: 20 Mar 2007 Page 16 of 59 Editors:T Beale
© 2004-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
Archetype Object Model Constraint Model Package Rev 2.0.1
FIGURE 5 illustrates the class model of 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 UML (or a similar object-oriented meta-model). 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’.
An informal way of understanding the model is as follows. An archetype definition is an instance of a C_COMPLEX_OBJECT, which can be thought of as expressing constraints on a object that is of some particular reference model type (recorded in the attribute rm_type_name), and which is larger than a simple instance of a primitive type such as String or Integer. The constraints define what 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. At the leaf nodes of an archetype definition are C_PRIMITIVE_OBJECT nodes, defining the constraints on leaf values of objects, i.e. Integers, Strings etc.
The effect of the model is to create archetype description structures that are a hierarchical alternation of object and attribute constraints, as shown in FIGURE 3. This structure can be seen by inspecting an ADL archetype, or by viewing an archetype in the openEHR ADL workbench [9], and is a direct con sequence 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 subset of the W3C Xpath syntax.
A small number of properties are defined for all node types. 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. The is_valid function indicates whether the current node and all subnodes are internally valid according to the semantics of this archetype model. The is_subset_of function is used for comparison between corresponding nodes from different archetypes, in order to asert specialisation.
Constraints on attributes are represented by instances of the two subtypes of C_ATTRIBUTE: C_SINGLE_ATTRIBUTE and C_MULTIPLE_ATTRIBUTE. For both subtypes, the common constraint is
Editors:T Beale Page 17 of 59 Date of Issue: 20 Mar 2007
© 2004-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
constraint_model
ARCHETYPE_CONSTRAINT
is_valid: Boolean has_path(a_path: String): Boolean path: String is_subset_of (other: ARCHETYPE_CONSTRAINT): Boolean
FIGURE 5 openehr.am.archetype.constraint_model Package
Archetype Object Model Constraint Model Package Rev 2.0.1
whether the corresponding instance (defined by the rm_attribute_name attribute) must exist. Both subtypes have a list of children, representing constraints on the object value(s) of the attribute.
Single-valued attributes (such as Person.date_of_birth: Date) are constrained by instances of the type C_SINGLE_ATTRIBUTE, which uses the children to represent multiple alternative object constraints for the attribute value.
Multiply-valued attributes (such as Person.contacts: List<Contact>) are constrained by an instance of C_MULTIPLE_ATTRIBUTE, which allows multiple co-existing member objects of the container value of the attribute to be constrained, along with a cardinality constraint, describing ordering and unique ness of the container. FIGURE 6 illustrates the two possibilities.
(PERSON.address as structured or free text form)
FIGURE 6 Single and Multiple-valued C_ATTRIBUTES
The need for both existence and cardinality constraints in the C_MULTIPLE_ATTRIBUTE class 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 required. 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.
The node_id attribute in the class C_OBJECT, inherited by all subtypes, is of great importance in the archetype constraint model. It has two functions:
The existence of node_ids in an archetype allows archetype paths to be created, which refer to each node. Not every node in the archetype needs a node_id, if it does not need to be addressed using a path; any leaf or near-leaf node which has no sibling nodes from the same attribute can safely have no node_id.
Editors:T Beale Page 19 of 59 Date of Issue: 20 Mar 2007
© 2004-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
Constraint Model Package Archetype Object Model Rev 2.0.1
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_OBJECTs as follows.
The any_allowed function a node 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. Any_allowed is effected in subtypes to indicate in concrete terms when it is True, usually related to Void attribute values.
When archetypes are defined to have optional parts, an ability to define ‘assumed’ values is useful. For example, an archetype for the concept ‘blood pressure measurement’ might contain an optional protocol section describing the 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 could be 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 values 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. Assumed values are definable at the leaf level only, which appears to be adequate for all purposes described to date; accordingly, they appear in descendants of C_PRIMITIVE and also C_DOMAIN_TYPE.
The notion of assumed values is distinct from that of ‘default values’. The latter is a local requirement, and as such is stated in templates; default values do appear in data, while assumed values don’t.
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.
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.
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.
Date of Issue: 20 Mar 2007 Page 20 of 59 Editors:T Beale
© 2004-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
Archetype Object Model Constraint Model Package Rev 2.0.1
Constraints on primitive types are defined by the classes inheriting from C_PRIMITIVE, namely C_STRING, C_INTEGER and so on. These types do not inherit from ARCHETYPE_CONSTRAINT, but rather are related by association, in order to allow them to have the simplest possible definitions, independent even from the rest of ADL, in the hope of acceptance in heath standardisation organisations. Technically, avoiding inheritance from ARCHETYPE_CONSTRAINT / C_PRIMITIVE_OBJECT into these base types (in other words, coalescing the classes C_PRIMITIVE_OBJECT and C_PRIMITIVE) does not pose a problem, but could be effected at a later date if desired.
The main part of the archetype constraint model allows any type in a reference model to be archetyped - i.e. constrained - in a standard way, which is to say, by a regular cascade of C_COMPLEX_OBJECT / C_ATTRIBUTE / C_PRIMITIVE_OBJECT objects. This generally works well, especially for ‘outer’ container types in models. However, it occurs reasonably often that lower level logical ‘leaf’ types need special constraint semantics that are not conveniently achieved with the standard aproach. To enable such classes to be integrated into the generic constraint model, the class C_DOMAIN_TYPE is included. This enables the creation of specific “C_” classes, inheriting from C_DOMAIN_TYPE, which represent custom semantics for particular reference model types. For example, a class called C_QUANTITY might be created which has different constraint semantics from the default effect of a C_COMPLEX_OBJECT / C_ATTRIBUTE cascade representing such constraints in the generic way (i.e. systematically based on the reference model). An example of domain-specific extension classes is shown in Domain-specific Extension Example on page 53 .
The subtypes of C_REFERENCE_OBJECT, namely, ARCHETYPE_SLOT, ARCHETYPE_INTERNAL_REF and CONSTRAINT_REF 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; and a reference to a constraint on a constraint defined in the archetype ontology, which in turn points to an external knowledge resource, such as a terminology.
A CONSTRAINT_REF is really a proxy for a set of constraints on an object that would normally occur at a particular point in the archetype as a C_COMPLEX_OBJECT, but where the actual definition of the constraints is outside the archetype definition proper, and is instead expressed in the binding of the constraint reference (e.g. ‘ac0004’) to a query or expression into an external service (e.g. a terminology service). The result of the query could be something like:
See the ADL specification for a fuller explanation, under the heading Placeholder constraints in the cADL section.
The C_ATTRIBUTE and subtypes of C_OBJECT enable constraints to be expressed in a structural fashion such that any constraint concerning a single attribute may be expressed, including recursively. In addition to this, any instance of a C_COMPLEX_OBJECT may include one or more invariants. Invariants are statements in a form of predicate logic, which can also be used to state constraints on parts of an object. They are not needed to constrain single attributes (since this can be done with an appopriate C_ATTRIBUTE), but are necessary for constraints referring to more than one attribute, such as a con
Editors:T Beale Page 21 of 59 Date of Issue: 20 Mar 2007
© 2004-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
Constraint Model Package Archetype Object Model Rev 2.0.1
straint that ‘systolic pressure should be >= diastolic pressure’ in a blood pressure measurement archetype. Invariants are expressed using a syntax derived from the OMG’s OCL syntax (adapted for use with objects rather than classes).
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 document.
4.3.1 ARCHETYPE_CONSTRAINT Class
CLASS | ARCHETYPE_CONSTRAINT (abstract) | |
---|---|---|
Purpose | Archetype equivalent to LOCATABLE class in openEHR Common reference model. Defines common constraints for any inheritor of LOCATABLE in any reference model. | |
Abstract | Signature | Meaning |
is_subset_of (other: ARCHETYPE_CONSTRAINT): Boolean require other /= Void | True if constraints represented by other are narrower than this node. Note: not easily evaluatable for CONSTRAINT_REF nodes. | |
is_valid: Boolean | True if this node (and all its sub-nodes) is a valid archetype node for its type. This function should be implemented by each subtype to perform semantic validation of itself, and then call the is_valid function in any subparts, and generate the result appropriately. | |
Functions | Signature | Meaning |
path: String | Path of this node relative to root of archetype. | |
has_path (a_path: String): Boolean require a_path /= Void | True if the relative path a_path exists at this node. | |
Invariant | path_exists: path /= Void |
Date of Issue: 20 Mar 2007 Page 22 of 59 Editors:T Beale
© 2004-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
Archetype Object Model Constraint Model Package Rev 2.0.1
4.3.2 C_ATTRIBUTE Class
CLASS | C_ATTRIBUTE(abstract) | |
---|---|---|
Purpose | Abstract model of constraint on any kind of attribute node. | |
Attributes | Signature | Meaning |
1..1 | rm_attribute_name: String | Reference model attribute within the enclosing type represented by a C_OBJECT. |
1..1 | existence: Interval<Integer> | Constraint 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). |
0..1 | children: List<C_OBJECT> | Child C_OBJECT nodes. Each such node represents a constraint on the type of this attribute in its reference model. Multiples occur both for multiple items in the case of container attributes, and alternatives in the case of singular attributes. |
Invariant | Rm_attribute_name_valid: rm_attribute_name /= Void and then not rm_attribute_name.is_empty Existence_set: existence /= Void and then (existence.lower >= 0 and existence.upper <= 1) Children_validity: any_allowed xor children /= Void |
4.3.3 C_SINGLE_ATTRIBUTE Class
CLASS | C_SINGLE_ATTRIBUTE | |
---|---|---|
Purpose | Concrete model of constraint on a single-valued attribute node. The meaning of the inherited children attribute is that they are alternatives. | |
Functions | Signature | Meaning |
alternatives: List<C_OBJECT> | List of alternative constraints for the single child of this attribute within the data. | |
Invariant | Alternatives_exists: alternatives /= Void |
4.3.4 C_MULTIPLE_ATTRIBUTE Class
CLASS | C_MULTIPLE_ATTRIBUTE | |
---|---|---|
Purpose | Abstract model of constraint on any kind of attribute node. | |
Attributes | Signature | Meaning |
Editors:T Beale Page 23 of 59 Date of Issue: 20 Mar 2007
© 2004-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
Constraint Model Package Archetype Object Model Rev 2.0.1
CLASS | C_MULTIPLE_ATTRIBUTE | |
---|---|---|
1..1 | cardinality: CARDINALITY | Cardinality of this attribute constraint, if it constraints a container attribute. |
Functions | Signature | Meaning |
members: List<C_OBJECT> | List of constraints representing members of the container value of this attribute within the data. Semantics of the uniqueness and ordering of items in the container are given by the cardinality. | |
Invariant | Cardinality_validity: cardinality /= Void Members_valid: members /= Void and then members.for_all(co: C_OBJECT | co.occurrences.upper <= 1) |
4.3.5 CARDINALITY Class
CLASS | CARDINALITY | |
---|---|---|
Purpose | Express constraints on the cardinality of container objects which are the values of multiply-valued attributes, including uniqueness and ordering, providing the means to state that a container acts like a logical list, set or bag. The cardinality cannot contradict the cardinality of the corresponding attribute within the relevant reference model. | |
Attributes | Signature | Meaning |
1..1 | is_ordered: Boolean | True if the members of the container attribute to which this cardinality refers are ordered. |
1..1 | is_unique: Boolean | True if the members of the container attribute to which this cardinality refers are unique. |
1..1 | interval: Interval<Integer> | The interval of this cardinality. |
Functions | Signature | Meaning |
is_bag: Boolean ensure Result = not is_ordered and not is_unique | True if the semantics of this cardinality represent a set, i.e. unordered, unique membership. | |
is_list: Boolean ensure Result = is_ordered and not is_unique | True if the semantics of this cardinality represent a list, i.e. ordered, non-unique membership. |
Date of Issue: 20 Mar 2007 Page 24 of 59 Editors:T Beale
Archetype Object Model Constraint Model Package Rev 2.0.1
CLASS | CARDINALITY | |
---|---|---|
is_set Boolean ensure Result = not is_ordered and is_unique | True if the semantics of this cardinality represent a bag, i.e. unordered, non-unique membership. | |
Invariant | Validity: not interval.lower_unbounded |
4.3.6 C_OBJECT Class
CLASS | C_OBJECT (abstract) | |
---|---|---|
Purpose | Abstract model of constraint on any kind of object node. | |
Attributes | Signature | Meaning |
1..1 | rm_type_name: String | Reference model type that this node corresponds to. |
1..1 | occurrences: Interval<Integer> | 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). |
1..1 | node_id: String | Semantic id of this node, used to differentiate sibling nodes of the same type. [Previously called ‘meaning’]. Each node_id must be defined in the archetype ontology as a term code. |
0..1 | parent: C_ATTRIBUTE | C_ATTRIBUTE that owns this C_OBJECT. |
Invariant | rm_type_name_valid: rm_type_name /= Void and then not rm_type_name.is_empty node_id_valid: node_id /= Void and then not node_id.is_empty Occurrences_validity: occurrences /= Void and then (parent /= Void implies (not parent.is_multiple implies occurrences.upper <= 1)) |
4.3.7 C_DEFINED_OBJECT Class
CLASS | C_DEFINED_OBJECT (abstract) | |
---|---|---|
Purpose | Abstract parent type of C_OBJECT subtypes that are defined by value, i.e. whose definitions are actually in the archetype rather than being by reference. | |
Inherit | C_OBJECT | |
Abstract | Signature | Meaning |
Editors:T Beale Page 25 of 59 Date of Issue: 20 Mar 2007
© 2004-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
Constraint Model Package Archetype Object Model Rev 2.0.1
CLASS | C_DEFINED_OBJECT (abstract) |
default_value: like assumed_value Generate a default value from this constraint object | |
valid_value (a_value: like assumed_value): Boolean require a_value /= Void True if a_value is valid with respect to constraint expressed in concrete instance of this type. | |
any_allowed: Boolean True if any value (i.e. instance) of the reference model type would be allowed. Redefined in descedants. | |
Attributes | Signature Meaning |
0..1 | assumed_value: Any Value to be assumed if none sent in data |
Functions | Signature Meaning |
has_assumed_value: Boolean True if there is an assumed value Assumed_value_valid: has_assumed_value implies valid_value(assumed_value) | |
Invariant |
4.3.8 C_COMPLEX_OBJECT Class
CLASS | C_COMPLEX_OBJECT | |
---|---|---|
Purpose | Constraint on complex objects, i.e. any object that consists of other object constraints. | |
Inherit | C_DEFINED_OBJECT | |
Functions | Signature | Meaning |
(effected) | any_allowed: Boolean ensure Result = attributes.is_empty | True if any value of the reference model type being constrained is allowed. |
Attributes | Signature | Meaning |
0..1 | attributes: Set<C_ATTRIBUTE> | List of constraints on attributes of the reference model type represented by this object. |
Invariant | attributes_valid: any_allowed xor (attributes /= Void and not attributes.is_empty) |
Date of Issue: 20 Mar 2007 Page 26 of 59 Editors:T Beale
© 2004-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
Archetype Object Model Constraint Model Package Rev 2.0.1
4.3.9 C_PRIMITIVE_OBJECT Class
CLASS | C_PRIMITIVE_OBJECT | |
---|---|---|
Purpose | Constraint on a primitive type. | |
Inherit | C_DEFINED_OBJECT | |
Functions | Signature | Meaning |
(effected) | any_allowed: Boolean ensure Result = (item = Void) | True if any value of the type being constrained in item is allowed. |
Attributes | Signature | Meaning |
0..1 | item: C_PRIMITIVE | Object actually defining the constraint. |
Invariant | item_exists: any_allowed xor item /= Void |
4.3.10 C_DOMAIN_TYPE Class
CLASS | C_DOMAIN_TYPE (abstract) | |
---|---|---|
Purpose | Abstract parent type of domain-specific constrainer types, to be defined in external packages. | |
Inherit | C_DEFINED_OBJECT | |
Abstract | Signature | Meaning |
standard_equivalent: C_COMPLEX_OBJECT | Standard (i.e. C_OBJECT) form of constraint. | |
Invariant |
4.3.11 C_REFERENCE_OBJECT Class
CLASS | C_REFERENCE_OBJECT (abstract) | |
---|---|---|
Purpose | Abstract parent type of C_OBJECT subtypes that are defined by reference. | |
Inherit | C_OBJECT | |
Abstract | Signature | Meaning |
Invariant |
Editors:T Beale Page 27 of 59 Date of Issue: 20 Mar 2007
© 2004-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
Constraint Model Package Archetype Object Model Rev 2.0.1
4.3.12 ARCHETYPE_SLOT Class
CLASS | ARCHETYPE_SLOT | |
---|---|---|
Purpose | Constraint describing a ‘slot’ where another archetype can occur. | |
Inherit | C_REFERENCE_OBJECT | |
Attributes | Signature | Meaning |
0..1 | includes: Set <ASSERTION> | List of constraints defining other archetypes that could be included at this point. |
0..1 | excludes: Set<ASSERTION> | List of constraints defining other archetypes that cannot be included at this point. |
Invariant | includes_valid: includes /= Void implies not includes.is_empty excludes_valid: excludes /= Void implies not excludes.is_empty validity: any_allowed xor (includes /= Void or excludes /= Void) |
4.3.13 ARCHETYPE_INTERNAL_REF Class
CLASS | ARCHETYPE_INTERNAL_REF | |
---|---|---|
Purpose | 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 an ARCHETYPE_INTERNAL_REF should always be used; when setting this from a serialised form, if no occurrences is mentioned, the target occurrences should be used (not the standard default of {1..1}); otherwise the locally specified occurrences should be used as normal. When serialising out, if the occurrences is the same as that of the target, it can be left out. | |
Inherit | C_REFERENCE_OBJECT | |
Attributes | Signature | Meaning |
1..1 | target_path: String | Reference to an object node using archetype path notation. |
Invariant | Consistency: not any_allowed target_path_valid: target_path /= Void and then not target_path.is_empty --and then ultimate_root.has_path(target_path) |
Date of Issue: 20 Mar 2007 Page 28 of 59 Editors:T Beale
© 2004-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
Archetype Object Model Constraint Model Package Rev 2.0.1
4.3.14 CONSTRAINT_REF Class
CLASS | CONSTRAINT_REF | |
---|---|---|
Purpose | Reference to a constraint described in the same archetype, but outside the main constraint structure. This is used to refer to constraints expressed in terms of external resources, such as constraints on terminology value sets. | |
Inherit | C_REFERENCE_OBJECT | |
Attributes | Signature | Meaning |
1..1 | reference: String | Reference to a constraint in the archetype local ontology. |
Invariant | Consistency: not any_allowed reference_valid: reference /= Void |
Editors:T Beale Page 29 of 59 Date of Issue: 20 Mar 2007
© 2004-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
Constraint Model Package Archetype Object Model Rev 2.0.1
Date of Issue: 20 Mar 2007 Page 30 of 59 Editors:T Beale
© 2004-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
Archetype Object Model The Assertion Package Rev 2.0.1
Assertions are expressed in archetypes in typed first-order predicate logic (FOL). They are used in two places: to express archetype slot constraints, and to express invariants in complex object constraints. In both of these places, their role is to constrain something inside the archetype. Constraints on external resources such as terminologies are expressed in the constraint binding part of the archetype ontology, described in section 7 on page 49. The assertion package is illustrated below in FIG URE 7.
assertion
FIGURE 7 The openehr.am.archetype.assertion package
The concrete syntax of assertion statements in archetypes is designed to be compatible with the OMG Object Constraint Language (OCL) [10]. Archetype assertions are essentially statements which con tain the following elements:
Editors:T Beale Page 31 of 59 Date of Issue: 20 Mar 2007
© 2004-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
The Assertion Package Archetype Object Model Rev 2.0.1
The written syntax of assertions is defined in the openEHR ADL document. The package described here is currently designed to allow the representation of a general-purpose binary expression tree, as would be generated by a parser. This may be replaced in the future by a more specific model, if needed.
This relatively simple model of expressions is sufficiently powerful for representing FOL expressions on archetype structures, although it could clearly be more heavily subtyped.
5.3.1 ASSERTION Class
CLASS | ASSERTION | |
---|---|---|
Purpose | Structural model of a typed first order predicate logic assertion, in the form of an expression tree, including optional variable definitions. | |
Attributes | Signature | Meaning |
0..1 | tag: String | Expression tag, used for differentiating multiple assertions. |
1..1 | expression: EXPR_ITEM | Root of expression tree. |
0..1 | string_expression: String | String form of expression, in case an expression evaluator taking String expressions is used for evaluation. |
0..1 | variables: List<ASSERTION_VARIABLE> | Definitions of variables used in the assertion expression. |
Invariant | Tag_valid: tag /= Void implies not tag.is_empty Expression_valid: expression /= Void and then expres-sion.type.is_equal(“BOOLEAN”) |
5.3.2 EXPR_ITEM Class
CLASS | EXPR_ITEM (abstract) | |
---|---|---|
Purpose | Abstract parent of all expression tree items. | |
Attributes | Signature | Meaning |
1..1 | type: String | Type name of this item in the mathematical sense. For leaf nodes, must be the name of a primitive type, or else a reference model type. The type for any relational or boolean operator will be “Boolean”, while the type for any arithmetic operator, will be “Real” or “Integer”. |
Date of Issue: 20 Mar 2007 Page 32 of 59 Editors:T Beale
© 2004-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
Archetype Object Model The Assertion Package Rev 2.0.1
Type_valid: type /= Void and then not type.is_empty
5.3.3 EXPR_LEAF Class
CLASS | EXPR_LEAF | |
---|---|---|
Purpose | Expression tree leaf item. This can represent one of: • a manifest constant of any primitive type (Integer, Real, Boolean, String, Character, Date, Time, Date_time, Duration), or (in future) of any complex reference model type, e.g. a DV_CODED_TEXT; • a path referring to a value in the archetype (paths with a leading ‘/’ are in the definition section; paths with no leading ‘/’ are in the outer part of the archetype, e.g. “archetype_id/value” refers to the String value of the archetype_id attribute of the enclosing archetype; • a constraint, expressed in the form of concrete subtype of C_OBJECT; most often this will be a C_PRIMITIVE_OBJECT. | |
Inherit | EXPR_ITEM | |
Attributes | Signature | Meaning |
1..1 | item: ANY | The value referred to; a manifest constant, an attribute path (in the form of a String), or for the right-hand side of a ‘matches’ node, a constraint, often a C_PRIMITIVE_OBJECT. [Future: paths including function names as well, even if not constrained in the archetype - as long as they are in the reference model]. |
1..1 | reference_type: String | Type of reference: “constant”, “attribute”, “function”, “constraint”. The first three are used to indicate the referencing mechanism for an operand. The last is used to indicate a constraint operand, as happens in the case of the right-hand operand of the ‘matches’ operator. |
Invariant | Item_valid: item /= Void Reference_type_valid: reference_type /= Void |
5.3.4 EXPR_OPERATOR Class
Editors:T Beale Page 33 of 59 Date of Issue: 20 Mar 2007
© 2004-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
The Assertion Package Archetype Object Model Rev 2.0.1
CLASS | EXPR_OPERATOR (abstract) | |
---|---|---|
Inherit | EXPR_ITEM | |
Attributes | Signature | Meaning |
1..1 | operator: OPERATOR_KIND | Code of operator. |
1..1 | precedence_overridden: Boolean | True if the natural precedence of operators is overridden in the expression represented by this node of the expression tree. If True, parentheses should be introduced around the totality of the syntax expression corresponding to this operator node and its operands. |
Invariant |
5.3.5 EXPR_UNARY_OPERATOR Class
CLASS | EXPR_UNARY_OPERATOR | |
---|---|---|
Purpose | Unary operator expression node. | |
Inherit | EXPR_OPERATOR | |
Attributes | Signature | Meaning |
1..1 | operand: EXPR_ITEM | Operand node. |
Invariant | operand_valid: operand /= Void |
5.3.6 EXPR_BINARY_OPERATOR Class
CLASS | EXPR_BINARY_OPERATOR | |
---|---|---|
Purpose | Binary operator expression node. | |
Inherit | EXPR_OPERATOR | |
Attributes | Signature | Meaning |
1..1 | left_operand: EXPR_ITEM | Left operand node. |
1..1 | right_operand: EXPR_ITEM | Right operand node. |
Invariant | left_operand_valid: operand /= Void right_operand_valid: operand /= Void |
Date of Issue: 20 Mar 2007 Page 34 of 59 Editors:T Beale
© 2004-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
Archetype Object Model The Assertion Package Rev 2.0.1
5.3.7 ASSERTION_VARIABLE Class
CLASS | ASSERTION_VARIABLE | |
---|---|---|
Purpose | Definition of a named variable used in an assertion expression. Note: the definition of named variables may change; still under development in ADL2. | |
Attributes | Signature | Meaning |
1..1 | name: String | Name of variable. |
1..1 | definition: String | Formal definition of the variable. (see ADL2 specification; still under development). |
Invariant | Name_valid: name /= Void and then not name.is_empty Definition_valid: definition /= Void and then not definition.is_empty |
Editors:T Beale Page 35 of 59 Date of Issue: 20 Mar 2007
© 2004-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
The Assertion Package Archetype Object Model Rev 2.0.1
5.3.8 OPERATOR_KIND Class
CLASS | OPERATOR_KIND | |
---|---|---|
Purpose | Enumeration type for operator types in assertion expressions | |
Use | Use as the type of operators in the Assertion package, or for related uses. | |
Constants | Signature | Meaning |
op_eq: Integer = 2001 | Equals operator (‘=’ or ‘==’) | |
op_ne: Integer = 2002 | Not equals operator (‘!=’ or ‘/=’ or ‘<>’) | |
op_le: Integer = 2003 | Less-than or equals operator (‘<=’) | |
op_lt: Integer = 2004 | Less-than operator (‘<’) | |
op_ge: Integer = 2005 | Greater-than or equals operator (‘>=’) | |
op_gt: Integer = 2006 | Greater-than operator (‘>’) | |
op_matches: Integer = 2007 | Matches operator (‘matches’ or ‘is_in’) | |
op_not: Integer = 2010 | Not logical operator | |
op_and: Integer = 2011 | And logical operator | |
op_or: Integer = 2012 | Or logical operator | |
op_xor: Integer = 2013 | Xor logical operator | |
op_implies: Integer = 2014 | Implies logical operator | |
op_for_all: Integer = 2015 | For-all quantifier operator | |
op_exists: Integer = 2016 | Exists quantifier operator | |
op_plus: Integer = 2020 | Plus operator (‘+’) | |
op_minus: Integer = 2021 | Minus operator (‘-’) | |
op_multiply: Integer = 2022 | Multiply operator (‘*’) | |
op_divide: Integer = 2023 | Divide operator (‘/’) |
Date of Issue: 20 Mar 2007 Page 36 of 59 Editors:T Beale
Archetype Object Model The Assertion Package Rev 2.0.1
CLASS | OPERATOR_KIND | |
---|---|---|
op_exp: Integer = 2024 | Exponent operator (‘^’) | |
Attributes | Signature | Meaning |
value: Integer | Actual value of this instance | |
Functions | Signature | Meaning |
valid_operator (an_op: Integer): Boolean ensure an_op >= op_eq and an_op <= op_exp | Function to test operator values. | |
Invariant | Validity: valid_operator(value) |
Editors:T Beale Page 37 of 59 Date of Issue: 20 Mar 2007
© 2004-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
The Assertion Package Archetype Object Model Rev 2.0.1
Date of Issue: 20 Mar 2007 Page 38 of 59 Editors:T Beale
© 2004-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
Archetype Object Model The Primitive Package Rev 2.0.1
Ultimately any archetype definition will devolve down to leaf node constraints on instances of primi tive types. The primitive package, illustrated in FIGURE 8, defines the semantics of constraint on such types.
C_PRIMITIVE_OBJECT (am.archetype.constraint_model)
1
item
C_PRIMITIVE
default_value: ANY assumed_value: ANY has_assumed_value: Boolean valid_value(a_value:ANY): Boolean
C_INTEGER
C_REAL C_BOOLEAN C_STRING
list[0..1]: Set<Integer>
list[0..1]: Set<Real> Boolean
true_valid[1]: pattern[0..1]: String
range[0..1]: false_valid[1]:
range[0..1]:
list[0..1]: Set<String>
Interval<Real> Boolean
Interval<Integer>
list_open[0..1]:
assumed_value: Integer
assumed_value: Real assumed_value[0..1]
Boolean
assumed_value
: Boolean [0..1]: String
C_DURATION C_DATE_TIME C_DATE C_TIME
years_allowedmonth_validity[0..1]:
month_validity[0..1]:
minute_validity[0..1]:
[0..1]: Boolean day_validity[0..1]:
VALIDITY_KIND VALIDITY_KIND VALIDITY_KIND months_allowed day_validity[0..1]:
second_validity[0..1]:
[0..1]: Boolean timezone_validity[0..1]:
VALIDITY_KIND VALIDITY_KIND VALIDITY_KIND weeks_allowed hour_validity[0..1]:
millisecond_validity
[0..1]: Boolean range[0..1]: Interval<Date>
VALIDITY_KIND VALIDITY_KIND [0..1]: VALIDITY_KIND
days_allowed assumed_value[0..1]: Date
minute_validity[0..1]:
timezone_validity[0..1]:
[0..1]: Boolean range[0..1]:
VALIDITY_KIND VALIDITY_KIND hours_allowed second_validity[0..1]:
[0..1]: Boolean assumed_value[0..1]:
VALIDITY_KIND Interval<Time> minutes_allowed millisecond_validity[0..1]:
[0..1]: Boolean timezone_validity[0..1]:
VALIDITY_KIND Time seconds_allowed
[0..1]: Boolean range[0..1]:
VALIDITY_KIND fractional_seconds_
allowed assumed_value[0..1]:
Interval<Date_Time>
[0..1]: Boolean Date_Time
range[0..1]: Interval<Duration>
assumed_value
[0..1]: Duration
FIGURE 8 The openehr.am.archetype.primitive Package
Most of the types provide at least two alternative ways to represent the constraint; for example the C_DATE type allows the constraint to be expressed in the form of a pattern (defined in the ADL speci
Editors:T Beale Page 39 of 59 Date of Issue: 20 Mar 2007
© 2004-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
The Primitive Package Archetype Object Model Rev 2.0.1
fication) or an Interval<Date>. Note that the interval form of dates is probably only useful for historical date checking (e.g. the date of an antique or a particular batch of vaccine), rather than constraints on future date/times.
6.2.1 C_PRIMITIVE Class
CLASS | C_PRIMITIVE (abstract) | |
---|---|---|
Purpose | Abstract supertype of all prmitive types. | |
Abstract | Signature | Meaning |
1..1 | default_value: ANY | Generate a default value from this constraint object |
1..1 | has_assumed_value: Boolean | True if there is an assumed value |
1..1 | assumed_value: like default_value | Value to be assumed if none sent in data |
valid_value (a_value: like default_value): Boolean require a_value /= Void | True if a_value is valid with respect to constraint expressed in concrete instance of this type. | |
Invariant | Assumed_value_valid: has_assumed_value implies valid_value(assumed_value) |
6.2.2 C_BOOLEAN Class
CLASS | C_BOOLEAN | |
---|---|---|
Purpose | Constraint on instances of Boolean. | |
Use | Both attributes cannot be set to False, since this would mean that the Boolean value being constrained cannot be True or False. | |
Inherit | C_PRIMITIVE | |
Attributes | Signature | Meaning |
1..1 | true_valid: Boolean | True if the value True is allowed |
1..1 | false_valid: Boolean | True if the value False is allowed |
1..1 (redefined) | assumed_value: Boolean | The value to assume if this item is not included in data, due to being part of an optional structure. |
Date of Issue: 20 Mar 2007 Page 40 of 59 Editors:T Beale
© 2004-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
Archetype Object Model The Primitive Package Rev 2.0.1
Binary_consistency: true_valid or false_valid Default_value_consistency: default_value.value and true_valid or else not default_value.value and false_valid
6.2.3 C_STRING Class
CLASS | C_STRING | |
---|---|---|
Purpose | Constraint on instances of STRING. | |
Inherit | C_PRIMITIVE | |
Attributes | Signature | Meaning |
0..1 (cond) | pattern: String | Regular expression pattern for proposed instances of String to match. |
0..1 (cond) | list: Set<String> | Set of Strings specifying constraint |
1..1 | list_open: Boolean | True if the list is being used to specify the constraint but is not considered exhaustive. |
1..1 (redefined) | assumed_value: String | The value to assume if this item is not included in data, due to being part of an optional structure. |
Invariant | Consistency: pattern /= Void xor list /= Void pattern_exists: pattern /= Void implies not pattern.is_empty |
6.2.4 C_INTEGER Class
CLASS | C_INTEGER | |
---|---|---|
Purpose | Constraint on instances of Integer. | |
Inherit | C_PRIMITIVE | |
Attributes | Signature | Meaning |
0..1 (cond) | list: Set<Integer> | Set of Integers specifying constraint |
0..1 (cond) | range: Interval<Integer> | Range of Integers specifying constraint |
Editors:T Beale Page 41 of 59 Date of Issue: 20 Mar 2007
© 2004-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
The Primitive Package Archetype Object Model Rev 2.0.1
CLASS | C_INTEGER | |
---|---|---|
1..1 (redefined) | assumed_value: Integer | The value to assume if this item is not included in data, due to being part of an optional structure. |
Invariant | Consistency: list /= Void xor range /= Void |
6.2.5 C_REAL Class
CLASS | C_REAL | |
---|---|---|
Purpose | Constraint on instances of Real. | |
Inherit | C_PRIMITIVE | |
Attributes | Signature | Meaning |
0..1 (cond) | list: Set<Real> | Set of Reals specifying constraint |
0..1 (cond) | range: Interval<Real> | Range of Real specifying constraint |
1..1 (redefined) | assumed_value: Real | The value to assume if this item is not included in data, due to being part of an optional structure. |
Invariant | Consistency: list /= Void xor range /= Void |
6.2.6 C_DATE Class
CLASS | C_DATE | |
---|---|---|
Purpose | ISO 8601-compatible constraint on instances of Date in the form either of a set of validity values, or an actual date range. There is no validity flag for ‘year’, since it must always be by definition mandatory in order to have a sensible date at all. Syntax expressions of instances of this class include “YYYY-??-??” (date with optional month and day). | |
Use | Date ranges are probably only useful for historical dates. | |
Inherit | C_PRIMITIVE | |
Attributes | Signature | Meaning |
0..1 (cond) | month_validity: VALIDITY_KIND | Validity of month in constrained date. |
Date of Issue: 20 Mar 2007 Page 42 of 59 Editors:T Beale
© 2004-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
Archetype Object Model The Primitive Package Rev 2.0.1
CLASS | C_DATE |
0..1 (cond) | day_validity: VALIDITY_KIND Validity of day in constrained date. |
0..1 (cond) | timezone_validity: VALIDITY_KIND Validity of timezone in constrained date. |
0..1 (cond) | range: Interval<Date> Interval of Dates specifying constraint |
1..1 (redefined) | assumed_value: Date The value to assume if this item is not included in data, due to being part of an optional structure. |
Functions | Signature Meaning |
1..1 | validity_is_range: Boolean True if validity is in the form of a range; useful for developers to check which kind of constraint has been set. Month_validity_optional: month_validity = {VALIDITY_KIND}.optional implies (day_validity = {VALIDITY_KIND}.optional or day_validity = {VALIDITY_KIND}.disallowed) Month_validity_disallowed: month_validity = {VALIDITY_KIND}.disallowed implies day_validity = {VALIDITY_KIND}.disallowed Validity_is_range: validity_is_range = (range /= Void) |
Invariant |
6.2.7 C_TIME Class
CLASS | C_TIME | |
---|---|---|
Purpose | ISO 8601-compatible constraint on instances of Time. There is no validity flag for ‘hour’, since it must always be by definition mandatory in order to have a sensible time at all. Syntax expressions of instances of this class include “HH:??:xx” (time with optional minutes and seconds not allowed). | |
Inherit | C_PRIMITIVE | |
Attributes | Signature | Meaning |
0..1 (cond) | minute_validity: VALIDITY_KIND | Validity of minute in constrained time. |
0..1 (cond) | second_validity: VALIDITY_KIND | Validity of second in constrained time. |
0..1 (cond) | millisecond_validity: VALIDITY_KIND | Validity of millisecond in constrained time. |
Editors:T Beale Page 43 of 59 Date of Issue: 20 Mar 2007
The Primitive Package Archetype Object Model Rev 2.0.1
CLASS | C_TIME |
0..1 (cond) | timezone_validity: VALIDITY_KIND Validity of timezone in constrained date. |
0..1 (cond) | range: Interval<Time> Interval of Times specifying constraint |
1..1 (redefined) | assumed_value: Time The value to assume if this item is not included in data, due to being part of an optional structure. |
Functions | Signature Meaning validity_is_range: Boolean True if validity is in the form of a range; useful for developers to check which kind of constraint has been set. Minute_validity_optional: minute_validity = {VALIDITY_KIND}.optional implies (second_validity = {VALIDITY_KIND}.optional or second_validity = {VALIDITY_KIND}.disallowed) Minute_validity_disallowed: minute_validity = {VALIDITY_KIND}.disallowed implies second_validity = {VALIDITY_KIND}.disallowed Second_validity_optional: second_validity = {VALIDITY_KIND}.optional implies (millisecond_validity = {VALIDITY_KIND}.optional or millisecond_validity = {VALIDITY_KIND}.disallowed) Second_validity_disallowed: second_validity = {VALIDITY_KIND}.disallowed implies millisecond_validity = {VALIDITY_KIND}.disallowed Validity_is_range: validity_is_range = (range /= Void) |
1..1 | |
Invariant |
6.2.8 C_DATE_TIME Class
CLASS | C_DATE_TIME | |
---|---|---|
Purpose | ISO 8601-compatible constraint on instances of Date_Time. There is no validity flag for ‘year’, since it must always be by definition mandatory in order to have a sensible date/time at all. Syntax expressions of instances of this class include “YYYY-MM-DDT??:??:??” (date/time with optional time) and “YYYY-MMDDTHH:MM:xx” (date/time, seconds not allowed). | |
Inherit | C_PRIMITIVE | |
Attributes | Signature | Meaning |
0..1 (cond) | month_validity: VALIDITY_KIND | Validity of month in constrained date. |
0..1 (cond) | day_validity: VALIDITY_KIND | Validity of day in constrained date. |
Date of Issue: 20 Mar 2007 Page 44 of 59 Editors:T Beale
Archetype Object Model The Primitive Package Rev 2.0.1
CLASS | C_DATE_TIME | |
---|---|---|
0..1 (cond) | hour_validity: VALIDITY_KIND | Validity of hour in constrained time. |
0..1 (cond) | minute_validity: VALIDITY_KIND | Validity of minute in constrained time. |
0..1 (cond) | second_validity: VALIDITY_KIND | Validity of second in constrained time. |
0..1 (cond) | millisecond_validity: VALIDITY_KIND | Validity of millisecond in constrained time. |
0..1 (cond) | timezone_validity: VALIDITY_KIND | Validity of timezone in constrained date. |
0..1 (cond) | range: Interval<Date_Time> | Range of Date_times specifying constraint |
1..1 (redefined) | assumed_value: Date_Time | The value to assume if this item is not included in data, due to being part of an optional structure. |
Functions | Signature validity_is_range: Boolean | Meaning True if validity is in the form of a range; useful for developers to check which kind of constraint has been set. |
1..1 |
Editors:T Beale Page 45 of 59 Date of Issue: 20 Mar 2007
© 2004-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
The Primitive Package Archetype Object Model
Rev 2.0.1
Month_validity_optional: month_validity = {VALIDITY_KIND}.optional implies (day_validity = {VALIDITY_KIND}.optional or day_validity = {VALIDITY_KIND}.disallowed) Month_validity_disallowed: month_validity = {VALIDITY_KIND}.disallowed implies day_validity = {VALIDITY_KIND}.disallowed Day_validity_optional: day_validity = {VALIDITY_KIND}.optional implies (hour_validity = {VALIDITY_KIND}.optional or hour_validity = {VALIDITY_KIND}.disallowed) Day_validity_disallowed: day_validity = {VALIDITY_KIND}.disallowed implies hour_validity = {VALIDITY_KIND}.disallowed Hour_validity_optional: hour_validity = {VALIDITY_KIND}.optional implies (minute_validity = {VALIDITY_KIND}.optional or minute_validity = {VALIDITY_KIND}.disallowed) Hour_validity_disallowed: hour_validity = {VALIDITY_KIND}.disallowed implies minute_validity = {VALIDITY_KIND}.disallowed Minute_validity_optional: minute_validity = {VALIDITY_KIND}.optional implies (second_validity = {VALIDITY_KIND}.optional or second_validity = {VALIDITY_KIND}.disallowed) Minute_validity_disallowed: minute_validity = {VALIDITY_KIND}.disallowed implies second_validity = {VALIDITY_KIND}.disallowed Second_validity_optional: second_validity = {VALIDITY_KIND}.optional implies (millisecond_validity = {VALIDITY_KIND}.optional or millisecond_validity = {VALIDITY_KIND}.disallowed) Second_validity_disallowed: second_validity = {VALIDITY_KIND}.disallowed implies millisecond_validity = {VALIDITY_KIND}.disallowed Validity_is_range: validity_is_range = (range /= Void)
Date of Issue: 20 Mar 2007 Page 46 of 59 Editors:T Beale
© 2004-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
Archetype Object Model The Primitive Package Rev 2.0.1
6.2.9 C_DURATION Class
CLASS | C_DURATION | |
---|---|---|
Purpose | ISO 8601-compatible constraint on instances of Duration. In ISO 8601 terms, constraints might are of the form “PWD” (weeks and/or days), “PDTHMS” (days, hours, minutes, seconds) and so on. In official ISO 8601:2004, the ‘W’ (week) designator cannot be mixed in; allowing it is an openEHR-wide exception. | |
Inherit | C_PRIMITIVE | |
Attributes | Signature | Meaning |
0..1 | years_allowed: Boolean | True if years are allowed in the constrained Duration. |
0..1 | months_allowed: Boolean | True if months are allowed in the constrained Duration. |
0..1 | weeks_allowed: Boolean | True if weeks are allowed in the constrained Duration. |
0..1 | days_allowed: Boolean | True if days are allowed in the constrained Duration. |
0..1 | hours_allowed: Boolean | True if hours are allowed in the constrained Duration. |
0..1 | minutes_allowed: Boolean | True if minutes are allowed in the constrained Duration. |
0..1 | seconds_allowed: Boolean | True if seconds are allowed in the constrained Duration. |
0..1 | fractional_seconds_allowed: Boolean | True if fractional seconds are allowed in the constrained Duration. |
1..1 | range: Interval<Duration> | Range of Durations specifying constraint |
1..1 (redefined) | assumed_value: Duration | The value to assume if this item is not included in data, due to being part of an optional structure. |
Invariant | Range_valid: range /= Void or else (years_allowed or months_allowed or weeks_allowed or days_allowed or hours_allowed or minutes_allowed or seconds_allowed or fractional_seconds_allowed) |
Editors:T Beale Page 47 of 59 Date of Issue: 20 Mar 2007
© 2004-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
The Primitive Package Archetype Object Model Rev 2.0.1
Date of Issue: 20 Mar 2007 Page 48 of 59 Editors:T Beale
© 2004-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
Archetype Object Model Ontology Package Rev 2.0.1
All linguistic and terminological entities in an archetype are represented in the ontology part of an archetype, whose semantics are given in the Ontology package, shown below.
FIGURE 9 openehr.am.archetype.ontology Package
An archetype ontology consists of the following things.
Any given archetype occurs at some point in a hierarchy of archetypes related by specialisation, where the depth is indicated by the specialisation_depth attribute. An archetype which is not a spe
Editors:T Beale Page 49 of 59 Date of Issue: 20 Mar 2007
© 2004-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
Ontology Package Archetype Object Model Rev 2.0.1
cialisation of another has a specialisation_depth of 0. Term and constraint codes introduced in the ontology of specialised archetypes (i.e. which did not exist in the ontology 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:
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.
Local term and constraint definitions are modelled as instances of the class ARCHETYPE_TERM, which is a code associated with a list of name/value pairs. For any term or constraint definition, this list must at least include the name/value pairs for the names “text” and “description”. It might also include such things as “provenance”, which would be used to indicate that a term was sourced from an external terminology. The attribute term_attribute_names in ARCHETYPE_ONTOLOGY provides a list of attribute names used in term and constraint definitions in the archetype, including “text” and “description”, as well as any others which are used in various places.
7.3.1 ARCHETYPE_ONTOLOGY Class
CLASS | ARCHETYPE_ONTOLOGY | |
---|---|---|
Purpose | Local ontology of an archetype. | |
Attributes | Signature | Meaning |
1..1 | terminologies_available: Set<String> | List of terminologies to which term or constraint bindings exist in this terminology. |
1..1 | specialisation_depth: Integer | Specialisation depth of this archetype. Unspecialised archetypes have depth 0, with each additional level of specialisation adding 1 to the specialisation_depth. |
Date of Issue: 20 Mar 2007 Page 50 of 59 Editors:T Beale
© 2004-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
Archetype Object Model Ontology Package Rev 2.0.1
CLASS | ARCHETYPE_ONTOLOGY | |
---|---|---|
1..1 | term_codes: List<String> | List of all term codes in the ontology. Most of these correspond to “at” codes in an ADL archetype, which are the node_ids on C_OBJECT descendants. There may be an extra one, if a different term is used as the overall archetype concept from that used as the node_id of the outermost C_OBJECTin the definition part. |
1..1 | constraint_codes: List<String> | List of all term codes in the ontology. These correspond to the “ac” codes in an ADL archetype, or equivalently, the CONSTRAINT_REF.reference values in the archetype definition. |
1..1 | term_attribute_names: List<String> | List of ‘attribute’ names in ontology terms, typically includes ‘text’, ‘description’, ‘provenance’ etc. |
1..1 | parent_archetype: ARCHETYPE | Archetype which owns this ontology. |
Functions | Signature has_language(a_lang: String): Boolean | Meaning True if language ‘a_lang’ is present in archetype ontology. |
has_terminology(a_terminology _id: String): Boolean require has_terminology(a_terminology_ id) | True if terminology ‘a_terminology’ is present in archetype ontology. | |
has_term_code(a_code: String): Boolean | True if term_codes has a_code. | |
has_constraint_code(a_code: String): Boolean | True if constraint_codes has a_code. | |
constraint_definition(a_lang, a_code: String): ARCHETYPE_TERM require has_language(a_lang) has_constraint_code(a_code) | Constraint definition for a code, in a specified language. |
Editors:T Beale Page 51 of 59 Date of Issue: 20 Mar 2007
Ontology Package Archetype Object Model Rev 2.0.1
CLASS | ARCHETYPE_ONTOLOGY | |
---|---|---|
term_binding (a_terminology_id, a_code: String): CODE_PHRASE require has_terminology(a_terminology_ id) has_term_code(a_code) | Binding of term corresponding to a_code in target external terminology a_terminology_id as a CODE_PHRASE. | |
constraint_binding (a_terminology_id, a_code: String): String require has_terminology(a_terminology_ id) has_constraint_code(a_code) | Binding of constraint corresponding to a_code in target external terminology a_terminology_id, as a string, which is usually a formal query expression. | |
Invariant | terminologies_available_exists: terminologies_available /= void term_codes_exists: term_codes /= void constraint_codes_exists: constraint_codes /= void term_bindings_exists: term_bindings /= void constraint_bindings_exists: constraint_bindings /= void term_attribute_names_valid: term_attribute_names /= void and then term_attribute_names.has(“text”) and term_attribute_names.has(“description”) Parent_archetype_valid: parent_archetype /= Void and then parent_archetype.description = Current |
7.3.2 ARCHETYPE_TERM Class
CLASS | ARCHETYPE_TERM |
Purpose Attributes | Representation of any coded entity (term or constraint) in the archetype ontology. Signature Meaning |
1..1 | code: String Code of this term. |
0..1 | items: Hash <String, String> Hash of keys (“text”, “description” etc) and corresponding values. |
Functions | Signature Meaning |
1..1 | keys: Set<String> List of all keys used in this term. |
Invariant | code_valid: code /= void and then not code.is_empty keys_valid: keys /= Void |
Date of Issue: 20 Mar 2007 Page 52 of 59 Editors:T Beale
© 2004-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
Rev 2.0.1
Domain-specific classes can be added to the archetype constraint model by inheriting from the class C_DOMAIN_TYPE. This section provides an example of how domain-specific constraint classes are added to the archetype model. Actual additions to the AOM for openEHR are documented in the openEHR Archetype Profile (oAP) specification.
FIGURE 10 shows the general approach, used to add constraint classes for commonly used concepts in scientific and clinical computing, such as ‘ordinal’ (used heavily in medicine, particularly in pathology testing), ‘coded term’ (also heavily used in clinical computing) and ‘quantity’, a general scientific meansurement concept. The constraint types shown are C_ORDINAL, C_CODED_TEXT and C_QUANTITY which can optionally be used in archetypes to replace the default constraint semantics represented by the use of instances of C_OBJECT / C_ATTRIBUTE to constrain ordinals, coded terms and quantities. The following model is intended only as an example, and does not try to define any normative semantics of the particular constraint types shown.
C_DOMAIN_TYPE
Editors:T Beale Page 53 of 59 Date of Issue: 20 Mar 2007
© 2004-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
Rev 2.0.1
Date of Issue: 20 Mar 2007 Page 54 of 59 Editors:T Beale
© 2004-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
Rev 2.0.1
The archetype model described in this document can be used with any reference model which is expressed in UML or a similar object-oriented formalism. It can also be used with E/R models. The following section describes is use a number of reference models used in clinical computing.
To Be Continued:
B.2.2 CEN ENV13606
B.2.3 HL7 Clinical Document Architecture (CDA)
Editors:T Beale Page 55 of 59 Date of Issue: 20 Mar 2007
© 2004-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
Rev 2.0.1
Date of Issue: 20 Mar 2007 Page 56 of 59 Editors:T Beale
© 2004-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
Rev 2.0.1
1 Beale T. Archetypes: Constraint-based Domain Models for Future-proof Information Systems. OOPSLA 2002 workshop on behavioural semantics. Available at http://www.deepthought.com.au/it/archetypes.html.
2 Beale T. Archetypes: Constraint-based Domain Models for Future-proof Information Systems. 2000. Available at http://www.deepthought.com.au/it/archetypes.html .
3 Beale T, Heard S. The Archetype Definition Language (ADL). See http://www.openehr.org/re positories/spec-dev/latest/publishing/architecture/archetypes/lan guage/ADL/REV_HIST.html.
4 Heard S, Beale T. Archetype Definitions and Principles. See http://www.openehr.org/reposi tories/spec-dev/latest/publishing/architecture/archetypes/princi ples/REV_HIST.html.
5 Heard S, Beale T. The openEHR Archetype System. See http://www.openehr.org/reposito- ries/spec-dev/latest/publishing/architecture/archetypes/system/REV_HIST.ht ml .
6 Rector A L. Clinical Terminology: Why Is It So Hard? Yearbook of Medical Informatics 2001. 7 W3C. OWL - The Web Ontology Language. See http://www.w3.org/TR/2003/CR-owl-ref-20030818/ . 8 Horrocks et al. An OWL Abstract Syntax. See http://www.w3.org/xxxx/ .
9 openEHR. EHR Reference Model. See http://www.openehr.org/repositories/spec dev/latest/publishing/architecture/top.html. 10 OMG. The Object Constraint Language 2.0. Available at http://www.omg.org/cgi bin/doc?ptc/2003-10-14.
Editors:T Beale Page 57 of 59 Date of Issue: 20 Mar 2007
© 2004-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
Rev 2.0.1
Date of Issue: 20 Mar 2007 Page 58 of 59 Editors:T Beale
© 2004-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
Rev 2.0.1
END OF DOCUMENT
Editors:T Beale Page 59 of 59 Date of Issue: 20 Mar 2007
© 2004-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org