We are translating an archetype (body temperature, specifically the measurement location) to lay mans terms. I’m struggling where to put the layman’s terms: in the archetype or in a template, since some users will prefer more official (latin) names and to me it makes most sense to put those latin words in the archetype, and the layman’s terms in the template. But we will run into this a lot, and it feels like a waste not to translate in a scalable way (template will probably remain private, while archetype translations will be done in the CKM)so I wondered how others handle this?
e.g. is there a way to translate specific words to latin as a language and put the layman’s terms in NL and pick and choose different languages in a template?
I assume you are talking about something like ‘axilla’ <> ‘armpit’ . If so, for me the answer is that I have never been asked for this. I can see the value but I can also imagine that it could be a nightmare of management, across multiple dialects. Templates is probably the way but we don’t right now AFAIK, have a way to add annotations/comments to term values in the template.
The Better form tools do allow this sort of renaming of terms, as there is value in that beyond ‘patient-friendly’ terms.
I think we are creeping towards some sort of way of adding more knowledge at or on top of the template but ‘before’ form-builder/ UI to reduce the build in pure UI territory.
I’ll raise this in the spec tooling space.
1 Like
Thanks for the answer. Yes it is about creating a translation axilla (medical Dutch) and armpit (“oksel”, layman’s Dutch). I’d like to do both translations in the archetype for reusability purposes. And specify in a template per element which translation to use.
Good to know is that we don’t have an intermediary form format for the frontend. We just render the operational template with logic in javascript. We use some annotations, e.g. to hide specific fields or headings that are required in the template.
Also good to know is that in dutch way fewer laypeople are used to medical terms then in English. E.g. no normal dutch person knows what appendicitis is, (they do know “blindedarmontsteking”)
I have seen needs for this in some contexts too and have mainly thought of shared reusable templates as a solution (so far).
Since templates can be included within other templates, I’d guess wrapping for example the Body Temperature archetype in a very open (in this a case Dutch Layman-term) body temperature template doing only text/label overrides would work and be very reusable if shared. It can be included as a layer in many other templates for different use cases dealing with “layman” input of body temperature. (Another layer of use-case-specific templating may then e.g. exclude or restrict different fields, set defaults etc.)
This is likely a good thing for national collaboration.
2 Likes
Hi Erik,
That makes sense but I am aware that in the past there has been significant reluctance to overload the template layer with what might be regarded as UI directives. However, there is a counter argument that there is something in the middle which is really implementation guidance , not UI directives per-se, so potentially we are into something new sitting between .opt and forms language, or do we just use the forms language and regard that as the implementation guidance layer, not just forms design - embedded AQL, other API access etc.
1 Like
I suggested trying to use the template model, partly since templates (e.g. small ones at OBSERVATION-level rather than at COMPOSITION-level) can be practical and suitable also for shared national use cases (if nationally shared), but also because the layman terms are linguistic variants of content that should likely be stored in the RM-instances that the patients/laymen produce when filling out and storing information.
The Data Types Information Model (section 5.1.2) says: “The model of DV_CODED_TEXT is designed to capture the actual term chosen by the user or software at runtime, i.e. preferred term or synonym (for terminologies supporting synonyms)”
Using a template (instead of UI-layer overides) would take care of all that in a sharable consistent way without requiring extra (not yet standardized) technology.
There may of course be several other contexts where you want to store the “latin-like” version instead of what the layman-user saw/selected upon entry (for example where the data entered by laymen is mainly used/read by non-laymen).
An option in some use cases with double reading-audiences is of course to use/store mixed terms like “armpit (axilla)” or “axilla (armpit)”.
No matter what text/label-value; AQL-queries, decision rules etc should likely rely on the language-neutral id/at-codes or external terminology codes rather than the lexical text itself.
Thoughts?
Reuseing templates feels like the right direction!
So what would this look like in this specific usecase:
For the body temperature archetype
Specifically the location of measurement (local) value set:
If I want to make translations of both the Dutch medical(Latin) and Dutch layman’s terms, where do I put each?
And what would the template for both use cases look like?
I think that remains a tricky question!! Getting it in the data in the CDR is not an issue. How you express it in the template is more challenging.
1 Like
I just remembered that there is no tooling support for changing the texts of internally coded multiple-choice values for such as the choises to go under “Location of measurement”. I have not checked if this is a model/spec constraint at template level or just not yet implemented in template tooling. (Pinging @thomas.beale who may know by heart.)
Changing the label of the entire fieldname at template level is tool-supported though, but wont help you change the choice “axilla” to “armpit”.
Another possible option is to do a “-layman” specialisation of the archetype. We need to think through the consequenses first though…
Regarding translating the medical/latin version of the things to Dutch you don’t need any template, just translate the archetype via the normal CKM translation support. (The tricky thing discussed is only how to have a parallel layman version.)
Wikipedia has a “simplified English” version. Could we use a similar concept? Translations into “simplified Dutch”, “simplified English”, “simplified Norwegian”, etc?
1 Like
That was sort of what I was hinting at (but too lazy to explore/explain)!!
@Silje - I’m not sure if we can support these technically.
I suspect the problem will be that there is actually not a clear separation of when to use the technical term and when to use the simplfied alternative. This feels like a real management nightmare in the making!!
I think I’d be tempted to go for Erik’s earlier suggestion to carry both terms where the technical term is unlikely to be familiar e.g. axilla (armpit) and yes let’s use those wikipaedia pages as reference.
Bear in mind too that before too long I suspect we will be making far more use of SNOMED and then we are not a whole other world of potential / pain. Or much more likely Alexa/Siri etc will do it for us in the UI?
2 Likes
I skimmed this thread…
The basic needs as far as I can see is a ‘consumer-level’ translation / equivalent of some terms in an archetype, for any language - English / Dutch / xyz.
Firstly, such terms are almost guaranteed to be local, and at least in a ‘big’ language like English, there’s no guarantee that the ‘layman’s’ term is even the same across the UK / Ireland, let alone South Africa, UK, US etc.
Secondly, the specific need for which terms need to have that kind of equivalent will presmably be strongly related to some particular apps from a particular health service in some place.
So I think we are talking about templates, and/or purely local (specialised) archetypes, not mainstream shareable archetypes or templates.
Next: there is no built-in formal feature to cater for variant unofficial ‘dialects’ of any language, only official forms, like en-GB, es-ES, de-CH and so on. So we don’t have any obvious immediate place to put such terms.
However… it’s not hard to see how the terminology representation structure in archetypes & (ADL2) templates could be augmented to include some template-local sparse interface vocabulary, identified somehow - it would look like a cross between a translation and a binding. Maybe something like:
local_vocabulary = <
[nl-NL+xxxx] = <
["at104"] = ["at8104"] -- axilla -> armpit in Dutch
["at122"] = ...etc
>
>
That id nl-NL+xxxx indicates that the terms are some kind of overlay for purpose / use identified by ‘xxxx’ (the name of some app, or maybe more general, e.g. nl-NL+consumer).
This might be (roughly) a way to do it in the future. Right now you don’t have any such mechanism, so I would be looking for places in the operational environment to possibly implement term mappings / interface vocabulary. Whether that is in a terminology service, or just in the app depends on how widely it needs to be used.
1 Like
@thomas.beale one of the things I wondered above was: do the models/specs allow overriding/changing archetype texts (e.g. the multiple-choice text alternatives like “armpit”) at the template level?
1 Like
Well it’s not something that has been done AFAIK, but in ADL2 archetypes / templates a redefinition of an existing term (i.e. from a parent level) would cause an error. Since .oet templates don’t have terminology, I don’t know if you can do anything there. But in a local specialised ADL 1.4 archetype you would be able to do it by redefining the term texts, because ADL 1.4. specialised archetypes are flattened, not differential. Needless to say, this is not a safe thing to be relying on, or long-term reliable…
@joostholslag - practically speaking, I think Erik’s suggestion above is the way to go if you need this right now, and realistically a ‘proper’ answer will not be in the archetype/template layer or tooling any time soon.
This is actually quite tricky to do and manage, I suspect, with evident safety issues.
1 Like
There have been attempts to develop a consumer health terminology, but I’m not aware of any being available such that we could do mappings to SNOMED or translations
1 Like
Cool. I’ll go with shareable partial templates.
So is there a guideline on which terms to use in the archetype translations? I guess layman’s terms make most sense, since e.g. axilla is not actually Dutch off course.
Looking at it from the user (interface) point of view, there could be a UI template including the language and type of display. For axilla that could be the translation text and a picture or diagram. For a temperature you could choose text/graph/histogram/units.