Medicinsk software udgives løbende, og oversættelsesprocessen skal kunne følge med uden at kompromittere noget undervejs. Mens lægemiddelbranchen og kliniske forsøg er præget af lange ansøgningscyklusser, er SaMD (software som medicinsk udstyr) baseret på kontinuerlig integration og kontinuerlig implementering (CI/CD). Mens det er afdelingen for regulatoriske anliggender, der har ansvaret for filen, er det udviklerne, der har ansvaret for dataene. Det bemyndigede organ i henhold til forordningen om medicinsk udstyr, overensstemmelsesorganet under EU’s AI-forordning og den britiske MHRA Software Group forventer alle et revisionsspor, der passer nøjagtigt ind i en sprintrytme, som ingen af dem er designet til.
Fem rammer regulerer denne overlapning i 2026:
- Forordning (EU) 2017/745 (MDR)
- Forordning (EU) 2017/746 (IVDR)
- Forordning (EU) 2024/1689 (EU’s AI-forordning)
- De britiske regler om medicinsk udstyr fra 2002
- MHRA’s program for ændringer vedrørende software og kunstig intelligens som medicinsk udstyr
Oversættelsen foregår på tværs af alle fem på samme tid, uanset hvilket udgivelsestempo udviklerteamet rent faktisk følger.
Denne guide samler elementerne på ét sted:
- MDR-regel 11-klassifikationsmatricen
- Softwarematricen
- Tidsplanen for EU’s AI-forordning efter Omnibusaftalen fra maj 2026
- Den britiske MHRA-ramme
- CI/CD-integrationsperspektivet
- Tjekliste til leverandørevaluering
Hvis du er CTO, teknisk chef, chef for internationalisering, chef for regulatoriske anliggender eller kvalitetschef i en virksomhed inden for digital sundhed, MedTech eller medicinsk udstyr baseret på kunstig intelligens, der leverer til EU og Storbritannien, kan du finde en mere dybdegående gennemgang af kvalitetsmetodik i vores artikel om kvalitetssikring af medicinske oversættelser. For en oversigt over, hvordan vi strukturerer vores arbejde med medicinske oversættelser, se vores side om medicinsk oversættelse.
KORT SAGT
|
Hvad der kræves ved oversættelse af medicinsk software i EU og Storbritannien
Fem regulatoriske rammer former oversættelsen af medicinsk software i 2026:
- MDR (forordning (EU) 2017/745), som regulerer både software som medicinsk udstyr og software i medicinsk udstyr.
- IVDR (forordning (EU) 2017/746), som regulerer software til in vitro-diagnostik gennem sine egne klassificeringsregler.
- EU’s AI-forordning (forordning (EU) 2024/1689), som pålægger AI-baseret medicinsk udstyr yderligere forpligtelser på grund af høj risiko ud over kravene i MDR eller IVDR.
- De britiske regler om medicinsk udstyr fra 2002 (UK Medical Devices Regulations 2002), som regulerer software i Storbritannien.
- MHRA’s program for ændringer vedrørende software og kunstig intelligens som medicinsk udstyr, der samtidig fremmer en aktiv reformdagsorden.
Oversættelsen foregår parallelt på alle fem sprog: det eller de officielle sprog i hver medlemsstat eller jurisdiktion, hvor softwaren stilles til rådighed – herunder softwarespecifikke elementer inden for dette omfang.
SaMD, SiMD og ledsager-apps: hvor grænserne går
Der findes tre softwarekategorier inden for medicinsk oversættelse:
- Software som medicinsk udstyr (SaMD): selvstændig software, der udfører medicinske funktioner uden at være en del af et hardwareapparat, herunder algoritmer til diagnostisk billedbehandling, apps til symptomtjek og systemer til støtte for kliniske beslutninger.
- Software i medicinsk udstyr (SiMD): software, der er integreret i hardware, f.eks. firmwaren i en infusionspumpe, algoritmen i en EKG-monitor eller software til at kunne bruge en CT-scanner.
- Ledsager-apps: mobilapplikationer rettet mod patienter, som afhængigt af deres tilsigtede formål kan falde ind under definitionen af medicinsk udstyr eller ej.
MDCG 2019-11 (opdateret 2023) er det beslutningsdokument, der fastlægger, om et givet stykke software kan betragtes som et medicinsk udstyr i henhold til MDR. Købere, der planlægger oversættelsesarbejde, bør spørge deres team for regulatoriske anliggender om den aktuelle klassificering i henhold til regel 11, inden de bestiller noget.
IVDR-grænsen
Software til in vitro-diagnostik falder ind under IVDR og ikke under MDR. Oversættelsesprincippet er det samme: Artikel 18, stk. 1, i IVDR afspejler MDR-artikel 10, stk. 11, om sprogomfang. Men proceduren for overensstemmelsesvurdering er anderledes, idet der gælder klassificeringsregler, der er specifikke for IVD’er, samt sprogkrav, der følger den enkelte medlemsstats gennemførelse af IVDR.
For medicotekniske producenter, der udvikler diagnostiske algoritmer, især ledsagende diagnostik til AI-billeddiagnostik, løber IVDR-processen sideløbende med MDR-processen som en separat arbejdsgang med sin egen sprogmatrice og sit eget revisionsspor.
MDR-regel 11: Hvordan software klassificeres, og hvad det betyder for oversættelsens omfang
Bilag VIII, regel 11, i MDR er den klassificeringsregel, der specifikt vedrører software. Det meste software, der var klassificeret som klasse I i henhold til det gamle direktiv om medicinsk udstyr, er nu klassificeret som klasse IIa eller højere i henhold til MDR. Klassen bestemmer, hvilket bemyndiget organ der skal inddrages, hvilken procedure for vurdering af overensstemmelse der skal følges, samt hvilket revisionsspor der kræves i forbindelse med oversættelsesarbejdet.
Regel 11 omhandler konsekvenserne af en fejl i oplysninger: hvor softwaren leverer information til diagnostiske eller terapeutiske beslutninger, afhænger klassen af skadens alvor, hvis oplysningerne er forkerte.
| Softwarefunktion | Regel 11-klasse | Inddragelse af et bemyndiget organ (BO) | Konsekvenser for oversættelsens omfang |
|---|---|---|---|
| Oplysninger til brug ved diagnostiske eller terapeutiske beslutninger, hvor en fejl kan medføre død eller uoprettelig skade | Klasse III | Fuldstændig overensstemmelsesvurdering med grundig gennemgang fra BO | Bilag I, § 23 i sin helhed; sammenfatning af sikkerhed og klinisk ydeevne (SSCP) pr. medlemsstat; obligatorisk gennemgang i det pågældende land |
| Oplysninger til brug ved diagnostiske eller terapeutiske beslutninger, hvor en fejl kan medføre en alvorlig forværring af en tilstand eller kræve et kirurgisk indgreb | Klasse IIb | Fuldstændig overensstemmelsesvurdering fra BO | Bilag I, § 23, i sin helhed; uddrag af den tekniske dokumentation på anmodning |
| Oplysninger til brug ved diagnostiske eller terapeutiske beslutninger (andet) | Klasse IIa | Fuldstændig overensstemmelsesvurdering fra BO | Bilag I, § 23 i sin helhed; overensstemmelseserklæring på medlemsstatens sprog |
| Software til overvågning af fysiologiske processer, hvor udsving kan udgøre en umiddelbar fare | Klasse IIb | Fuldstændig overensstemmelsesvurdering fra BO | Bilag I, § 23, i sin helhed; indberetning af overvågningsdata pr. medlemsstat |
| Software til overvågning af fysiologiske processer (andet) | Klasse IIa | Fuldstændig overensstemmelsesvurdering fra BO | Bilag I, § 23, i sin helhed |
| Al anden software (standard) | Klasse I | Selverklæret | Bilag I, § 23, gælder stadig; oversættelsesarbejdet er ofte underprioriteret |
Overgangen fra klasse I til klasse IIa og de dermed forbundne omkostninger til oversættelsesarbejde
Klasse I i henhold til MDD (direktivet for medicinsk udstyr) bliver til klasse IIa, IIb eller III i henhold til MDR for det meste diagnostiske og terapeutiske software. Konsekvenserne af denne ændring er konkrete: Inddragelse af et bemyndiget organ, gennemgang af den tekniske dokumentation under overensstemmelsesvurderingen samt sprogkrav, der følger de fulde forpligtelser i bilag I, afsnit 23.
For en virksomhed inden for digital sundhed, der har opbygget sin produktportefølje i henhold til det gamle MDD, medfører overgangen reelle omkostninger, som skal indregnes i tidsplanen for overgangen til MDR. Den omkostning, der ofte overses: den tid, som en lokal evalueringsperson bruger på at gennemgå de oversatte brugergrænsefladestrenge under det bemyndigede organs gennemgang, hvor evalueringspersonen sammenligner hver enkelt oversat streng med den oprindelige hensigt og den tekniske dokumentation. MDCG 2024-7 (spørgsmål og svar om klassificering i henhold til regel 11) er den nyeste operationelle vejledning og er værd at læse, inden man fastlægger omfanget af et nyt oversættelsesprogram for SaMD.
Hvilke softwaredele skal oversættes?
Oversættelse af medicinsk software omfatter mere end blot tekster i brugergrænsefladen. Den samlede projektmatrice kan opdeles i fire kategorier:
- Brugerrettet softwareindhold: UI-tekster, tekst i appen, onboardingforløb, udgivelsesnoter.
- Ledsagende oplysninger, der opfylder kravene i MDR: elektronisk brugsanvisning (IFU), hjælp i appen med link fra enheden, EULA’er.
- Teknisk dokumentation i henhold til lovgivningen: Dele fra softwarelivscyklussen i henhold til IEC 62304, dokumentation vedrørende cybersikkerhed, teknisk dokumentation i henhold til AI-forordningen.
- Materialer efter markedsføring: udgivelsesnoter, sikkerhedsmeddelelser og sikkerhedsmeddelelser til brugere.
Hver kategori har sit eget oversættelsestempo og sine egne krav til sporbarhed.
| Kategori | Primær læser | Regulatorisk funktion | Oversættelsesspecifikt |
|---|---|---|---|
| UI-strenge (menuer, knapper, dialogbokse) | Brugere | UX; brugervenlighed i henhold til IEC 62366-1 | Strenglængde, flertalsdannelse, tilgængelighed |
| Fejlmeddelelser | Brugere, klinikere | Brugersikkerhed | Kortfattet, klart sprog, konsistent terminologi |
| Hjælp i appen | Brugere | Ledsagende oplysninger (bilag I, § 23) | Kontekstbaseret gennemgang i layoutet |
| Onboardingforløb | Brugere | Orientering til førstegangsbrug | Kort tekst, skærm for skærm |
| Udgivelsesnoter | Brugere, klinikere | Kommunikation efter produktet er på markedet | Versionsstyret, kadencestyret |
| Elektronisk brugsanvisning (eIFU) | Brugere, klinikere | Bilag I, § 23 | Fuldstændig oversættelse af brugsanvisningen, i henhold til myndighedskrav |
| EULA og privatlivspolitik | Brugere | Jura | Nøjagtig og med hensyn til jurisdiktion |
| Tilgængelighedsstrenge (skærmlæser, alt-tekst) | Brugere af hjælpemiddelsteknologi | Overholdelse af tilgængelighedskrav | Et særskilt arbejdsforløb, der ofte overses |
| Dokumentation vedrørende softwarecyklus i henhold til IEC 62304 | Bemyndiget organ | Overensstemmelsesvurdering | Fremsendt på BO’s arbejdssprog (ofte engelsk) |
| IEC 62366-1-dokument om brugervenlighedsdesign | Bemyndiget organ | Validering af brugervenlighed | Understøtter godkendelse af oversat brugergrænseflade |
| Dokumentation vedrørende cybersikkerhed | BO: de kompetente myndigheder | MDR, bilag I; MDCG 2019-16 | Der kan anmodes om uddrag på det lokale sprog |
| Teknisk dokumentation i henhold til AI-forordningen | Organ for overholdelse af AI-forordningen | Artikel 11-15 i AI-forordningen | Sproget følger praksis i henhold til AI-forordningen |
| Meddelelse om gennemsigtighed i henhold til artikel 50 i AI-forordningen | Brugere | Oplysninger om interaktion med kunstig intelligens | Pr. sprog; brugerrettet |
| Vigtig produktinformation vedrørende sikkerhed (software) | Brugere; kompetente myndigheder | Artikel 89, stk. 8 | Pr. medlemsstat |
UI-tekster og de begrænsninger, oversættelser skal tage højde for
Oversættelse af brugergrænseflader er underlagt visse softwarespecifikke begrænsninger, som ikke gælder for oversættelse af brugsanvisninger til hardwareenheder. De vigtigste er:
- Strenglængde. Tysk er i gennemsnit ca. 30 procent længere end engelsk, mens kinesisk er ca. 40 procent kortere. En knaptekst, der passer på engelsk, kan fylde for meget i kontrolelementet eller se malplaceret ud på målsprogene.
- Flertalsdannelse, køn og variabler. ICU MessageFormat håndterer disse på tværs af de vigtigste sprogområder og er den gældende standard for alle UI-strenge med grammatiske variationer.
- Tilgængelighedsstrenge. Tekst til skærmlæsere, alt-tekst og ARIA udgør et særskilt arbejdsområde, som de fleste LSP’er overser, og som medfører, at tilgængelighedskontrollen ikke består, hvis det overses.
- Tovejstekst. For alle sprogindstillinger, der bruger arabisk eller hebraisk, medfører layoutvending og indlejrede retningsmarkører yderligere et teknisk overdragelsestrin.
- Kodning. Unicode UTF-8 er standarden.
Kontekstbaseret gennemgang via vores SmartEdit giver oversætteren mulighed for at se hver enkelt streng i brugergrænsefladen, præcis som brugeren vil se den, hvilket indgår direkte i IEC 62366-1-filen om brugervenlighed.
Grænsen mellem software og MDR
Oversættelse af brugsanvisninger, etiketter, emballage og implantatkort til hardware-enheder behandles separat i MDR-oversættelseskrav. Emnet for denne artikel er softwarespecifikke dele. Købere, der har brug for begge dele, bør vælge en enkelt sprogleverandør, der kan håndtere begge dele med én proces, én termbase og ét revisionsspor. To forskellige leverandører vil skabe terminologiske afvigelser og huller i revisionssporet, som vil vise sig ved den næste inspektion fra det bemyndigede organ.
EU’s AI-forordning efter Omnibusaftalen fra maj 2026
EU’s AI-forordning (forordning (EU) 2024/1689) klassificerer AI-baserede medicinske produkter som højrisikobaserede AI-systemer i henhold til artikel 6, stk. 1. Den politiske aftale om “Digital Omnibus”, som Rådet og Parlamentet indgik den 7. maj 2026, forlængede fristerne for overholdelse af kravene til højrisikobaserede systemer.
For SaMD med AI- eller ML-komponenter er dette den mest vidtrækkende regulatoriske ændring i 2026 for oversættelsesarbejdet. Tre forpligtelsesområder har konsekvenser for oversættelsesarbejdet: teknisk dokumentation i henhold til AI-forordningen, artikel 11 til 15, gennemsigtighed over for brugerne i henhold til artikel 50 samt AI-færdigheder i henhold til artikel 4.
| Dato | Hvad der er gældende | Implikationer for oversættelsen |
|---|---|---|
| 1. august 2024 | AI-forordningen træder i kraft | Ingen direkte |
| 2. februar 2025 | Forbudt AI-praksis og forpligtelser vedrørende AI-færdigheder | Oversættelse af interne retningslinjer; indhold til personaleuddannelse |
| 2. august 2025 | GPAI-modellens forpligtelser | Dokumentation til grundlæggende modeller, hvis sådanne anvendes |
| 2. august 2026 | Forpligtelsen til at sikre AI-færdigheder (artikel 4) | Medarbejderuddannelse, oplysninger om AI-færdigheder rettet mod brugerne pr. medlemsstat |
| 2. december 2026 | Gennemsigtighed i forbindelse med AI-genereret indhold (artikel 50) | Oplysninger om brugerrettet AI-interaktion pr. medlemsstat |
| 2. december 2027* | Selvstændig AI med høj risiko i henhold til bilag III (udvidelse efter Omnibusaftalen) | Fuldstændig dokumentation vedrørende overensstemmelsesvurdering på de sprog, som ansøgningen fremsendes på |
| 2. august 2028* | AI med høj risiko, der er integreret i regulerede produkter i henhold til bilag I (udvidelse efter Omnibusaftalen; omfatter det meste medicinske AI) | Fuldstændig teknisk dokumentation i henhold til AI-forordningen samt MDR-dokumentation |
*Under forbehold for den formelle vedtagelse af den politiske aftale om “Digital Omnibus”, der blev indgået den 7. maj 2026. De oprindelige frister var den 2. august 2026 (bilag III) og den 2. august 2027 (bilag I).
Hvilke højrisiko-AI-baserede medicinske produkter, der skal oversættes
Medicinsk udstyr med kunstig intelligens (AI), der er klassificeret som højrisiko, skal ledsages af et dokumentationssæt i henhold til AI-forordningen, som supplerer den tekniske dokumentation i henhold til MDR. Dokumentationssættet omfatter styring af træningsdata, vurdering af datakvalitet og bias, gennemsigtighed over for brugerne, design af menneskelig overvågning, specifikationer for nøjagtighed og robusthed, planer for overvågning efter markedsføring samt en registrering i EU’s database. Størstedelen af dette fremsendes til det bemyndigede organ på engelsk, da dette er organets arbejdssprog.
To dokumenter sendes til brugerne på den pågældende medlemsstats sprog:
- gennemsigtighedsmeddelelsen i henhold til artikel 50 om at brugeren interagerer med et AI-system, og
- eventuelle AI-specifikke tilføjelser i brugsanvisningen.
Forpligtelsen til AI-færdigheder i henhold til artikel 4, som fortsat gælder fra den 2. august 2026, selv efter Omnibusaftalen, kræver, at der tilbydes uddannelsesmateriale til fremme af AI-færdigheder til medarbejdere, der implementerer AI-systemer, ofte på målmarkedets sprog.
Virkeligheden med dobbelt overholdelse i forbindelse med MDR
AI-baseret SaMD kræver både en overensstemmelsesvurdering i henhold til MDR og i henhold til AI-forordningen inden for samme program. Europa-Kommissionens holdning, som blev bekræftet ved den politiske omnibusaftale fra maj 2026, er, at de to vurderinger integreres, når et enkelt bemyndiget organ dækker begge: én CE-mærkning, én overensstemmelseserklæring, ét teknisk dossier med afsnit vedrørende både MDR og AI-forordningen.
Konsekvensen for oversættelsen: én sammenhængende teknisk dokumentation, der dækker begge reguleringsregimer, med revisionsspor og versionskontrol, der omfatter begge. Et oversættelsesbureau, der håndterer MDR, men ikke kan dokumentere kendskab til AI-forordningen, vil skabe et revisionsmæssigt hul, så snart AI-afsnittene kommer ind i anvendelsesområdet. Vores SmartDesk indeholder dette kombinerede revisionsspor.
Den britiske MHRA-ramme i 2026
Medicinsk software i Storbritannien er underlagt Medical Devices Regulations 2002 (i ændret form), som administreres af MHRA. MHRA’s program for ændringer vedrørende software og kunstig intelligens som medicinsk udstyr har været i gang siden oktober 2022 og vil fortsætte med at udvikle sig gennem 2026.
Tre udviklinger præger oversættelsesarbejdet inden for SaMD i maj 2026:
- de nye regler om overvågning efter produktet er på markedet, der har været i kraft siden juni 2025
- International Reliance-ordningen, der blev indført i første halvår af 2026, og
- den nationale kommission for regulering af kunstig intelligens i sundhedssektoren forventes at fremlægge sine anbefalinger senere på året.
CE-accepten i Storbritannien er blevet forlænget på ubestemt tid i henhold til reformen af 22. juli 2025, hvilket forenkler den tekniske dokumentation for det dobbelte marked for multinationale SaMD-virksomheder.
International Reliance-ordningen
MHRA’s International Reliance-ordning giver SaMD, der har godkendelse fra FDA, Health Canada eller TGA, mulighed for at benytte en forenklet procedure for at opnå markedsadgang i Storbritannien. For en virksomhed inden for digital sundhed med en FDA 510(k)- eller De Novo-godkendelse forkortes tidsrammen i Storbritannien betydeligt.
Oversættelsesmæssigt er det snarere et operationelt end et regulatorisk anliggende: dokumentationen afstemmer den udenlandske dokumentation vedrørende klinisk ydeevne, cybersikkerhed og risikostyring med de britiske regler om medicinsk udstyr fra 2002. Det meste af den regulatoriske dokumentation forbliver på engelsk, men de britiske udgivelsessnoter, brugerrettede udgivelsesmeddelelser og materialer efter produkter er kommet på markedet skal specifikt være på britisk engelsk. Forskellene i stil og konventioner mellem amerikansk engelsk, australsk engelsk og britisk engelsk er store nok til at berettige en separat sprogvariant i oversættelseshukommelsen.
CE-accept i Storbritannien og forenkling af det fælles marked
Siden reformen af 22. juli 2025 er CE-mærkede enheder fortsat gyldige på det britiske marked på ubestemt tid. De tidligere udløbsbestemmelser pr. 30. juni 2028 og 30. juni 2030 er blevet fjernet i afventning af en høring. Multinationale SaMD-virksomheder opretholder ét enkelt EU-teknisk dossier for begge markeder, hvor der ovenpå lægges en britisk-engelsk sprogvariant til brugerrettet indhold.
Implikationen for oversættelser: ét sæt EU-dokumenter med en britisk-engelsk variant til brugerrettet indhold i stedet for to parallelle sæt dokumenter. Dette udgjorde en betydelig driftsmæssig forenkling, da det trådte i kraft i juli 2025, og det er fortsat den gældende antagelse for de fleste SaMD-virksomheder, der kører britiske og EU-programmer parallelt.
CI/CD-integration og kontinuerlig lokalisering
SaMD udgives løbende. Patientrettede ledsager-apps udgives ugentligt, nogle gange oftere. Oversættelsesprocessen skal integreres med softwarens udviklingsproces via API eller et forbindelsesled og må ikke køre sideløbende som en separat, blokerende proces. Dette er den teknisk drevne del af oversættelsen af medicinsk software – og den del, som de fleste oversættelsesbureauer dumper i. Vores SmartConnect er vores primære teknologiske grundpille for denne integration.
Integration med datalager
Vores SmartConnect tilbyder API- eller webhook-integration med kilde-repo’et (GitHub, GitLab, Bitbucket), så ændringer i tekstrækker automatisk føres gennem oversættelsesforløbet uden manuel overdragelse. Konnektoren overvåger commits til udvalgte ressourcefiler (JSON, YAML, .properties, .strings, .xliff), udtrækker ændrede strenge, sender dem gennem oversættelseshukommelsen og til en menneskelig sprogspecialist og returnerer de oversatte strenge til en feature-gren eller en pull-anmodning til teknisk gennemgang.
Revisionssporet over, hvem der har oversat hvilken version af hvilken streng, hvornår og i forhold til hvilken termbase, registreres i vores SmartDesk til et MDR-bemyndiget organs gennemgang og teknisk dokumentation i henhold til AI-forordningen. For et udviklerteam, der arbejder med ugentlige udgivelsescyklusser, er alternativet en manuel eksport-oversættelse-import-cyklus, der blokerer for udgivelser og skaber terminologiske uoverensstemmelser mellem udgivelserne.
Kontekstbaseret gennemgang og overleveringen i henhold til IEC 62366-1
Softwareoversættelser, der ikke gennemgår en kontekstbaseret gennemgang, opfylder ikke kravene til brugervenlighed i henhold til IEC 62366-1. Oversætteren skal se teksten i brugergrænsefladen, præcis som brugeren vil se den, med den omgivende kontekst, layoutet og de visuelle elementer synlige.
Vores SmartEdit tilbyder kontekstbaseret gennemgang for evalueringspersoner i målsprogslandet uden behov for en InDesign- eller front-end-værktøjslicens. Evalueringspersonen kan justere strenglængden, rette layoutproblemer og bekræfte, at oversættelsen lyder naturligt i den gengivne brugergrænseflade. Resultatet indgår direkte i IEC 62366-1-filen om brugervenlighed som en del af den tekniske dokumentation, der fremsendes til det bemyndigede organ. Uden dette trin er den oversatte brugergrænseflade ikke valideret som en del af brugergrænsefladen, hvilket udgør en manglende overensstemmelse under MDR-gennemgangen.
Tjekliste til vurdering af leverandører af oversættelse af medicinsk software
En oversættelsesleverandør, der er klar til medicinsk software, kombinerer indgående kendskab til medicinsk lovgivning (MDR-regel 11, EU’s AI-forordning, MHRA Software Group) med evnen til at integrere softwareudvikling (API, CI/CD, ICU MessageFormat, kontekstbaseret gennemgang). De fleste oversættelsesbureauer har det ene eller det andet, men kun få har begge dele. Nedenstående tjekliste tester begge dele ned i den dybde, som et SaMD-program kræver.
| Kriterium | Hvorfor det er vigtigt for udviklingen af medicinsk software | Hvad man bør spørge om ved indhentning af tilbud |
|---|---|---|
| ISO 17100 | Procesgrundlag for menneskeudført oversættelse | Vedhæft venligst jeres aktuelle ISO 17100-certifikat samt oplysninger om certificeringsmyndigheden. |
| ISO 18587 | Påkrævet, når der anvendes MTPE (maskinoversættelse med menneskeudført efterredigering) til UI-strenge eller tekst i appen | Er I certificeret i henhold til ISO 18587 for arbejdsgange med efterredigering af maskinoversættelser? Vedhæft venligst certifikatet. |
| ISO 27001 | Informationssikkerhed for reguleret softwareindhold | Bekræft venligst ISO 27001-certificeringen, og vedhæft dokumentation. |
| Ekspertise i MDR-regel 11 | Klassen afgør oversættelsens omfang og revisionssporet | Beskriv, hvordan jeres kvalitetsstyringssystem afspejler MDR-regel 11 og MDCG 2024-7. Hvilke dokumenter kan I fremlægge som bevis for nylige ansøgninger vedrørende software som medicinsk udstyr (SaMD)? |
| Kendskab til EU’s AI-forordning | Medicinsk udstyr med kunstig intelligens, der udgør en høj risiko, skal ledsages af teknisk dokumentation i henhold til AI-forordningen | Beskriv, hvordan I håndterer den tekniske dokumentation i henhold til artikel 11 til 15 i AI-forordningen samt gennemsigtighedsforpligtelserne i henhold til artikel 50. |
| MHRA Software Group-rammen | Den britiske godkendelsesprocedure anvender MHRA – ikke EMA eller BO | Forklar, hvordan I håndterer arbejdet med SaMD i Storbritannien – herunder britisk engelsk som en separat sprogvariant og tilpasning af International Reliance-dokumentationen? |
| Integration af softwaredatalager | Kontinuerlige udgivelser udelukker manuelle overleveringer | Hvilke repo’er opretter I forbindelse til (GitHub, GitLab, Bitbucket)? Gennemgå en typisk proces fra commit til udgivelse. |
| Integration af CI/CD-proces | Oversættelsen må ikke forhindre udgivelsen | Hvordan integreres jeres platform med Jenkins, GitHub Actions, GitLab CI eller CircleCI? |
| Understøttelse af ICU MessageFormat | Flertalsdannelse, køn, indsættelse af variabler på tværs af sprogversioner | Bekræft, at I fuldt ud understøtter ICU MessageFormat, og beskriv, hvordan reglerne for flertalsdannelse håndteres i jeres sprogteam. |
| Værktøjer til kontekstbaseret gennemgang | Påkrævet i forbindelse med validering af brugervenlighed i henhold til IEC 62366-1 | Kan lokale evalueringspersoner se og redigere oversatte strenge i den viste brugergrænseflade uden at skulle bruge tekniske værktøjer? |
| Tilgængelighedsstrenge | Tekst til skærmlæsere, alt-tekst og ARIA udgør et særskilt arbejdsforløb | Hvordan håndterer I tilgængelighedsstrenge, og hvordan tester I, at de vises korrekt på målsprogene? |
| Revisionsspor pr. projekt | Forventes af både det MDR-bemyndigede organ og det organ, der sikrer overensstemmelse med AI-forordningen | Hvilke revisionsdokumenter udarbejder I for hvert enkelt projekt, og hvor længe opbevarer I dem? |
Hos AdHoc Translations er vi certificeret i henhold til ISO 17100 og ISO 18587, og certifikaterne kan ses på vores hjemmeside, hvor de kan kontrolleres direkte:
- vores SmartConnect leverer det datalager og den CI/CD-integration, som den tekniske side af oversættelsen af medicinsk software kræver;
- vores SmartDesk indeholder det projektbaserede revisionsspor, som det MDR-bemyndigede organ kræver i sin gennemgang, og som den tekniske dokumentation i henhold til AI-forordningen forudsætter; og
- vores SmartEdit understøtter kontekstbaseret gennemgang uden en licens til et udviklerværktøj
For en grundigere gennemgang af kvalitetssikringsprocessen inden for al medicinsk oversættelse, se kvalitetssikring af medicinske oversættelser.
Ofte stillede spørgsmål
Hvad er SaMD?
Software som medicinsk udstyr (SaMD), som defineret af International Medical Device Regulators Forum, er software, der er beregnet til et eller flere medicinske formål, og som udfører disse formål uden at være en del af et medicinsk udstyr i form af hardware. Eksempler herpå er algoritmer til diagnostisk billedbehandling, apps til symptomtjek og systemer til støtte for kliniske beslutninger. SaMD er omfattet af forordning (EU) 2017/745 (MDR) i EU.
Gælder EU’s AI-forordning for medicinsk software?
Ja, hvis softwaren indeholder AI- eller maskinlæringskomponenter. AI-baserede medicinske produkter, der er reguleret i henhold til MDR eller IVDR, klassificeres automatisk som højrisikoprodukter i henhold til artikel 6, stk. 1, i AI-forordningen. I forlængelse af den politiske aftale om “Digital Omnibus” den 7. maj 2026 er fristen for overholdelse af kravene til indbygget medicinsk AI i henhold til bilag I blevet forlænget til den 2. august 2028, forudsat at aftalen vedtages formelt.
Hvad er MDR-regel 11?
Bilag VIII, regel 11, i forordning (EU) 2017/745 udgør den softwarespecifikke klassificeringsregel i henhold til MDR. Her klassificeres det meste software, der betragtes som medicinsk udstyr, som klasse IIa eller højere, afhængigt af konsekvenserne af en fejl i informationen. Beslutninger, der kan medføre død eller uoprettelig skade, placerer softwaren i klasse III. Beslutninger, der kan medføre alvorlig forværring af en tilstand, placerer den i klasse IIb. Det meste diagnostiske og terapeutiske informationssoftware hører til klasse IIa.
Hvordan adskiller oversættelse af medicinsk software sig fra almindelig softwarelokalisering?
Oversættelse af medicinsk software skal opfylde de lovgivningsmæssige krav, der gælder for medicinsk udstyr: sprogkravene i MDR artikel 10, stk. 11, ledsagende oplysninger i bilag I, afsnit 23, dokumentation af softwarens livscyklus i henhold til IEC 62304, validering af brugervenlighed i henhold til IEC 62366-1 samt (for AI-komponenter) teknisk dokumentation i henhold til AI-forordningen. Almindelig softwarelokalisering er ikke underlagt nogen af disse krav. Oversættelsesleverandøren skal have indsigt i både lovgivningen og integrationen i softwareudviklingen.
Forbind dine systemer med SmartConnect
Hvis din nuværende oversættelsesleverandør ikke kan integrere med dit software-repo, din CI/CD-proces og dine krav til revisionsspor fra det bemyndigede organ i én samlet proces, er en struktureret leverandørvurdering det næste skridt. Forbind dine systemer med SmartConnect for at se, hvordan vi håndterer oversættelse af medicinsk software for SaMD-, SiMD- og virksomheder, der laver ledsager-apps i hele EU og Storbritannien.
Kilder
- EUR-Lex, forordning (EU) 2017/745 (MDR), bilag VIII, regel 11. https://eur-lex.europa.eu/eli/reg/2017/745/oj. Tilgået den 14. maj 2026.
- EUR-Lex, forordning (EU) 2017/746 (IVDR). https://eur-lex.europa.eu/eli/reg/2017/746/oj
- EUR-Lex, forordning (EU) 2024/1689 (EU’s AI-forordning). https://eur-lex.europa.eu/eli/reg/2024/1689/oj
- Rådet for Den Europæiske Union, politisk enighed om AI-forordningen og Digital Omnibus, 7. maj 2026 (med forbehold for formel vedtagelse). 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 (opdateret 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, revideret december 2024).
- MHRA International Reliance-ordningen (annonceret den 22. juli 2025; starter i første halvår 2026).
- GOV.UK, National Commission into the Regulation of AI in Healthcare (indsamling af høringsmateriale fra 18. december 2025 til 2. februar 2026; anbefalinger forventes i 2026.
- IEC 62304, IEC 82304-1, IEC 62366-1, ISO 14971, ISO 13485.
- ISO 17100:2015 og ISO 18587:2017.