Index: adl/trunk/pdf2html/am/archetype_system/archetype_system.htm =================================================================== --- adl/trunk/pdf2html/am/archetype_system/archetype_system.htm (revision 76) +++ adl/trunk/pdf2html/am/archetype_system/archetype_system.htm (revision 76) @@ -0,0 +1,2620 @@ + + + + +
+ + + + + + + + + ++ | +Editors: {T Beale, S Heard}a | +||
---|---|---|---|
+ +Revision: 0.5 + | ++ | + +Pages: 19 + | ++ +Date of issue: 12 Mar 2007 + | +
+a. Ocean Informatics
++Keywords: EHR, health records, repository, archetype
++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 +
++ +The openEHR Archetype System +
++Rev +0.5 +
++© Copyright openEHR Foundation 2001 - 2007 +All Rights Reserved +
++Date of Issue: + 12 Mar 2007 + +Page 2 of 19 + +Editors:{T Beale, S Heard} +
++ +© 2003-2007 The openEHR Foundation. + + +email: info@openEHR.org web: http://www.openEHR.org + +
++ +The openEHR Archetype System +
++Rev +0.5 +
++Amendment Record
++Issue | ++Details | ++Who | ++Completed | +
---|---|---|---|
+ | +R E L E A S E 1.0.1 | ++ | + |
+0.5 | ++Restructured and rewritten | ++T Beale | ++12 Mar 2007 | +
+ | +R E L E A S E 1.0 | ++ | + |
+ | +R E L E A S E 0.95 | ++ | + |
+ | +R E L E A S E 0.9 | ++ | + |
+0.3.1 | ++Updated diagram; added notes on dissemination network. | ++S Heard | ++20 Dec 2003 | +
+0.3 | ++Initial Writing | ++T Beale | ++29 Nov 2003 | +
+ +Editors:{T Beale, S Heard} + +Page 3 of 19 +Date of Issue: +12 Mar 2007 +
++ +© 2003-2007 The openEHR Foundation. + + +email: info@openEHR.org web: http://www.openEHR.org + +
++ +The openEHR Archetype System +
++Rev +0.5 +
++Date of Issue: + 12 Mar 2007 + +Page 4 of 19 + +Editors:{T Beale, S Heard} +
++ +© 2003-2007 The openEHR Foundation. + + +email: info@openEHR.org web: http://www.openEHR.org + +
++ +The openEHR Archetype System +
++Rev +0.5 +
++ +1 Introduction.............................................................................. 7 + +
+ + + ++ +2 Overview ................................................................................... 8 + +
++ +3 The Archetype Authoring Environment................................ 9 + +
+ + + + + ++ +3.6 Terminology Access and Use...............................................................10 + +
+ + + ++ +4 The Dissemination Network.................................................. 12 + +
+ + ++ +5 Archetype Semantics ............................................................. 13 + +
+ + ++ +6 Change Management............................................................. 14 + +
+ + + + + ++ +G References............................................................................... 17 + +
++ +Editors:{T Beale, S Heard} + +Page 5 of 19 +Date of Issue: +12 Mar 2007 +
++ +© 2003-2007 The openEHR Foundation. + + +email: info@openEHR.org web: http://www.openEHR.org + +
++ +The openEHR Archetype System +
++Rev +0.5 +
++Date of Issue: + 12 Mar 2007 + +Page 6 of 19 + +Editors:{T Beale, S Heard} +
++ +© 2003-2007 The openEHR Foundation. + + +email: info@openEHR.org web: http://www.openEHR.org + +
++ +The openEHR Archetype System +Introduction Rev +0.5 +
++This document provides a description of the openEHR Archetype System, an archetype authoring, quality assurance, certification and publishing infrastructure for archetype-enabled information systems. The Archetype System provides a technical underpinning for a governance infrastructure for archetypes and templates. Service interfaces based on the Archetype System archictecture are described informally here, and specified in detail in other openEHR documents.
++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_system.pdf. New versions are +announced on +openehr-announce@openehr.org +.
++ +Editors:{T Beale, S Heard} + +Page 7 of 19 +Date of Issue: +12 Mar 2007 +
++ +© 2003-2007 The openEHR Foundation. + + +email: info@openEHR.org web: http://www.openEHR.org + +
++Overview +The openEHR Archetype System +Rev +0.5 +
++The ‘Archetype System’ is a framework for development and use of archetypes, and consists of two parts. The first, the Archetype Authoring Network, includes an online repository, collaborative authoring process, querying and research tools, quality assurance, testing and approval processes, ultimately generating archetypes certified for production use. The second consists of dissemination mechanisms for archetypes to be made available to production systems. Two service models are implied. The archetype repository corresponds to one interface, providing the semantics of querying, browsing requests, life-cycle management etc, while the dissemination of archetypes corresponds to a smaller ‘archetype service’ interface that makes certified archetypes available to production systems.
++Archetypes can be authored locally as well as centrally, so for any particular archetype consumer, there may be at least two logical repositories. Each logical repository can be linked to a parent, creating a single logical archetype space from the point of view of any particular group of authors. Logical repositories may be engineered as literally separate repository instances, or more likely (given the required sophistication of the functionality), as separate ‘compartments’ in a centralised repository at a national or regional level.
++Currently it appears that templates will mostly be authored locally, with some templates that correspond to re-usable message structures, reports (e.g. discharge referrals) being designed for national or regional use. Reusable templates will therefore need to be accommodated in the archetype repository framework, although templates for local use only would be managed locally.
++All approved archetypes and templates are made available through instances of the archetype service. +The Archetype System is illustrated in FIGURE 1. +
+ ++FIGURE 1 The Archetype System
++Date of Issue: + 12 Mar 2007 + +Page 8 of 19 + +Editors:{T Beale, S Heard} +
++ +© 2003-2007 The openEHR Foundation. + + +email: info@openEHR.org web: http://www.openEHR.org + +
++ +The openEHR Archetype System +The Archetype Authoring Environment Rev +0.5 +
++The archetype and template authoring activity is carried out using tools that interface with the Archetype Repository. Each archetype is elaborated according to a development process over which the archetype will progress from an initial draft to an approved archetype, certified for use. Once an archetype has reached this point, and can no longer be changed, it should be digitally signed. All further changes must be carried out in new revisions, new versions, specialisations, or new archetypes. These categories are explained below. During the development process, the Archetype Repository enables querying and browsing of the existing library of archetypes, as well as access to the classificational ontology, and external resources. The archetype authoring environment is illustrated in +FIG + +URE 2. +
++Business Process
+ ++Archetype Repository
++FIGURE 2 The Archetype Authoring Environment
++A basic function of the Archetype Repository is the versioning and audit-trailing of all committed resources. The versioning functions are the same as available with well-known systems such as Subversion and other commercial tools. Both optimistic and pessimistic locking should be available, with merging tools available for conflicts in the former case.
++One of the key parts of the archetype development activity is an initial and ongoing review of work already done in the same area, in terms of previous archetypes, and also related external resources. The Archetype Repository supports querying of archetypes based on identifiers, relationship to other archetypes, theme / clinical details, use, and other attributes. Browsing tools using this querying interface can build graphical or textual renditions of existing archetypes.
++ +Editors:{T Beale, S Heard} + +Page 9 of 19 +Date of Issue: +12 Mar 2007 +
++ +© 2003-2007 The openEHR Foundation. + + +email: info@openEHR.org web: http://www.openEHR.org + +
++The Archetype Authoring Environment +The openEHR Archetype System +Rev +0.5 +
++The development of an archetype will follow a trajectory similar to documents or other artifacts in a technical authoring space. The archetype proceeds through a defined set of lifecycle states, usually defined as a state machine. At certain points in the lifecycle, group reviews and other similar activities take place. Managing this requires a way of registering users as part of an authoring group, as well as a way of defining the workflows for review, approval and so on. The Archetype Repository provides support for workflow definition and execution.
++As with software development, the first step to creating an archetype should be to determine whether any archetypes already exist corresponding to the requirements; a basic service is therefore to find archetypes. Two types of indexing are required, ‘content-based’ and ‘semantic’. Content-based indexing means that archetypes are indexed by concrete properties of individual archetypes, such as:
++This kind of indexing can easily be achieved by standard database indexing and content-based retrieval (if indexing is required on the contained text). Querying for archetypes based on combinations of properties can then be supported, such as “find all archetypes created by UK organisations within the last six months, which have ‘pain’ in the title”.
++In contrast, semantic indexing allows for much more sophisticated queries, but relies on making inferences on archetypes in the presence of other archetypes, terminologies and ontologies. For example, a user might wish to find all archetypes describing (clinical) examinations or investigations relevant to the heart. Some lab result types are clinically relevant, but their archetypes are unlikely to contain the words “heart” or “cardiac” etc., so content-based indexing won’t retrieve them. If however an underlying ontology has links that indicate useful laboratory tests relevant to the heart, the archetypes will be retrieved.
++The underlying resources used to achieve this are likely include a ontology defined specifically for indexing archetypes, and one or more published terminologies such as SNOMED-CT and LOINC.
++Once it is determined whether a new archetype needs to be authored or an existing one adapted (usually specailised), the next step is to make the changes. Ontological and terminological resources within the environment can be used to enable the archetype author to understand the meaning of the archetype under construction, in a number of ways.
++Finding internal archetype terms: internal terms defining node meanings may be derived from terms defined in published terminologies. For example, the author might wish to define an archetype node whose local code means “myocardial infaction”, a term which will easily be found in a number of terminologies and ontologies. If searching the available terminologies reveals the exact definition required by the author, she can create the local term, copy the definition, and include a ‘provenance’ meta-data item in the term definition indicating the source.
++Date of Issue: + 12 Mar 2007 + +Page 10 of 19 + +Editors:{T Beale, S Heard} +
++ +© 2003-2007 The openEHR Foundation. + + +email: info@openEHR.org web: http://www.openEHR.org + +
++ +The openEHR Archetype System +The Archetype Authoring Environment Rev +0.5 +
++Verifying value sets. In the ‘value’ position of an archetype leaf node, constraints are often defined which evaluate to a set of terms, raning from the simple such as “blood groups” to the more complex, such as “any disease which is-a auto-immune disease with-site liver”. If these constraints can be tested at authoring time against an appropriate terminology or ontology, the archetype designer will be able to ensure that the intended meaning is achieved.
++In the authoring of archetypes, recourse to external resources, such as published guidelines, published data-sets, documents from professional bodies and so on is needed. The Archetype Repository provides a way to capture links, resource content, and index and cross-reference this with archetypes created based on the resources. This facilitates maintenance and review by other professionals.
++When an archetype is approved and registered for use, it should be digitally signed using a combination of a hash (e.g. using SHA-1) and the private key of the issuing organisation (e.g. using RSA). The first of these measures ensures that the integrity of the archetype can be trusted, while the second ensures that its origin can be trusted. The decrypted signature should regenerate the hash, which can also be generated from the archetype source in order to check the archetype’s integrity. Signatures should be stored within the Archetype Repository as well as in Archetype Service instances.
++The service interface to an Archetype Repository includes semantics corresponding to each of the functional areas described above. It is described in a separate specification.
++ +Editors:{T Beale, S Heard} + +Page 11 of 19 +Date of Issue: +12 Mar 2007 +
++ +© 2003-2007 The openEHR Foundation. + + +email: info@openEHR.org web: http://www.openEHR.org + +
++The Dissemination Network +The openEHR Archetype System +Rev +0.5 +
++Archetypes and templates are disseminated from one or more Archetype Repositories via an Archetype Service network. The topology and dynamics of the network may be similar to the DNS (fully distributed hierarchy), or of a client/server form, where each Archetype Service node communicates only with an Archetype Repository. By either means, archetypes (and centrally defined templates) are made available to client systems such as EHR environments. In the target environment, it is likely although not essential that shareable archetypes (i.e. archetypes in openEHR/CEN standard ADL or X-ADL) will be converted locally into a runtime format, typically dependent on the kind of persistence technology in use. One view of these elements is shown in +FIGURE 3 +.
+ ++FIGURE 3 The Archetype Dissemination Network
++The service interface of the Archetype Service corresponds to the requirements of archetype consumer systems, rather than human authors. Accordingly it is significantly simpler than that of the Archetype Repository. Most functions are based on archetype identifiers rather than keyword or concept-based searching. The interface is specified in a separete document.
++Date of Issue: + 12 Mar 2007 + +Page 12 of 19 + +Editors:{T Beale, S Heard} +
++ +© 2003-2007 The openEHR Foundation. + + +email: info@openEHR.org web: http://www.openEHR.org + +
++ +The openEHR Archetype System +Archetype Semantics Rev +0.5 +
++Much of the functionality of the Archetype System is informed by the semantics of archetypes, particularly the identification system and inter-archetype relationships. The relevant semantics are briefly described here in relation to the Archetype System, and are described in detail in the openEHR Archetype Semantics specification.
++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. A typical example of an archetype identifier is:
++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.
++ISO Oids can also be used to identify archetypes within storage systems, online repositories etc., regardless of where the archetype sits in the concept space. Currently Oids are not in use in the openEHR archetype environment.
++Archetypes can relate to each other in the following ways:
++revision: the revised archetype contains changes that do not invalidate the data created by the previous archetype in any way;
++specialisation: similar to specialisation in object-oriented models, specialised archetypes can change existing parts of an archetype definition in a conformant way, or introduce new nodes;
++version: the new version of an archetype will usually contain a small number of changes incompatible with the previous version; a data conversion algorithm should be supplied;
++composition: archetypes use ‘slots’ to define the set of other archetypes that may be used at a node, rather than defining the same semantics inline.
++All of these relationships should be assertable and viewable within the Archetype Repository.
++ +Editors:{T Beale, S Heard} + +Page 13 of 19 +Date of Issue: +12 Mar 2007 +
++ +© 2003-2007 The openEHR Foundation. + + +email: info@openEHR.org web: http://www.openEHR.org + +
++Change Management +The openEHR Archetype System +Rev +0.5 +
++Archetypes are like any other models in that they reflect changing realities and understandings of reality. For both reasons, changes need to be made to existing archetypes as time goes on. However, archetypes are also used to create data, and to remain technically reliable, the relationship between archetypes and the data must always be known. If an archetype is ‘changed’ in some way, the relationship of the new variant to the previously created data must be known, in order for the data to be properly queryable and modifiable.
++Four types of ‘change’ are identified below. Only one of them, ‘revision’ is a change in the literal sense of the word. The other three all create new archetypes that are formally related to existing archetypes. In the following sections, each type of change is described in terms of a ‘semantic integrity constraint’ that must be preserved, and the entailed logical consequence. The detailed semantics of each type of archetype relationship are found in the Archetype Semantics document.
++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:
++The validity rule for revisions is:
++• Backward compatibility: data created by precursor of revised archetype is compatible with revised version.
++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 the same as the corresponding nodes in the parent archetype in terms of occurrences, reference model type and other constraints.
++The identifier of a specialised archetype is a clone of the parent identifier, with an extra item appended to the concept section of the identifier, using a ‘-’ separator. The following exemplify a typical parent and specialised child archetype identifiers:
++openEHR-EHR-EVALUATION.problem.v1 +openEHR-EHR-EVALUATION.problem-diagnosis.v1 +openEHR-EHR-EVALUATION.problem-diagnosis-histological.v1 +
++Date of Issue: + 12 Mar 2007 + +Page 14 of 19 + +Editors:{T Beale, S Heard} +
++ +© 2003-2007 The openEHR Foundation. + + +email: info@openEHR.org web: http://www.openEHR.org + +
++ +The openEHR Archetype System +Change Management Rev +0.5 +
++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.
++The validity rule for specialised archetypes is:
++• Specialised archetype creates data that conform to the parent archetype in the sense of data/archetype conformance described in the Archetype Semantics document.
++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 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 should only be 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.v1
++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:
++A new archetype is one whose identifier is different in the reference model or concept sections to that of other archetypes. New archetypes should be created compatibly with existing archetypes. ‘Compatibility’ here means that the scope of the archetype should not straddle concepts found in existing archetypes, but should either re-use them, or be complementary.
++ +Editors:{T Beale, S Heard} + +Page 15 of 19 +Date of Issue: +12 Mar 2007 +
++ +© 2003-2007 The openEHR Foundation. + + +email: info@openEHR.org web: http://www.openEHR.org + +
++Change Management +The openEHR Archetype System +Rev +0.5 +
++Date of Issue: + 12 Mar 2007 + +Page 16 of 19 + +Editors:{T Beale, S Heard} +
++ +© 2003-2007 The openEHR Foundation. + + +email: info@openEHR.org web: http://www.openEHR.org + +
++ +The openEHR Archetype System +References Rev +0.5 +
++Publications
++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. A Shared Language for Archetypes and Templates - Part I. 2003. Available at +http://www.deepthought.com.au/health/arche + +types/archetype_language_2v0.6.2.doc. +
++4 Beale T, Heard S. A Shared Language for Archetypes and Templates - Part II. 2003. Available at +http://www.deepthought.com.au/health/arche + +types/archetype_language.doc. +
++5 Dolin R, Elkin P, Mead C et al. HL7 Templates Proposal. 2002. Available at +http://www.hl7.org +.
++6 Gruber T R. Toward Principles for the Design of Ontologies Used for Knowledge Sharing. in Formal Ontology in Conceptual Analysis and Knowledge Representation. Eds Guarino N, Poli R. Kluwer Academic Publishers. 1993 (Aug revision).
++7 OWL - Web Ontology Language. See +http://www.w3.org/TR/2003/CR-owl-ref-20030818/ +. 8 openEHR. Knowledge-enabled EHR and related specifications. See +http://www.openEHR.org +. 9 openEHR. EHR reference model. See +http://www.openEHR.org +.
++ +Editors:{T Beale, S Heard} + +Page 17 of 19 +Date of Issue: +12 Mar 2007 +
++ +© 2003-2007 The openEHR Foundation. + + +email: info@openEHR.org web: http://www.openEHR.org + +
++References +The openEHR Archetype System +Rev +0.5 +
++Date of Issue: + 12 Mar 2007 + +Page 18 of 19 + +Editors:{T Beale, S Heard} +
++ +© 2003-2007 The openEHR Foundation. + + +email: info@openEHR.org web: http://www.openEHR.org + +
++ +The openEHR Archetype System +
++Rev +0.5 +
++END OF DOCUMENT +
++ +Editors:{T Beale, S Heard} + +Page 19 of 19 +Date of Issue: + 12 Mar 2007 +
++ +© 2003-2007 The openEHR Foundation. + + +email: info@openEHR.org web: http://www.openEHR.org + +
++The openEHR Archetype Model
++ | +Editors: {T Beale, S Heard}a | +||
---|---|---|---|
+ +Revision: 0.5 + | ++ | + +Pages: 19 + | ++ +Date of issue: 13 Mar 2007 + | +
+a. Ocean Informatics
++Keywords: EHR, ADL, health records, archetypes, templates
++EHR Extract | ++ | |||||
---|---|---|---|---|---|---|
+EHR | ++Demographic | ++Integration | ++Template OM | +|||
+Composition | ++openEHR Archetype Profile | +|||||
+Security | ++Common | ++Archetype OM | ++ | +ADL | +||
+ | ||||||
+Data Structures | +||||||
+Data Types | +||||||
+Support | +
+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: + 13 Mar 2007 + +Page 2 of 19 + +Editors:{T Beale, S Heard} +
++ +© 2005-2007 The openEHR Foundation + + +email: info@openEHR.org web: http://www.openEHR.org + +
++ +The Template Object Model (TOM) +
++Rev +0.5 +
++Amendment Record
++Issue | ++Details | ++Raiser | ++Completed | +
---|---|---|---|
+ | +R E L E A S E 1.0.1 | ++ | + |
+0.5 | ++Minor content modifications. | ++T Beale | ++13 Mar 2007 | +
+ | +R E L E A S E 1.0 | ++ | + |
+0.5rc1 | ++CR-000178. Add Template Object Model to AM. Initial Writing | ++T Beale | ++10 Nov 2005 | +
+ | +R E L E A S E 0.96 | ++ | + |
+ +Editors:{T Beale, S Heard} + +Page 3 of 19 +Date of Issue: +13 Mar 2007 +
++ +© 2005-2007 The openEHR Foundation + + +email: info@openEHR.org web: http://www.openEHR.org + +
+ ++Rev +0.5 +
++Microsoft is a trademark of the Microsoft Corporation
++Date of Issue: + 13 Mar 2007 + +Page 4 of 19 + +Editors:{T Beale, S Heard} +
++ +© 2005-2007 The openEHR Foundation + + +email: info@openEHR.org web: http://www.openEHR.org + +
++ +The Template Object Model (TOM) +
++Rev +0.5 +
++ +Editors:{T Beale, S Heard} + +Page 5 of 19 +Date of Issue: +13 Mar 2007 +
++ +© 2005-2007 The openEHR Foundation + + +email: info@openEHR.org web: http://www.openEHR.org + +
+ ++Rev +0.5 +
++Date of Issue: + 13 Mar 2007 + +Page 6 of 19 + +Editors:{T Beale, S Heard} +
++ +© 2005-2007 The openEHR Foundation + + +email: info@openEHR.org web: http://www.openEHR.org + +
++ +The Template Object Model (TOM) +Introduction Rev +0.5 +
++This document describes an object model for openEHR templates, based only upon the generally accepted semantics of object models (typified by the OMG UML meta-model). The model presented here can be used as a basis for building software that processes archetypes and templates, independent of their persistent representation. As a specification, it can be treated as an API for templates.
++It is recommended that the openEHR ADL and AOM documents be read in conjunction with this document, since they contain a detailed explanation of the semantics of archetypes.
++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.
++The latest version of this document can be found in PDF format at +http://svn.openehr.org/spec + +ification/BRANCHES/Release-1.0.1-candidate/publishing/architecture/am/tom.pdf. +New versions are announced on + +openehr-announce@openehr.org +. +
++Blue text indicates sections under active development.
++THIS DOCUMENT IS UNDER ACTIVE DEVELOPMENT AND IS NOT YET SUBJECT TO ARB CONTROL.
++The openEHR template concept is related to openEHR archetypes. Where archetypes define widely re-usable components of information, templates are locally defined and encapsulate local usage of archetypes, and relevant preferences. In informal terms, templates include the following semantics:
++archetype ‘chaining’: choice of archetypes to make up a larger structure, specified via indicating identifiers of archetypes to fill slots in higher-level archetypes;
++ +Editors:{T Beale, S Heard} + +Page 7 of 19 +Date of Issue: +13 Mar 2007 +
++ +© 2005-2007 The openEHR Foundation + + +email: info@openEHR.org web: http://www.openEHR.org + +
++Introduction +The Template Object Model (TOM) +Rev +0.5 +
++local optionality: narrowing of some or all 0..1 constraints to either 1..1 (mandatory) or 0..0 (removal) according to local needs;
++tightened constraints: tightening of other constraints, including cardinality, value ranges, terminology value sets and so on;
++default values: choice of default values for use in templated structure at runtime.
++At runtime, templates are used with archetypes to create data and to control its modification. Template design is usually strongly linked to the design of corresponding screen forms.
++Various tools exist for creating and processing templates. The openEHR tools are available in source and binary form from the website ( +http://www.openEHR.org +).
++Date of Issue: + 13 Mar 2007 + +Page 8 of 19 + +Editors:{T Beale, S Heard} +
++ +© 2005-2007 The openEHR Foundation + + +email: info@openEHR.org web: http://www.openEHR.org + +
++ +The Template Object Model (TOM) +The Template Object Model Rev +0.5 +
++An underpinning principle of openEHR is the use of archetypes and templates, which are formal models of domain concepts controlling data structure and content of data. The elements of this architecture are twofold.
++This document describes the Template Object Model, which is used with the Archetype Object Model as a basis for archetype-processing software.
++The openEHR template + package is illustrated in FIGURE 1. +
++am openehr_profilearchetype
++template +template_spec +
++operational_template
+ ++FIGURE 1 openehr.am.template Package in context
++Two forms of templates are used in openEHR. The form created by template design tools is known as the ‘specification’ form, since it specifies the contents of a template using references to archetypes and other additions. The specification form is defined in the am.template.template_spec package. The second form is the ‘operational’ form, created by processing a template specification so as to partially pre-populate terminology value sets, expand out references to other templates and archetypes, and create runtime structures that representing other aspects of the specification. The operational form is specified in the operational_template package.
++ +Editors:{T Beale, S Heard} + +Page 9 of 19 +Date of Issue: +13 Mar 2007 +
++ +© 2005-2007 The openEHR Foundation + + +email: info@openEHR.org web: http://www.openEHR.org + +
++The Template Object Model +The Template Object Model (TOM) +Rev +0.5 +
++Date of Issue: + 13 Mar 2007 + +Page 10 of 19 + +Editors:{T Beale, S Heard} +
++ +© 2005-2007 The openEHR Foundation + + +email: info@openEHR.org web: http://www.openEHR.org + +
++ +The Template Object Model (TOM) +The Template_spec Package Rev +0.5 +
++To Be Continued:
++ +Editors:{T Beale, S Heard} + +Page 11 of 19 +Date of Issue: +13 Mar 2007 +
++ +© 2005-2007 The openEHR Foundation + + +email: info@openEHR.org web: http://www.openEHR.org + +
++AUTHORED_RESOURCE
+ ++FIGURE 2 The openehr.am.template.template_spec Package
++ +The Template Object Model (TOM) +The Template_spec Package Rev +0.5 +
++(TEMPLATE_SPEC) <
++definition = < archetype_id = <openEHR-EHR-COMPOSITION.report.v1>slot_specs = <
++[“/content”] = < +path = </content> +fillers = < +
++[“findings”] = <archetype_id = <openEHR-EHR-SECTION.findings.v1>slot_specs = <
++[“items”] = <path = <items>fillers = <
++[“histology”] = <cardinality = <min = <1> max = <1>>archetype_id = <openEHR-EHR
++OBSERVATION.histology.v1> > > >
++> +> +[“summary”] = < +
++archetype_id = <openEHR-EHR-SECTION.summary.v1>slot_specs = <
++[“items”] = <path = <items>fillers = <
++[“clinical_synopsis”] = <archetype_id = <openEHR-EHR
++EVALUATION.clinical_synopsis.v1> > [“problem-diagnosis-histological”] = <
++archetype_id = <openEHR-EHREVALUATION.problem-diagnosishistological.v1>
++path_specs = <path = </data[at0001]/items[at0031]>
++[1] = <cardinality = <max = <0>> > > > > > > > > > >
++> +> +
++ +Editors:{T Beale, S Heard} + +Page 13 of 19 +Date of Issue: +13 Mar 2007 +
++ +© 2005-2007 The openEHR Foundation + + +email: info@openEHR.org web: http://www.openEHR.org + +
++The Template_spec Package +The Template Object Model (TOM) +Rev +0.5 +
++3.2.1 TEMPLATE_SPEC Class
++CLASS | ++TEMPLATE_SPEC | +|
---|---|---|
+Purpose | ++ | |
+Use | ++ | |
+Abstract | ++Signature | ++Meaning | +
+ | +template_id: ARCHETYPE_ID | ++ |
+ | + | + |
+Invariant | ++xxx | +
+Date of Issue: + 13 Mar 2007 + +Page 14 of 19 + +Editors:{T Beale, S Heard} +
++ +© 2005-2007 The openEHR Foundation + + +email: info@openEHR.org web: http://www.openEHR.org + +
++ +The Template Object Model (TOM) +The Operational_template Package Rev +0.5 +
++To Be Continued:
++FIGURE 3 The openehr.am.template.operational_template Package | +|
---|---|
+4.2 | ++Class Definitions | +
+4.2.1 | ++TEMPLATE Class | +
+CLASS | ++TEMPLATE | +|
---|---|---|
+Purpose | ++ | |
+Use | ++ | |
+Abstract | ++Signature | ++Meaning | +
+ | +template_id: TEMPLATE_ID | ++ |
+ | + | + |
+Invariant | ++xxx | +
+ +Editors:{T Beale, S Heard} + +Page 15 of 19 +Date of Issue: +13 Mar 2007 +
++ +© 2005-2007 The openEHR Foundation + + +email: info@openEHR.org web: http://www.openEHR.org + +
++The Operational_template Package +The Template Object Model (TOM) +Rev +0.5 +
++Date of Issue: + 13 Mar 2007 + +Page 16 of 19 + +Editors:{T Beale, S Heard} +
++ +© 2005-2007 The openEHR Foundation + + +email: info@openEHR.org web: http://www.openEHR.org + +
++ +The Template Object Model (TOM) +
++Rev +0.5 +
++Publications
++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 openEHR. EHR Reference Model. See +http://www.openehr.org/repositories/spec + +dev/latest/publishing/architecture/top.html. +
++ +Editors:{T Beale, S Heard} + +Page 17 of 19 +Date of Issue: +13 Mar 2007 +
++ +© 2005-2007 The openEHR Foundation + + +email: info@openEHR.org web: http://www.openEHR.org + +
+ ++Rev +0.5 +
++Date of Issue: + 13 Mar 2007 + +Page 18 of 19 + +Editors:{T Beale, S Heard} +
++ +© 2005-2007 The openEHR Foundation + + +email: info@openEHR.org web: http://www.openEHR.org + +
++ +The Template Object Model (TOM) +
++Rev +0.5 +
++END OF DOCUMENT +
++ +Editors:{T Beale, S Heard} + +Page 19 of 19 +Date of Issue: + 13 Mar 2007 +
++ +© 2005-2007 The openEHR Foundation + + +email: info@openEHR.org web: http://www.openEHR.org + +
+