Archetype governance
Clinical program
Responsibilities
The responsibilities of the Clinical Program Board are as follows:
Determination of resource needs, including human resources and funding;
Management and governance of:
all clinical models and related artefacts:
Archetypes
Templates
through all development, management and governance processes including:
design and development
content review and publication
translation review and governance
maintenance
change requests
across the entire CKM domain, including subdomains, projects and incubators
management of community roles and participation
Communication to the openEHR community
Maintenance of the Clinical Program Roadmap
Risk management
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 - 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:
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
Member proposed requirements
Driven by project-based requirements - liaison with Clinical Knowledge Administrators
Examples: Groups of coherent archetypes to support specific projects or implementations - Artificial Reproduction Technology; Infectious disease surveillance
Grassroots community proposals via CKM
Community proposal process - one archetype at a time
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.
Technical versioning - https://specifications.openehr.org/releases/AM/Release-2.0.6/Identification.html
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:
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 (CKM Change Requests).
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.