In a questionnaire there are often questions directed to the patient like “Do you experience fatigue that affects your daily life?” where do we put those questions to make the lives of form authors easier?
I gusess the “Symptom or sign name” should be saved for shorter descriptioins that the reader of an EHR prefers, e.g. “Fatigue” (including underlying code).
Our current candidate “hack” we are experimenting with is to rename the “Specific symptom/sign” cluster structure to contain the long question. See node highlighted in yellow in picture below
Is this a good pattern? Or is there some other recommended way?
Or should a field for questions be added to the openEHR-EHR-OBSERVATION.symptom_sign_screening.v0 archetype?
Or should the mandatory “Symptom or sign name” of the scrrening archetype be set to repeating [0…*] so that it can contain multiple different labels?
Or should template annotations be used? - If so let’s recommend a specific annotation tag to be used for patient directed questions.
Edited new alternative see post 7 below: renaming the “Presence?”-field to hold the parient-facing question,
No matter what is recommended, it should probably be added as a comment in the archetype or field description.
I guess another option would be to add a “statement” text element like in the exclusion archetypes. That way the full and complex question could be stored in data.
Coming from an ontological point of view, and having looked at quite a few of these kinds of questionnaires, I would suggest that these questions, although they relate to symptoms, are not clinical recordings of symptoms or signs as observed or characterised by a clinical professional. Instead they are patient reports of presence or absence or level of some symptom as experienced by the patient. Usually there is some kind of score that adds up the results of many such questions to form a picture of disease progress, risk or presence.
I suspect what is really needed is a library of ‘model question’ archetypes that can be used for this purpose.
We are thinking of tagging these filled out forms as patent reported (for e.g. display and AQL-filtrering). But we want part of the response to be modeled using the same structure that a clinician would use, so that when the clinician is looking at the questionnaire and speaking to the patient they can (semiautomatically) generate a clinical reporting of symptoms based on selected parts of the form.
(We can likely demo this when done and usability tested.)
The pattern in the general questionnaire archetypes actually allows creating a kind of library at the template level, combined with terminology system usage, instead of maintaining a gazillion of archetypes.
In the case of standardized question libraries like PROMIS, an (inter)nationally shared archetype library makes sense though. (See PROMIS in CKM.)
Questionnaires are notoriously difficult. The family of simple screening questionnaires are intended to provide some limited structure where it is simple and provides value. The notion of simple is important here. For example:
systematic screening symptoms - ‘Are you experiencing…’ is effectively assumed, then the list of 'fits/faints/dizziness/numbness/weakness/headaches. Then on to the list of GI or respiratory symptoms that are part and parcel of typical screening within the context of a clinical consultation.
screening for significant disease - ‘Have you ever had…’ Diabetes, Hypertension, Asthma etc…
screening for significant meds or types of meds - ‘Are you taking…’ prednisolone, antibiotics, ventolin, etc…
I think your model is fine. Your question is a more nicely phrased version of ‘Are you experiencing…’ and could be considered part of the UI, given that the semantics are essentially the same. No one would likely be
asking about, yet alone recording, fatigue that does not affect daily life.
Trickier again if the semantics are more loaded, such as ‘In the past 2 hours, have you experienced’… fits/faints/dizziness/numbness/weakness/headaches. We could start to use the history/event but it is more complex modelling.
The pattern does work if the Symptom name is set as ‘Fatigue that affects your daily life’, or ‘Fatigue in the past 2 hours’, although hard to code. IMO, in these situations it may just be better to build a ‘PROMIS’ like archetype where the semantics can be explicit and precise, even if only used locally.
The ‘statement’ contains the semantics in the Exclusion archetype, and can be coded. Whereas, to me, @erik.sundvall’s issue may be more about a UI ‘label’ that is vital part of the modeller’s instructions to implementers and extremely difficult for us to document at present.
If there are semantics in the question, more than just the name of a symptom and the intention to find if it is present, then perhaps a more specific archetype should be used, rather than the screening questionnaires.
Yes, this is exactly what I’m asking for. Where does the template modeller put that ‘UI label’ wich is usually phrased like a question for the Yes/No/Unknown answers for the “Presence?”-field (in order to guide Form developers). We could invent our own local hack, but having a recommended place/mechanism for it would make different implementations more alike.
I just realized that…
…I have missed one obvious potential place: renaming the “Presence?”-field to hold the parient-facing question, see yellow highlight in image below (I’ll also edit the previous list in the previos post to add that pattern.)
…and that the the “symptom or sign name”-fields should of course not be renamed to “Fatigue” as I erraneously did in a previous post, but rather keep their field name (green highlight in image below). Instead it is of course the content of “symptom or sign name” (The DV_TEXT value) that should contain “Fatigue” and be properly terminology-coded to match the query intent,
RE #1: Theoretically, I have envisaged that one instance of the Specific symptom cluster will carry each of fits/faints/dizziness/numbness/weakness/headaches etc values in the Symptom name - a value set for a CLUSTER with multiple occurrences would be most efficient. Again only for a simple Yes/No, Present/Absent with no additional semantics situation. So a specific question or label wouldn’t work in that situation. And imagine modelling that list of symptoms, extended to cover each clinical system eg GIT, GUT, CNS, CVS, Resp etc, - one instance of the CLUSTER for every symptom will be a nightmare.
Re #2 - agree, so that a value set can be included as per answer above.
I think I didn’t fully realise what your question was about until now. If this is all you need, this works, and we’re doing it. Heather is right that it’s a bit cumbersome, but it definitely works.
The only reason to need a “Statement” element like I suggested above would be if you needed to query the exact question in data, which I guess is rarely an issue?
It’s not just a UI label - it’s the question text, which is significant. It’s not usually the same thing as the semantic definition of the thing the question talks about. That is why for questionnaires like this, a model of ‘question’ is needed that distinguishes ‘question text’ from the gathered datum, among other things.
This wiki page has some related analysis by Samuel Frade.
We have several questionnaires like this modelled, that were created before the symptom/sign screening questionnaire archetype. So they do not currently use it. They are patient-reported symptoms.
We have the Patient Specific Functional Scale, where a single symptom/sign cluster in the archetype with occurrences {0…5}, with a single value set plus DV_TEXT alternative, works just fine. Setting the severity on a 0-10 scale in the symptom/sign is required - we would then need to copy the symptom/sign name from the the questionnaire to the symptom/sign cluster, which is possible with a ADL 2 rule in our implementation.
Then we have the Utrecht Symptom Diary, which would be 12 specific instances of this cluster, plus the option to add more patient reported symptoms. A single value set will not work, because all of the specific symptoms must be scored on the 0-10 scale, not just a subset of them. I guess this is possible by just making 12 specific instances of the cluster, all referring to the same symptom/sign cluster template overlay with all unnecessary elements excluded/removed (ADL 2, so this works differently!). Plus 12 of the above rules to set the symptom/sign name. While that is a bit cumbersome to model, it would work.
I would have to check if we have more questionnaires like this. Most use ordinal scales with specific situations instead of a present? field, or they contain more than monitoring of symptoms/signs, so those do not sound like a good match for this archetype currently.
@thomas.beale Yes the question text is significant, and when using this questionnaire archetype I assume that the “semantic definition” used for AQL-querying etc goes terminology-coded (possibly even post-coordinated) into the “Symptom or sign name” field (also assuming that the question and the content of the “Symptom or sign name” field are authored together in a consistent way).
For the simple use cases with e.g. Yes/No/unknown responses I beleive proper use of terminology is a “semantic definition” good enough. Making new specific separate archetypes does not help the semantics much in those simple cases. Could we focus this part of the discussion thread on the case when we have made an analysis and actually want to use this screening archetype rather than discussing when we would need to create another specific archetype?
@heather.leslie well that probaly depends on use case, sometimes that is certainly true, but:
Efficient for the template author or effeicient for the form developer? With today’s tooling form structures can be semiautomatically generated from templates, and in those situations requiring the form developer to manually repeat the cluster and picking different things from the value set only shifts the burden to them instead and adds a potential source of error. (And in many settings the template author, often an informatician, will be better at clinical semantics than the form developer.)
In our use case we want to specify the sypmtoms further (if answeting “Yes”) for the different questions in different ways depending on the specific question, using the “Screening details” slot (e.g. filled with different configurations of the symptom_sign archetype and other cluster archetypes). Thus we’d need to repeat the “Specific symptom/sign” cluster in the template anyway (I’ll demo some other day to clarify…).
So if I interptet the discusison correctly so far:
If we repeat the “Specific symptom/sign” cluster in a template, then renaming e.g. the “Presence?”-field would work for carrying the text of “patient-directed questions”. (A hint/comment about this or some other recommended pattern could then be added to the screening archetype)
If one wants to use the approach @heather.leslie mentioned - “a value set for a CLUSTER with multiple occurrences” - then there is not yet any obvious place to put “patient-directed questions” in a template and this information would then have to be carried in some other way to form developers. (I guess some kind of annotation of (or terminology binding to) individual values in a value set would be needed to match a “patient-directed question” to each value)
Hello again! Looking for some feedback. I believe we may have found a way of making maintainable symptom questionnaires with chunks of related question that can be maintained as embeddable templates potentially reused between different forms. (We have also appreciated the dilemma duscussions in Philosophy fun - model questionnaires literally or via existing archetypes?)
Our use case is self-reported symptoms from chemotherapy that need to be stored in a CDR as self reported data and then evaluated by a clinician (and often discussed with the patient) before the next treatment. The clinician’s EHR note from the evaluation is not using the same template as the patient form, examples of desired differences are that…
we want to use more compact language than the patient form’s question+answer and use normal symptom archetypes etc
we don’t want to record negative findings (e.g. “fatigue : No”) in the note.
…but parts of the evaluation could be pre-filled by the system as a suggestion based on what the patient answered in their form. The clinician’s evaluation note (or a separate form) could also optionally be used to report adverese reactions using CTCAE-scores.
The enhanced requirements document for the patient form (plus potentially related CTCAE-stuff) looks like this in excel-format: Underlag_Symptomkontroll_sv+en_2023-03-09.xlsx (29.9 KB)
The template structure of the patient form (now in it’s forth experimantal iteration) looks like below before we apply a pattern of embedded templates. (Note some hopefully pedagogical hints within [brackets] in the node names.)
And then everything regarding fatigue can be maintained (and reused in other forms) as a neat little multilingual and terminology bound package, both the initial Yes/No and any followup questions regarding severity etc:
Do you see any problems with modeling this way? (Good to know before we start using this approach live for real data farily soon.)
Would it be of interest to standardise and add the openEHR-EHR-CLUSTER.specific_sign_question.v0.adl archetype to the CKM? (So that others also can use this pattern to make modular embeddable templates in symptom/sign forms. I copied the content including translations from the corresponding subtree in the Questionnaire archeteype - the metadata will need to be further updated before CKM submission of course.)
I don’t see why it is necessary to use a new CLUSTER for specific symptoms and signs (CLUSTER.specific_symptom_sign_question) as this is identical with the internal Cluster in the “Symptom/sign screening questionnaire” CLUSTER. This internal Cluster is repeatable, and elements can be renamed in template according to what is needed in any use case.
The above mentioned internal Cluster contains an “Additional details” SLOT, open for any CLUSTER you want, including - if necessary - your new Follow up questions.
If I understand your requirements correctly, you would like to use “proper” archetypes for these details, meaning clinically validated data, in sound archetypes meant for persistence. Correct? If so, why not use the published Symtom/Sign CLUSTER? It’s fairly big, but as always possible to deprecate any superfluous elements.
It’s also possible to slot in another instance of the same Symptom/Sign questionnaire in “Additional details” SLOT within the internal Cluster (Specific symptom/sign) or the other “Additional details” SLOT at root level.
The same “Additional details” SLOT can be used to insert the CTCAE CLUSTER, which I hope will be published soon.
BTW, we try to use “CLUSTER” in capitals to identify archetypes of the CLUSTER class, and “Cluster” for internal (normally repeatable) sections within an archetype.
Hi @varntzen! The reasons for the new extra CLUSTER archetype openEHR-EHR-CLUSTER.specific_sign_question.v0.adl is that you can’t base an embedded template on arbitrary nodes inside an archetype, for example the “Specific symptom/sign”-subtree inside the current CKM openEHR-EHR-OBSERVATION.symptom_sign_screening.v1archetype. Instead you can only base it on a node that is an archetype slot.
If you go a bit back in the thread you may see the problem of maintaining both the yes/no-question and suitable follow-up questions as an integrated (multilingual, terminology bound and logic-annotated) package that can be reused between different forms. We want to capture all semantics at template-design-time rather than pushing unneccesarily big parts of semantics etc. to form-building-time. (Especially since we will be using the same templates in two different form editors+engines from different vendors and then would need to redo things twice.)
That is a separate thing from the need maintanability/reusability need descibed above. Yes the Symtom/Sign archetype can, and likely will, actually be used sometimes in our patient forms where it brings more value than noise. In this particular use-case it will likely instead be used by clinicians evaluating the form response (and often talking to the patient via phone to get more details). Many of the patient-directed followup questions in this use case are not a perfect fit for the intended semantics of that archetype though.
@erik.sundvall - thanks for bringing up this topic. It’s a problem area we meet regulary and it would be wise to have a shared way of modelling such use-cases.
I like the idea of a separate CLUSTER which can be an embedded and reusable template.
I would like to add an extra requirement to the design process: “It should be possible to reuse the template in different languages, i.e. some Norwegian hospitals might use the same quiestionnaire as you at Karolinska”
Multi-language seems to be a problem with Templates. With this in mind: Would it be better to develop specific archetypes to model the specific content (as a whole or parts) of a questionnaire?
Anyone with other suggestions to make multi-langual questionnaire models?
@bna I agree that multilingual would be the norm (and that sharing with e.g. Norway would be great). The templates we experiment with are actually multilingual, and multiple languages in templates now do seem to be supported in Archetype Designer.
(We could add Norwegian if somebody adds a norwegian column to the spreadsheet included in a previous post above. Note that Google translate actually treats multiple-row cut&paste to/from-spreadsheets pretty well if you want some translation speed-up.)
Do note that:
export still may need to be done once per language due to a deficiency in ADL 1.4 OPT-specification design (solved in ADL2 I believe), but with a Better-specific workaround that I guess other vendors could copy, see: Limitation preventing multilingual repeated parts in the OPT (operational template) export format But archetype/template maintenance and design of AQL queries could be done together in a language independent way.
The design allows for reuse of questions and associated response alternatives (as embedded reusable templates) in several different questionnaires. (An important requirement for scalable reusability in practice here.) If this works out well I think the pattern could be included in discussions about future versions of the "Symptom/sign screening questionnaire” archetype and associated archetypes.
We also supply a reusable follow-up-question archetype.
