Clinical Program Definition

Status

This page is now frozen, following the RFC (September 2022). The Live version of the content may be found here.

Overview

The new openEHR Clinical Program will be a sibling of the Specifications and Education Programs, and will be managed by a newly constituted Clinical Program Board (CPB) which will be established in 2022. The CPB will be governed according to a formal Terms of Reference (ToR) as used in other openEHR Programs. There will be a Clinical Program Expert Panel (CPXP) as well, which allows a larger number of experts to work as formal members of the Program without being responsible as such for its management.

See here for CPB Terms of Reference.

Priorities

The following priorities have been identified so far (order of importance determined later by CPB):

Archetype Development

• accelerate rate of review of existing v0 archetypes

• democratise & scale modelling effort, and organise, probably via Work Groups;

  • reduce editorial and other bottle-necks slowing down archetype production

  • better outreach: Calling for more clinical modellers and health professionals to join the community during the discussions, trying to cover most of the specialties

  • strategies to obtain funding and resource-in-kind

  • use Affiliates to help scale clinical requirements gathering, modelling and dissemination

Governance

• review intellectual property (IP) safety/risk of archetypes, particularly scores, scales, terminology bindings

• good integration with other openEHR Programs (Specification, Software, and Education) to work together and discuss issues in periodic meetings.

• Priority integration with Educational program to capacitate more people to work with openEHR standards, help create modelling training materials etc

• Creation of working groups (WGs) based on individual's expertise and projects e.g. cardiology, pediatrics, PROMS, scores, ...

• more transparent project definition and management

• Establishment of a governance team to maintain CKM quality

Technology

• migrate CKM to ADL2

• migrate modelling eco-system - human and tools - to ADL2, to enable use of proper specialisation, ADL2 templates with overlays, translations, and many other ADL2 improvements.

  • For some time, ADL1.4 OPTs will need to be supported for runtime systems;

  • Migration can be done progressively, with support for ADL2 <=> ADL1.4 inter-conversion, already supported by many tools.

• better support for (partly) generating 'implementation guides', including dependency maps or similar (see Infrastructure & Tooling)

Methodology

• review current archetype modelling style guideline (current version)

• review all Clinical content on the openEHR wiki, particularly to do with archetype lifecycle, using CKM, etc.

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.

Open

The essential concepts are:

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

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;

• authoring of tutorials / training material on using tools for clinical modelling;

• 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);

• (potential) clinical model terminologies available within a service, e.g. as FHIR value sets etc.

Program Board Member Qualifications

The Clinical Program Board operates as a meritocracy, following the Apache model. This means the starting team (who are considered creators of the effort, and thus ‘competent') can establish what qualifications are required of new members. These may be any combination of formal qualifications and participatory experience.

The only formally required qualification for accession to the Clinical Program Board or Expert Panel is:

• An understanding and acceptance of the openEHR mission;

Otherwise, any of the following qualities are desirable:

• Clinical background (with some minimum understanding of information issues), including specific domains; public health, medical research;

• Healthcare management background including knowledge of administration, clinical workflow, etc

• Health informatics background: a demonstrable knowledge of key health informatics areas such as EHR, terminology, etc;

• openEHR experience: some period of active participation in the openEHR community (e.g. CKM review) and /use of openEHR systems or products;

• experience in knowledge engineering and quality control;

• experience in open source community building and engagement;

• experience in tool usability / UX analysis.

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 new Clinical Program and its Board will have a significantly expanded remit, to manage not just the core modelling activity, but the many things mentioned under Scope above.

Nevertheless, clinical model development is likely to remain the central activity. CKM currently has 400-500 active known users, and nearly 3,000 user accounts. This is large enough to need its own managers, i.e. Editors, Clinical Knowledge Admins etc. Working Groups (WGs) could be an organisational way to solve this.

The crucial challenge to solve in terms of the clinical modelling activity is scaling - similar to Linux software development - any number of workers can be accommodated with the right on-boarding, project management and integration approach.

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.

Proposed 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.

Contributors

The following people contributed during the RFC Sep 2022.