Building a Localization Pipeline for IVDR-Compliant Medical Device Documentation

If you work on software or tooling for medical device manufacturers, you've probably run into IVDR (Regulation (EU) 2017/746) somewhere in a requirements doc. It's the regulation governing in vitro diagnostic devices in the EU, and it has a language requirement that's easy to underestimate until you're the one building the system that has to manage it: every Member State can require its own official language for labels, instructions for use (IFU), and technical documentation.

The M21Global article on IVDR translation requirements covers the regulatory side well: risk classes, terminology pitfalls, which documents need what. This post is about the other half of the problem, the one that lands on engineering and content ops teams: how do you actually manage dozens of language variants of regulated content without losing your mind, and without shipping a mistranslated cut-off value to a hospital lab?

Why this isn't a normal i18n problem

Standard localization workflows assume you can be a little loose. Marketing copy, UI strings, onboarding flows — if a translation is 90% right, you ship it and fix it later based on user feedback.

Regulated medical content doesn't work that way. A few things make IVDR content structurally different from typical i18n:

• Zero tolerance for drift. "Analytical sensitivity" and "clinical sensitivity" are different concepts with different regulatory meanings. A fuzzy-matched translation memory suggestion that's "close enough" is a compliance bug, not a UX nit.
• Cross-document consistency is enforced externally. Notified bodies compare terminology across the IFU, the label, and the Summary of Safety and Performance (SSP). If your pipeline generates these from different sources, or if translators work on them independently, you will get inconsistencies that trigger clarification requests.
• Versioning has legal weight. A post-approval change from a notified body can require re-translation of a specific section, not the whole document. Your system needs to track which paragraph, in which language, corresponds to which approved version of the source.
• No graceful degradation. There's no "beta translation" tier for a calibration instruction.

If you're designing or picking tooling for this, treat it closer to a compliance/audit system than a content management system.

A practical architecture

Here's a structure that works reasonably well for teams managing multilingual regulated documentation at scale.

1. Single source of truth, structured, not a Word doc

Store the technical file content (IFU sections, label fields, SSP sections) as structured data, not flat documents. XML (following something like DITA) or a headless CMS with strict content models works well:

<ifu-section id="cutoff-value" device="glucose-test-v3" version="1.4">
  <term ref="glossary:cutoff-value">Cut-off value</term>
  <content>Results above 126 mg/dL are considered positive...</content>
</ifu-section>

This lets you diff versions at the section level, which matters when a notified body approves a change to one paragraph and you need to know exactly what needs re-translation.

2. A locked, versioned terminology glossary

Build the glossary before translation starts, and treat it like an API contract. Store it as structured data (TBX format is the industry standard for termbases) so it can be validated programmatically:

{
  "term": "cut-off value",
  "domain": "IVD-analytical",
  "translations": {
    "pt-PT": "valor de corte",
    "es-ES": "valor de corte",
    "fr-FR": "valeur seuil",
    "de-DE": "Grenzwert"
  },
  "forbidden_synonyms": ["threshold", "limit value"],
  "regulatory_note": "Must match wording in SSP and label for same device."
}

You can write a simple linter that scans translated content and flags any use of a forbidden synonym or any term missing from the glossary. This catches the kind of terminology drift that's invisible to a human reviewer skimming a 40-page IFU but very visible to a notified body auditor.

3. Translation memory scoped per device family, not per project

Most TMS tools (memoQ, Trados, Phrase, Lokalise) let you segment translation memory by project. For regulated content, scope it by device family instead, so the IFU, label, and SSP for the same device all draw from the same memory. This is the single highest-leverage thing you can do to reduce cross-document inconsistency.

4. A review gate that mirrors ISO 17100

Whatever workflow tool you use, encode a mandatory second-linguist review step before content moves to "ready for notified body submission." If you're building this in-house, a simple state machine works:

draft -> translated -> reviewed_by_second_linguist -> qa_passed -> approved

Don't allow shortcuts around reviewed_by_second_linguist for Class C/D devices. This maps to the audited workflow described in ISO 17100, and it's the kind of thing auditors will ask about directly.

5. Traceability from source term to final rendered document

When a notified body flags an issue, you need to answer "where did this term come from, who translated it, when, and against which glossary version" in minutes, not days. Log:

• source segment ID and version
• glossary version used at translation time
• translator and reviewer IDs
• timestamp of each state transition

This is boring infrastructure work, but it's the difference between a one-day fix and a multi-week re-audit when something goes wrong.

Tooling notes

A few things worth knowing if you're picking tools for this:

• CAT tools with strict termbase enforcement (memoQ, Trados Studio) can hard-block segments that don't match an approved term, which is more useful here than soft suggestions.
• API-driven TMS platforms (Phrase, Lokalise, Crowdin) work fine for the workflow orchestration layer, but you'll likely need a custom linting step for regulatory terminology since general-purpose i18n tools aren't built with IVDR-specific rules in mind.
• Machine translation has a role in first-pass drafts for lower-risk content (internal notes, non-clinical marketing material about the device), but for Class C/D IFUs and SSPs, treat MT output as untrusted input requiring full human translation and review, not post-editing.

The takeaway

The regulatory requirements are the easy part to understand. The hard part is building a pipeline where terminology consistency, versioning, and reviewer sign-off are enforced by the system, not by hoping someone remembers to check the glossary. If you're scoping this kind of project, read the source article on IVDR translation requirements first to understand what documents and terms are actually in scope, then build the pipeline around those constraints rather than retrofitting a generic localization workflow later.