Archetype governance

Owned by Silje Ljosland Bakke
Last updated: 08-Apr-2024
5 min read

Clinical program

Responsibilities

The responsibilities of the Clinical Program Board are as follows:

  1. Determination of resource needs, including human resources and funding;

  2. Management and governance of:

    1. all clinical models and related artefacts:

      1. Archetypes

      2. Templates

    2. through all development, management and governance processes including:

      1. design and development

      2. content review and publication

      3. translation review and governance

      4. maintenance

      5. change requests

    3. across the entire CKM domain, including subdomains, projects and incubators

    4. management of community roles and participation

  3. Communication to the openEHR community

  4. Maintenance of the Clinical Program Roadmap

  5. Risk management

  6. Reporting to the openEHR International Board

Tools

CKM roles

  • Clinical Knowledge Administrators (CKAs) - 2-3 people max per CKM

    • CKAs are responsible for all content management and governance on the Clinical Knowledge Manager (CKM).

    • Highly skilled at clinical knowledge governance and archetype design

  • Editors - usually 5-10, working in close alignment with the CKAs

    • Editors are responsible for running archetype reviews on the CKM

    • Skilled at coherent archetype design that will complement the existing archetypes on CKM

  • Reviewers - potentially the whole community of registered users on CKM

    • Reviewers participate in archetype reviews on the CKM

  • Translators

    • Translators volunteer candidate translations for each archetype

  • Translation Editors

    • Editors are responsible for running archetype translation reviews on the CKM

  • Translation reviewers

    • Reviewers participate in translation reviews on the CKM

Archetype design principles

  • Archetypes for incorporation into CKM need to align and be coherent with existing content design patterns

  • Wherever possible, archetypes are designed to be context agnostic, intended for broad reuse

  • Archetypes have no technical language primacy, but in practice archetypes for international governance must use English as their original language

  • Deconstruct clinical knowledge into archetypes according to:

    • the Clinical Investigator Record ontology - using an appropriate archetype class

    • reusable modelling patterns at the archetype and data element levels

  • Intentional inclusive design of all related concepts, aiming towards a maximal data set, including:

    • clinical quality and safety

    • best practice data supporting evidence-based care

    • legacy data

  • Supports: 

    • clinical documentation at the point-of-care

      • integrated with a layer of purpose-built models designed to capture data that is derived, extracted and abstracted from point-of-care data for 

        • secondary use

        • data aggregation and analysis, such as population health

    • exchange

    • clinical workflow 

    • knowledge-based activities such as decision support, AI and personalised medicine

    • reporting

  • No data for data’s sake

  • Alignment with national and international standards and initiatives, including but not limited to: 

    • HL7

    • SNOMED CT

    • OMOP etc

  • Separation of primary clinical documentation from models that are derived and designed for secondary use

  • Modelling priorities - Modelling principles in CKM - openEHR Clinical - Confluence (atlassian.net)

  • Editorial style guide - Archetype content & style guide - openEHR Clinical - Confluence (atlassian.net)

Archetype development process

Archetype proposals

Archetypes can be developed and deployed by anyone with access to archetype design software. For an archetype to be included in the international governance, it needs to be proposed by the following methods:

  1. CKA/Editor initiation

    • Driven by international requirements - prioritisation between Clinical Knowledge Administrators; designed and published outside of any specific project, especially designing data patterns for broad reuse as a global good.

    • Examples: Adverse reactions, Advance intervention decisions (NFR), Exclusions, Medications management; Physical  Examination

  2. Member proposed requirements 

    1. Driven by project-based requirements - liaison with Clinical Knowledge Administrators

    2. Examples: Groups of coherent archetypes to support specific projects or implementations - Artificial Reproduction Technology; Infectious disease surveillance

  3. Grassroots community proposals via CKM

Proposals are assessed by CKAs, and if approved as candidates are imported into either a project or incubator, depending on the maturity and availability of an Editor to run a review.

Content review and publication process

On initial import of a proposed archetype, the archetype is added as a draft. Any number of changes may be made to the archetype in this state, to further align with existing archetypes as well as established modelling patterns.

In order to move an archetype into the published state, reviews are performed with relevant clinicians and health informaticians. Reviews are performed in the CKM, and results are collated and published by editors. Any number of iterative review rounds may be performed per archetype, but typically consensus between reviewers are reached within 1-3 review rounds.

As the result of a review round, an archetype may be rejected, suspended, or progressed into a release candidate for publication. After assessment by the Editor and CKAs and notification of the community via Discourse, the archetype may be published. At the first publication, the archetype version is set to v1.0.0  as per Semantic Versioning (SemVer) 2.0. A published archetype may be brought back into review if Editors and/or CKAs judge proposed changes to be significant enough to warrant a new review process.

When a published archetype is changed in a non backwards-compatible way, on republication the version is increased by a major number, for example from v1.0.0 to v2.0.0.

After publication, changes to archetypes are performed based on the developing requirements for the archetype’s concept. These requirements are communicated using Change Requests in the CKM.

development lifecycle
Figure 1: Archetype governance and publication process

 

Technical versioning - https://specifications.openehr.org/releases/AM/Release-2.0.6/Identification.html

  1. Start as v0 prior to content publication; essentially ungoverned v0 to support agile iterative evolution. When the content is published it becomes a v1, then governed tightly with semantic versioning.

Patch

When making small backward compatible changes. e.g. typos. Udating version from 1.0.0 to 1.0.1

Minor revision

When making backward compatible changes/non breaking. Updating version from 1.0.0 to 1.1.0

Major revision

When making incompatible/breaking changes. Changing version. Updating version from 1.0.0 to 2.0.0.

development lifecycle with versioning
Figure 2: Development Lifecycle with Versioning

Change management

After publication an archetype may require changes for any number of reasons, including but not limited to:

  • Changed requirements for recording the clinical concept of the archetype

  • Requirements have appeared that were not incorporated into the previously published version of the archetype

  • On implementation, it turns out the concept is wrong, and need to be redesigned

Changes can be requested by any registered CKM user, for each archetype, through the CKM Change Request facility ().

Proposed changes are considered by Editors and CKAs, and either rejected or incorporated into the archetype. Minor or non-urgent changes are usually accumulated and performed when a larger or more urgent change needs to be incorporated.

Translation management, review and publication

Archetypes can be translated into any number of languages, and translations have their own review, publication and management process. The CKM has specific roles for translators and translation editors. Translation editors can run a review and publication process on translations, separately from the review and publication process of the archetype content. After review, a translation is given the status “Completed” by its editor. Later content changes are likely to invalidate existing translations on specific data or metadata elements, which will give the translation the “Reassess” status for the translators and translation editors to review.