Global Studies: Language, CCGs & Coding Readiness

Why this matters

Global trials succeed when every country captures the same scientific intent in their own language. If guidance and translations are inconsistent, you get different verbatims, different coding, and analysis that doesn’t pool cleanly. That fragments safety summaries, inflates query volume, and slows submission. The fix is disciplined localization: one master set of rules, faithfully translated, with aligned medical dictionaries and clear site training.

Core concepts & definitions

• CCG (CRF Completion Guidelines) — The “how to fill the case report form (CRF)” manual. It tells sites what to enter, with examples of good and poor entries. The Master CCG is the sponsor‑approved source (usually English).
• Localized CCGs — Official translations of the Master CCG. They preserve intent and examples, add country‑specific notes (e.g., decimal comma), and are version‑linked to the master.
• Coding conventions (for medical coding) — Short rules coders follow so verbatims are mapped consistently (e.g., how to handle synonyms, misspellings, abbreviations).
• Dictionary parity — Using the same versions of coding dictionaries everywhere (e.g., MedDRA for adverse events and medical history; WHODrug for medications), with the same sponsor conventions.
• Locale specifics — Differences that affect data entry and coding: language, common synonyms, units, decimal separators, date formats, permitted abbreviations.
• Verbatim — The exact words recorded by the site (in the local language where the study allows it) for things like adverse events or concomitant medications. Verbatims are later coded to standardized terms (e.g., MedDRA Preferred Term).
• Back‑translation — A quality technique: translate localized CCG or key CRF text back into the master language to confirm meaning hasn’t drifted.

One rule of thumb: Sites enter the term documented in the source (the investigator’s diagnosis if one was made, otherwise the sign or symptom in plain medical words), in the study’s data‑entry language. Coders standardize later; sites don’t “pre‑code.”

The process, step‑by‑step

1. Author the Master CCG

   • Write in plain language. For each field, give do/don’t examples.
   • Call out abbreviations to avoid (e.g., “SOB” can be ambiguous; prefer “shortness of breath”). List the permitted abbreviations with their meanings; verbatim fields are written in full. Abbreviations differ by language, so each localized CCG carries its own reviewed list.

2. Localize the CCG (officially)

   • Use certified translators familiar with medical terms.
   • For high‑risk sections (adverse events (AEs), medications, labs), use back‑translation to confirm intent.
   • Keep the same version ID across all languages; maintain a shared change log. When the master changes, every translation is updated and sites are retrained before it takes effect.

3. Align dictionaries and conventions

   • Freeze and communicate one MedDRA version and one WHODrug version for the study globally, and record them in the coding plan. Any upgrade is made for all countries together, under change control.
   • Publish coder conventions that mention regional spellings and synonyms (e.g., “dyspnoea” vs “shortness of breath”; “paracetamol” vs “acetaminophen”).
   • State the data‑entry language in the data management plan (DMP); many sponsors require English free text. Where local‑language verbatims are allowed, they are coded with the same MedDRA version in that language (a term keeps one code in every language) or from a documented, qualified translation. The original verbatim is kept unchanged; an unclear one is queried.

4. Configure CRFs for language & units

   • Show prompts, help text, and controlled lists in the site language. Only the displayed label is translated: every language stores the same code (“Sí”, “Ja”, and “Yes” all store Y).
   • Decide unit strategy: a single canonical unit where every source already reports it (e.g., one central lab), or capture value + unit as shown on the source and convert centrally with a versioned conversion rule, so sites do not have to convert by hand. The reported value and unit are kept.
   • Normalize numeric entry (e.g., accept “3,5” or “3.5” but store one representation).

5. Train, confirm, and monitor

   • Train sites with localized CCGs before go‑live and before they get electronic data capture (EDC) access; collect acknowledgements.
   • In the first data cut, sample early entries from each country for drift (do verbatims say more than the source, or too little? Are units mixed?).
   • Reinforce with micro‑refreshers and targeted, non‑leading queries where needed: they show how to write an entry, never which term to choose, and only the site changes its entry.

What good looks like

• One Master CCG + localized translations that are version‑linked and track changes together.
• CRFs display local language labels and controlled lists; numeric fields handle local decimal habits but store a single standard.
• Coders use the same dictionary versions and a short, accessible conventions note covering regional spelling/synonym traps.
• Evidence of training and early drift checks is filed (audit‑ready).

Worked examples

Example 1 — Cardiovascular (CV) trial across Spain & Germany

Goal: Comparable AE and lab data across Spanish and German sites.

Self‑contained context

• AE verbatims are captured in the site language and later coded to MedDRA.
• Fasting glucose is a key lab. Sponsor wants mmol/L as the canonical unit.
• The CCG provides “good vs poor” examples and unit guidance.

CCG excerpts given to sites

• Adverse Events (AE) — What to enter

  • Good: “Náuseas” (ES), “Übelkeit” (DE) — short, specific symptom.
  • Poor: “Se sintió mal” / “Fühlte sich schlecht” — too vague.
  • Avoid: a lab value as the AE term (“Glucosa 180”, with or without units): describe the finding in words (“Glucosa elevada”) and enter the value in the lab fields.
  • Don’t upgrade meaning: If the source says “ataque al corazón,” do not enter “infarto de miocardio” unless the diagnosis is confirmed in the source.

• Labs — Units and decimals

  • Enter glucose value as recorded on the lab report and select the unit from the list (mg/dL or mmol/L).
  • If your locale uses a decimal comma (e.g., “5,6”), enter it that way; the system will standardize on storage.
  • The database will convert mg/dL to mmol/L centrally using a versioned conversion rule documented in the CCG.

Outcomes

• AE verbatims like “Náuseas” and “Übelkeit” code to the same MedDRA Preferred Term Nausea.
• Mixed site entries of “5,6 mmol/L” and “101 mg/dL” are harmonized to mmol/L centrally (glucose: mg/dL ÷ 18, so 101 mg/dL ≈ 5.6 mmol/L, the same result), with the conversion method version‑controlled and the reported value and unit kept.

Example 2 — Concomitant medication naming across languages

Goal: Ensure “paracetamol” (EU) and “acetaminophen” (US) map to the same active ingredient in WHODrug.

Self‑contained context

• Sites must capture what’s on the label (brand/generic) in the local language.
• The coding tool uses WHODrug to standardize.

CCG excerpts given to sites

• If the medication label shows brand + strength, enter both (e.g., “Tylenol 500 mg” or “Dafalgan 500 mg”).
• If only the generic is known, that’s acceptable (e.g., “paracetamol”).
• Do not translate brand names; write them exactly as seen. The same brand name can contain different ingredients in different countries, so the coder uses the site’s country to pick the right product.

Outcomes

• “Paracetamol,” “Acetaminophen,” “Tylenol,” and “Dafalgan” are each coded to their own WHODrug entry (every name has its own drug code); all four have the same active ingredient (paracetamol), so use can be pooled at ingredient level.

Example 3 — Decimal separators & dates (operational traps)

Goal: Prevent numeric and date confusion across countries.

Self‑contained context

• Some countries write 3,5 mg; others write 3.5 mg.
• Date formats vary (DD‑MM‑YYYY vs MM‑DD‑YYYY).

Design choices & CCG snippets

• Numeric fields accept either separator but store a single normalized value; the CCG tells sites: “Enter the number as shown on source, without thousands separators; the system standardizes.” A comma or a point is always read as the decimal mark (“1,234” is stored as 1.234), and each locale is tested before go‑live.
• Date fields display the local format but store the date in ISO 8601 form (YYYY‑MM‑DD), so “03‑04‑2025” is never 3 April at one site and March 4 at another; the CCG tells sites to pick from a calendar control to avoid mis‑keying.

Outcomes

• No decimal‑separator confusion in listings; dates align for cross‑country visit windows and analyses.

Pitfalls & misconceptions

• “Any staff translation is fine.” No. Use officially translated CCGs tied to the master version. Ad‑hoc translations drift in meaning and won’t stand up to inspection.
• “Let each region choose its own dictionary version.” That breaks pooling. Freeze one version globally and document it.
• “Sites should upgrade what the source says to a diagnosis.” No. Sites capture verbatim; do not upgrade “heartburn” to “gastro‑oesophageal reflux disease” unless the source states that diagnosis.
• “Units can vary; analysts will figure it out later.” Without a documented conversion plan and storage standard, you’ll get errors and rework.

Practice in the wild (checklist)

• Master CCG written with field‑level do/don’t examples.
• Localized CCGs produced by qualified translators; back‑translated for high‑risk sections.
• Version linkage: master and all translations share the same version ID and change log.
• Dictionary parity: one MedDRA version; one WHODrug version; coder conventions published.
• CRFs localized (prompts, help, lists) with numeric/date normalization under the hood.
• Unit strategy chosen and documented (canonical unit or unit+value with versioned conversion).
• Site training completed pre–go‑live; acknowledgements filed.
• Early drift check run on first data cut; corrective coaching sent if needed.
• Trial master file (TMF) contains translation certificates, training rosters, and version evidence.

Key points to remember

• One master intent, many languages. Maintain a single Master CCG with official, version‑linked localized CCGs and a shared change log; use back‑translation on high‑risk sections. Include clear, field‑level do/don’t examples.
• Localize the CRF, not the meaning. Show prompts, help text, and controlled lists in the site language while the system normalizes numbers and dates on storage (decimal comma/point; local display, standardized save).
• Dictionary parity across countries. Freeze and communicate the same MedDRA and WHODrug versions globally for the study.
• Coder conventions are explicit and short. Publish concise rules that address regional spellings and synonyms and reinforce “do not change medical meaning.”
• Verbatim first, coding later. Sites record the term documented in the source (no “upgrading” to diagnoses, no translating of brand names); coders standardize downstream.
• Units strategy is deliberate and documented. Use one canonical unit where every source reports it; otherwise capture value + unit as on the source and convert centrally using versioned conversion rules, so sites do not have to convert by hand.
• Train before go‑live and reinforce early. Collect training acknowledgements; run early drift checks on first data cut and provide targeted refreshers where needed.
• Be audit‑ready. File translation certificates, CCG/translation version linkage, frozen dictionary versions, coder conventions, training rosters, and evidence of drift monitoring.