General archetype of clinical score/scale for templating measurement instruments

Background

Currently my team and I are contributing to a national bioregistry platform development in Indonesia (see: BGSI). This bioregistry platform will be used as a semi-automated electronic data capture, where it will integate manual input by enumerators and automatic data retrieval from connected EHR systems. We chose OpenEHR to store the clinical data considering its two-level data model which we believe will help retaining the semantic relations in our data.

Problem statement

Only a limited amount of score/scale are available in the international CKM repository, which I found under the Scores and Scales Project. Our bioregistry requires an extensive support of deploying webform collecting various clinical score/scale and measurement instruments (e.g. Mini-Mental State Examination, Beck Depression Inventory, etc.) One of the urgently needed clinical scale is TICI scale, which I proposed in RP-229 on 16^th^ April, 2022.

Current work-around

Though not ideal, currently we record the clinical score/scale within openEHR-EHR-OBSERVATION.story.v1. We avoid using unpublished archetypes due to interoperability reasons.

User story

As a clinical researcher, I need to adopt a general archetype of clinical score/scale so that I can create a template of measurement instruments.

Proposed solution

  1. The general archetype will contain two fields:
  • Scale/score/measurement instrument name (free text or coded input)
  • Extension
  1. The extension will be a non-exhaustive list of:
  • Scale/scale item: either as an ordinal or nominal data
  • Extensions: Any condition-specific additional information

Why does this matter?

Having a general archetype of clinical score/scale will help researchers (especially in psychiatry) to create a template of currently-unavailable measurement instruments.

Any thought on this?

1 Like

Hi lamurian, and welcome to the community! :smile:

It’s of course possible to model scores and scales as you propose, but the archetype design guidance consensus until now has been to model each score, and indeed each revision or variant of a score, as a separate archetype.

The reasoning behind this consensus is that we need to be able to uniquely identify each score or scale, similar to how body temperature and body weight are uniquely identifyable concepts. It could be conceivable to use a terminology for this, but that would require us to have a complete terminology of scores and scales, including versions or variants, which to my knowledge we don’t have.

It is a bit of work creating an archetype for each score or scale, but with the proposed solution of templating a generic score/scale archetype for each score, you have the same amount of work, which then likely will be repeated across vendors, healthcare providers, etc. This will result in much more work in total, as well as variations in how the same score or scale is modelled, or slightly different scores or scales being indistinguishable from each other when querying data.

I suspect the real problem here is that currently it takes a long time to get new archetype proposals, such as your TICI scale archetype, through the CKM and into a published state. The Norwegian archetype governance program, which I’m part of, has solved this issue for our own needs by running the reviews of our own archetypes in the international CKM in parallel with our domestic CKM. This gives us a little bit more work, but in return gives us a much larger clinical reviewer base, and makes sure our Norwegian CKM is harmonised with international archetypes. As a bonus, others can reuse our archetypes internationally. It’s certainly possible for other programs to run their own reviews as well, with a little training. :smiley:

4 Likes

I agree with that advice Silje,

It is tempting to create a generic archetype as you have suggested but ultimately each score, if properly modelled, is going to need its own archetype or extension, so te modelling effort ends up much the same but is actually more burdensome.

What we are loo

It is worth looking in other regional CKMS such as Apperta
and Highmed but also Cambio’s [CDS related archetpying] (GitHub - gdl-lang/common-clinical-models: Common clinical models in the forms of openEHR archetypes and GDL guidelines

One thing we do lack is the easy ability to query across these different Observations in a generic way, something I will raise with the Specs group.

2 Likes

The international CKM has incorporated many of the scores & scales from the Cambio team’s original work already, although not complete - including aligning them with the CKM Editorial guidelines, ready for review.

From memory, many/?most of the Apperta CKM score & scale/PROMs/PREMs archetypes have also been referenced within the international CKM, but only available as read-only at this point.

To my mind this is a major task for the Clinical Modelling Program - coordinating access to these resources so it is easy to find available content and minimise any duplicated modelling efforts.

Unfortunately, we haven’t identified the ‘silver bullet’ for managing the proliferation of scores & scales - but as each one is developed & used in a project, we hope it can be proposed as a candidate archetype to the international CKM.

The upside is that a review of any of the well-documented scores and scales is usually orders of magnitude simpler than most other clinical content, as the score data points are usually extremely well defined & undergone clinical validation. Publication can often occur after only 1 review round. Editors need to ensure that each score/scale represents the content accurately and faithfully but usually there is not much debate about the content itself, with the exception of some outliers that are not so digital-friendly.

And of course, some scores/scales are proprietary and only available under license, which can sometimes be tricky to navigate.

3 Likes

Hi Silje, thanks for your advice; and yes, our main issue is the amount of time needed to review a proposed archetype. I read in the confluence page that installing a regional CKM (as a domain) requires Mediaflux, which @ian.mcnicoll mentioned would need a license. Currently we can’t afford a VPS nor procure Mediaflux license to host a regional CKM instance.

Is it possible to request a new incubator for BGSI? Because I read that:

Incubators are used to facilitate informal collaboration, innovation and development of new or immature assets in an informal and ungoverned space within the CKM.

I suppose it will be essential for my team to get more familiar with Archetype designing. I’ve read the Archetype authoring, review and publication life cycle, but would you have further recommendation on the training we might need?

Thanks for your advice Ian, I’m particularly interested in Cambio’s approach to manage their archetypes and GDL guidelines. I also found that Cambio has their own incubator in the international CKM, so I’m wondering do they keep their archetype development synchronised with international CKM through the incubator?

Thanks for your insight Heather, we also wish to contribute to the international CKM through our research project. I read the steps to create a project in CKM, but would there be any particular requirement to create a new project that I’m unaware of?

2 Likes

I follow the advices from my friends in #openehr .

You dont need a CKM to get started. Just use github if any source control system. Prefer to do the modelling open and you might get help and feedbacks from the community.

Many scoring concepts are quite easy to model. Many is also of global interest. I assume many of them will be quite straightforward to get reviewed.

I also think you will find local concepts with no need to send through formal reviews. Feel free to use #openehr as a platform with tooling to model and implement such applications fast and safe.

Here in Norway we are moving into integrations with different legacy systems which governs clinical data. Many of these didn’t do the work of property information modelling. Still we can use #openehr to model whatever they have in the system and import the data to the EHR.

It would be great if your work provides new archetypes to global #ehealth

Thanks for opening this topic.

3 Likes

you can also have a look for our archetypes:
(Register for free account)
They’ve not been reviewed internationale and there’s no support or waranty.
There are many scales.
https://archetype-editor.nedap.healthcare/repositories/Nedap%20Basis%20archetypen/archetypes

2 Likes

Installing your own regional/local CKM requires purchase of a licence from Ocean Health Systems, which includes the Mediaflux license. Then there are the purpose/governance/philosophical decisions on whether to operate in isolation or in close collaboration with the international CKM. See ‘Not all CKMS are created equal’.

The Cambio project contains the archetypes from GitHub that I’ve edited - those that fitted within the existing ecosystem (ie concept, scope, class etc), and edited to align with the CKM Editorial guidelines, especially those on score & scales.

The Cambio modelling work is extremely valuable but it was done in isolation and required some significant time to edit the metadata & patterns etc so they are coherent with the other archetypes already within CKM. This work is not yet complete.

@Joost has also volunteered Nedap’s archetypes but they are still waiting for Editorial support. So you are not alone in being frustrated that your proposal appears to have been ignored - sadly, at the moment there is currently no one resourced to act on it, so all proposals have stalled for now.

The ideal situation would be to have an active Clinical Modelling Program with Editors resourced by openEHR to coordinate and support early dev work and encourage CKM-conformant modelling from the initial drafts.

CKM projects are part of the tightly governed CKM space and need to be managed by the Clinical Knowledge Administrators & assigned Editors. The incubators, on the other hand, are for informal collaboration as you rightly suggest, effectively a sandpit under the control of the participants - both private, by invitation only, and public, so that others can see evolving modelling. The main limitation of incubators is that they can’t run reviews, however mature & ‘CKM-ready’ incubator archetypes can be promoted into a governed Project so that they can then be sent out on review.

openEHR members can request incubators for private or public collaboration. Please DM me with your details if this is useful.

3 Likes

Hi Bjørn, I think this would be the most suitable approach for our team at the moment. We will also add some documentation so it will be easier for the community to chime in.

Thank you Joostholslag, I will check on the scales available in your repository for further reference.

Hi Heather, thank you for your warm words. I can understand that it must be challenging, especially considering the growing number of OpenEHR adoption in various clinical/research settings.

Thank you, I will communicate this with the stakeholders from the Ministry of Health of Indonesia. If they are keen on opening the designed Archetype to be reviewed by the OpenEHR community, I’ll seek your advice on how to best implement a public collaboration.

3 Likes