A Notified Body has come back with comments on translated UI strings during the technical documentation review for a Class IIa diagnostic imaging SaMD. An AI-enabled symptom-checker app needs AI Act technical documentation prepared across six EU languages alongside the MDR file. A digital health company has missed the MHRA International Reliance application window because the UK English release notes were out of sync with the EU release.
These situations share one cause. Medical software translation got scoped as either engineering work or regulatory work, when it is both at the same time. Medical software translation is the work of translating every regulated and user-facing software artefact a SaMD, SiMD, or companion patient app requires for the EU and UK markets, under Regulation (EU) 2017/745 (the MDR), Regulation (EU) 2017/746 (the IVDR), Regulation (EU) 2024/1689 (the EU AI Act), the UK Medical Devices Regulations 2002, and the MHRA Software and AI as a Medical Device Change Programme.
This guide is for the SaMD CTO, head of engineering, head of internationalisation, head of regulatory affairs, or head of quality at a digital health, MedTech, or AI medical device company shipping into the EU and the UK. It gives you the MDR Rule 11 classification matrix, the software artefact matrix, the EU AI Act timeline after the May 2026 Omnibus, the UK MHRA framework, the CI/CD integration angle, and a vendor evaluation checklist. For the deeper read on quality methodology, see the AdHoc cluster piece on medical translation quality assurance, and for an overview of how we structure medical translation work, see our service page.
TL;DR
|
What EU and UK medical software translation requires
Five regulatory frameworks shape medical software translation in 2026. The MDR (Regulation (EU) 2017/745) governs both Software as a Medical Device and Software in a Medical Device. The IVDR (Regulation (EU) 2017/746) handles in vitro diagnostic software through its own classification rules. The EU AI Act (Regulation (EU) 2024/1689) layers high-risk obligations on top of the MDR or IVDR for AI-enabled medical devices. The UK operates under the Medical Devices Regulations 2002, with the MHRA Software and AI as a Medical Device Change Programme driving an active reform agenda. Translation runs in parallel across all five frameworks: the official language(s) of every member state or jurisdiction where the software is made available, with software-specific artefacts inside that scope.
SaMD, SiMD, and companion apps: where the boundaries sit
Three software categories sit inside the medical translation scope. Software as a Medical Device (SaMD) covers standalone software that performs medical functions without being part of a hardware device, including diagnostic imaging algorithms, symptom checker apps, and clinical decision support systems. Software in a Medical Device (SiMD) sits embedded in hardware: the firmware running an infusion pump, the algorithm inside an ECG monitor, the operating software for a CT scanner. Companion apps are patient-facing mobile applications that may or may not meet the medical device definition, depending on intended purpose. MDCG 2019-11 (updated 2023) is the decision-tree document that determines whether a given piece of software qualifies as a medical device under the MDR. Buyers scoping translation work should ask their regulatory affairs team for the current Rule 11 classification before commissioning anything.
The IVDR boundary
In vitro diagnostic software falls under the IVDR rather than the MDR. The translation principle is the same: Article 18(1) of the IVDR mirrors MDR Article 10(11) on language scope. The conformity assessment pathway differs, with classification rules specific to IVDs and language requirements that follow each member state’s IVDR implementation. For MedTech manufacturers building diagnostic algorithms, especially companion diagnostics for AI imaging, the IVDR pathway runs alongside the MDR pathway as a separate workstream with its own language matrix and its own audit trail.
MDR Rule 11: how software gets classified and what it means for translation scope
Annex VIII Rule 11 of the MDR is the software-specific classification rule. Most software that was Class I under the old Medical Device Directive is now Class IIa or higher under the MDR. Class determines Notified Body involvement, the conformity assessment route, and the audit trail required around translation work. Rule 11 reads against the consequence of an information error: where the software provides information for diagnostic or therapeutic decisions, the class scales with the severity of harm if that information is wrong.
| Software function | Rule 11 class | Notified Body involvement | Translation scope implication |
|---|---|---|---|
| Information for diagnostic or therapeutic decisions where error risks death or irreversible harm | Class III | Full NB conformity assessment with scrutiny | Full Annex I §23; SSCP per member state; in-country review mandatory |
| Information for diagnostic or therapeutic decisions where error risks serious deterioration or surgical intervention | Class IIb | Full NB conformity assessment | Full Annex I §23; technical documentation extracts on request |
| Information for diagnostic or therapeutic decisions (other) | Class IIa | Full NB conformity assessment | Full Annex I §23; declaration of conformity in member-state language |
| Software monitoring physiological processes where variation could cause immediate danger | Class IIb | Full NB conformity assessment | Full Annex I §23; vigilance reporting per member state |
| Software monitoring physiological processes (other) | Class IIa | Full NB conformity assessment | Full Annex I §23 |
| All other software (default) | Class I | Self-declared | Annex I §23 still applies; translation often under-resourced |
The Class I to Class IIa migration and what it costs in translation work
Class I under the MDD becomes Class IIa, IIb, or III under the MDR for most diagnostic and therapeutic software. The translation consequence is concrete: Notified Body involvement, technical documentation review during conformity assessment, and language scope that follows full Annex I Section 23 obligations. For a digital health company that built its product portfolio under the old MDD, the migration carries real cost that has to be planned into the MDR transition timeline. The often-missed cost: in-country reviewer time for translated UI strings during the Notified Body audit, where the reviewer is checking each translated string against the original intent and the technical documentation. MDCG 2024-7 (Q&A on Rule 11 classification) is the freshest operational guidance and worth reading before scoping any new SaMD translation programme.
Which software artefacts need translation
Medical software translation covers more than UI strings. The full artefact matrix splits into four streams: user-facing software content (UI, in-app text, onboarding flows, release notes), accompanying information that satisfies the MDR (electronic IFU, in-app help linked from the device, EULAs), regulatory technical documentation (IEC 62304 software lifecycle artefacts, cybersecurity documentation, AI Act technical documentation), and post-market materials (release notes, security advisories, field safety notices for software). Each stream has its own translation cadence and its own audit-trail requirement.
| Artefact | Primary reader | Regulatory function | Translation specifics |
|---|---|---|---|
| UI strings (menus, buttons, dialogs) | Users | UX; usability under IEC 62366-1 | String-length, pluralisation, accessibility |
| Error messages | Users, clinicians | User safety | Concise, plain language, consistent terminology |
| In-app help | Users | Accompanying information (Annex I §23) | Context-bound, in-layout review |
| Onboarding flows | Users | First-use orientation | Short copy, screen-by-screen |
| Release notes | Users, clinicians | Post-market communication | Version-controlled, cadence-driven |
| Electronic IFU (eIFU) | Users, clinicians | Annex I §23 | Full IFU translation, regulator-grade |
| EULA and privacy policy | Users | Legal | Accurate, jurisdiction-aware |
| Accessibility strings (screen reader, alt text) | Assistive technology users | Accessibility compliance | Distinct workstream, often missed |
| IEC 62304 software lifecycle docs | Notified Body | Conformity assessment | Submitted in NB working language (often English) |
| IEC 62366-1 usability engineering file | Notified Body | Usability validation | Supports translated UI sign-off |
| Cybersecurity documentation | NB; competent authorities | MDR Annex I; MDCG 2019-16 | Extracts may be requested in local language |
| AI Act technical documentation | AI Act conformity body | AI Act Articles 11–15 | Language follows AI Act practice |
| AI Act Article 50 transparency notice | Users | Disclosure of AI interaction | Per-language; user-facing |
| Field safety notices (software) | Users; competent authorities | Article 89(8) | Per member state |
UI strings and the constraints translation has to handle
User interface translation carries software-specific constraints that hardware-device IFU translation does not. String length varies sharply between languages: German averages around 30 percent longer than English, Chinese around 40 percent shorter, so a button label that fits in English may overflow or look stranded in target languages. ICU MessageFormat handles pluralisation, gender forms, and variable insertion across major locales. Accessibility strings for screen readers, alt text, and ARIA labels form a distinct workstream most LSPs overlook, and one that fails the accessibility audit when missed. For any locale using bidirectional text (Arabic, Hebrew), layout flipping and embedded directional markers add a further engineering hand-off. Unicode UTF-8 is the baseline encoding. In-context review through SmartEdit lets the translator see each string in the UI as the user will, which feeds the IEC 62366-1 usability engineering file directly.
The software and MDR boundary
Hardware-device IFU, label, packaging, and implant card translation sit under the cluster piece on MDR translation requirements. The pharma equivalent of eIFU – the patient leaflet (PIL) and the summary of product characteristics (SmPC) under the post-approval marketing authorisation regime – sits in its own regulatory framework and is covered in package leaflet translation.
Software-specific artefacts are the subject of this piece. Buyers sourcing both should pick a single LSP that handles both with one process, one termbase, and one audit trail. Two suppliers create terminology drift and audit-trail gaps that surface at the next Notified Body inspection.
The EU AI Act after the May 2026 Omnibus
The EU AI Act (Regulation (EU) 2024/1689) classifies AI-enabled medical devices as high-risk AI systems under Article 6(1). The Digital Omnibus political agreement reached by Council and Parliament on 7 May 2026 (one week before this article publishes) extended the high-risk compliance deadlines. For SaMD with AI or ML components, this is the most consequential regulatory change of 2026 for translation work. Three obligation streams carry translation implications: AI Act technical documentation under Articles 11 to 15, transparency to users under Article 50, and AI literacy under Article 4.
| Date | What applies | Translation implication |
|---|---|---|
| 1 August 2024 | AI Act enters into force | None directly |
| 2 February 2025 | Prohibited AI practices and AI literacy obligations apply | Internal policy translation; staff training content |
| 2 August 2025 | GPAI model obligations apply | Foundation model documentation if used |
| 2 August 2026 | AI literacy obligation (Article 4) applies | Staff training, user-facing AI literacy notices per member state |
| 2 December 2026 | Transparency for AI-generated content (Article 50) | User-facing AI interaction disclosure per member state |
| 2 December 2027* | Standalone high-risk AI under Annex III (post-Omnibus extension) | Full conformity assessment documentation in submission languages |
| 2 August 2028* | High-risk AI embedded in regulated products under Annex I (post-Omnibus extension; covers most medical AI) | Full AI Act technical documentation alongside MDR documentation |
*Subject to formal adoption of the Digital Omnibus political agreement reached 7 May 2026. Original deadlines were 2 August 2026 (Annex III) and 2 August 2027 (Annex I).
What high-risk AI medical devices have to translate
High-risk AI medical devices carry an AI Act documentation set that runs alongside the MDR technical file. The documentation set covers training data governance, data quality and bias assessment, transparency to users, human oversight design, accuracy and robustness specifications, post-market monitoring plans, and an EU database registration entry. Most of this goes to the Notified Body in English as the body’s working language. Two pieces flow to users in per-member-state language: the Article 50 transparency notice that the user is interacting with an AI system, and any AI-specific additions to the instructions for use. The AI literacy obligation under Article 4, still applying from 2 August 2026 even after the Omnibus, requires AI literacy training content for staff who deploy AI systems, often in the target market’s language.
The dual-compliance reality with MDR
AI-enabled SaMD requires MDR conformity assessment AND AI Act conformity assessment in the same programme. The European Commission’s position, confirmed by the May 2026 Omnibus political agreement, is that the two assessments integrate where a single Notified Body covers both: one CE marking, one Declaration of Conformity, one technical file with MDR and AI Act sections. The translation implication: a single coherent technical file across both regulatory regimes, with audit trail and version control spanning both. An LSP that handles MDR but cannot show AI Act fluency will create an audit gap as soon as the AI sections enter scope. SmartDesk carries that combined audit trail.
The UK MHRA framework in 2026
UK medical software operates under the Medical Devices Regulations 2002 (amended), administered by the MHRA. The MHRA Software and AI as a Medical Device Change Programme has been running since October 2022 and continues to evolve through 2026. Three developments shape SaMD translation work in May 2026: the new post-market surveillance regulations in force since June 2025, the International Reliance scheme that opened in H1 2026, and the National Commission into the Regulation of AI in Healthcare due to report its recommendations later in the year. CE recognition in Great Britain has been extended indefinitely under the 22 July 2025 reform, simplifying the dual-market technical file for multinational SaMD companies.
The International Reliance scheme
The MHRA International Reliance scheme allows SaMD that holds FDA, Health Canada, or TGA clearance to take a streamlined route to UK market access. For a digital health company with an FDA 510(k) or De Novo clearance, the UK timeline shrinks meaningfully. The translation implication is operational rather than regulatory: the dossier maps the foreign clinical-performance, cybersecurity, and risk-management documentation to the British Medical Devices Regulations 2002. Most regulatory documentation stays in English, but the UK release notes, user-facing release communications, and post-market materials remain UK English specifically. Style and convention differences between US English, Australian English, and UK English are large enough to warrant a separate locale in the translation memory.
CE recognition in Great Britain and dual-market simplification
Since the 22 July 2025 reform, CE-marked devices remain valid for the UK market indefinitely. The previous sunset clauses of 30 June 2028 and 30 June 2030 have been removed pending consultation. Multinational SaMD companies maintain a single EU technical file for both markets, with a UK English locale layered on top for user-facing content. The translation implication: one EU artefact set with a UK English variant for user-facing content, instead of two parallel artefact sets. This was a meaningful operational simplification when it landed in July 2025 and continues to be the working assumption for most SaMD companies running UK and EU programmes in parallel.
CI/CD integration and continuous localisation
SaMD ships continuously. Patient-facing companion apps ship weekly, sometimes more often. The translation workflow has to integrate with the software development workflow through API or connector, not run alongside as a separate blocking process. This is the engineering-led half of medical software translation, and the half that most LSPs fail. SmartConnect is AdHoc’s primary technology anchor for this integration.
Repository integration
SmartConnect provides API or webhook integration with the source repository (GitHub, GitLab, Bitbucket) so that string changes flow through the translation pipeline without manual handoff. The connector watches for commits to designated resource files (JSON, YAML, .properties, .strings, .xliff), extracts changed strings, routes them through the translation memory and the human linguist, and returns translated strings to a feature branch or pull request for engineering review. The audit trail of who translated which version of which string, when, against which termbase is captured in SmartDesk for MDR Notified Body audit and AI Act technical documentation. For an engineering team running weekly release cadences, the alternative is a manual export-translate-import cycle that blocks releases and creates terminology drift between releases.
In-context review and the IEC 62366-1 handoff
Software translation that does not pass through in-context review fails usability validation under IEC 62366-1. The translator has to see the string in the UI as the user will, with surrounding context, layout, and visual elements visible. SmartEdit provides in-context review for in-country reviewers without needing an InDesign or front-end-tooling licence. The reviewer can adjust string length, fix layout issues, and confirm the translation reads naturally in the rendered UI. The output feeds directly into the IEC 62366-1 usability engineering file as part of the technical documentation submitted to the Notified Body. Without this step, the translated UI is unvalidated as part of the user interface, which is a conformity gap during MDR review.
Medical software translation vendor evaluation checklist
A medical-software-ready translation supplier combines medical regulatory fluency (MDR Rule 11, EU AI Act, MHRA Software Group) with software engineering integration capability (API, CI/CD, ICU MessageFormat, in-context review). Most LSPs have one or the other, and few have both. The checklist below tests for both at the depth a SaMD programme demands.
| Criterion | Why it matters for medical software work | What to ask in the RFP |
|---|---|---|
| ISO 17100 | Process foundation for human translation | Please attach your current ISO 17100 certificate and certification body. |
| ISO 18587 | Required when MTPE is used on UI strings or in-app text | Do you hold ISO 18587 for any post-edited MT workflows? Please attach the certificate. |
| ISO 27001 | Information security for regulated software content | Please confirm ISO 27001 certification and attach evidence. |
| MDR Rule 11 fluency | Class determines translation scope and audit trail | Describe how your QMS reflects MDR Rule 11 and MDCG 2024-7. What evidence can you provide of recent SaMD submissions? |
| EU AI Act awareness | High-risk AI medical devices need AI Act technical documentation | Describe how you handle AI Act Articles 11 to 15 technical documentation and Article 50 transparency notices. |
| MHRA Software Group framework | UK pathway uses MHRA, not EMA or NB | Walk us through how you handle UK SaMD work, including UK English as a separate locale and International Reliance dossier alignment. |
| Software repository integration | Continuous shipping rules out manual handoff | Which repositories do you connect to (GitHub, GitLab, Bitbucket)? Walk us through a typical commit-to-release flow. |
| CI/CD pipeline integration | Translation must not block release | How does your platform integrate with Jenkins, GitHub Actions, GitLab CI, or CircleCI? |
| ICU MessageFormat support | Pluralisation, gender, variable insertion across locales | Confirm full ICU MessageFormat support and describe how pluralisation rules are handled across your linguist team. |
| In-context review tooling | Required for IEC 62366-1 usability validation | Can in-country reviewers see and edit translated strings in the rendered UI without needing engineering tools? |
| Accessibility strings | Screen reader text, alt text, ARIA labels are a distinct workstream | How do you handle accessibility strings, and how do you test that they read correctly in target languages? |
| Per-project audit trail | MDR Notified Body and AI Act conformity body both expect it | What per-project audit records do you produce, and for how long do you retain them? |
AdHoc holds current ISO 17100 and ISO 18587 certifications, with the certificates hosted on the AdHoc site for direct verification. SmartConnect provides the repository and CI/CD integration the engineering side of medical software translation demands. SmartDesk carries the per-project audit trail that MDR Notified Body review and AI Act technical documentation expect. SmartEdit supports in-context review without an engineering-tool licence.
For the deeper read on the QA stack across all medical translation work, see medical translation quality assurance. HCP-facing companion software briefs, e-detailing tools, and digital sales aids sit under the EFPIA Code, the ABPI Code 2024, and the MedTech Europe Code rather than under MDR Rule 11 or the EU AI Act, and are covered in HCP content translation.
Frequently asked questions
What is Software as a Medical Device (SaMD)?
Software as a Medical Device, defined by the International Medical Device Regulators Forum, is software intended for one or more medical purposes that performs those purposes without being part of a hardware medical device. Examples include diagnostic imaging algorithms, symptom-checker apps, and clinical decision support systems. SaMD sits under Regulation (EU) 2017/745 (the MDR) in the EU.
Does the EU AI Act apply to medical software?
Yes, where the software contains AI or machine learning components. AI-enabled medical devices regulated under the MDR or IVDR are automatically classified as high-risk under Article 6(1) of the AI Act. Following the Digital Omnibus political agreement on 7 May 2026, the high-risk compliance deadline for embedded medical AI under Annex I has been extended to 2 August 2028, subject to formal adoption.
What is MDR Rule 11?
Annex VIII Rule 11 of Regulation (EU) 2017/745 is the software-specific classification rule under the MDR. It classifies most Software as a Medical Device as Class IIa or higher, depending on the consequences of an information error. Decisions involving death or irreversible harm push the software to Class III. Decisions involving serious deterioration push to Class IIb. Most diagnostic and therapeutic information software is Class IIa.
How is medical software translation different from regular software localisation?
Medical software translation must satisfy regulatory requirements that govern hardware medical devices: MDR Article 10(11) language obligations, Annex I Section 23 accompanying information, IEC 62304 software lifecycle documentation, IEC 62366-1 usability validation, and (for AI components) AI Act technical documentation. Regular software localisation has none of these obligations. The translation supplier must understand both regulation and software engineering integration.
Connect your systems with SmartConnect
If your current translation supplier cannot integrate with your software repository, your CI/CD pipeline, and your Notified Body audit-trail requirements with one process, a structured supplier review is the next step. Connect your systems with SmartConnect to see how AdHoc handles medical software translation for SaMD, SiMD, and companion app companies across the EU and the UK.
Sources
- EUR-Lex, Regulation (EU) 2017/745 (MDR), Annex VIII Rule 11. https://eur-lex.europa.eu/eli/reg/2017/745/oj. Accessed 14 May 2026.
- EUR-Lex, Regulation (EU) 2017/746 (IVDR). https://eur-lex.europa.eu/eli/reg/2017/746/oj
- EUR-Lex, Regulation (EU) 2024/1689 (the EU AI Act). https://eur-lex.europa.eu/eli/reg/2024/1689/oj
- Council of the EU, AI Act Digital Omnibus political agreement, 7 May 2026 (subject to formal adoption). https://www.consilium.europa.eu/en/press/press-releases/2026/05/07/artificial-intelligence-council-and-parliament-agree-to-simplify-and-streamline-rules/
- MDCG 2019-11, Guidance on qualification and classification of software (updated 2023).
- MDCG 2020-1, Clinical evaluation of medical device software.
- MDCG 2024-7, Q&A on Rule 11 classification.
- MDCG 2019-16, Cybersecurity for medical devices.
- GOV.UK, Software and Artificial Intelligence as a Medical Device (MHRA Software Group). https://www.gov.uk/government/publications/software-and-artificial-intelligence-ai-as-a-medical-device
- MHRA Software and AI as a Medical Device Change Programme Roadmap (October 2022, revised December 2024).
- MHRA International Reliance scheme (announced 22 July 2025; opens H1 2026).
- GOV.UK, National Commission into the Regulation of AI in Healthcare (call for evidence 18 December 2025 to 2 February 2026; recommendations due 2026).
- IEC 62304, IEC 82304-1, IEC 62366-1, ISO 14971, ISO 13485.
- ISO 17100:2015 and ISO 18587:2017.