Medicinsk programvara utvecklas och uppdateras kontinuerligt. Översättningsprocessen måste kunna hålla samma takt utan att äventyra regelefterlevnaden. Där läkemedel och kliniska prövningar präglas av långa ansöknings- och godkännandeprocesser, utvecklas Software as a Medical Device (SaMD) i miljöer som bygger på kontinuerlig integration och kontinuerlig driftsättning (CI/CD). Där regulatoriska frågor ansvarar för ansökningsdokumentationen, så ansvarar utvecklingsteamet för kodbasen. Anmälda organ enligt MDR, organ för bedömning av överensstämmelse enligt AI-förordningen och MHRA:s programvaruspecialister förväntar sig alla en tydlig och spårbar dokumentation. Samtidigt måste den fungera i utvecklingscykler och sprintar som regelverken aldrig utformades för att hantera.
Fem ramverk reglerar denna överlappning år 2026:
- Förordning (EU) nr 2017/745 (MDR)
- Förordning (EU) nr 2017/746 (IVDR)
- Förordning (EU) nr 2024/1689 (EU:s AI-lag)
- The UK Medical Devices Regulations 2002
- MHRA:s Software and AI as a Medical Device Change Programme
Översättningen sker för alla fem samtidigt, oavsett vilken utgivningsfrekvens som utvecklingsteamet faktiskt följer.
Denna guide samlar alla dessa delar på ett ställe:
- Klassificeringsmatrisen enligt regel 11 i MDR
- Matrisen över programvaruprodukter
- Tidslinje för AI-förordningen efter Omnibus-överenskommelsen i maj 2026
- Det brittiska MHRA-ramverket
- Perspektivet på CI/CD-integration
- En checklista för leverantörsutvärdering
Om du är teknisk chef, chef för internationalisering, chef för regulatoriska frågor eller kvalitetschef på ett företag inom digital hälsa, medicinteknik eller medicintekniska produkter med AI-teknik som levererar till EU och Storbritannien, hittar du mer ingående information om kvalitetsmetodik i vår artikel om kvalitetssäkring av medicinska översättningar. För en översikt över hur vi strukturerar vårt arbete med medicinsk översättning, se vår sida om medicinska översättningstjänster.
I korthet
|
Vad som krävs för översättning av medicinsk programvara inom EU och Storbritannien
Fem regelverk präglar översättningen av medicinsk programvara år 2026:
- MDR (förordning (EU) 2017/745), som reglerar både programvara som medicinteknisk produkt och programvara i en medicinteknisk produkt.
- IVDR (förordning (EU) 2017/746), som reglerar programvara för in vitro-diagnostik genom egna klassificeringsregler.
- EU:s AI-lag (förordning (EU) 2024/1689), som lägger till krav för högriskprodukter utöver MDR eller IVDR för AI-baserade medicintekniska produkter.
- UK Medical Devices Regulations 2002, som reglerar programvara i Storbritannien.
- MHRA:s program för förändring av programvara och AI som medicintekniska produkter, som samtidigt driver en aktiv reformagenda.
Översättningen sker parallellt för samtliga fem områden och omfattar de officiella språk som krävs i varje medlemsstat eller jurisdiktion där programvaran tillhandahålls. I detta ingår även de programspecifika artefakter som hör till produkten.
SaMD, SiMD och tillhörande appar: var går gränserna?
Inom området medicinsk översättning finns tre programvarukategorier:
- Programvara som medicinteknisk produkt (SaMD): fristående programvara som utför medicinska funktioner utan att ingå i en hårdvaruenhet, till exempel algoritmer för diagnostisk bildbehandling, appar för symptomkontroll och system för kliniskt beslutsstöd.
- Programvara i medicintekniska produkter (SiMD): programvara som är inbyggd i hårdvara, till exempel den inbyggda programvaran i en infusionspump, algoritmen i en EKG-monitor eller driftsprogramvaran för en datortomograf.
- Kompletterande appar: mobilappar avsedda för patienter som, beroende på det avsedda användningsområdet, kan omfattas av definitionen av medicinteknisk produkt eller inte.
MDCG 2019-11 (uppdaterad 2023) är det beslutsträd som avgör om en viss programvara ska betraktas som en medicinteknisk produkt enligt MDR. Inköpare som planerar översättningsarbete bör be sitt team för regel- och myndighetsfrågor om den aktuella klassificeringen enligt regel 11 innan de beställer något.
IVDR:s tillämpningsområde
Programvara för in vitro-diagnostik omfattas av IVDR snarare än MDR. Översättningsprincipen är densamma: artikel 18.1 i IVDR motsvarar artikel 10.11 i MDR vad gäller språktäckning. Däremot skiljer sig förfarandet för bedömning av överensstämmelse, med klassificeringsregler som är specifika för IVD-produkter och språkkrav som följer varje medlemsstats genomförande av IVDR.
För medicintekniska tillverkare som utvecklar diagnostiska algoritmer, särskilt kompletterande diagnostik för AI-bildbehandling, löper IVDR-processen parallellt med MDR-processen som en separat arbetsström med egen språkmatris och eget revisionsspår.
MDR-regel 11: Hur programvara klassificeras och vad det innebär för översättningens omfattning
Regel 11 i bilaga VIII till MDR är den klassificeringsregel som specifikt gäller programvara. Merparten av den programvara som klassificerades som klass I enligt det tidigare direktivet om medicintekniska produkter (MDD) klassificeras nu som klass IIa eller högre enligt MDR. Klassificeringen avgör om ett anmält organ måste involveras, vilken väg för bedömning av överensstämmelse som ska följas, och vilka krav på spårbarhet och dokumentation som gäller för översättningsarbetet.
Regel 11 utgår från konsekvenserna av ett informationsfel. Om programvaran tillhandahåller information som används för diagnostiska eller terapeutiska beslut ökar klassificeringen i takt med den potentiella skada som kan uppstå om informationen är felaktig.
| Programvarufunktion | Klass enligt regel 11 | Inblandning av anmält organ | Konsekvenser för översättningsarbetet |
|---|---|---|---|
| Information för diagnostiska eller behandlingsrelaterade beslut där ett fel kan leda till dödsfall eller irreversibla skador | Klass III | Fullständig bedömning av överensstämmelse med granskning av anmält organ | Hela bilaga I §23; SSCP per medlemsstat; granskning inom landet är obligatorisk |
| Information för diagnostiska eller behandlingsmässiga beslut där ett fel kan leda till allvarlig försämring av tillståndet eller kräva kirurgiskt ingrepp | Klass IIb | Fullständig bedömning av överensstämmelse med NB-kraven | Bilaga I §23 i sin helhet, utdrag ur den tekniska dokumentationen på begäran |
| Information för diagnostiska eller terapeutiska beslut (övrigt) | Klass IIa | Fullständig bedömning av överensstämmelse med NB-kraven | Bilaga I § 23 i sin helhet, försäkran om överensstämmelse på medlemsstatens språk |
| Programvara som övervakar fysiologiska processer där avvikelser kan utgöra en omedelbar fara | Klass IIb | Fullständig bedömning av överensstämmelse med NB-kraven | Bilaga I § 23 i sin helhet, rapportering av säkerhetsövervakning per medlemsstat |
| Programvara för övervakning av fysiologiska processer (övrigt) | Klass IIa | Fullständig bedömning av överensstämmelse med NB-kraven | Bilaga I, punkt 23 i sin helhet |
| All övrig programvara (standard) | Klass I | Självutnämnd | Bilaga I §23 gäller fortfarande; översättningsarbetet har ofta otillräckliga resurser |
Övergången från klass I till klass IIa och vad det innebär för översättningsarbetet
Klass I enligt MDD blir klass IIa, IIb eller III enligt MDR för de flesta diagnostiska och terapeutiska programvaror. Konsekvenserna av denna övergång är konkreta: inblandning av anmält organ, granskning av den tekniska dokumentationen under bedömningen av överensstämmelse, samt språkkrav som följer de fullständiga skyldigheterna i bilaga I, avsnitt 23.
För ett digitalt hälsoföretag som byggt upp sin produktportfölj enligt den gamla MDD medför övergången verkliga kostnader som måste tas med i tidsplanen för övergången till MDR. Den kostnad som ofta förbises är den tid som granskarna i landet lägger ner på att granska översatta UI-strängar under det anmälda organets granskning, där granskaren jämför varje översatt sträng med den ursprungliga avsikten och den tekniska dokumentationen. MDCG 2024-7 (Frågor och svar om klassificering enligt regel 11) är den senaste operativa vägledningen och väl värd att läsa innan man fastställer omfattningen av ett nytt översättningsprogram för SaMD.
Vilka programvarukomponenter behöver översättas?
Översättning av medicinsk programvara omfattar mer än bara strängar i användargränssnittet. Den fullständiga projektmatrisen kan delas upp i fyra delar:
- Användargränssnitt: UI-strängar, text i appen, introduktionsflöden, versionsinformation.
- Medföljande information som uppfyller kraven i MDR: elektronisk bruksanvisning, hjälp i appen med länk från enheten, användaravtal.
- Teknisk dokumentation enligt lagstiftningen: dokumentation avseende programvarans livscykel enligt IEC 62304, dokumentation om cybersäkerhet, teknisk dokumentation enligt AI-lagen.
- Material efter marknadsintroduktionen: versionsinformation, säkerhetsmeddelanden och säkerhetsmeddelanden för programvara.
Varje del har sin egen översättningstakt och sina egna krav på spårbarhet.
| Dokumentation | Primär målgrupp | Reglerande funktion | Översättningsspecifikationer |
|---|---|---|---|
| UI-texter (menyer, knappar, dialogrutor) | Användare | UX; användbarhet enligt IEC 62366-1 | Strängars längd, pluralbildning, tillgänglighet |
| Felmeddelanden | Användare, vårdpersonal | Användarsäkerhet | Kortfattat, lättförståeligt språk, enhetlig terminologi |
| Hjälp i appen | Användare | Tilläggsinformation (bilaga I § 23) | Kontextbaserad granskning direkt i layouten |
| Introduktionsprocesser | Användare | Introduktionskurs för nyanställda | Kort text, bild för bild |
| Versionsinformation | Användare, vårdpersonal | Kommunikation efter marknadsintroduktionen | Versionshanterad, taktstyrd |
| Elektronisk bruksanvisning (eIFU) | Användare, vårdpersonal | Bilaga I § 23 | Fullständig översättning av bruksanvisningen, avsedd för myndighetsgodkännande |
| Användaravtal och integritetspolicy | Användare | Juridisk | Exakt, med hänsyn till jurisdiktion |
| Tillgänglighetstexter (skärmläsare, alt-text) | Användare av hjälpmedel | Efterlevnad av tillgänglighetskrav | Ett separat arbetsflöde som ofta förbises |
| Dokumentation om programvarans livscykel enligt IEC 62304 | Anmält organ | Bedömning av överensstämmelse | Inlämnat på NB:s arbetsspråk (oftast engelska) |
| IEC 62366-1 – Dokument om användbarhetsutveckling | Anmält organ | Validering av användbarhet | Stöder godkännande av översatt användargränssnitt |
| Dokumentation om cybersäkerhet | Obs! Behöriga myndigheter | MDR bilaga I; MDCG 2019-16 | Utdrag kan beställas på det lokala språket |
| Teknisk dokumentation för AI-lagen | Organ för övervakning av efterlevnaden av AI-lagen | Artiklarna 11–15 i AI-lagen | Språket följer praxis enligt AI-lagen |
| Meddelande om öppenhet enligt artikel 50 i AI-lagen | Användare | Information om interaktion med AI | Per språk; synligt för användaren |
| Säkerhetsmeddelanden för fältanvändning (programvara) | Användare; behöriga myndigheter | Artikel 89.8 | Per medlemsstat |
UI-strängar och de begränsningar som översättningen måste hantera
Översättning av användargränssnitt medför programvaruspecifika begränsningar som inte förekommer vid översättning av bruksanvisningar för hårdvaruenheter. De viktigaste är:
- Strängarnas längd. Tyska strängar är i genomsnitt cirka 30 procent längre än engelska och kinesiska cirka 40 procent kortare. En knappetikett som fungerar i den engelska versionen kan därför antingen överskrida det tillgängliga utrymmet eller se oproportionerligt kort ut i andra språkversioner.
- Pluralform, genus och variabler. ICU MessageFormat hanterar dessa i de flesta språkversioner och är den gällande standarden för alla UI-strängar med grammatiska variationer.
- Tillgänglighetstexter. Text för skärmläsare, alt-text och ARIA-etiketter utgör ett separat arbetsflöde som de flesta språktjänstleverantörer förbiser, och som leder till underkänd tillgänglighetsgranskning om det utelämnas.
- Tvåvägstext. För språkversioner som använder arabiska eller hebreiska tillkommer ytterligare utvecklingsarbete i form av spegelvänd layout och hantering av inbäddade riktningsmarkörer för text.
- Kodning. Unicode UTF-8 är standard.
Kontextbaserad granskning med hjälp av vår SmartEdit gör att översättaren kan se varje sträng i användargränssnittet precis som användaren ser den, vilket matas direkt in i IEC 62366-1-filen för användbarhetsdokumentation.
Programvaran och MDR-gränsen
Översättning av bruksanvisningar, etiketter, förpackningar och implantatkort för hårdvaruenheter behandlas separat i MDR:s översättningskrav. Programvaruspecifika artefakter är ämnet för denna artikel. Köpare som behöver båda bör välja en enda språkleverantör som hanterar båda med en enda process, en enda termbas och ett enda revisionsspår. Två leverantörer skapar terminologiska avvikelser och luckor i revisionsspåret som kommer att upptäckas vid nästa inspektion av det anmälda organet.
EU:s AI-lag efter Omnibus-överenskommelsen i maj 2026
EU:s AI-lag (förordning (EU) 2024/1689) klassificerar AI-baserade medicintekniska produkter som AI-system med hög risk enligt artikel 6.1. Den politiska överenskommelsen om Digital Omnibus som rådet och parlamentet nådde den 7 maj 2026 – en vecka före publiceringen av den här artikeln – flyttade fram tidsfristerna för efterlevnad av kraven för högrisk-AI.
För SaMD som innehåller AI eller maskininlärning är detta den viktigaste regulatoriska förändringen för översättningsarbetet under 2026. Tre delar av AI-förordningen påverkar översättningsomfattningen: kraven på teknisk dokumentation i artiklarna 11–15, transparenskraven i artikel 50 och kravet på AI-kompetens i artikel 4.
| Datum | Vad som gäller | Vad det innebär för översättning |
|---|---|---|
| 1 augusti 2024 | AI-lagen träder i kraft | Ingen direkt |
| 2 februari 2025 | Förbud mot vissa former av AI-användning och skyldigheter avseende AI-kunskap gäller | Översättning av interna riktlinjer, utbildningsmaterial för personalen |
| 2 augusti 2025 | GPAI-modellens skyldigheter gäller | Dokumentation för grundmodellen, om sådan används |
| 2 augusti 2026 | Skyldigheten att ha kunskaper om AI (artikel 4) gäller | Personalutbildning, informationsmeddelanden om AI-kunskap riktade till användarna per medlemsstat |
| 2 december 2026 | Öppenhet kring AI-genererat innehåll (artikel 50) | Information om AI-interaktioner riktade till användare per medlemsstat |
| 2 december 2027* | Fristående AI med hög risk enligt bilaga III (förlängning efter Omnibus-överenskommelsen) | Fullständig dokumentation för bedömning av överensstämmelse på de språk som används i ansökan |
| 2 augusti 2028* | AI med hög risk som ingår i reglerade produkter enligt bilaga I (förlängning efter Omnibus-överenskommelsen; omfattar större delen av medicinsk AI) | Fullständig teknisk dokumentation enligt AI-lagen samt dokumentation enligt MDR |
*Förutsatt formellt antagande av den politiska överenskommelsen om Digital Omnibus från den 7 maj 2026. De ursprungliga tidsfristerna var den 2 augusti 2026 (bilaga III) och den 2 augusti 2027 (bilaga I).
Vilket översättningskrav som gäller för högrisk-AI inom medicinteknik
Högrisk-AI inom medicinteknik omfattas av ett dokumentationspaket enligt AI-förordningen som kompletterar den tekniska dokumentationen enligt MDR. Dokumentationen omfattar bland annat styrning av träningsdata, bedömning av datakvalitet och bias, transparens gentemot användare, utformning av mänsklig övervakning, specifikationer för noggrannhet och robusthet, planer för övervakning efter lansering på marknaden samt registrering i EU:s AI-databas. Merparten av denna dokumentation lämnas till det anmälda organet på engelska, som normalt är dess arbetsspråk.
Två delar skickas till användarna på det språk som används i respektive medlemsstat:
- det transparensmeddelande som krävs enligt artikel 50 och som informerar användaren om att de interagerar med ett AI-system, och
- eventuella AI-specifika tillägg till bruksanvisningen.
Skyldigheten att tillhandahålla utbildning i AI-kunskap enligt artikel 4, som även efter Omnibus-överenskommelsen gäller från och med den 2 augusti 2026, innebär att personal som implementerar AI-system måste få utbildning i AI-kunskap, ofta på målmarknadens språk.
Den dubbla regelefterlevnaden enligt MDR
AI-baserade medicintekniska produkter (SaMD) kräver både bedömning av överensstämmelse med MDR och bedömning av överensstämmelse med AI-lagen inom samma program. Europeiska kommissionens ståndpunkt, som bekräftades i den politiska Omnibus-överenskommelsen i maj 2026, är att de två bedömningarna ska integreras när ett och samma anmält organ ansvarar för båda: en CE-märkning, en försäkran om överensstämmelse, en teknisk dokumentation med avsnitt för både MDR och AI-lagen.
Översättningsimplikationen: en enda sammanhängande teknisk dokumentation som spänner över båda regelverken, med revisionsspår och versionskontroll som omfattar båda. En språkleverantör som hanterar MDR men inte kan visa kunskaper om AI-lagen kommer att skapa en revisionslucka så snart AI-avsnitten omfattas. Vår SmartDesk har det kombinerade revisionsspåret.
Det brittiska MHRA-ramverket år 2026
Medicinsk programvara i Storbritannien omfattas av förordningen om medicintekniska produkter från 2002 (i dess ändrade lydelse), som förvaltas av MHRA. MHRA:s Software and AI as a Medical Device Change Programme har pågått sedan oktober 2022 och fortsätter att utvecklas under 2026.
Tre utvecklingar präglar översättningsarbetet för SaMD i maj 2026:
- de nya bestämmelserna om övervakning efter marknadsintroduktion som trätt i kraft i juni 2025
- det internationella Reliance-programmet som inleddes under första halvåret 2026, och
- National Commission into the Regulation of AI in Healthcare, som väntas presentera sina rekommendationer senare under året.
Genom reformen den 22 juli 2025 förlängdes erkännandet av CE-märkning i Storbritannien på obestämd tid, vilket förenklar den tekniska dokumentation som krävs för företag som marknadsför SaMD på både EU- och den brittiska marknaden
International Reliance-programmet
MHRA:s International Reliance-program gör det möjligt för medicintekniska digitala produkter (SaMD) som har godkänts av FDA, Health Canada eller TGA att följa en förenklad väg till marknadstillträde i Storbritannien. För ett företag inom digital hälsa med ett FDA 510(k)-godkännande eller ett De Novo-godkännande förkortas tidsramen i Storbritannien avsevärt.
Översättningsaspekten är snarare operativ än regulatorisk: dokumentationen anpassar den utländska dokumentationen om klinisk prestanda, cybersäkerhet och riskhantering till British Medical Devices Regulations 2002. Merparten av den regulatoriska dokumentationen förblir på engelska, men de brittiska release-noterna, kommunikationen till användarna och materialet efter marknadsintroduktionen förblir specifikt brittisk engelska. Skillnaderna i stil och konventioner mellan amerikansk engelska, australisk engelska och brittisk engelska är tillräckligt stora för att motivera en separat språkversion i översättningsminnet.
CE-godkännande i Storbritannien och förenkling av den dubbla marknaden
Sedan reformen den 22 juli 2025 är CE-märkta produkter fortsatt giltiga för den brittiska marknaden på obestämd tid. De tidigare slutdatumen den 30 juni 2028 respektive den 30 juni 2030 har tagits bort i avvaktan på fortsatt samråd. Multinationella SaMD-företag kan därmed använda en gemensam teknisk dokumentation för EU- och UK-marknaden, med en brittisk-engelsk språkversion som tillägg för användarinriktad information.
Översättningsmässigt innebär detta en enda EU-dokumentuppsättning med en brittisk engelsk variant för användarvänligt innehåll, istället för två parallella dokumentuppsättningar. Detta innebar en betydande operativ förenkling när det infördes i juli 2025 och fortsätter att vara den gällande utgångspunkten för de flesta SaMD-företag som driver program parallellt i Storbritannien och EU.
CI/CD-integration och kontinuerlig lokalisering
SaMD släpps kontinuerligt. Appar för patienter släpps varje vecka, ibland ännu oftare. Översättningsprocessen måste integreras med programvarornas utvecklingsprocess via API eller annan systemintegration, inte fungera som en separat process som bromsar eller blockerar leveranser. Detta är den tekniskt inriktade delen av översättningen av medicinsk programvara, och den del där de flesta språktjänstleverantörer misslyckas. Vår SmartConnect är vår primära tekniska grund för denna integration.
Integration med datalager
Vår SmartConnect erbjuder API- eller webhook-integration med källkodsförvaret (GitHub, GitLab, Bitbucket) så att ändringar av strängar flödar genom översättningsprocessen utan manuell hantering. Kopplingen övervakar ändringar i angivna resursfiler (JSON, YAML, .properties, .strings, .xliff), extraherar ändrade strängar, dirigerar dem genom översättningsminnet och den mänskliga lingvisten, och returnerar översatta strängar till en funktionsgren eller pull-begäran för teknisk granskning.
Revisionsspåret över vem som översatte vilken version av vilken sträng, när och mot vilken termbas, registreras i vår SmartDesk för MDR-anmälda organs granskning och AI-lagens tekniska dokumentation. För ett teknikteam som kör veckovisa releaser är alternativet en manuell export-översätt-import-cykel som blockerar releaser och skapar terminologiska avvikelser mellan releaser.
Kontextbaserad granskning och överlämning enligt IEC 62366-1
Programvaruöversättningar som inte genomgår en kontextbaserad granskning klarar inte användbarhetsvalideringen enligt IEC 62366-1. Översättaren måste se strängen i användargränssnittet precis som användaren ser den, med omgivande sammanhang, layout och visuella element synliga.
Vår SmartEdit erbjuder kontextbaserad granskning för granskare i landet utan att de behöver en licens för InDesign eller front-end-verktyg. Granskaren kan justera stränglängden, åtgärda layoutproblem och bekräfta att översättningen låter naturligt i det renderade användargränssnittet. Resultatet matas direkt in i IEC 62366-1-filen för användbarhetsteknik som en del av den tekniska dokumentationen som skickas in till det anmälda organet. Utan detta steg valideras inte det översatta användargränssnittet som en del av användargränssnittet, vilket utgör en brist i överensstämmelsen vid MDR-granskningen.
Checklista för utvärdering av leverantörer av översättningstjänster för medicinsk programvara
En översättningsleverantör som är specialiserad på medicinsk programvara förenar gedigna kunskaper inom medicinsk lagstiftning (MDR regel 11, EU:s AI-lag, MHRA Software Group) med förmågan att integrera med mjukvaruutveckling (API, CI/CD, ICU MessageFormat, granskning i sitt sammanhang). De flesta språkleverantörer har antingen det ena eller det andra, men få har båda delarna. Checklistan nedan testar båda dessa aspekter på den nivå som ett SaMD-program kräver.
| Kriterium | Varför det är viktigt för utvecklingen av medicinsk programvara | Vad man bör fråga efter i anbudsförfrågan |
|---|---|---|
| ISO 17100 | Processgrunder för mänsklig översättning | Bifoga aktuellt ISO 17100-certifikat och ange certifieringsorganet. |
| ISO 18587 | Krävs när MTPE används i gränssnittssträngar eller text i appen | Har ni certifiering enligt ISO 18587 för några arbetsflöden med efterredigerad maskinöversättning? Bifoga certifikatet. |
| ISO 27001 | Informationssäkerhet för reglerat programvaruinnehåll | Bekräfta att ni har en ISO 27001-certifiering och bifoga dokumentation som styrker detta. |
| Språklig kvalitet enligt MDR regel 11 | Klassificeringen avgör översättningsomfattningen och vilka krav på spårbarhet som gäller | Beskriv hur ert kvalitetsledningssystem (QMS) återspeglar MDR regel 11 och MDCG 2024-7. Vilken dokumentation kan ni tillhandahålla som visar erfarenhet från nyligen genomförda SaMD-ansökningar? |
| Information om EU:s AI-lag | Medicinska produkter med AI som medför hög risk måste åtföljas av teknisk dokumentation enligt AI-lagen | Beskriv hur ni hanterar den tekniska dokumentationen enligt artiklarna 11–15 i AI-lagen samt informationsmeddelandena enligt artikel 50. |
| MHRA Software Groups ramverk | I Storbritannien följer man MHRA:s riktlinjer, inte EMA:s eller nationella myndigheters | Berätta hur ni hanterar arbetet med SaMD i Storbritannien, inklusive hanteringen av brittisk engelska som en separat språkversion och anpassningen av dokumentationen enligt International Reliance. |
| Integration med källkodsförvaret | Kontinuerliga leveranser utesluter manuell överlämning | Vilka repositorier ansluter du till (GitHub, GitLab, Bitbucket)? Beskriv ett typiskt arbetsflöde från kodändring till release. |
| Integration av CI/CD-pipeline | Översättningen får inte hindra lanseringen | Hur integreras er plattform med Jenkins, GitHub Actions, GitLab CI eller CircleCI? |
| Stöd för ICU MessageFormat | Pluralbildning, genus, infogning av variabler i olika språkversioner | Bekräfta att ni har fullt stöd för ICU MessageFormat och beskriv hur reglerna för pluralbildning hanteras inom ert språkteam. |
| Verktyg för kontextbaserad granskning | Krävs för validering av användbarhet enligt IEC 62366-1 | Kan lokala granskare se och redigera översatta strängar i det färdiga gränssnittet utan att behöva använda tekniska verktyg? |
| Tillgänglighetstexter | Text för skärmläsare, alt-text och ARIA-etiketter utgör ett separat arbetsflöde | Hur hanterar ni tillgänglighetstexter, och hur testar ni att de återges korrekt på målspråken? |
| Revisionsspår per projekt | Både det anmälda organet enligt MDR och organet för bedömning av överensstämmelse enligt AI-förordningen förväntar sig detta | Vilka revisionshandlingar sammanställer ni för varje projekt, och hur länge sparar ni dem? |
AdHoc Translations är certifierat enligt ISO 17100 och ISO 18587, och certifikaten finns tillgängliga på vår webbplats för direkt kontroll:
- vår SmartConnect erbjuder den datalagring och CI/CD-integration som krävs för den tekniska sidan av översättning av medicinsk programvara,
- vår SmartDesk innehåller den projektvisa revisionsspår som krävs enligt MDR-anmälda organets granskning och den tekniska dokumentationen enligt AI-lagen, och
- vår SmartEdit-funktion stöder kontextbaserad granskning utan att någon licens för utvecklingsverktyg krävs.
För en mer ingående genomgång av kvalitetssäkringsprocessen inom all medicinsk översättning, se kvalitetssäkring av medicinska översättningar.
Vanliga frågor
Vad är programvara som medicinteknisk produkt (SaMD)?
Programvara som medicinteknisk produkt, enligt definitionen från International Medical Device Regulators Forum, är programvara som är avsedd för ett eller flera medicinska ändamål och som utför dessa ändamål utan att ingå i en medicinteknisk hårdvaruprodukt. Exempel på detta är algoritmer för diagnostisk bildbehandling, appar för symptomkontroll och system för kliniskt beslutsstöd. SaMD omfattas av förordning (EU) 2017/745 (MDR) inom EU.
Gäller EU:s AI-lag för medicinsk programvara?
Ja, om programvaran innehåller komponenter för artificiell intelligens eller maskininlärning. Medicintekniska produkter med AI-funktioner som omfattas av MDR eller IVDR klassificeras automatiskt som högriskprodukter enligt artikel 6.1 i AI-lagen. Efter den politiska överenskommelsen om Digital Omnibus den 7 maj 2026 har tidsfristen för efterlevnad av högriskkraven för inbyggd medicinsk AI enligt bilaga I förlängts till den 2 augusti 2028, förutsatt att förordningen antas formellt.
Vad är MDR-regel 11?
Bilaga VIII, regel 11 i förordning (EU) 2017/745 utgör den programvaruspecifika klassificeringsregeln enligt MDR. Den klassificerar de flesta programvaror för medicintekniska produkter som klass IIa eller högre, beroende på konsekvenserna av ett informationsfel. Beslut som kan leda till dödsfall eller irreversibel skada placerar programvaran i klass III. Beslut som kan leda till allvarlig försämring placerar den i klass IIb. De flesta programvaror för diagnostik och behandling tillhör klass IIa.
På vilket sätt skiljer sig översättning av medicinsk programvara från vanlig programvarulokalisering?
Översättning av medicinsk programvara måste uppfylla de lagstadgade krav som gäller för medicintekniska produkter: språkkraven i artikel 10.11 i MDR, den medföljande informationen enligt bilaga I, avsnitt 23, dokumentationen av programvarans livscykel enligt IEC 62304, validering av användbarhet enligt IEC 62366-1 samt (för AI-komponenter) den tekniska dokumentationen enligt AI-lagen. Vid vanlig programvarulokalisering gäller inte dessa krav. Översättningsleverantören måste ha kunskap om både lagstiftningen och hur den integreras i programvaruutvecklingen.
Koppla ihop dina system med SmartConnect
Om din nuvarande översättningsleverantör inte kan integrera med ditt programvarulager, din CI/CD-pipeline och kraven på revisionsspår för anmälda organ i en och samma process, är en strukturerad leverantörsgranskning nästa steg. Anslut dina system med SmartConnect för att se hur vi arbetar med översättning av medicinsk programvara för SaMD, SiMD och kompletterande appar i hela EU och Storbritannien.
Källor
- EUR-Lex, förordning (EU) 2017/745 (MDR) bilaga VIII, regel 11.https://eur-lex.europa.eu/legal-content/SV/TXT/?uri=CELEX%3A32017R0745&utm. Hämtad 14 maj 2026.
- EUR-Lex, förordning (EU) 2017/746 (IVDR). https://eur-lex.europa.eu/legal-content/SV/TXT/?uri=CELEX%3A32017R0746&utm
- EUR-Lex, förordning (EU) 2024/1689 (EU:s AI-lag). https://eur-lex.europa.eu/legal-content/SV/TXT/?uri=CELEX:32024R1689
- 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 (uppdaterad 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 (oktober 2022, reviderad december 2024).
- MHRA International Reliance scheme (annonserades 22 juli 2025; öppnas 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.