Screening questionnaire archetypes and simple checkbox lists

TL;DR: Would adding a new element for the simplest presence checklists to the Screening questionnaire archetypes work?

The long explanation:
The “Screening questionnaire” family of archetypes, here exemplified by Problem/Diagnosis screening questionnaire, enables a template modeller to create a wide variety of questionnaires based on a fairly small base structure. It allows heaps of flexibility for expressing presence/non-presence statements, timing, and any additional information required for each questionnaire item.

However, this flexibility comes with the price of increased clunkiness when using the archetype for its simplest use cases:
Simple checkbox lists of items, where a checked box implies “present”.

Here’s a pretty standard example, from a blood donation form:

For each of the procedures, problems/diagnoses or medications listed, there’s no need for additional information, and each checked box implies that the checked item is present.

To create a template for this kind of form using the current Screening questionnaire archetypes, we have to instantiate the “Specific [concept]” internal cluster for each item in the checklist (for this example 23 times), and assign the “[concept] name” element within each of those instances with an item from the checklist. The “Presence?” element would also need to be constrained to “yes”, and set to be mandatory. Then there’d need to be extra UI work to make the elements of the repeating clusters appear as a consistent checklist.

To try and mitigate this clunkiness, I created a change request for the Problem/diagnosis screening questionnaire archetype, suggesting to change the occurrences of the “Problem/diagnosis name” element from 1…1 to 0…*. This proposed would enable a template modeller to create a checklist such as the “Do you suffer from or have suffered from any of the following diseases?” section in the image above by inserting the whole value set into the “Problem/diagnosis name” element of a single instance of the “Specific problem or diagnosis” cluster, and constraining the “Presence?” element of that instance to “Yes”. The change request was supported by @johnmeredith, and a similar change was recently proposed by @ian.mcnicoll in the ongoing review of the Family history screening questionnaire archetype.

During editorial discussions there have been some concerns that this proposed change will make the data contained within the “Specific [concept]” cluster unpredictable, and would make the semantics of the “Timing” element and “Additional details” SLOT unclear. On this basis we’re suggesting the alternative of adding a new root level element to the screening archetypes, for the simplest presence checklists only. We’re envisioning something like this (element name and description totally up for discussion):

This solves the requirements of the Norwegian team without potentially blurring the semantics of the current “Specific problem or diagnosis” cluster, but we’d like to get input about whether it solves the requirements of the other parties who’ve been involved in these discussions as well. If the addition of this element breaks anything else, we’d really like to know that too :blush:

3 Likes

@ian.mcnicoll , @johnmeredith, do you have any opinions on this? Since you’ve suggested this kind of use case in several of the “Screening questionnaire” archetype reviews?

Sorry,

I have been cheweing it over before replying.

First;y, thanks for recognising the issue, and documenting it so clearly. It applies to many, many similar patterns, not just in the Screening archetypes.

We have actually created some local variants , just to get around this specific problem.

The idea of adding a new ‘pizza-topping’ 'Present checklist) element is interesting but I think I’d still prefer just to make the item 0…*

The good argument against this approach is that it really only makes sense/ is safe if Presence is defaulted to Present, and any other elements with that cluster such as timing etc are constrained out at template-level.

That is certainly our approach, works well and does not seem too hard to explain/ document.

The alternative new ‘Present checklist’ would, of course make this very explicit but would still need explained and documented. My biggest concern is that it does not provide a very seamless data upgrade route, should the simple check box turn into something a bit more complex, i.e. requiring "timing’ etc.

Of course, there would be a lot of UI work needed regardless.

So on balance, I think I’d still prefer tweaking the courences, rather than adding a new element.

1 Like

Thanks for your response! I’d be interested in examples of similar requirements outside the Screening questionnaire archetypes.

Certainly, the fact that the semantics of the internal cluster changes significantly if the name element is 0…*, among other things completely invalidating the “Timing” element, is one of the main arguments against making this change.

I don’t think documenting the usage of the additional root level element would be that difficult tbh. On the other hand, clearly documenting the alternative pattern, where the semantics of the internal cluster varies based on whether there’s 0, 1 or many instances of the name element, is a big headache.

Going from a simple use case to a more complex one will require a lot of work regardless of whether the route of a separate repeatable element on the root level, or a repeatable name element in the internal cluster is chosen. You will still need to duplicate the internal cluster and transpose the relevant values into the name element of each cluster. If the “repeatable name element in the internal cluster route” is chosen, you’d also have to constrain the occurrences of the name element from 0…* to 1…1.

@ian.mcnicoll @johnmeredith, any further thoughts on this? :smile:

@siljelb Just as those elements/nodes highlighted in my reply in another related topic show, I love the modelling pattern for the family of questionnaires, especially for the specific details, because it provides inclusiveness and expression-flexibility for template modellers.

BTW, I’d like adding a comment element beside the SLOT Additional details [Cluster] directly under the root.

I did, which is that I now think that neither of the solutions are ideal!!

Maybe before we do anything else, we could chat to some UI form-builder folks to see if the single item use-case can be automatically detected or annotated differently, to make the UI easier without changing the modelling pattern i.e keep the current cluster-based approach but have the UI allow the simpler cases o be managed as simple checkboxes.

Feel’s like it is worth a discussion?

A few months ago, I designed a health risk assessment questionnaire of this type using FHIR Questionnaire resource. Many of its items are such questions. However, when none of the options listed exist, they also require respondents to explicitly select “None of the above”. As a result, I had to split the original question into two questions, namely, the Presence (Y/N) and the Checkboxes (Multiple Choice); and then linked the latter to the former using a skip logic. In other words, the latter shows only when the respondent answer Yes. Such a solution seems not that elegant but it works.

That would be ideal, although I’m not holding my breath for it to happen quickly

(prove me wrong? :sweat_smile: )

Sure, let’s have a chat about it. Do you have any suggestions for participants and times?

Suppliers of low-code-ish openEHR Form builder tooling

  1. Better
  2. Big Picture Medical
  3. Cambio
  4. Medblocks
  5. NeoEHR

Others welcome!!

Perhaps we could re-summarise the issue here and invite them to comment on the thread, and then setup a specific call if needs be?

If it is decided that this can be done but needs some sort of annotation in a template, then we might need to speak to tooling suppliers.

3 Likes

I have another approach to these kind of use-cases:

IMHO the correct solution is to make CLUSTER archetypes that fits the use-case you model for. You will get a lot of benefits from such an approach:

  • The archetype has attributes for purpose, use and misuse.
  • An archetype is by default ready for translation to different languages
  • The questions/elements can be modelled directly according to the use-case
  • The archetype can support terminology binding
  • The archetype is versioned for historic data
  • The archetype defines a boundrary for the contained data

The modellerer should continue to use the screening archetype as the root for the screening/questionaire. This makes it trivial to query (AQL) for different screening types within the EHR. When there is a need to extract details about the questions the archetype will be a more specific target for your AQL paths.

@ian.mcnicoll - this is a reply from one “low-code” vendor you could add to your list :slight_smile:

I think this issue is relevant for “high-code” applications both when creatiing and query data. My experience over the year is that the approach I suggest would make life easier both when modelling, developing and over the years using the data.

2 Likes

Haha,

I knew I should have added DIPS to the list and would love for you to get involved :smiling_face_with_three_hearts:

I agree this is not just about ‘low-code’ environments but these are the more tricky ones precisely because we can’t ask the devs to do something smarter, we just get what is delivered by the template structure.

I also agree about using cluster archetypes to extend the basic pattern but I don’t think that really solves our problem, as it is that ‘basic pattern’ that is the issue.

I’ll try to restate the problem in a separate message with a recent use-case from London, as I think that will help as we try to get Ux people involved.

1 Like

My approach would be to not use the internal cluster and add archetypes clusters under additional details.

This approach will overcome the basic pattern.

And if there is a med for specific problems the internal cluster might be cloned Into containers for specific areas of interest. Here you meet s problem since there are no slots (?) for additional details on a lower level…

Restating the problem… using our case of needing to list items of care equipment used at home by people with complex care needs, in particular to flag where that may need to be transported to hospital with them, if they are admitted.

The template is
https://tools.openehr.org/designer/#/viewer/shared/Pz9zaGFyZWRJZD0xJDhiYzE5OGI2YjY4MTQwOWU4NzVmZWJlMWQ1NWQ4NTQ1

The Screening archetype is Equipment screening questionnaire
https://tools.openehr.org/designer/#/viewer/shared/Pz9zaGFyZWRJZD0xJDc1NzFkNzQ4MTg2ZDQ2ODY4NjE4MDczZTUzNmE3OTVi

If we were doing this now, we would probably use the Device screening Questionairre , with some extensions

The screening questionnaire set of archetypes has been, in our experience, really successful, with a basic pattern replicated in our archetype

Screening purpose:
Presence (0…1): Yes/No/Unknown
Specific device (cluster 0…*)
Device name (1…1)
Presence: Yes/no unknown

The problem we have is with Device name (1…1), inside a repeating cluster. This works perfectly where, as in the Oxygen cluster example below, we need to record other information, in addition to ‘present’ i.e. long-term oxygen prescription details, as some kind of complex structure will be needed in the UI.

However, in quite a number of cases, a much simpler pattern is required i.e. just the names of any devices that are actually present. This is often best represented visullay as multi-select dropwon/checkbox, as would be triggered by something like

Equipment used [1…*] : ‘Ambulatory oxygen’ , ‘Defibrillator’ …

The problem is that currently, we have to fit into this pattern, which is semantically correct but generally generates a more complex UI i.e multiple rows

Details [0…*]
Equipment name[1…1]
Presence: true ( default)

and in the data

Details [0]
Equipment name: Ambulatory oxygen
Presence: true

Details [1]
Equipment name: Defibrillator
Presence: true

Earlier in this thread we explored some different archetype patterns to make this easier but the problem with both suggestions is that they make it difficult to move from the simple ‘Equipment used’ scenario to the more complex .where we require more attributes against a particular device, without the previous data becoming invalid, inconsistent.

So the question to our UX colleagues is whether we can somehow have this special case detected

Details [0…*]
Equipment name[1…1]
Presence: true ( default) (hidden in UI)

so that it can be displayed as a checklist/ multi-select list, and not as a set of multiple controls - one per cluster iteration.

If it cannot be detected automatically, can we consider some sort of template annotation?

So this

Details [0]
Equipment name: Ambulatory oxygen
Presence: true

Details [1]
Equipment name: Defibrillator
Presence: true

is displayed as

Equipment name:

Ambulatory oxygen X
Defibrillator
3 Likes

Thanks Ian!

In addition to the problem of how the structures are displayed, there’s the issue of template modelling overhead. Ideally, in the context of your proposal, we could paste in a list of equipment which would then be used to generate instances of the “Details” cluster, with each value set as the single-value “value set” of the “Equipment name” element.

When there’s two pieces of equipment this of course isn’t a big issue, but when there’s 20 it’s a significant overhead when compared to pasting the values into the value set of a single element.

2 Likes

Wouldn’t it be wonderful to paste a list of equipment as names of an element (or cluster) and let the UI generate a presentation for each name?

Let’s say we explore how to add runtime name constraints on either the element or the cluster, and then repeat the same structure. It could be Improved by adding logic for each repeated structure. Both for all equipments like “if yes show description field” or for specific equipment to i e add additional questions.

I think this could be a pattern which UI and modelling vendors could build further on.

Again thanks to @siljelb for the discussion earlier today.

Thanks @bna!

I think we could significantly simplify and improve the ‘screening questionnaire’ archetype family for a v2 if we could apply a DV_CODED_TEXT name to any structure on the template level.

Example using ‘Problem/diagnosis screening’:
If we could add the value set ['Diabetes', 'Heart disease', 'Lung disease'] (with their respective external codes) as the value set of a run-time name constraint to the single instance of the ‘Specific problem/diagnosis’ in a template, we could have the form builder create a structure like this for the UI to display, much like we regularly do with single repeatable element checklists today:

'Problem/diagnosis screening' root:
  'Any problem/diagnosis?' element: yes/no
  'Specific problem/diagnosis' cluster  AND coded_name='Diabetes':
    'Presence?' element: true/false
  'Specific problem/diagnosis' cluster  AND coded_name='Heart disease':
    'Presence?' element: true/false
  'Specific problem/diagnosis' cluster  AND coded_name='Lung disease':
    'Presence?' element: true/false

This takes care of carrying the coding, giving the form builder a single place to get the naming of each repeated structure in the list, and removing the need to both rename the cluster to ensure a unique path and adding the code to the ‘Problem/diagnosis name’ element which holds the code in the current archetypes.

1 Like

Interesting approach.

I have mixed feelings about using nam/value constraints. What you are suggesting is certainly legal, and I guess the whole intent of name constraints. It certainly standardises how the ‘name’ is handled but we’d still need to have sort of ‘recognised pattern’ where this was couple with a single ‘Present’ element.

The other problem I have found in the past is that the idea of re-coding the name of an element, tends to confuse some developers who are used to seeing an explicit name node. That was one reason why we have specific ‘analyte name’ in the lab analyte cluster.

I think also, we still end up with the same idea off a repeating cluster, albeit, than the name is handled in the RM, rather than as a n explicit element.

I’ll ponder some more!!

1 Like

The idea to add the repeating definition on the CLUSTER makes it more precise what is intended by the modellerer.

Current approach is to manually clone a CLUSTER and then define some terminology code or name on an element within the CLUSTER.

The need from modeller and application developers are to make the instances of a repeating container (here CLUSTER) automatic. Then it makes sense to define the repeating constraint on the container. I think it would be interesting to look more into such an approach.

I wonder if some other vendors or other have tried out this approach before?

3 Likes

After further discussion in Norway, we’re proposing to handle this issue by improving form builder tools instead of changing the archetypes. The problem of creating a checklist from a repeatable container is relevant in a lot of use cases other than screening questionnaire archetypes, which speaks for a more generic solution.

Our suggestion can be summed up as follows:

Features:

  1. “ShowAsSelectionList” Tag:
    Applying the ShowAsSelectionList tag to a container signals the form renderer to display it as a selection list. This list is populated by a predefined set of options tied to an index element within the container.
  2. Value Set Assignment:
    The index element within the container (for example a mandatory field that identifies the type of risk) is assigned a specific value set. These values populate the selection list.
  3. Customisation of Elements:
  • Some elements can be hidden with default values
  • Optional or free-text fields can remain editable, displayed alongside the selection list in corresponding columns

Example using the “Health risk assessment” Archetype:

Configuration:

  • Container: The CLUSTER “Risk factors” (0..*) within the archetype represents multiple risk factors for a patient.
  • Tagging: The “ShowAsSelectionList” tag is applied to the Risk factors container.
  • Index Element: The ELEMENT “Risk factor” (1..1) within the cluster is assigned a predefined value set, for example {"Depot patch", "Titanium glasses", "Stoma"}.
  • Default Elements:
    • “Presence” is hidden and set with a default value of “Present”.
  • Additional Fields:
    • “Comment” (0..1) is editable for free-text input and is displayed next to the selection list.

Form display

The “Risk factors” container is displayed as follows:

Selection Comment
:black_square_button: Depot patch [Text]
:black_square_button: Titanium glasses [Text]
:black_square_button: Stoma [Text]

User interaction:

  • Checking a box creates an instance of the container with:
    • The selected value saved to the “Risk factor” field.
    • Hidden elements (like “Presence”) automatically set to their default value.
    • Any entered comments saved in the respective field.
  • Unchecked boxes do not create instances.
1 Like