How to Build a Scalable MDR/IVDR Translation Program

Medical device teams usually feel MDR/IVDR pressure in a very practical moment. An SSCP is moving forward. The IFU already exists. The CER contains overlapping clinical language. Product specs hold related device details.

Then someone has to make sure the same information stays accurate across every document and every required language. That’s where MDR/IVDR translation becomes an operational problem, not just a language task.

To discuss these challenges and more, we brought together expert perspectives in our webinar, “MDR/IVDR Reality Check: Managing Multilingual Content at Scale.” The conversation was moderated by Manchandan Sandhu, Senior Vice President and General Manager, Life Sciences at Acolad, and featured Terri Kurtz, Senior Principal in Regulatory Affairs at BD, sharing direct experience from large-scale SSCP and MDR work, alongside Erin Helton, Strategic Account Manager, Life Sciences at Acolad. Together, they explored how translation memory, workflow structure, and review planning shape multilingual MDR/IVDR programs in practice.

The Short Version

Medical device teams feel MDR/IVDR pressure when the same clinical and technical content appears across SSCPs, IFUs, CERs, and other documents, then has to stay consistent in many languages. The webinar’s clearest answer was this: scalable MDR/IVDR translation starts upstream, with structured source writing, defined ownership, controlled reuse, and review steps built for change.

When Documents Connect, Small Differences Become Big Problems

Handling a small number of simple documents can be handled by most teams.

Trouble starts when the same intended purpose, clinical wording, or device description appears in five places, written by different people, at different times, for different audiences. A small wording change in one file can create review issues in another. Once translation begins, those differences spread fast.

Furthermore, when several teams contribute to the same body of regulated content, consistency stops being an editorial preference. It becomes part of compliance control.

“The fact that everything is now more connected - What you write in one document shows up in another, and then that needs to be consistent across multiple languages. And that’s where things get challenging.”

Manchandan Sandhu

Terri Kurtz gave a useful example from BD’s SSCP work. The SSCP was new, clinically demanding, and larger than many teams were used to managing under the older framework. At the same time, the content was closely tied to IFUs, product specifications, CERs, and other technical documentation. Different regulatory writers produced slightly different versions of the same ideas, and the result lacked cohesion.

If you’re running a multilingual MDR/IVDR program, that situation probably feels familiar. The real risk often starts before translation. It starts when connected documents are drafted as if each one stands alone.

Write Source Content With the Next Document in Mind

Teams usually begin by trying to finish the immediate document in front of them. That’s understandable. Deadlines are tight, reviews are moving, and each function is trying to close its own work. The problem is that under MDR and IVDR, content rarely stays where it was first written.

A more durable model is to decide where each recurring statement should live first, then reuse it deliberately. Terri Kurtz explained that the MDCG 2019-9 template gave BD a structure for the SSCP, but the harder task was identifying the right source for each section so the same information could stay consistent across documents.

“The better you define your source material, the better you can then move it over. If we were writing our technical documentation or our CER with the SSCP in mind, then it becomes systematic, so you know what to expect, people know where to find the information, and it’s not so much writing as moving content over.”

Terri Kurtz

That thinking changed who drafted what. Because so much of the SSCP content came from the CER, BD moved more drafting responsibility to the medical side. Kurtz said the CER and the SSCP were then written in tandem, with the future SSCP already in mind while source documents were being written.

That shift is easy to describe and harder to implement. It usually means choosing which document owns the original language for repeated claims, agreeing which team controls reusable sections, and resisting the urge to rewrite the same idea slightly differently in each file.

For readers in Regulatory Affairs or Medical Affairs, this is where multilingual efficiency often begins. It begins long before the first file is sent for translation.

Translation Memory Works Best When Teams Stop Reinventing Approved Language

Translation memory is a database of previously translated, approved content that can be reused instead of translated again. In practical MDR/IVDR work, that matters because the same language appears again and again across IFUs, SSCPs, and related documentation.

What makes translation memory valuable is not the tool itself. It’s the writing behavior behind it. When teams keep rewriting the same intended purpose, safety wording, or clinical summary in slightly different ways, they lose reuse. When they standardize approved language early, reuse grows and review becomes easier because the wording is already familiar.

“What we typically saw early on was that the content was created without reuse in mind. It was written in isolation, focused on the immediate document rather than how that content might be reused later. But as this process matured, there was a shift toward writing with reuse in mind, from the very beginning.”

Erin Helton

That change was a major turning point in the BD example. Terri Kurtz said the team initially did not even think about translation memory while writing. Once they understood how it worked, they went back and started writing specifications, IFUs, and CER content so it could be lifted directly into the SSCP.

Erin Helton connected that discipline to measurable impact. In the BD program, she said translation memory reuse drove about 30% savings in 2024, or about $2 million in cost savings, and that a recent SSCP saw 50% translation memory leverage. Those figures belong to one program, not every manufacturer, but they show what becomes possible when approved language is reused on purpose.

There’s also a less obvious benefit here. Reuse helps with maintenance. Kurtz said BD began setting up SSCPs so most of the content could stay static from year to year, while changed numbers or added paragraphs could be updated without rewriting the full document.

One Owner Keeps the Multilingual Process From Drifting

In many regulated programs, language work sits between functions. Regulatory owns one part. Medical owns another. Procurement may manage suppliers. Localization may sit elsewhere. That structure works until timelines tighten. Then gaps appear fast.

The BD example showed the value of one coordinating owner. Terri Kurtz said Regulatory Affairs owned the technical documentation and the SSCP, coordinated translation, and reviewed the content before it went out. That kind of ownership matters because somebody has to see the whole process, not just one step in it.

“We do have Regulatory Affairs owning the technical documentation and the SSCP. So Regulatory Affairs does all of the translation coordination for the SSCP and reviews the content before it goes for translation.”

Terri Kurtz

Language planning also needs to happen earlier than many teams expect. Kurtz said BD reviews the countries it plans to market in and maps what needs to be translated for each market. That is not a one-time exercise. National expectations change. Some countries may require patient-facing information in translation while healthcare professional content can remain in English.

Then comes verification. BD still checks returned files against practical elements such as figures, paragraphs, bullets, and a localization guide. Erin Helton added another useful detail in the webinar discussion: shared rules for things like addresses and units of measure reduce ambiguity and cut back on late questions. These are small decisions on the surface. In multilingual regulated workflows, they prevent avoidable back-and-forth.

The Strongest Programs Are Built for the Next Update, Not Just the Next Submission

The teams that make progress here are usually the ones that stop treating multilingual work as a final production step. They start seeing it as part of how regulated content is designed, reviewed, and maintained.

That idea came through strongly in the closing advice from the speakers. Erin Helton said the work becomes more effective when it is treated as a shared responsibility instead of a downstream task. Terri Kurtz advised teams to write for translation, involve the translation partner early, and bring Medical Affairs and Regulatory Affairs into the same efficiency conversation.

“Once the team started to see how small changes impacted the downstream workflows, the shift happened pretty quickly. It became very clear that we’re not just improving translation, but we’re reducing rework and simplifying reviews, which made the entire process more efficient.”

Erin Helton

BD is still working through desktop publishing and paper IFUs, but Kurtz said the team is looking for more dynamic ways to respond as labels, IFUs, and other content evolve. That feels like the right sequence. First control source content, reuse, and workflow. Then look at broader content system changes.

Key Takeaways

MDR/IVDR translation gets harder when connected documents are drafted separately and repeated language starts to drift before translation begins.
Translation memory delivers the most value when approved wording is reused on purpose across IFUs, CERs, SSCPs, and technical files.
Near-final content can move into translation before every review is closed, as long as the workflow isolates and updates only changed text.
One coordinating owner, early market-by-market language planning, and practical verification steps keep multilingual programs from slowing down.
The most scalable MDR/IVDR programs are built for repeat updates, not just one submission cycle.