What we work on
- Instructions for use and user manuals
- Labelling, symbols and packaging text
- Technical documentation and design files
- Clinical evaluation reports and literature summaries
- Risk management documentation
- Software user interface strings and on-device text
- Training and service material
- Post-market surveillance and vigilance documentation
Why machine output is not sufficient here
Not because it is bad. Because being right is only half of what the regulation asks for.
An instruction for use is a safety control. A mistranslated warning, a dropped negation, a unit converted incorrectly or a contraindication softened into a recommendation is a patient safety issue before it is a documentation issue. These are precisely the failure modes of fluent machine output: the sentence reads correctly and says the wrong thing.
Traceability is part of the requirement. MDR and IVDR expect documentation that is accurate and traceable. A file that arrived from an engine with no record of who verified it, against which source version, at what date, is a gap in the technical file whether or not the language is correct.
Every EU official language is in scope for much device documentation, which means the weakest language in your set determines your exposure — not the average.
A generalist reviewer is not enough. The relevant standard for post-editing states directly that generalist post-editors are insufficient for safety-critical content. A reviewer who understands the device, the clinical context and the regulatory vocabulary catches things a linguistically excellent generalist does not.
What we deliver
- Review by reviewers matched to the device area, with documented training, qualifications and years in domain — records you can produce if asked. Two passes by two people. The linguist who post-edited the file is not the linguist who signs it off. A structured error report, categorised by type and severity against MQM, with critical findings called out separately from cosmetic ones. A version trail — source version, target version, reviewer, date, changes. Terminology held across the document family, so the IFU, the labelling and the technical file use the same words for the same things. In-country review support, where your local clinical or regulatory reviewers are part of the sign-off chain and that process needs managing and recording.
On confidentiality and infrastructure
Device documentation is commercially sensitive before launch and regulated after it. If your content cannot pass through public cloud infrastructure, say so at the start — it is a normal requirement in this sector and it changes how the job is set up, not whether we can do it.
Languages where this matters most
Japanese and Korean, for the Asian device markets and for content that is scrutinised closely by both regulators and clinicians. German, for the DACH market and for technical documentation where terminology discipline across large sets is the whole problem. Arabic, for Gulf market entry, where dialect and register decisions are made badly by default. And every EU official language where the requirement is coverage and the risk is the weakest one.