Oversættelse af medicinsk software: En køberguide fra 2026 til SaMD, SiMD og ledsager-apps

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

  • Forordning (EU) 2017/745 (MDR) regulerer software som medicinsk udstyr (SaMD) og software i medicinsk udstyr (SiMD). Regel 11 i bilag VIII er den softwarespecifikke klassificeringsregel, og det meste SaMD hører under klasse IIa eller højere.
  • Oversættelsesomfanget følger samme regel i artikel 10, stk. 11, som for hardwareenheder: de officielle sprog i alle de medlemsstater, hvor softwaren stilles til rådighed. Softwarespecifikke elementer (brugergrænsefladestrengene, fejlmeddelelser, hjælp i appen, udgivelsesnoter, slutbrugerlicensaftaler (EULA’er), IEC 62304-dokumentation og teknisk dokumentation i henhold til AI-forordningen) falder alle inden for dette omfang.
  • Forordning (EU) 2024/1689 (EU’s AI-forordning) klassificerer automatisk medicinsk udstyr med AI-funktioner som højrisiko i henhold til artikel 6, stk. 1. Den politiske “Digital Omnibus”-aftale af 7. maj 2026 forlængede fristerne for højrisiko-AI i henhold til bilag I til den 2. august 2028 og for selvstændig højrisiko-AI i henhold til bilag III til den 2. december 2027. Forpligtelsen til AI-færdigheder i henhold til artikel 4 gælder stadig fra den 2. august 2026.
  • Storbritannien er underlagt forordningen om medicinsk udstyr fra 2002 (Medical Devices Regulations 2002), og MHRA’s Software Group gennemfører et aktivt reformprogram. “International Reliance”-ordningen blev indført i første halvår af 2026; den nationale kommission for regulering af kunstig intelligens i sundhedssektoren fremlagde sine anbefalinger i 2026; CE-accepten i Storbritannien er blevet forlænget på ubestemt tid.
  • SaMD udgiver løbende i nye versioner. CI/CD-integration mellem oversættelsesproces og softwaredata er en absolut forudsætning – ikke blot en ekstra fordel.
  • Købere, der overvejer en leverandør af sprogtjenester (LSP), bør kræve overholdelse af ISO 17100 og ISO 18587, indgående kendskab til MDR-regel 11, kendskab til EU’s AI-forordning, kendskab til den britiske MHRA-ramme, API-integration med softwaredatalagre, understøttelse af ICU MessageFormat, værktøjer til kontekstbaseret gennemgang samt et revisionsspor for hvert enkelt projekt.

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.

SoftwarefunktionRegel 11-klasseInddragelse 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 skadeKlasse IIIFuldstændig overensstemmelsesvurdering med grundig gennemgang fra BOBilag 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 indgrebKlasse IIbFuldstændig overensstemmelsesvurdering fra BOBilag I, § 23, i sin helhed; uddrag af den tekniske dokumentation på anmodning
Oplysninger til brug ved diagnostiske eller terapeutiske beslutninger (andet)Klasse IIaFuldstændig overensstemmelsesvurdering fra BOBilag I, § 23 i sin helhed; overensstemmelseserklæring på medlemsstatens sprog
Software til overvågning af fysiologiske processer, hvor udsving kan udgøre en umiddelbar fareKlasse IIbFuldstændig overensstemmelsesvurdering fra BOBilag I, § 23, i sin helhed; indberetning af overvågningsdata pr. medlemsstat
Software til overvågning af fysiologiske processer (andet)Klasse IIaFuldstændig overensstemmelsesvurdering fra BOBilag I, § 23, i sin helhed
Al anden software (standard)Klasse ISelverklæretBilag 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.

KategoriPrimær læserRegulatorisk funktionOversættelsesspecifikt
UI-strenge (menuer, knapper, dialogbokse)BrugereUX; brugervenlighed i henhold til IEC 62366-1Strenglængde, flertalsdannelse, tilgængelighed
FejlmeddelelserBrugere, klinikereBrugersikkerhedKortfattet, klart sprog, konsistent terminologi
Hjælp i appenBrugereLedsagende oplysninger (bilag I, § 23)Kontekstbaseret gennemgang i layoutet
OnboardingforløbBrugereOrientering til førstegangsbrugKort tekst, skærm for skærm
UdgivelsesnoterBrugere, klinikereKommunikation efter produktet er på markedetVersionsstyret, kadencestyret
Elektronisk brugsanvisning (eIFU)Brugere, klinikereBilag I, § 23Fuldstændig oversættelse af brugsanvisningen, i henhold til myndighedskrav
EULA og privatlivspolitikBrugereJuraNøjagtig og med hensyn til jurisdiktion
Tilgængelighedsstrenge (skærmlæser, alt-tekst)Brugere af hjælpemiddelsteknologiOverholdelse af tilgængelighedskravEt særskilt arbejdsforløb, der ofte overses
Dokumentation vedrørende softwarecyklus i henhold til IEC 62304Bemyndiget organOverensstemmelsesvurderingFremsendt på BO’s arbejdssprog (ofte engelsk)
IEC 62366-1-dokument om brugervenlighedsdesignBemyndiget organValidering af brugervenlighedUnderstøtter godkendelse af oversat brugergrænseflade
Dokumentation vedrørende cybersikkerhedBO: de kompetente myndighederMDR, bilag I; MDCG 2019-16Der kan anmodes om uddrag på det lokale sprog
Teknisk dokumentation i henhold til AI-forordningenOrgan for overholdelse af AI-forordningenArtikel 11-15 i AI-forordningenSproget følger praksis i henhold til AI-forordningen
Meddelelse om gennemsigtighed i henhold til artikel 50 i AI-forordningenBrugereOplysninger om interaktion med kunstig intelligensPr. sprog; brugerrettet
Vigtig produktinformation vedrørende sikkerhed (software)Brugere; kompetente myndighederArtikel 89, stk. 8Pr. 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.

DatoHvad der er gældendeImplikationer for oversættelsen
1. august 2024AI-forordningen træder i kraftIngen direkte
2. februar 2025Forbudt AI-praksis og forpligtelser vedrørende AI-færdighederOversættelse af interne retningslinjer; indhold til personaleuddannelse
2. august 2025GPAI-modellens forpligtelserDokumentation til grundlæggende modeller, hvis sådanne anvendes
2. august 2026Forpligtelsen til at sikre AI-færdigheder (artikel 4)Medarbejderuddannelse, oplysninger om AI-færdigheder rettet mod brugerne pr. medlemsstat
2. december 2026Gennemsigtighed 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.

KriteriumHvorfor det er vigtigt for udviklingen af medicinsk softwareHvad man bør spørge om ved indhentning af tilbud
ISO 17100Procesgrundlag for menneskeudført oversættelseVedhæft venligst jeres aktuelle ISO 17100-certifikat samt oplysninger om certificeringsmyndigheden.
ISO 18587Påkrævet, når der anvendes MTPE (maskinoversættelse med menneskeudført efterredigering) til UI-strenge eller tekst i appenEr I certificeret i henhold til ISO 18587 for arbejdsgange med efterredigering af maskinoversættelser? Vedhæft venligst certifikatet.
ISO 27001Informationssikkerhed for reguleret softwareindholdBekræft venligst ISO 27001-certificeringen, og vedhæft dokumentation.
Ekspertise i MDR-regel 11Klassen afgør oversættelsens omfang og revisionssporetBeskriv, 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-forordningMedicinsk udstyr med kunstig intelligens, der udgør en høj risiko, skal ledsages af teknisk dokumentation i henhold til AI-forordningenBeskriv, 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-rammenDen britiske godkendelsesprocedure anvender MHRA – ikke EMA eller BOForklar, hvordan I håndterer arbejdet med SaMD i Storbritannien – herunder britisk engelsk som en separat sprogvariant og tilpasning af International Reliance-dokumentationen?
Integration af softwaredatalagerKontinuerlige udgivelser udelukker manuelle overleveringerHvilke repo’er opretter I forbindelse til (GitHub, GitLab, Bitbucket)? Gennemgå en typisk proces fra commit til udgivelse.
Integration af CI/CD-procesOversættelsen må ikke forhindre udgivelsenHvordan integreres jeres platform med Jenkins, GitHub Actions, GitLab CI eller CircleCI?
Understøttelse af ICU MessageFormatFlertalsdannelse, køn, indsættelse af variabler på tværs af sprogversionerBekræ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 gennemgangPåkrævet i forbindelse med validering af brugervenlighed i henhold til IEC 62366-1Kan lokale evalueringspersoner se og redigere oversatte strenge i den viste brugergrænseflade uden at skulle bruge tekniske værktøjer?
TilgængelighedsstrengeTekst til skærmlæsere, alt-tekst og ARIA udgør et særskilt arbejdsforløbHvordan håndterer I tilgængelighedsstrenge, og hvordan tester I, at de vises korrekt på målsprogene?
Revisionsspor pr. projektForventes af både det MDR-bemyndigede organ og det organ, der sikrer overensstemmelse med AI-forordningenHvilke 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