How to use the "Symptom/sign screening questionnaire" archetype

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

1 Like

Yes, but that is not what I asked about.

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

Hi Erik,

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.

1 Like

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.

1 Like

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…

  1. …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.)
  2. …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,


1 Like

Hi Erik,

Good points.

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?

1 Like

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.

1 Like

@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)
1 Like