Overview
This page provides a description of the openEHR Clinical Program, managed by the Clinical Program Board (CPB), and includes:
Program structure
Program scope
Program Structure
The Program structure is described in the CPB Terms of Reference (ToR). It is illustrated here, including a possible structure of working groups.
...
official membership is of the Clinical Program Board (CPB), with voting rights and responsibilities, and the Clinical Program Experts Panel (CPXP), which has the same rights of access and participation but no responsibility for voting or accountability. I.e. the CPB manages, and the CPXP provides a larger team of part-time experts;
most work is done within working groups (WGs). It is up to the CPB to determine what WGs to create and when;
it is proposed that some WGs are created to cover specific domain areas and to act as the editorial group for clinical models of those areas within CKM and other model repositories under the purview of the Clinical Program;
most likely a specific WG will be dedicated to overall editor and auditing function of CKM models, which coordinates with other modelling WGs to ensure they all produce coherent models.
Clinical Program Board / CKM relationship
Historically, work has been focussed on archetypes and managed in CKM. Both the archetypes and CKM remain world-best efforts in their category. There is no organisation, including in the US that has a tool like CKM.
...
The CKM community can be understood as an open source community, i.e. where the key functions (any kind of changes, releasing etc) are managed by an official ‘owner’ - in this case, the openEHR Clinical Program - but where anyone may contribute from the outside. Management of changes to CKM will probably be via dedicated Work Groups supplying members who act as editors and quality controllers. At least one Work Group is likely to be dedicated to Quality assurance, and therefore covering model consistency, correct versioning, determining change impacts and so on.
Program Scope
The work of the Clinical Program is classified under the following areas.
Planning
roadmap development
project definition and management
Governance
Adopt FAIR principles (see Discourse discussion)
Maintain well-defined governance for controlled artefacts (current version)
Define governance for new kinds of artefacts
Provide public means of raising issues against published artefacts.
Engagement
connecting to organisations to understand requirements and/or obtain human resource for this program, e.g. modellers, editors, reviewers, translators etc
major providers e.g. UK NHS, CatSalut, Swedish regions; Ministries/Departments of Health, DoH;
organizations representing clinical specialties e.g. national / European association for cardiology, American College of Emergency Physicians, local regional organisations (e.g. nursing) etc…
outreach and support to create a high quality clinical modelling community [make more specific]
visual guideline on the process of analysis from clinical data to creating an initial archetype to be shared to CKM
connect better with implementers / vendors to obtain usage feedback, problem reports etc
facilitating model sharing: enable vendors and other local clinical model developers to easily share their models, e.g. a lightweight publication / discovery service for vendor Git repos or similar
Work actively with openEHR affiliates to connect with organisations under each geography.
IP agreements relating to archetypes (scores, scales) and terminology orgs, including SNOMED International, LOINC, WHO, etc;
Make the process of reviewing, updating, deleting and submitting new archetypes more public;
engagement with other clinical modelling efforts and standards internationally, including professional colleges;
consider strategies such as gamification, approaches for the involvement of health informatics institutions to bring their students on board;
Develop a form of integration between CKM, ADL designer and the models used by the industry when there is an update of an archetype (e.g. notification of updates and/or removal of CKM archetypes)
public help desk;
Methodology
artefact governance system & Quality Assurance
meta-data, e.g. based on ISO 13119
easily accessible, detailed description of clinical model / archetype lifecycle, from initial clinical data to formal representation, and quality checks / criteria throughout (current version)
template design and building guide (current material)
better management of 'core (aka gold standard)' archetypes, to reduce instability in library as a whole
methodology manual - design patterns guide; publish openly for community review / input
style manual (current version)
optimising models for backward compatibility
how to manage breaking changes
better support for making elements or structures deprecated
Model Development
clinical modelling
archetypes;
templates - e.g. a core discharge summary suitable for localisation;
(limited) terminology subsets as needed for archetypes (NB: the intention is not to replicate major efforts like SNOMED, HL7, etc - more to define small subsets not available elsewhere);
support for authoring rules for scores and scales (intra-archetype)
clinical algorithms, as needed for archetypes, e.g. mapping a measured value (Hb 115 g/L) into an ordinal (moderately reduced, in relation to age, sex, BSA…)
guideline authoring (future); potential formalisms - Guideline Definition Language (GDL); Task Planning and Decision Language
adoption / adaptation of information models in standards e.g. HL7 (FHIR, CDA, etc), ISO (various) to inform openEHR archetypes
terminology use within clinical models, including value set definition and terminology bindings
quality control (QMS approach) - ensuring models meet defined style guides, naming conventions, editorial processes, clinical assurance and fitness for purpose.
Model Transformation Guides
Development of transformation guides for target standards like OHDSI OMOP, HL7 FHIR, ISO 11179 etc, to support technical transformation efforts.
Model Maintenance
adding new translations to existing archetypes
adding new terminology bindings to existing archetypes
error fixes & minor improvements due to feedback from the field
publishing notices of changes, including dependency maps / analysis
refactoring existing archetypes due to updates to methodology
managing / retiring obsolete archetypes, including providing data transformation guides for systems using them.
Artefact Use
dissemination & socialisation in national/regional programs
monitoring use in the field, including change impact issues (dependency-related);
Infrastructure & Tooling
Many of the tooling features described here are assumed to be realised by development in the openEHR Software Program or by vendors, universities and other implementers. The Clinical Program is mainly responsible for providing detailed requirements and working with tool builders by reporting issues, documenting etc.
...
Support for (partly) generating 'implementation guides' for archetypes and templates, particularly indicating which data are covered by the RM;
...
authoring tooling & usability, e.g. refactoring support;
...
on
...
better release management and publication of changes, new features etc to modelling community
...
Clinical Knowledge Manager (CKM) upgrades & features;
...
need a reliable terminology service;
...
specify advanced tool functions like archetype → form generation within CKM or other modelling tools to see effects of proposed changes;
...
(future) specify executable style rules (enforce style guide), design pattern checks / suggestions (like template-based programming; Tools to maintain/interface to macros a la AutoHotKey);
...
.
Initial Activities on Establishment
Agree mission with CIC Board
Review priorities list
Build an initial roadmap for 3 / 6 / 12 / 24 months
Propose a Work Group (WG) structure, including to cover CKM archetypes editor function
Estimate resourcing needs over various time-frames.
Review and agree any updates to ToR with CIC Board.
...