Distributed Development Model

A model of distributed development, publication and dissemination of knowledge artefacts such as archetypes and templates is becoming of crucial importance in openEHR and in e-health generally. Key concepts include identification of artefacts, definition of 'releases', and authentication of artefacts.

Identification System for Knowledge Artefacts

The purpose of this document is to describe an identification system for health informatics knowledge artefacts, including archetype, template and terminology subsets. This includes such artefacts created by organisations such as the openEHR Foundation, standards bodies and clinical modelling initiatives.

Latest draft (Oct 2014).

converted '+uNNNN' to '-unstable'; this makes the specification completely compliant to semver.org .
rename lifecycle state 'development' to 'in_development'

This specification describes:

human readable (machine-processable) archetype, template and subset identifiers
machine identifiers
references to identified artefacts from other artefacts and data
lifecycle management and states;
virtual library re-use;
dealing with transfer and forking;
supporting integrity and non-repudiation.

Its status is 'development' and input is welcomed:

by commenting on this page, e.g. the Feedback table below, or otherwise.
on the openEHR technical mailing list

Meta-data

This page shows the meta-data model assumed for archetypes. These are meta-data items stored in archetypes, not items that would be stored within a registry. Note that some items are defined in the ARCHETYPE class from the Archetype Object Model (AOM) and others are inherited from the Common Information Model class AUTHORED_RESOURCE.

Please use the child page to discuss the details, propose modifications etc.

Feedback

Location

Comment

Author

Knowledge Artefact Identification, Section 3

The archetype metadata should include information about the exact version of the RM used to create that archetype. Together with validation purposes, it could be an indicator of design decisions taken due to RM release characteristics/limitations.

Since indicating a RM version does not imply compatibility or incompatibility with other RM versions (pre or post), additional metadata could be added to indicate compatible versions of the RM. Having tools that can manage several RM versions make easy to tho that checking automatically at the archetype editor:

rm_compatibility = <"openEHR-RM_1.0.0", "openEHR-RM_1.0.1">

David Moner

Browser not supported