Clinical Program Scope

The remit of the openEHR Clinical Program covers 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.