PROM modelling style guide (DRAFT)
2025 01 06 HLeslie higher level thoughts:
Suggest we need clear guidance/context in a header section on:
When to use this style guide rather than the Score and Scales Style Guide. This needs a clear definition of PROM vs a score/scale. Or do we merge them together?
Further questions:
What to do with PREMs?
Should this become a more generic guide for the ‘umbrella term’ of Clinical Outcome Assessments (COA) which includes PREMs, PROMs and other assessments? Should this guidance subsume the Scores and Scales guidelines as well?
Have we investigated, identified and documented common patterns in the COAs? And the outliers that need to be considered? As with any archetype design patterns, we shouldn’t be making plans about the detail until we fully understand the scope. In some ways I feel we are jumping in too quickly to the detail and this is causing us some problems.
Then we decide the principles overall
Then we solve the issues with the outliers, hopefully pushing these up to inform the development of the overall principles and keep them consistent.
From my CKA perspective:
the most important and non-negotiable principle is not to break copyright - this has legal ramifications for the openEHR organisation. This does not mean copying the form verbatim into an archetype, but the art of creating archetypes for COAs is understanding how to distil the intent and essence of each assessment without misrepresenting it, misinterpreting it, or, at the other extreme, overloading it with ‘non-stored data’ information.
For example: If we ‘make up’ short names for data elements then this is potentially compromising the integrity of the COA. The name of the data elements is really important ensure each question is clearly identifiable and identical in wording, or as close to the original as possible. We should not be making stuff up in these archetypes!
If there is no copyright, then keeping the data element names supports keeping the original intent of the authors intact and should be a priority.
The second principle is KISS. Keep it simple - so that we represent the data correctly and so it can be reviewed easily. The more options we add in re UI support opens it up to a governance nightmare - everyone will have different opinions as to what level is appropriate. So I suggest we keep it the archetype content to the bare minimum required to govern in CKM. We should not/are not trying to duplicate the look and feel of the paper copy faithfully. Archetypes are primarily representations of data structure, not UI, nor needing to be inclusive of question preamble/context. If there are choices about the data structure that may be used to assist UI design, then this should be supported where easy/feasible but only as an adjunct to appropriate representation of the data structure. However, if it creates confusion or compromise in the data structure, then any UI representation should be excluded.
Perhaps we can consider the development of accompanying artefacts that might support UI suggestions or similar? Any suggestions?
PRO part | Description | Example | |
Concept (PRO) name | Model as the full name of the PRO. If the name is also used as an acronym, model the name in capitals, including the acronym in brackets. If the most known name is an acronym, use the acronym as the name. | Patient Health Questionnaire-9 (PHQ-9) | |
Archetype ID | Same as concept name unless it is necessary to distinguish from another archetypes with a similar name. Avoid ‘and', ‘&’, slashes or other signs in the archetype ID. | OBSERVATION.phq-9 → Proposed (avoiding dash): OBSERVATION.phq_9 | |
Concept description | Record an explanation of the concept being recorded (not the PRO itself). | ||
Purpose | Record the reason for using this archetype to record data, not to describe the purpose of the score or scale itself. Commence the first sentence with the standard phrase "To record..." unless there is a good reason not to do so. | ||
Use | (Record how the archetype might be used in implementation, not how to perform the assessment. Commence the first sentence with the standard phrase "Use to Additional information might provide guidance to modellers or implementers about how to utilise the archetype in templates or clinical systems. | ||
PRO-Question | RM Type | Use DV_Ordinal. In most cases DV_Ordinal can also be used for a two-answer question instead of boolean. |
suggestion jannis: The answer: “Yes, most of the time” (3) has to have the same assigned value (“3” in this case) as in the PRO. |
Label | Use short text representing the content of the question (as well as for superordinate clusters and answers to the question) | Short label: “Carrying groceries” (*see Full Question below) Short label: “Vision impairment” (*see Full Question below) | |
Description | Record the full text question including the number of the question and the exact wording. | Full text question: “6. I have trouble carrying groceries in my daily life.” Full text question: “2. I have a hard time reading traffic signs while driving.” | |
Comment | Add further info for explicit styling requirements necessary for PROM Validation. Add further information about conditional rendering. | suggestion jannis: Have “in the last 2 weeks” in bold font. suggestion jannis: If response “I felt dizzy” was selected ask questions 5, 6 and 7. | |
Annotation | Should Annotations be used to indicate for example: question-numbers, the specific scale/subscore the question belongs to etc..? (OPEN QUESTION) | 
| |
Superordinate PRO-Instruction | Use Cluster (instead of previously stated: DV_Cluster) if there is one parent-container for a group of | Example would be “Seattle Angina Questionnaire-7” ( https://www.ahajournals.org/doi/pdf/10.1161/CIRCOUTCOMES.114.000967) “1. The Following is a list of activities that people do during the week. […] Go over the activities and indicate your level of limitation over the past weeks:” | |
Subordinate PRO-Question | Use the same as per PRO-Question. | Description: “1b. Gardening, vacuuming or carrying groceries” etc… | |
Total Score | Naming of the total score or calculated ratio should not contain the name of the score or scale. | ||
Open Questions:
Where should we indicate the version of the Questionnaire (not of the Archetype)? Example: EORTC QLQ-C30 has different versions (current one is Version 3: https://www.eortc.org/app/uploads/sites/2/2018/08/Specimen-QLQ-C30-English.pdf). For later analysis it would be important to know what version of the questionnaire the data belongs to.