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.
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.
Name | Org |
---|---|
Heather Grain | GeHCo, Australia |
Silje Ljosland Bakke | Helsevest, Norway |
| |
Danielle Alves RN, PhD | Ars Semantica, UK |
Ian McNicoll MD | FreshEHR, UK |
Vanessa Pereira |
|
Jose Luis Jorge |
|
Paul Miller MD | NHS Scotland |
SCATA UK |
|
Samanta Dall'Agnese | Status |
Anders Thurin | Sahlgrenska University Hospital, Gothenburg, SE |
Vebjørn Arntzen | Oslo University Hospital |
(original author list) |
|
This is really important: to define design patterns and to collect and promote best practices. There are many different ways to model clinical information, but probably, there are only fey ways to do it in the right way. This seems to me very similar to what SW industry has done on patterns.
In our company we are starting to design archetypes and, each time we face a different use case, there is a lot of thinking about what is the right way to do it. Probably this is a process that someone else has already done, so, that could be used to create a library of patterns.
Here I see not only archetypes but also templates. I see templates more based on how clinical information i produced and consumed in the local clinical practice, but again, here I we face a lot of doubts about what is a good template.