# openEHR and PROMS, PREMS and patient self reported questionnaires **Category:** [Ask IEB](https://discourse.openehr.org/c/ask-ieb/37) **Created:** 2023-04-21 16:11 UTC **Views:** 1002 **Replies:** 27 **URL:** https://discourse.openehr.org/t/openehr-and-proms-prems-and-patient-self-reported-questionnaires/3898 --- ## Post #1 by @Kanthan_Theivendran 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: https://ckm.apperta.org/ckm/archetypes/1051.32.1179 Having created this PROM (QuickDASH ): 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. --- ## Post #2 by @varntzen 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 --- ## Post #3 by @Kanthan_Theivendran 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). --- ## Post #4 by @ian.mcnicoll 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(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) --- ## Post #5 by @Kanthan_Theivendran 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?) --- ## Post #6 by @ian.mcnicoll 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!! --- ## Post #7 by @Kanthan_Theivendran Thanks Ian. Its currently in the Apperta CKM: 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 I would be keen to port this archetype to the international CKM may be after initial review in the Apperta one? --- ## Post #8 by @ian.mcnicoll 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. --- ## Post #9 by @Kanthan_Theivendran I agree Ian. --- ## Post #10 by @ian.mcnicoll 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. --- ## Post #11 by @Kanthan_Theivendran 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: https://ckm.apperta.org/ckm/archetypes/1051.32.1175 https://ckm.apperta.org/ckm/archetypes/1051.32.1177 --- ## Post #13 by @Koray_Atalag 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 --- ## Post #14 by @Koray_Atalag 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|attachment](upload://d0RL71uGcHASzVKCF7GO2WHTftM.pdf) (984.2 KB) Enjoy! @ian.mcnicoll @Kanthan_Theivendran @siljelb @heather.leslie @jannisp --- ## Post #15 by @varntzen 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. --- ## Post #16 by @Koray_Atalag 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. --- ## Post #17 by @JPMesserli 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|690x429](upload://seB3SV30AXcTJ1sTBXwOLHvgssX.png) --- ## Post #18 by @joostholslag [quote="JPMesserli, post:17, topic:3898"] 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? [/quote] 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. --- ## Post #19 by @Koray_Atalag 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. --- ## Post #20 by @JPMesserli Thank you very much for your explanation. I found another variant at the Apperta Foundation 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|690x467](upload://zjH4NnVcUw7Y09SGoY8DrLu8jhf.jpeg) [openEHR-EHR-OBSERVATION.oxford_hip.v0.adl|attachment](upload://fFHalTQr2pRL0ujOsh9diIloQNo.adl) (22.7 KB) --- ## Post #21 by @ian.mcnicoll Hi Jean-Pierre, You are stepping into a hotly contested area!! See 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. 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. --- ## Post #22 by @heather.leslie Hi Jean-Pierre, Ian, Koray Ian has pointed to some of the Confluence discussions which was very diverse. It was hard to draw strong conclusions from it. More here - https://openehr.atlassian.net/wiki/spaces/healthmod/pages/2471886851/PROM+modelling+style+guide+DRAFT As CCIO and a CKA of CKM, I undertook to develop a proposal that would be discussed as our working proposal for PROMs. I haven't had a chance to do it yet. Mea culpa. Most of the discussion in Confluence was about where/how to document the full question and hierarchies to represent the contextual information. What didn't feature so much was the important protection of copyright where relevant and governance issues, such as ensuring that original authors were satisfied that their tools were represented correctly and that reviewers did not find any ambiguity in the archetypes. My notes are currently a few thousand miles away, but from memory, my discussions with @siljelb (as the other CKA) and @Kanthan_Theivendran (as lead of the CPB PROMs working group) established the following principle: **Data elements should accurately represent the PROM questions as authored.** This means using the full original question as the data element name. Shortening or paraphrasing introduces subjective interpretation, which risks diverging from the author’s intent, triggering debate during review, and potentially breaching copyright. **In short, don’t make anything up**. I will endeavour to write this up more formally later in the week. Thanks for the poke. Cheers Heather --- ## Post #23 by @JPMesserli [quote="heather.leslie, post:22, topic:3898"] Heather [/quote] Hi Heather Thank you very much for the link, where also the current PROM guidelines for the University Hospital Basel, which Ian referred to, can also be found. You point out that, in addition to implementation guidelines for instructions and questions, other aspects need to be taken into account. I have added an 'Extension' to 'Protocol” and drafted a CLUSTER openEHR-EHR-CLUSTER.questionnaire_metadata.v0.adl. This is attached. It should also take into account the FHIR questionnaire metadata as far as possible. Is this a viable option? I look forward to the final Implementation Guidelines for PROM/PREM Questionnaires in openEHR. Regards Jean-Pierre DRAFT Metadata Questionaire for protocol: [openEHR-EHR-CLUSTER.questionnaire_metadata.v0.adl|attachment](upload://21VMx0drixLdM65veXZjyqZ8Ddb.adl) (6.6 KB) --- ## Post #24 by @ian.mcnicoll With regard to your proposed metadata extension, much of this has been discussed and the view was that many of the items were already carried in the archetype metadata definition and did not have to be explicitly recorded in the patient record. FHIR Questionnaires are in essence, design-time artefacts i.e not actually part of a patient record. If we need to carry some of these items it would probably be as extra tags in the `other_details` section of the archety\[e and not as an actual CLUSTER which intended for data that will end up in the patient record But definitely worth reviewing, in terms of any extra information that we should include as routine. --- ## Post #25 by @ian.mcnicoll Thanks Heather, As you know, I have, until now been on the other side of this argument i.e. that we **should** use short names but carry the long named elsewhere. This is definitely a case of ‘both sides’ having a good case but we do need to come to a conclusion, and on balance, it is probably easier to accomodate those scenarios where short names are required, as an exception, with a particular need to lower the burden on CKM authors/editors. In that case, those of us who might want or need to surface short names in downstream tech artefacts should get together and find a way of advising tooling folks what we need. e.g we just overwrite the long name in a local template. Not quite that simple but hopefully we can find an approach that is not too burdensome for modellers but is also supported in tooling. --- ## Post #26 by @JPMesserli [quote="ian.mcnicoll, post:24, topic:3898"] With regard to your proposed metadata extension, much of this has been discussed and the view was that many of the items were already carried in the archetype metadata definition and did not have to be explicitly recorded in the patient record. FHIR Questionnaires are in essence, design-time artefacts i.e not actually part of a patient record. If we need to carry some of these items it would probably be as extra tags in the `other_details` section of the archety\[e and not as an actual CLUSTER which intended for data that will end up in the patient record But definitely worth reviewing, in terms of any extra information that we should include as routine. [/quote] Hello Ian, thank you very much, good points. I am primarily concerned with the secondary use of the composition, i.e. scientific evaluation. There are certain general conditions that may be required, e.g. * Language on then screen of the questionnaire when completed by the patient (recognition of language-related bias) * How the questionnaire was administered (e.g. patient himself, proxy, interviewer) * On which device was the questionnaire completed (desktop, tablet, smartphone/manually, speech recognition) What would be the best practices for storing this data in the composition? --- ## Post #27 by @ian.mcnicoll Language is captured by default at Composition and Entry level by the CDR as part of the openEHR reference model. Similarly we can use RM participations to capture the way it was administered and probably feeder_audit to capture the device/app modality concerned. --- ## Post #28 by @Koray_Atalag Hi @JPMesserli and all, long story short I prepared a very [comprehensive guide ](https://openehr.atlassian.net/wiki/external/YjVkOWQwYWY5NTE3NDJkMWI3NzYxYzM0NjU1ZGM3NzU#Questionnaire-Properties)for full-lifecycle of PROMs representation and implementation. I’m sharing this because I put a lot of previous real-world implementation experience and knowledge (we built a PROMs/PREMs solution and undertook quite large-scale (national/state-wide projects) - but our data model was proprietary and we used FHIR Questionnaire/QuestionnaireResponse resources for integation with EMR/HIEs). Related with your query on meta-data the link will take you to relevant section in my guide. This was at early stages of PROMs WG discussions and I dumped all my ideas without much consideration of existing work and approaches within the openEHR Community. I’m talking about pre-EHRCon2024. There, we had a good discussion with quite a few people around the table and then we mostly converged. Where the contention lies at the moment is: 1. Long vs short labels in PROMs Archetypes: 100% I think we should stick with author’s guide BUT when administering it. But we don’t need full path for data analysis and secondary use (e.g. as data dictionary and after response is collected). So, I think we need to consider these two options together. I also think proper tooling should also support the latter use cases; for example reducing length of full path of elements using a discrete shortener (e.g. like URL shortener but leaving enough semantics for human readability) so the Web Template will look much better. 2. Mitigating copyright/IP issues: now this is really really important and I echo what @heather.leslie said. My take on this is we need to answer an existential question: a) Is the purpose of PROMs Archetypes to faithfully represent full instrument (with instructions at the top - which can change for example for adult vs paediatric patients or when administered by a proxy). Followed by individual or groups of nodes to capture questions to the degree it will drive ePRO solutions to be able to provide GUI for administration to patient/proxy as well support linkage with other assessments in a VBHC care pathway. Plus all the analytics, trended results, dashboards and reporting for quality improvement/performance benchmarking as well VBHC payment and population health/policy making. So, I’m talking about the end-to-end use case here. b) Is the purpose to simply persist, query and unpack PROMs data to populate proper clinical concepts (e.g. comorbidities captured in Problem/Diagnosis archetype, symptoms patient is reporting into proper openEHR models so they can be part of the EHR) - while full question labels and meta-data is managed separately and with proper licensing/permissions from authors. I think the answer is the latter. And take how ICHOM provides full data dictionaries, including PROMs that are not in the public domain. I’m attaching the Excel data dictionary which has the gold standard PAID PROMs (copyrighted and with license fees in most cases) and you’ll see its data elements. [14-Diabetes-Data-Dictionary-V4.0_2021.xlsx|attachment](upload://a5RiPagf2g32FdjZdCn97mDERLN.xlsx) (32.0 KB) The way they get around this is simply the data dictionary is providing a template for storing data and not for electronic PROMs administration. It’s the vendor’s and consuming organisations responsibility to get access to the full instrument and build UIs, administration workflows, integrations - using additional data from the instrument but also others such as scoring guides, CAT-IRT item banks etc. BOTTOMLINE: I think we should shorten the Archetype labels, optionally store full label in Description (we need to check of authors’ are comfortable - since ICHOM data dictionaries include full labels it should be doable). Proper tooling should allow for consistent shortening while keeping key semantics of the node/element/question for users who would consume this (data analysts, quality managers etc.). Clinical and other operational users who need full labels can always use text in Description. Hope it all makes sense. --- ## Post #29 by @JPMesserli Hi @Koray_Atalag, impressive and valuable collection and comprehensive considerations of all relevant points on PROMS in your guideline. As a clinical modeller, I find concise instructions such as those for the University Hospital Basel helpful:. https://openehr.atlassian.net/wiki/spaces/healthmod/pages/2785673246/PROMs+style-guide+University+Hospital+Basel @heather.leslie is working on it. --- **Canonical:** https://discourse.openehr.org/t/openehr-and-proms-prems-and-patient-self-reported-questionnaires/3898 **Original content:** https://discourse.openehr.org/t/openehr-and-proms-prems-and-patient-self-reported-questionnaires/3898