Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Table of Contents

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

  • Xmind

    • Collaboration, pre-design and requirements gathering tool

  • Clinical Knowledge Manager (CKM) - https://ckm.openehr.org  

    • A purpose-built online community hub providing:

      • A library of openEHR knowledge artefacts

      • An online review portal - peer review of clinical content towards consensus and content publication as fit for use

      • Governance and maintenance of artefacts, activities, processes and community

    • As at January 15, 2024:

      • General statistics - Clinical Knowledge Manager - statistics

        • 3372 registered users from 114 countries

        • 1322 volunteer reviewers

        • 335 translators

      • Archetype statistics - Clinical Knowledge Manager - archetype statistics

        • 1212 archetypes in the whole CKM

          • 663 coherent archetypes in governed projects (approx 6500 data points) -

            • 30% have undergone a peer review, achieved a consensus as fit for use, and been published

            • 70% are in draft state

            • Only archetypes in governed projects can undergo community review

          • the remaining archetypes are under development in ungoverned public and private incubator/sandpit collaborations

        • Archetypes are represented in 34 languages

  • Archetype Designer (AD) - https://tools.openehr.org

    • An online tool for creating and modifying openEHR archetypes and templates

  • Discourse community forum - openEHR Discourse Forum

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 - /wiki/spaces/healthmod/pages/1912111120

  • 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:

...

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.

...

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.

...

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.

...

Change management

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

...

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.