Does this field have a kinda “purpose” property like the FHIR CodeSystem.concept.designation.use?
Since I had misunderstood the initial proposed step, let me try again:
- Add an archetype annotation (to the AOM?) specifying that tools are to use the Description field instead of the element name for labelling a UI field. Would this annotation be set per archetype, per element, or perhaps per container?
- Implement support for this new annotation in relevant tools such as CKM, form builders and possibly form renderers
- Add workload for modellers to identify element names longer than some defined number of characters, make up a shortened version which is still unique, add the original question to the Description field, and potentially set the annotation mentioned above
- Get archetype reviewers to look at the Description when reviewing PROM archetypes, but the element names for all other archetypes
- Convince copyright holders that this is fine
And if I understand correctly, the alternative is:
- Slightly inconvenience PROM implementers who are using the natural language FLAT format paths
I don’t have a strong impression about the percentage of PROM questions which are longer than 50 characters. Perhaps people who have worked more actively with implementing PROM tools would know? I’ve had a quick look at the following archetypes. Some of them may not be PROMs, but they’re all standardised questionnaires intended to be filled out by the patient themselves. Numbers in brackets are the number of element and container names over 50 characters in length, and the total number of elements and containers.
- EPIC (32 of 70)
- MAP-hand (2 of 23)
- EQ-5D-5L (0 of 7)
- Birth Satisfaction Scale-Revised (0 of 14)
- Western Ontario and McMaster Universities Arthritis Index (0 of 28)
- Simplified Endoscopic Disease Severity Score for Crohn’s Disease (0 of 57)
- Short Inflammatory Bowel Disease Questionnaire (2 of 16)
This question came up again while I was modelling around 20 questionnaires for a German use case. I wasn’t aware of this thread before, so I had posted a related question here: Long question names from validated instruments.
From what I’ve read so far, it seems like there isn’t a clear consensus yet.
My current (and possibly incomplete) understanding is that the modelling approach should focus less on how an instrument is used in real-world settings, and more on how to storing the resulting data in a structured, semantic way. Some of these instruments can be quite complex, questions and items can be several sentences long, include images, or make formatting suggestions.
Also, some questionnaires or interviews come with a guidance manual that defines the exact questions, context, rules for orders based on previous answers, and even a separate data capture sheet.
It feels like this level of detail can’t really be represented in the element name, or even in an Archetype or Template?
I’m also not sure if it’s a good idea to try and convert a paper-based tool directly, one-to-one, into an archetype and then just use that archetype for data capture. Is there a way to define rules about hiding and showing elements based on previous answers?
I’d really appreciate any advice on how to approach this, especially as we’d like to propose our new archetypes for CKM review in the future. I just want to make sure we’re following best practices and not missing something fundamental around element naming.
1 Like