...
Most archetypes used on a project are obtainable from elsewhere – either the international openEHR archetype repository, or one or more other national repositories. Thus, archetypes represent a growing global library of re-usable content models, greatly reducing the amount of work required in any new project or jurisdiction to define needed content. An incremental effort of 15% of the total content models deployed, plus translation where relevant, is a realistic expectation in terms of work for a new project.
...
2.2 Templates
openEHR templates are more detailed specifications that represent the implementable data sets – the documents, clinical notes, messages and screens required for use within, and between, EHRs. Templates are aggregations of specific elements of one or more archetypes; for example, up to 60 archetypes may be required to represent all of the clinical data elements that are needed for a discharge summary or antenatal record.
...
As long as the underlying archetypes are tightly governed, governance of the resulting templates can be lightweight, unless the template is representing something that has an official status, such as a formalised and structured data report to government.
...
3 Tools
...
3.1 Clinical Modelling Suite
Current openEHR tools for clinical modelling consist of:
- Archetype Editor – an open source tool with a ‘drag and drop’ user interface that enables local authoring and editing of archetypes. The complex technical attributes of the openEHR Reference Model and Archetype Definition Language (ADL) that underpin the archetypes is largely hidden to clinician authors. The Editor enables all classes of archetypes to be created: Compositions; Sections; all types of Entries, including Observation, Evaluation, Instruction, Action and Admin Entry; and Cluster and Elements.
- Template Designer – a free tool with a ‘drag and drop’ user interface that enable local authoring and editing of templates. In addition, the Template Designer is used in production contexts to generate template-specific downstream software artefacts, including Template Data Objects (TDOs), which are programming facades, and also Template Data Schemas (TDSs), which are XML Schemas that define an XML payload that can be used in a message, document or other communication. These downstream artefacts allow non-openEHR trained developers to immediately use openEHR semantic models to build and deploy software.
...
3.2 Clinical Knowledge Governance
As openEHR archetypes and templates were developed by the international community, it rapidly become apparent these clinical models required a formal publishing and governance support to be able to achieve the goal of semantic interoperability. Development of an online knowledge repository commenced testing in late 2008, and is known as the Clinical Knowledge Manager[3] (CKM). It holds and manages archetypes, templates and terminology subsets as primary assets, as well as associated documentation
...
The openEHR Clinical Knowledge Manager (CKM), under the auspice of the openEHR Foundation, is used as an international source of excellence. As of July 2014 there are over 1100 experts registered on the openEHR CKM from 83 countries, with many archetypes translated into multiple languages to enable cross country sharing of health data. Norway, Slovenia and Australia have established CKM instances for their national eHealth programs. Negotiations are underway with Brazil for a national instance. The UK instance currently serves Scottish NHS, and is being proposed for use for NHS England.
...
4 Summary
In essence:
- The openEHR clinical content specifications will be defined, reviewed and declared fit for purpose by clinicians and domain experts, not just software developers/engineers.
- The archetype and template development, quality control, standardisaton and governance processes should be managed by expert health informaticians who understand health data and how it will be implemented and used in the clinical environment.
- The end users will be the vendors and organisations building clinical information systems and applications and organisations who need to utilise quality health data for secondary purposes.
- The overall project governance should be led by clinical professional groups +/- a potential consortia with appropriate political/industry groups etc.
- Clinical professional and government organisations can endorse the resulting clinical models as fit for use.
- openEHR Solutions can be deployed at any time with respect to the development of clinical content models – including before any are complete. The release and deployment of each model (template) requires no changes at all to openEHR-based EHR back-end implementations, i.e. services and database; changes / additions are limited to user screens and content-specific logic.
...