Archetype Definitions and Principles
Rev 1.0
Editors: {T Beale, S Heard}a | |||
---|---|---|---|
Revision: 1.0 | Pages: 15 | Date of issue: 14 Mar 2007 |
a. Ocean Informatics
Keywords: EHR, health records, archetypes, principles
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
Archetype Definitions and Principles
Rev 1.0
© Copyright openEHR Foundation 2001 - 2007 All Rights Reserved
Date of Issue: 14 Mar 2007 Page 2 of 15 Editors:{T Beale, S Heard}
© 2003-2007 The openEHR Foundation email: info@openEHR.org web: http://www.openEHR.org
Archetype Definitions and Principles
Rev 1.0
Amendment Record
Issue | Details | Who | Completed |
---|---|---|---|
R E L E A S E 1.0.1 | |||
1.0 | CR-000203: Release 1.0 explanatory text improvements. | T Beale, S Heard | 14 Mar 2007 |
R E L E A S E 1.0 | |||
R E L E A S E 0.95 | |||
0.6 | CR-000127. Restructure archetype specifications. Minor text changes. | T Beale, S Heard | 14 Mar 2005 |
R E L E A S E 0.9 | |||
0.5 | Initial Writing. Based on Material taken from “A Shared Archetype and Template Language, Part I: A Position Paper for HL7, CEN TC 251, openEHR and other organisations”. | T Beale, S Heard | 28 Dec 2003 |
Editors:{T Beale, S Heard} Page 3 of 15 Date of Issue: 14 Mar 2007
© 2003-2007 The openEHR Foundation email: info@openEHR.org web: http://www.openEHR.org
Archetype Definitions and Principles
Rev 1.0
Date of Issue: 14 Mar 2007 Page 4 of 15 Editors:{T Beale, S Heard}
© 2003-2007 The openEHR Foundation email: info@openEHR.org web: http://www.openEHR.org
Archetype Definitions and Principles
Rev 1.0
1 Introduction.............................................................................. 7
2 Definitions................................................................................. 8 3 Purpose of Archetypes and Templates ................................... 9
4 Principles ................................................................................ 10
4.2 Archetype Design Principles ...............................................................10
4.3 Template Design Principles .................................................................13
Editors:{T Beale, S Heard} Page 5 of 15 Date of Issue: 14 Mar 2007
© 2003-2007 The openEHR Foundation email: info@openEHR.org web: http://www.openEHR.org
Archetype Definitions and Principles
Rev 1.0
Date of Issue: 14 Mar 2007 Page 6 of 15 Editors:{T Beale, S Heard}
© 2003-2007 The openEHR Foundation email: info@openEHR.org web: http://www.openEHR.org
Archetype Definitions and Principles Introduction Rev 1.0
This document describes the design principles of archetypes and templates. 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.
Prerequisite documents for reading this document include:
• The openEHR Architecture Overview Related documents include:
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/archetype_principles .pdf.
The latest version of this document can be found at http://svn.openehr.org/specifica tion/TRUNK/publishing/architecture/am/archetype_principles .pdf.
Editors:{T Beale, S Heard} Page 7 of 15 Date of Issue: 14 Mar 2007
© 2003-2007 The openEHR Foundation email: info@openEHR.org web: http://www.openEHR.org
Definitions Archetype Definitions and Principles Rev 1.0
The definitions of the terms "archetype", "template" and variants as used in this paper are as follows:
archetype: a computable expression of a domain content model in the form of structured constraint statements, based on a reference (information) model. openEHR archetypes are based on the openEHR reference model. Archetypes are all expressed in the same formalism. In general, they are defined for wide re-use, however, they can be specialized to include local particularities. They can accommodate any number of natural languages and terminologies.
template: a directly locally usable definition which composes archetypes into a larger structures often corresponding to a screen form, document, report or message. A templates may add further local constraints on the archetypes it mentions, including removing or mandating optional sections, and may define default values.
Date of Issue: 14 Mar 2007 Page 8 of 15 Editors:{T Beale, S Heard}
© 2003-2007 The openEHR Foundation email: info@openEHR.org web: http://www.openEHR.org
Archetype Definitions and Principles Purpose of Archetypes and Templates Rev 1.0
Archetypes are created for a number of purposes (described in detail in [1] and [3]), summarised here: Human Communication: to enable domain concepts to be modelled in a formal way by domain experts; Specialised Searching: also to compare data to specialised archetypes, or "predicates". Archetypes can be used directly for the computational purposes described below, but are normally encapsulated by templates for this purpose. The key benefits of archetypes include: Knowledge-enabled systems: the separation of information and knowledge concerns in software systems, allowing cheap, future-proof software to be built; Knowledge-level interoperability: the ability of systems to reliably communicate with each other at the level of knowledge concepts; Domain empowerment: the empowerment of domain specialists to define the informational concepts they work with, and have direct control over their information systems. Intelligent Querying: to be used at runtime to enable the efficient querying of data based on the structure of archetypes from which the data was created.
Templates constitute a form of constraint statement model, which is directly usable for:
Data Construction: to be used at runtime to constrain the creation of data in local contexts to conform to data capture requirements; Data Validation: to be used at runtime to validate data from other sources.
While archetypes are generally broad models, and have very open compositional possibilities, templates are used to narrow the choices of archetypes for local or specific purposes. They can be used to control the following things:
Editors:{T Beale, S Heard} Page 9 of 15 Date of Issue: 14 Mar 2007
© 2003-2007 The openEHR Foundation email: info@openEHR.org web: http://www.openEHR.org
Principles Archetype Definitions and Principles Rev 1.0
Examples of domain-level concepts include "blood pressure", "physical examination (headings)", "biochemistry results" and so on. Here, the term reference model refers to any information model which can have data instances in a computational system. The following figure illustrates the relation
ships of archetypes with data. | ||
---|---|---|
INFORMATION | KNOWLEDGE | |
Information Model | Archetype Description Language |
semantics of constraint
formal instances
formal instances
constrain at
runtime
FIGURE 1 Archetype Model Meta-architecture
In this figure, the following relationships hold:
These concepts can be stated in more formal terms as the following principles:
Principle 1: An archetype defines a whole, distinct, domain-level model of content.
Date of Issue: 14 Mar 2007 Page 10 of 15 Editors:{T Beale, S Heard}
© 2003-2007 The openEHR Foundation email: info@openEHR.org web: http://www.openEHR.org
Archetype Definitions and Principles Principles Rev 1.0
Archetypes should define coherent, whole informational concepts from the domain, in order to be useful. Archetypes enable self-standing groupings of information to be defined regardless of context. For example, there may be an archetype for "ECG result" since this is understood and used as a whole concept by clinicians, but not "ECG lead 2 result", which would only ever be understood as part of an "ECG result". The heart rate, as determined in an ECG, may be archetyped separately as this is a distinct concept that can be understood on its own. Similarly, we would not consider the heading "systolic" to be a meaningful archetype on its own, rather it would be part of a "blood pressure" or "intravascular pressure" archetype.
Principle 2: An archetype defines constraints on the structure of instances of a reference model.
An archetype can define the valid structuring of data instances to form a logical instance of domain content. For example, the hierarchical structure of “SOAP” headings used in problem-oriented recording is definable in an archetype in terms of a structure of Section instances, assuming Section is a type from the model. The implication of this principle is that reference models do not need to supply domain-specific structures, only generic building blocks suitable for creating the latter.
Principle 3: An archetype defines constraints on types and values of instances of a reference model.
Archetypes also express constraints on allowable constructions of reference model instances, e.g. on allowed types, ordering, cardinality, values and so on. The combination of structure and constraint expression means that numerous variations on a data instance may conform to a single archetype.
Principle 4: The granularity of an archetype corresponds to the granularity of a business concept in an information model.
Archetypes are defined at the same level of granularity as the ‘business’ entities in the reference model, i.e. the key types that in turn may have internal finer-grained structure. For example, since the openEHR reference model includes the business concepts Composition and Observation, archetypes of these same concepts can be created, e.g. a “cholesterol result” (a kind of Observation) and an “encounter note” (a kind of Composition).
Principle 5: Since each business concept in the reference model corresponds to a particular ontological level found in the domain, archetypes based on each business concept belong to the same ontological level.
Taking the openEHR reference model as an example, there are four ontological levels: the EHR, the Composition, the Section, and the Entry. Each of these defines a different category of artefact, for exmaple, the Entry (including subtypes Observation, Evaluation etc) defines the generic semantics of ‘clinical statements’. All archetypes based on Entry or its subtypes belong to this same ontological category, defining specific kinds of clinical statement.
Principle 6: A compositional relationship can exist between archetypes.
Archetypes can be composed to express valid possibilities for larger structures of data from different levels of the ontological hierarchy of the reference model. Such compositional connections are termed ‘slots’. For example, Section and Entry archetypes can be linked in a compositional way to define valid structures for the headings and data of a model of information captured in a "physical examination".
Editors:{T Beale, S Heard} Page 11 of 15 Date of Issue: 14 Mar 2007
© 2003-2007 The openEHR Foundation email: info@openEHR.org web: http://www.openEHR.org
Principles Archetype Definitions and Principles Rev 1.0
Principle 7: An archetype can be a specialisation of another archetype.
Archetypes can be defined at higher or lower levels of detail at a given ontological level. Thus, a "biochemistry result" archetype would define the general shape and constraints for all biochemistry results, while a "cholesterol result" archetype could be defined as a specialisation of this, in order to further constrain data to conform only to the shape of a cholesterol test.
Principle 8: Archetypes are internally hierarchical in structure; that is to say, the constraints in an archetype has an internal hierarchical compositional structure.
This is because object models give rise to data that is inherently hierarchical in structure.
Principle 9: Archetype nodes, including the root and all leaves, are identified by semantic identifiers which act as the basis for human-readable ‘meanings’, and for computational paths.
Archetype node identifiers are defined within the archetype using coded terms. The definition of any such code acts as a standardised ‘design-time meaning’ of the node, e.g. “5 minute Apgar result”.
Any node in an archetype can be referenced by concatenating attribute names and node identifiers from the archetype root to the node, to form an archetype path.
Principle 10: Archetype paths form the basis of reusable semantic queries on archetyped data.
Archetype paths can be used to construct queries that specify data items at a domain level, rather than being limited to the classes and attributes of the reference model as for a query in standard database theory. For example, paths from a “blood pressure measurement” archetype may identify the systolic blood pressure (baseline), systolic pressures for other time offsets, the patient position, and numerous other data items.
Principle 11: Data generated from an archetype will have a compositional structure, in which nodes must be uniquely named, in order to be able to refer to them.
Since an archetype acts as a kind of ‘template’, there can be repetitions of archetype structures in real data. Each node therefore needs a unique runtime name in order to be uniquely identified within the data. The archetype can be used to constrain this unique name.
Principle 12: Archetypes have no language primacy: they are completely translatable artefacts.
An archetype can be developed in any language, and have translations in other languages added a posteriori.
Principle 13: Archetypes are neutral with respect to terminologies.
Archetypes are able to be developed with or without reference to external terminologies. Multiple external terminologies can be bound to an archetype; the definition of terms in an archetype is not predicated on the existence or use of any particular terminology.
Principle 14: There is a means of evolving existing archetypes to accommodate changing requirements, without invalidating data created with earlier versions.
Since archetypes are used to create data, changes to archetypes must be regarded as creating a new archetype; i.e. the identifier of an archetype must incorporate its version. The only
Date of Issue: 14 Mar 2007 Page 12 of 15 Editors:{T Beale, S Heard}
© 2003-2007 The openEHR Foundation email: info@openEHR.org web: http://www.openEHR.org
Archetype Definitions and Principles Principles Rev 1.0
types of change to archetypes that can be made without changing the version are those which do not invalidate previously created data. Formally, such changes must not ‘narrow’ constraints expressed in the existing version.
While archetypes support the definition of re-usable domain content models, templates provide a means of defining localised use of archetypes, often corresponding to screen forms, reports, documents (such as discharge referrals) and so on.
Templates, like archetypes can be shared. Their use is to express the data collection requirements for specific clinical situations - many will be situation specific and some will express the requirements of individual users. From this we can deduce that just a few archetypes may lead to a plethora of templates.
Principle 1: Templates are used to define aggregates of archetypes suitable for particular local uses.
Archetypes define re-usable content models, and possible ways to connect them compositionally, according to the underlying reference model. Such connections, termed ‘slots’, are usually defined as openly as possible, i.e. they indicate all allowable compositional relationships from one archetype to others.
Principle 2: Templates cannot create new constraints with respect to the archetypes they reference; they can only further constrain in a compatible way.
While archetypes define the possibilites for compositional relationships with ‘slots’, templates make the choices of which archetypes will actually be used in particular slots, to form structures directly usable in a local context.
Similarly, templates can further constrain optionality and cardinality constraints in archetypes. Any optional (i.e. 0..1) attribute defined in an archetype can be constrained by a template to be removed (0..0) or to be mandatory (1..1), since both of these constraints are formal subsets of the 0..1 constraint. Similar compatible constraints can be made on container cardinalities defined in archetypes.
Principle 3: Template identifiers do not need to be recorded in the data for the data to be usable.
Since templates do not change the structure of archetypes other than deleting or mandating certain branches, the path structure of the archetypes remains intact. Hence, archetype paths can be used to interrogate the created data, without reference to the particular templates that originally referenced the archetypes.
In summary, the constraints expressible in templates includes:
Editors:{T Beale, S Heard} Page 13 of 15 Date of Issue: 14 Mar 2007
© 2003-2007 The openEHR Foundation email: info@openEHR.org web: http://www.openEHR.org
Principles Archetype Definitions and Principles Rev 1.0
Date of Issue: 14 Mar 2007 Page 14 of 15 Editors:{T Beale, S Heard}
© 2003-2007 The openEHR Foundation email: info@openEHR.org web: http://www.openEHR.org
Archetype Definitions and Principles
Rev 1.0
END OF DOCUMENT
Editors:{T Beale, S Heard} Page 15 of 15 Date of Issue: 14 Mar 2007
© 2003-2007 The openEHR Foundation email: info@openEHR.org web: http://www.openEHR.org