How do we handle messy source language when translating?

Clinical
,
1

Hi,
We just published the Swedish translation of Procedure (Swe: Åtgärd). The “Use” field is a long, wordy, not very well organized text where content is unnecessarily repeated. It is not only hard to understand, it is also a nightmare when translating. For the Swedish translation we decided to rearrange the text to make it shorter, clearer and more to the point, but keeping the meaning. We went from 685 words to 293 (!).

I lift the issue here since Procedure is not the only archetype suffering from descriptions that are not well suited for translation. I think it is not a very good idea to continue in the same manner as we did with Procedure; it would be much better to improve the English version and then keep the translation more close to the source. But also, to get such improvements through before translating is not a fast track.

  • What is the best way to attack this problem? How do we do next time we face the same situation?
  • Do you think that the Swedish version of “Use” in Procedure is better than the original? WHy? Why not? If you like it, should we propose a change of the original?
  • Can we somehow make sure that we document new archetypes with multiple languages in mind right from the start? A little guideline on how to think perhaps. Or documenting in two languages (English + 1) directly.

This is the original “Use” text of the Procedure archetype (source language):

Use to record information about the activities required to carry out a procedure, including the planning, scheduling, performance, suspension, cancellation, documentation and completion. This is done by the recording of data against specific activities, as defined by the ‘Pathway’ careflow steps in this archetype.

The scope of this archetype encompasses activities for a broad range of clinical procedures performed for evaluative, investigative, screening, diagnostic, curative, therapeutic or palliative purposes. Examples range from the relatively simple activities, such as insertion of an intravenous cannula, through to complex surgical operations.

Additional structured and detailed information about the procedure can be captured using purpose-specific archetypes inserted into the ‘Procedure detail’ slot, where required.

Timings related to a procedure can be managed in one of two ways:

  • Using the reference model - the time for performance of any pathway step will use the ACTION time attribute for each step.
  • Archetyped data elements:
    — the ‘Scheduled date/time’ data element is intended to record the precise time when the procedure is planned. Note: the corresponding ACTION time attribute for the Scheduled pathway step will record the time that the procedure was scheduled into a system, not the intended date/time on which the procedure is intended to be carried out; and
    — the ‘Final end date/time’ is intended to record the precise time when the procedure was ended. It can be used to document the complex procedures with multiple components. Note: the corresponding ACTION time attribute for the ‘Procedure performed’ will document the time each component performed was commenced. This ‘Final end date/time’ data element will record the date/time of the final active component of the procedure. This will enable a full duration of the active procedure to be calculated.

Within the context of an Operation Report, this archetype will be used to record only what was done during the procedure. Separate archetypes will be used to record the other required components of the Operation Report, including the taking of tissue specimen samples, use of imaging guidance, operation findings, post-operative instructions and plans for follow up.

Within the context of a Problem list or summary, this archetype may be used to represent procedures that have been performed. The EVALUATION.problem_diagnosis will be used to represent the patient’s problems and diagnoses.

In practice, many procedures (for example, in ambulatory care) will occur once and not be ordered in advance. The details about the procedure will be added against the pathway step, ‘Procedure completed’. In some cases a recurring procedure will be ordered, and in this situation data against the ‘Procedure performed’ step will be recorded on each occasion, leaving the instruction in the active state. When the last occurrence is recorded the ‘Procedure completed’ action is recorded showing that this order is now in the completed state.

In other situations, such as secondary care, there may be a formal order for a procedure using a corresponding INSTRUCTION archetype. This ACTION archetype can then be used to record the workflow of when and how the order has been carried out.

Recording information using this ACTION archetype indicates that some sort of activity has actually occurred; this will usually be the procedure itself but may be a failed attempt or another activity such as postponing the procedure. If there is a formal order for the procedure, the state of this order is represented by the Pathway step against which the data is recorded. For example, using this archetype the progressing state of a Gastroscopy order may be recorded through separate entries in the EHR progress notes at each ‘Pathway’ step:

  • record the scheduled Start date/time for the gastroscopy (Procedure scheduled); and
  • record that the gastroscopy procedure has been completed, including information about the procedure details (Procedure completed).

Please note that in the openEHR Reference Model there is a ‘Time’ attribute, which is intended to record the date and time at which each pathway step of the Action was performed. This is the attribute to use to record the start of the procedure (using the ‘Procedure performed’ pathway step) or the time that the procedure was aborted (using the ‘Procedure aborted’ pathway step).

And this is the Swedish translation/modification (target language):

Används för att dokumentera aktiviteter som krävs för att utföra en åtgärd. Detta inkluderar information om alla steg, från planering och schemaläggning till utförande, dokumentation och färdigställande. Varje aktivitet registreras genom specifika processteg som definieras i arketypens “Pathway”.

Arketypen är flexibel och omfattar:

  • Enkla åtgärder som insättning av en intravenös kateter.
  • Komplexa åtgärder som kirurgiska ingrepp.
    Detaljerad information om åtgärden kan registreras med hjälp av ytterligare arketyper infogade i SLOT “Åtgärdsdetaljer” vid behov.

Tider relaterade till en åtgärd hanteras på två sätt:

  • Referensmodell – Attributet “ACTION time” används för att registrera när ett processteg utfördes, dvs exakta tidpunkter för varje steg i åtgärden, inklusive avbrott och färdigställande.
  • Dataelement i en arketyp: “Schemalagt datum/tid” registrerar den planerade tidpunkten för åtgärden. “Datum/tid avslut av åtgärd” anger exakt tid för åtgärdens avslutning.

Notera att “ACTION time” för schemalagda steg registrerar när en åtgärd dokumenteras i systemet, inte den faktiska tiden för åtgärden. Notera även att vid komplexa åtgärder med flera komponenter registreras durationen av åtgärden genom att dokumentera varje enskilt steg av åtgärden.

Används för att registrera utförda åtgärder i en operationsrapport (Övriga delar, som provtagning, avbildning och uppföljning, hanteras med separata arketyper.).
Används för att registrera utförda åtgärder i problemlistor eller sammanfattningar (medan EVALUATION.problem_diagnosis hanterar patientens problem och diagnoser).

Används för att dokumentera arbetsflöden, där åtgärder i vissa situationer kommer registreras i steget “Åtgärd slutförd” eftersom de inte registreras i förväg.
Används för att dokumentera återkommande åtgärder, där varje utförd åtgärd dokumenteras individuellt.
Används för att dokumentera formella arbetsflöden, såsom ordningsföljd för åtgärder i specialistvård.

Används för att dokumentera att en aktivitet faktiskt inträffat. Om en åtgärd avbrutits registreras detta i motsvarande processteg.
Exempelvis gastroskopi med

  • Schemalagt startdatum/tid registreras som en planerad åtgärd.
  • Slutförd gastroskopi registreras med detaljer om åtgärden.

Translating back from the new Swedish version to English using ChatGPT gives us this, 325 words (I haven’t checked the translation quality, just did it to help the ones of you that don’t speak Swedish but it looks quite OK at a glance):

Use to document activities required to carry out an action. This includes information about all steps, from planning and scheduling to execution, documentation, and completion. Each activity is recorded through specific process steps defined in the archetype’s “Pathway.”

The archetype is flexible and encompasses:

  • Simple actions such as the insertion of an intravenous catheter.
  • Complex actions such as surgical procedures.
    Detailed information about the action can be recorded using additional archetypes inserted in the “Action details” SLOT, if needed.

Times related to an action are handled in two ways:

  • Reference model – The “ACTION time” attribute is used to record when a process step was performed, i.e., the exact times for each step in the action, including interruptions and completion.
  • Data elements in an archetype – “Scheduled date/time” records the planned time for the action. “Action end date/time” indicates the exact time of action completion.

Note that “ACTION time” for scheduled steps records when an action is documented in the system, not the actual time the action took place. Also note that for complex actions with multiple components, the duration of the action is recorded by documenting each individual step of the action.

Use to record performed actions in an operation report (Other aspects, such as sampling, imaging, and follow-up, are handled using separate archetypes).
Used to record performed actions in problem lists or summaries (while EVALUATION.problem_diagnosis manages the patient’s problems and diagnoses).

Use to document workflows, where actions in certain situations will be recorded in the “Action completed” step since they are not registered in advance.
Use to document recurring actions, where each performed action is documented individually.
Use to document formal workflows, such as the sequence of actions in specialist care.

Use to document that an activity has actually occurred. If an action is discontinued, this is recorded in the corresponding process step.
For example, gastroscopy with:

  • Scheduled start date/time is recorded as a planned action.
  • Completed gastroscopy is recorded with details of the action.

/Åsa

2 Likes
2

Great question, it also came up in the openEHR Finland work last year. I’ll bring it up in the next CPB meeting as it would be good to have clear guidance around archetype translations, which will probably require a working group to discuss and define best practices. Meanwhile, any recommendations on how to handle this issue @heather.leslie @siljelb @varntzen?

3

The translation does not have to be exact a copy of the original text. The most important is the meaning is kept. However, the author of the archetype and the editors running the reviews have spent a lot of time with the wording, based on experience and review feedback. Not seldom, there are comments in the review that clearly shows that even when the editors think the wording and definitions are super-clear, reviewers think differently. Misunderstandings are not uncommon. This is why the Use section and other meta information can be quite extensive and wordy.

I do not say there are no room for improvements in archetypes. During the years there has been established common ways to express the same content of documentation, and some of the older archetypes haven’t been updated to reflect that.

Whenever someone discovers clunky or unnecessary wordy blocks of text, or in Description or Comment, I recommend making a Change Request, preferably with a suggestion of improvement to the original language before doing major changes in the translation.

3 Likes
4

I really recognise the challenge of translating the archetype’s description fields. To me there’s several issues here. My main concern is if a translation changes the meaning of the source text, it will lead to different data for the same archetype. This is counter the mission of openEHR and CKM archetype modelling. So I would be very reluctant to do an intensive rewording of a key archetype part like ‘use’. And in my translations I try to stay as close as possible to the source text (for archetypes! Redefined nodes in templates is different), even if it makes the translation akward. I’d like to have a low bar for the reader to study the original text and use different (machine/AI generated or other human) translations. The main audience for the use statement is template modellers, which are usually highly trained professionals with, at least in my country usually quite good English proficiency.
I’m increasingly less motivated to translate those description sections at all and focus on the archetype content. Because this is what end users see.

2 Likes
5

I can’t add much to the question of how to deal with use sections that are currently messy, but sort of seems to me that preventing changes or new archetypes with messy sections may be just as important?

As non-native english speaker who has recently started writing/modifying use and misuse sections I’m fully aware of being at risk of writing bad ones, but I feel that it’s not that easy to understand the best practices surrounding them.

I sort of generally understand what’s supposed to go in there, but how should it be structured, what’s important enough to be included there, should there be specific subsections with a specific order?

We could probably write a Wiki page per Archetype to describe the use, misuse, best practices and pitfalls in detail but I know that’s not all supposed to go in the ADL…

Is there a “Do’s and Don’ts of Use and Misuse” somewhere?

Would be nice to have some examples of what the community considers a “perfect” use sections or what is problematic

2 Likes