Editors: T Bealea | ||
---|---|---|
Revision: 0.5 | Pages: 17 | Date of issue: 16 Mar 2007 |
a. Ocean Informatics
Keywords: semantics, archetype
© 2003-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 0.5
© Copyright openEHR Foundation 2001 - 2007 All Rights Reserved
Date of Issue: 16 Mar 2007 Page 2 of 17 Editors:T Beale
© 2003-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
Rev 0.5
Issue | Details | Who | Completed | |
---|---|---|---|---|
R E L E A S E 1.0.1 | ||||
0.5 | Initial Writing. | T Beale | 16 Mar 2007 |
Editors:T Beale Page 3 of 17 Date of Issue: 16 Mar 2007
© 2003-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
Rev 0.5
Date of Issue: 16 Mar 2007 Page 4 of 17 Editors:T Beale
© 2003-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
Rev 0.5
Table of Contents
Editors:T Beale Page 5 of 17 Date of Issue: 16 Mar 2007
© 2003-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
Rev 0.5
Date of Issue: 16 Mar 2007 Page 6 of 17 Editors:T Beale
© 2003-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
Archetype Semantics Introduction Rev 0.5
This document provides a description of the semantics of populations openEHR archetypes, i.e. archetypes that obey the openEHR Archetype Object Model (AOM) specification. The semantics of single archetypes are described in the ADL and AOM specifications.
Prerequisite documents for reading this document include:
This document is under development, and is published as a proposal for input to standards processes and implementation works.
The latest version of this document can be found in PDF format at http://svn.openehr.org/spec ification/TRUNK/publishing/architecture/am/archetype_semantics.pdf. New versions are announced on openehr-announce@openehr.org .
Editors:T Beale Page 7 of 17 Date of Issue: 16 Mar 2007
© 2003-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
Overview Archetype Semantics Rev 0.5
This specification describes the formal semantics of populations of archetypes, i.e. beyond the semantics of a single archetype. The areas dealt with include identification; archetype path relationships; conformance; and the various archetype-archetype relationships including specialisation, composition, versioning etc.
To Be Continued:
Date of Issue: 16 Mar 2007 Page 8 of 17 Editors:T Beale
© 2003-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
Archetype Semantics Archetype Identification Rev 0.5
Archetypes can be identified with various kinds of identifiers. Currently, the multi-axial archetype identifier specified by the rm.support.identification.ARCHETYPE_ID class in the openEHR Support IM is used. Other identifier types such as an ISO Oid could be deployed in the future, most likely in parallel with the multi-axial identifier.
The archetype identifier is declared in the heading section of an archetype, e.g.
openEHR-EHR-OBSERVATION.haematology.v1
The multi-axial archetype identifier encodes the partitioning of the archetype space in the identifier. Each identifier instance denotes a single archetype within a versioned 2-dimensional space, with the dimensions being:
As with any multi-axial identifier, the underlying principle of an archetype id is that all parts of the id must be able to be considered immutable. This means that no variable characteristic of an archetype
(e.g. accrediting authority, which might change due to later accreditation by another authority, or may be multiple) can be included in its identifier. The syntax of an Archetype id is as follows:
archetype_id: qualified_rm_entity ‘.’ domain_concept ‘.’ version_id
qualified_rm_entity: rm_originator ‘-’ rm_name ‘-’ rm_entity_name
domain_concept: concept_name { ‘-’ specialisation }*
version_id: ‘v’ NUMBER
rm_originator: NAME
The name of the authority issuing the underlying reference model to which this archetype applies e.g. openEHR,
HL7, CEN etc.
rm_name: NAME
The name of the model as labelled by the model_originator e.g. ehr, demographics, CDA etc.
rm_entity_name: NAME
The name of the class in the model (model_name) to which this archetype applies.
domain_concept: NAME
A unique string that describes the concept expressed in the archetype e.g. weight
specialisation: NAME
A string which describes this specialisation e.g. ‘birth’ as a specialisation of ‘weight’ to describe birth-weight
NUMBER: [0-9]*
NAME: [a-z][a-z0-9()/%$#&]* The field meanings are as follows:
rm_originator: id of organisation originating the reference model on which this archetype is
based;
rm_name: id of the reference model on which the archetype is based;
Editors:T Beale Page 9 of 17 Date of Issue: 16 Mar 2007
© 2003-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
Archetype Identification Archetype Semantics Rev 0.5
rm_entity: ontological level in the reference model;
domain_concept: the domain concept name, including any specialisations;
version_id: numeric version identifier.
Examples of archetype identifiers include:
openEHR-EHR-SECTION.physical_examination.v2
openEHR-EHR-SECTION.physical_examination-prenatal.v1
A basic rule for the multi-axial archetype identifier is that it changes as soon as anything is done to the archetype that makes data created using the previous form invalid with respect to the new form. For this reason, version is included in the identifier. The rules for change management are described below.
ISO Oids can be used to unambiguously identify archetypes within storage systems, online repositories etc., regardless of where the archetype sits in the concept space. In order that archetypes can be authored at any place and time without access to OIDs, the OID is optional at all times until publication. The OID can have been issued at any point in the publication lifecycle, but must be unique in the authority’s database. Local specialisations do not require OIDs.
Date of Issue: 16 Mar 2007 Page 10 of 17 Editors:T Beale
© 2003-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
Archetype Semantics Conformance Rev 0.5
Data are deemed to directly conform to an archetype if:
This kind of conformance occurs with data that were created directly from the archetype in question. Data may also have been created from a more specialised child of the archetype in question. In this case, the data are deemed to conform if for all items found on paths containing codes from the parent archetype (e.g. at0001), or any derived code (e.g. at0001.3):
There may be codes in the data not derived from a parent archetype, such as at0.0.1. These are found on nodes introduced new in a child archetype.
Editors:T Beale Page 11 of 17 Date of Issue: 16 Mar 2007
© 2003-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
Path Relationships Archetype Semantics Rev 0.5
To Be Continued:
Date of Issue: 16 Mar 2007 Page 12 of 17 Editors:T Beale
© 2003-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
Archetype Semantics Archetype Relationships Rev 0.5
To Be Continued:
Revision is the smallest kind of change that can be done to an archetype, and the only one not causing a change in identifier. The new revision is indicated in the revision_history section of an archetype. A new revision can safely replace the previous revision in an Archetype Service. Revisions are made in order to:
Semantic Integrity Constraint
• Backward compatibility: data created by precursor of revised archetype are compatible with revised version.
Change Rules
Allowed changes:
- any change to description section;
- any change to translations of whole archetype, not affecting semantics, i.e.
meanings of terms;
- changes to term bindings;
- changes to constraint bindings where the new term subset is a superset of the
previous one (i.e. a broader subset);
- changes to cardinality and optionality such that they are broader than the previous
values.
Excluded changes:
- changes to indentifier, ADL version, specialisation status;
- original_language cannot be changed;
- removal of archetype codes, since this would render data created with the previous
revision invalid in some parts;
- removal of any part of the definition section.
A specialisation of an archetype is similar in concept to a descendant class in an object-oriented model. Specialised archetypes can redefine nodes and add node in a way that respects the conformance relationship between archetypes; essentially this means that redefine nodes must be narrower or
Editors:T Beale Page 13 of 17 Date of Issue: 16 Mar 2007
© 2003-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
Archetype Relationships Archetype Semantics Rev 0.5
the same as the corresponding nodes in the parent archetype in terms of occurrences, reference model type and other constraints.
The node term code of a redefined node is defined as a ‘dot’ specialisation of the parent, e.g. ‘at0013.1’ is a valid code for the redefined version of the ‘at0013’ node in a top-level archetype. New nodes are given ‘dot’ node identifiers specific to the specialisation level; for example ‘at0.1’ is a code introduced new in a second level specialisation of an archetype.
Specialised archetypes are created when there is a need to customise an existing general purpose archetype, e.g. a ‘laboratory result’ archetype (containing generic ‘panel items’) into a particular subtype, such as ‘cholesterol result’ (containing named ‘LDL’, ‘HDL’, ‘Total’ etc items which are specialisations of the ‘panel item’ nodes in the parent). Sometimes the customisation is just the addition of new nodes.
Semantic Integrity Constraint
• Specialised archetype must create data that conform to the parent archetype, in the sense described above.
Change Rules
Required changes:
- the identifier of the new archetype must be redefined to a derived form of the
identifier of the parent, by creating a specialised concept section of the indentifer;
Allowed changes:
- any change covered by the ‘revision’ relationship;
- existing object nodes can be redefined as follows:
- new object nodes can be added, as long as the type conforms to the type and defined by the archetype for the attribute, and as long as the occurrences of the new node conforms with the cardinality of the attribute, taking into account the occurrences of sibling attributes defined in the parent. New nodes are given non-derivative specialised at-codes, e.g. at0.0.1.
Excluded changes: -exclusions specified in revision relationship;
A new version of an archetype is created when the existing version of an archetype is incompatible with the current data collection requirement. Given that well-designed archetypes contain mostly optional parts, this occurs rarely. The usual reason is that a mandatory item in the existing archetype
Date of Issue: 16 Mar 2007 Page 14 of 17 Editors:T Beale
© 2003-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
Archetype Semantics Archetype Relationships Rev 0.5
is now regarded as inappropriate; a value range or coded term set may also be incorrect from the point of view of current requirements. Almost all other required changes can be achieved by a new revision or specialisation.
A new version is created when the archetype required models the same content as the existing archetype, and is intended to replace it in time. If this is not the case, a new (unrelated) archetype is created. When a new version is created, the same archetype identifier is used, with the version number in the final segment incremented, thus generating a new archetype identifier, as in the following example:
openEHR-EHR-EVALUATION.problem.v2In general, nothing can be formally said about the semantic relationship between different versions of an archetype. However, it is strongly recommended in all archetype environments that:
To Be Continued:
Editors:T Beale Page 15 of 17 Date of Issue: 16 Mar 2007
© 2003-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
Archetype Relationships Archetype Semantics Rev 0.5
Date of Issue: 16 Mar 2007 Page 16 of 17 Editors:T Beale
© 2003-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
Rev 0.5
END OF DOCUMENT
Editors:T Beale Page 17 of 17 Date of Issue: 16 Mar 2007
© 2003-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org