openEHR and PROMS, PREMS and patient self reported questionnaires

Hi All,

I’m developing PROMs in the UK in openEHR. I have noticed that a self reported data archetype (container for PROMS) has been created: Clinical Knowledge Manager

Having created this PROM (QuickDASH ): Clinical Knowledge Manager

I wanted to know from the correct modelling perspective to maximise reuse etc should I have used the container archetype or is the one I created OK? Do I need to change anything.

Apologies for my ignorance I am new to openEHR.

1 Like

The COMPOSITION archetypes are like a blank paper sheet, with a name. No archetypes can be added to a template, unless there are a COMPOSITION to put them in.
Your quick assessment can reside in any COMPOSITION, depending on whether it is self-reported, during a consultancy or stay or something else.
The assessment should be worked on a bit more, to comply with the design style.

Cheers, Vebjørn

2 Likes

Thanks Vebjørn.

So what is the purpose of the self reported data archetype (container for PROMS) if its a blank sheet? How does it fit in with what I have created (QuickDASH) (again forgive me for the stupid questions from a newbie!).

I appreciate the style guide hasn’t been militantly followed but pretty good for a newbie I think in particular for a fairly new concept of self reported PROMs etc. Isn’t that the purpose of publishing it on the CKM so that people can contribute and improve it? (Apologies again for my ignorance).

1 Like

The Self-reported data Composition acs as the top-level container for one or more Entry archetype like PROMS scores.

Any time you commit data to an openEHR CDR it has to be in the context of a composition. So templates provide you with the way of slotting in Entry archetypes like PROMS or procedure inside a composition.

[Example(Archetype Designer)

You don’t have to use the self_reported_data composition, that will make sense in some cases but not in others. As Thomas has said there is a way of flagging a composition composer (author) as being PARTY_SELF which says that the person themselves was the author but the self-reported data composition allows a bit more detail to be recorded about exactly who was involved (may be a carer)

Thanks Ian.

So my original version is an observation archetype. So its ok to carry on with this way of creating it or do I use the self_reported_data composition that you have shown in the archetype designer above? ALL PROMS are self reported by the patient.

Should I upload the self reported one that you have created in the link above or leave it as it is and it can be changed later?

As you know we are creating a whole suite of these PROMs so its worth ensuring we have best modelling practice for reuse (I appreciate we have certain requirements from our developer SC13 that may not follow perfectly the correct openEHR approach?)

Carry on with just getting the PROMS Observation reviewed. |Each archetype is regarded as its own sperately governed component, that can be embedded in any appropriate composition. What I have linked to is a ‘template’ not an archetype - the template brings together the self_reported composition container archetype and you new archetype to create a delpoyable but use-case specific model.

It would be perfectly reasonable for the same QuickDash archetype to be used inside completely different compositon e.g an Encounter, if perhaps the score wa completed as part of a clinical encounter. Ultimately these are all cross-queryable.

So carry on as you are!!

Thanks Ian.

Its currently in the Apperta CKM: Clinical Knowledge Manager

How can I invite reviewers to review it? Should I post it in the new archetype section of discourse to make everyone aware of it?

To me its a quick one to review as the data is fixed to the specific questions from the validated PROMs. I guess its essentially a review to check style guide (not sure how this differs for self reported (Patient) archetypes).

Its a very internationally relevant PROM which have been approved/validated in a number of different languages: https://dash.iwh.on.ca/available-translations

I would be keen to port this archetype to the international CKM may be after initial review in the Apperta one?

The problem (in both CKMs) is the difficulty in getting Editorial support for the process. Even though, as you say, it is not likely to be hard to do, nevertheless, it does need someone to manage the process and ensure compliance with Style guides.

It is something we would expect openEHR UK to help get running more efficiently but will require finding some sustainable resource and a fair methodology.

I agree Ian.

We can probably get something going temporarily but it really needs to be put on a more sustainable footing, especially as openEHR is advancing in the UK.

3 Likes

I am keen to get speciality societies from the British Orthopaedic Association (BOA) involved. I wanted to get a few reviewed in particular these to show how it all works to get engagement:

1 Like

Here’s a very draft PROPOSAL I prepared for modelling the content and workflow for patient reported questionnaires (PROMs, PREMs, FREMs etc.). Feedback welcome. Hoping to discuss in detail during the openEHR Conference in Reading (and the sessions on the 4th of Monday).
@pablo @ian.mcnicoll @Kanthan_Theivendran @heather.leslie @ukpenguin

2 Likes

Here’s the (significantly updated) next version of my PROPOSAL for PROMs modelling and electronic administration guide - kind of an Implementation Guide (IG) I guess. I tried to factor in all point of views from the EHRcon conference but it is far from complete. Also sticked to existing Style Guide where relevant. Hope it’ll be useful for upcoming discussions.
Also attaching the PDF form.
PROMs Modelling and ePRO Administration Proposal (by Koray Atalag)-181124-130908.pdf (984.2 KB)

Enjoy!
@ian.mcnicoll @Kanthan_Theivendran @siljelb @heather.leslie @jannisp

2 Likes

Thanks Koray,
It’s become more a manifesto, but very useful as a background for further work. We need to tease out what belongs in the archetypes, templates and the app using them, and also what the tools allow us to do. Some of it isn’t possible to sort out in a short timeframe.

1 Like

Thanks Vebjørn, agreed.

I think we need to get the barebones right first. But hopefully the proposal will be helpful to drive further discussions.

Looking forward to our chat later today.

2 Likes