# openEHR and PROMS, PREMS and patient self reported questionnaires

**URL:** <https://discourse.openehr.org/t/openehr-and-proms-prems-and-patient-self-reported-questionnaires/3898>\
**Category:** Ask IEB\
**Created:** [21 April 2023 16:11 UTC](https://discourse.openehr.org/t/openehr-and-proms-prems-and-patient-self-reported-questionnaires/3898 "2023-04-21T16:11:04Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![Kanthan\_Theivendran](https://discourse.openehr.org/user_avatar/discourse.openehr.org/kanthan_theivendran/32/2632_2.png) [@Kanthan\_Theivendran](https://discourse.openehr.org/u/Kanthan_Theivendran)\
**Post date:** [21 April 2023 16:11 UTC](https://discourse.openehr.org/t/openehr-and-proms-prems-and-patient-self-reported-questionnaires/3898/1 "2023-04-21T16:11:04Z")

</div>

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](https://ckm.apperta.org/ckm/archetypes/1051.32.1179)

Having created this PROM (QuickDASH ): [Clinical Knowledge Manager](https://ckm.apperta.org/ckm/archetypes/1051.32.1177)

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.

---

<div class="post-metadata">

**Author:** ![varntzen](https://discourse.openehr.org/user_avatar/discourse.openehr.org/varntzen/32/3946_2.png) [@varntzen](https://discourse.openehr.org/u/varntzen)\
**Post date:** [21 April 2023 17:07 UTC](https://discourse.openehr.org/t/openehr-and-proms-prems-and-patient-self-reported-questionnaires/3898/2 "2023-04-21T17:07:46Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Kanthan\_Theivendran](https://discourse.openehr.org/user_avatar/discourse.openehr.org/kanthan_theivendran/32/2632_2.png) [@Kanthan\_Theivendran](https://discourse.openehr.org/u/Kanthan_Theivendran)\
**Post date:** [21 April 2023 19:15 UTC](https://discourse.openehr.org/t/openehr-and-proms-prems-and-patient-self-reported-questionnaires/3898/3 "2023-04-21T19:15:57Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![ian.mcnicoll](https://discourse.openehr.org/user_avatar/discourse.openehr.org/ian.mcnicoll/32/4430_2.png) [@ian.mcnicoll](https://discourse.openehr.org/u/ian.mcnicoll)\
**Post date:** [22 April 2023 10:58 UTC](https://discourse.openehr.org/t/openehr-and-proms-prems-and-patient-self-reported-questionnaires/3898/4 "2023-04-22T10:58:02Z")

</div>

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](https://tools.openehr.org/designer/#/viewer/shared/Pz9zaGFyZWRJZD0xJDEwNWMxNDhjODE5ZjRmOGNhODBlZGU4ZDQ2YzJlYTU5))

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)

---

<div class="post-metadata">

**Author:** ![Kanthan\_Theivendran](https://discourse.openehr.org/user_avatar/discourse.openehr.org/kanthan_theivendran/32/2632_2.png) [@Kanthan\_Theivendran](https://discourse.openehr.org/u/Kanthan_Theivendran)\
**Post date:** [22 April 2023 11:50 UTC](https://discourse.openehr.org/t/openehr-and-proms-prems-and-patient-self-reported-questionnaires/3898/5 "2023-04-22T11:50:05Z")

</div>

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?)

---

<div class="post-metadata">

**Author:** ![ian.mcnicoll](https://discourse.openehr.org/user_avatar/discourse.openehr.org/ian.mcnicoll/32/4430_2.png) [@ian.mcnicoll](https://discourse.openehr.org/u/ian.mcnicoll)\
**Post date:** [22 April 2023 12:13 UTC](https://discourse.openehr.org/t/openehr-and-proms-prems-and-patient-self-reported-questionnaires/3898/6 "2023-04-22T12:13:40Z")

</div>

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!!

---

<div class="post-metadata">

**Author:** ![Kanthan\_Theivendran](https://discourse.openehr.org/user_avatar/discourse.openehr.org/kanthan_theivendran/32/2632_2.png) [@Kanthan\_Theivendran](https://discourse.openehr.org/u/Kanthan_Theivendran)\
**Post date:** [22 April 2023 13:43 UTC](https://discourse.openehr.org/t/openehr-and-proms-prems-and-patient-self-reported-questionnaires/3898/7 "2023-04-22T13:43:26Z")

</div>

Thanks Ian.

Its currently in the Apperta CKM: [Clinical Knowledge Manager](https://ckm.apperta.org/ckm/archetypes/1051.32.1177)

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](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?

---

<div class="post-metadata">

**Author:** ![ian.mcnicoll](https://discourse.openehr.org/user_avatar/discourse.openehr.org/ian.mcnicoll/32/4430_2.png) [@ian.mcnicoll](https://discourse.openehr.org/u/ian.mcnicoll)\
**Post date:** [25 April 2023 10:51 UTC](https://discourse.openehr.org/t/openehr-and-proms-prems-and-patient-self-reported-questionnaires/3898/8 "2023-04-25T10:51:44Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Kanthan\_Theivendran](https://discourse.openehr.org/user_avatar/discourse.openehr.org/kanthan_theivendran/32/2632_2.png) [@Kanthan\_Theivendran](https://discourse.openehr.org/u/Kanthan_Theivendran)\
**Post date:** [25 April 2023 11:04 UTC](https://discourse.openehr.org/t/openehr-and-proms-prems-and-patient-self-reported-questionnaires/3898/9 "2023-04-25T11:04:41Z")

</div>

I agree Ian.

---

<div class="post-metadata">

**Author:** ![ian.mcnicoll](https://discourse.openehr.org/user_avatar/discourse.openehr.org/ian.mcnicoll/32/4430_2.png) [@ian.mcnicoll](https://discourse.openehr.org/u/ian.mcnicoll)\
**Post date:** [25 April 2023 11:06 UTC](https://discourse.openehr.org/t/openehr-and-proms-prems-and-patient-self-reported-questionnaires/3898/10 "2023-04-25T11:06:58Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Kanthan\_Theivendran](https://discourse.openehr.org/user_avatar/discourse.openehr.org/kanthan_theivendran/32/2632_2.png) [@Kanthan\_Theivendran](https://discourse.openehr.org/u/Kanthan_Theivendran)\
**Post date:** [25 April 2023 15:12 UTC](https://discourse.openehr.org/t/openehr-and-proms-prems-and-patient-self-reported-questionnaires/3898/11 "2023-04-25T15:12:28Z")

</div>

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:

> **[Clinical Knowledge Manager](https://ckm.apperta.org/ckm/#showarchetype_1051.32.1175)**
>
> The Clinical Knowledge Manager is a system for collaborative development, management and publishing. It enables the implementation of knowledge governance within and across the health enterprise. Resources include archetypes, templates, terminology...

> **[Clinical Knowledge Manager](https://ckm.apperta.org/ckm/#showarchetype_1051.32.1177)**
>
> The Clinical Knowledge Manager is a system for collaborative development, management and publishing. It enables the implementation of knowledge governance within and across the health enterprise. Resources include archetypes, templates, terminology...

---

<div class="post-metadata">

**Author:** ![Koray\_Atalag](https://discourse.openehr.org/user_avatar/discourse.openehr.org/koray_atalag/32/70_2.png) [@Koray\_Atalag](https://discourse.openehr.org/u/Koray_Atalag)\
**Post date:** [2 November 2024 19:32 UTC](https://discourse.openehr.org/t/openehr-and-proms-prems-and-patient-self-reported-questionnaires/3898/13 "2024-11-02T19:32:41Z")

</div>

Here’s a very draft [**PROPOSAL**](https://openehr.atlassian.net/wiki/spaces/healthmod/pages/2616361032/PROMs+Lifecycle+and+ePRO+Administration+Proposal+by+Koray+Atalag) 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

---

<div class="post-metadata">

**Author:** ![Koray\_Atalag](https://discourse.openehr.org/user_avatar/discourse.openehr.org/koray_atalag/32/70_2.png) [@Koray\_Atalag](https://discourse.openehr.org/u/Koray_Atalag)\
**Post date:** [18 November 2024 13:12 UTC](https://discourse.openehr.org/t/openehr-and-proms-prems-and-patient-self-reported-questionnaires/3898/14 "2024-11-18T13:12:54Z")

</div>

Here’s the (significantly updated) next version of my [PROPOSAL for PROMs modelling and electronic administration guide](https://openehr.atlassian.net/wiki/x/SIDymw) - 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](https://discourse.openehr.org/uploads/short-url/d0RL71uGcHASzVKCF7GO2WHTftM.pdf) (984.2 KB)

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

---

<div class="post-metadata">

**Author:** ![varntzen](https://discourse.openehr.org/user_avatar/discourse.openehr.org/varntzen/32/3946_2.png) [@varntzen](https://discourse.openehr.org/u/varntzen)\
**Post date:** [21 November 2024 07:01 UTC](https://discourse.openehr.org/t/openehr-and-proms-prems-and-patient-self-reported-questionnaires/3898/15 "2024-11-21T07:01:36Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Koray\_Atalag](https://discourse.openehr.org/user_avatar/discourse.openehr.org/koray_atalag/32/70_2.png) [@Koray\_Atalag](https://discourse.openehr.org/u/Koray_Atalag)\
**Post date:** [21 November 2024 07:15 UTC](https://discourse.openehr.org/t/openehr-and-proms-prems-and-patient-self-reported-questionnaires/3898/16 "2024-11-21T07:15:27Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![JPMesserli](https://discourse.openehr.org/user_avatar/discourse.openehr.org/jpmesserli/32/5054_2.png) [@JPMesserli](https://discourse.openehr.org/u/JPMesserli)\
**Post date:** [22 July 2025 14:15 UTC](https://discourse.openehr.org/t/openehr-and-proms-prems-and-patient-self-reported-questionnaires/3898/17 "2025-07-22T14:15:14Z")

</div>

Hi all

I am working on my first project after completing the Rosaldo Masterclasses.

As part of the Swiss Federal Quality Commission (EQK) OpenPROMs pilot programme, I am modelling the PROM EQ-5D-5L and the PREM NORPEQ in openEHR.

I found the PROM EQ-5D-5L in CKM and translated it into German (de-ch), French (fr-ch) and Italian (it-ch) according to the official translations of the Swiss register SIRIS.

I have to recreate the PREM NORPEQ. To do this, I found Ian’s template and Koray’s instructions in this post. However, I mainly followed Ian’s template.

The challenge with the PREM NORPEQ is the lengthy wording of the question per item. I therefore chose a short text for the name of the data field and placed the actual question for the patient in “Description” as in Ian’s template.

Is this still best practice in openEHR?

 ![NORPEQ Archetpye 2](https://discourse.openehr.org/uploads/default/original/2X/c/c5e34e5a34127b93a9cee2eaa585aec018226443.png)

---

<div class="post-metadata">

**Author:** ![joostholslag](https://discourse.openehr.org/user_avatar/discourse.openehr.org/joostholslag/32/1981_2.png) [@joostholslag](https://discourse.openehr.org/u/joostholslag)\
**Post date:** [23 July 2025 06:45 UTC](https://discourse.openehr.org/t/openehr-and-proms-prems-and-patient-self-reported-questionnaires/3898/18 "2025-07-23T06:45:29Z")

</div>

> [@JPMesserli](#):
>
> The challenge with the PREM NORPEQ is the lengthy wording of the question per item. I therefore chose a short text for the name of the data field and placed the actual question for the patient in “Description” as in Ian’s template.
> 
> Is this still best practice in openEHR?

I’m not up to date on the rest of this topic and the discussions around prom modelling.  
But in general I would say best practice is to put the ‘question’ in the ‘text’ and only more elaborate descriptions and remarks in ‘description’. Because form renderers (like medblocks ui, and similar for proprietary offerings) pick the ‘name’ field as a label for an input text box, and some pick the ‘description’ as a ‘secondary label’, that’s displayed only on some user action like a mouse hover, or clicking an ‘I’ symbol. Unless this is desirable behaviour for the form, I would recommend to just put the long question into ‘text’. But before proceeding we should understand @ian.mcnicoll reasons for his approach.

---

<div class="post-metadata">

**Author:** ![Koray\_Atalag](https://discourse.openehr.org/user_avatar/discourse.openehr.org/koray_atalag/32/70_2.png) [@Koray\_Atalag](https://discourse.openehr.org/u/Koray_Atalag)\
**Post date:** [23 July 2025 06:47 UTC](https://discourse.openehr.org/t/openehr-and-proms-prems-and-patient-self-reported-questionnaires/3898/19 "2025-07-23T06:47:17Z")

</div>

Hi JP, after further discussions with the team I agree with short labels and put the long form into description. AFAIK this IS the recommended approach but worth checking with @heather.leslie as she could make sure it aligns with other modelling patterns and best practices.

---

<div class="post-metadata">

**Author:** ![JPMesserli](https://discourse.openehr.org/user_avatar/discourse.openehr.org/jpmesserli/32/5054_2.png) [@JPMesserli](https://discourse.openehr.org/u/JPMesserli)\
**Post date:** [28 July 2025 06:34 UTC](https://discourse.openehr.org/t/openehr-and-proms-prems-and-patient-self-reported-questionnaires/3898/20 "2025-07-28T06:34:56Z")

</div>

Thank you very much for your explanation.

I found another variant at the Apperta Foundation [GitHub - AppertaFoundation/apperta-uk-ckm-mirror](https://github.com/AppertaFoundation/apperta-uk-ckm-mirror).

In openEHR-EHR-OBSERVATION.oxford\_hip.v0.adl, the text of the question for the patient is written under Comment (see print screen).

- Can I assume that at present the wording of the question should be placed in Description?
- Should a prefix be placed before the question, e.g. question: or is it better for a form builder to just write the question here?
- Is it permissible to end the sentence in Description with a question mark (?) instead of a full stop (.)?

Kind regards  
Jean-Pierre

 ![Bildschirmfoto 2025-07-28 um 08.23.14](https://discourse.openehr.org/uploads/default/original/2X/f/f78605cb25ee7e9e4fad1dda2222c50125b0c479.jpeg)  
[openEHR-EHR-OBSERVATION.oxford\_hip.v0.adl](https://discourse.openehr.org/uploads/short-url/fFHalTQr2pRL0ujOsh9diIloQNo.adl) (22.7 KB)

---

<div class="post-metadata">

**Author:** ![ian.mcnicoll](https://discourse.openehr.org/user_avatar/discourse.openehr.org/ian.mcnicoll/32/4430_2.png) [@ian.mcnicoll](https://discourse.openehr.org/u/ian.mcnicoll)\
**Post date:** [28 July 2025 11:38 UTC](https://discourse.openehr.org/t/openehr-and-proms-prems-and-patient-self-reported-questionnaires/3898/21 "2025-07-28T11:38:23Z")

</div>

Hi Jean-Pierre,

You are stepping into a hotly contested area!!

See [Natural language based FLAT format and long container/element names - #22 by siljelb](https://discourse.openehr.org/t/natural-language-based-flat-format-and-long-container-element-names/6765/22)

but there was also a very long discussion ‘hosted’ by the openEHR tem at Basel which got a bit stuck on the same topic.

> **[PROMs style-guide University Hospital Basel - openEHR Clinical - Confluence](https://openehr.atlassian.net/wiki/spaces/healthmod/pages/2785673246/PROMs+style-guide+University+Hospital+Basel)**

The Apperta archetypes were an earlier attempt to solve the problem but were also driven by a particular openOutcomes application requirement, and a current specific limitation in webTemplates so I would not use these as exemplars.

Fundamentally, there are several compelling requirements that are in-conflict.

1. We need to be able to represent and easily show the full original text, both to help implementers and to help the CKM editors satisfy PROMS licence-holders that the archetypes are compliant

2. This tends to go against previous CKM guidance that archetype node names should be kept short, as we are not directly trying to represent UI names. The use of long names also complicates the generation of downstream technical artefacts which use human language e.g. Web templates/FLAT format. The dev community is getting more interested in this because FHIR has shown that using tokenised English has a lot of advantages vs e.g atCodes, in terms of ease of use and e.g FHIRPath

We went round the houses quite a few times and it really came down to a choice between…

1. Imposing a burden on archetype authors/editors to create appropriate short names, along with some changes in tooling to allow long names to be displayed, if these were held in e.g archetype node ‘description’.

2. Imposing a burden on developers in potentially having very long tokenised paths in various artefacts esp in FLAT Composition formats

Until recently, I was very much in favour of using short names for archetype nodes but I can see the other argument, and I’m now coming round to the idea that perhaps the place for shortened node names is at template level. i.e if you need/want a short version of a node name, overwrite the original long name in the template, or otherwise direct the short path generator to use a short name carried in the archetype/template.

Either way, we will need some changes in tooling to allow this all to work smoothly for all parties.

[Next page](https://discourse.openehr.org/t/openehr-and-proms-prems-and-patient-self-reported-questionnaires/3898.md?page=2)