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.

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.