top of page

Slik setter du opp AI-dokumentoversettelse for teknisk MDR-dokumentasjon

for 3 døgn siden
6 min lesing
Gjennomgangsansvarlige sammenligner en oversatt teknisk fil for medisinsk utstyr med kildeteksten

En teknisk fil for medisinsk utstyr kan løpe opp i tusenvis av sider, fra de generelle kravene til sikkerhet og ytelse til risikofilen og hver bruksanvisning. Du kan oversette den med AI-dokumentoversettelse og holde deg innenfor MDR, men bare i én rekkefølge: lås terminologien, bind modellen til den, og sett så en sertifisert lingvist foran outputet før det når filen.


AD VERBUM er et EU-hostet AI-oversettelsesselskap som kjører teknisk MDR-dokumentasjon gjennom en klienttilpasset LLM bundet til termbasen din, etterfulgt av sertifisert medisinsk gjennomgang etter ISO 13485, ISO 17100 og ISO 18587, uten public cloud-transitt og uten trening på klientdata. Her er arbeidsflyten vi bruker, trinn for trinn, så teamet ditt kan sette opp den samme.


Én ting først. MDR forbyr ingen verktøy og nevner ikke noe AI-oversettelsesprodukt. Det som kontrolleres, er om det oversatte dokumentet er nøyaktig og oppdatert og støttet av et kvalitetssystem. Det er et spørsmål om gjennomgangsdokumentasjonen din, ikke modellen din.


Hva MDR krever av en oversatt teknisk fil


Artikkel 10(11) i forordningen om medisinsk utstyr (forordning (EU) 2017/745) krever bruksanvisningen og merkingen på det offisielle språket eller språkene i hver medlemsstat der du selger utstyret. Vedlegg II i samme forordning fastsetter selve den tekniske dokumentasjonen, som må være klar, strukturert og lett å søke i. En oversettelse som avviker fra kilden, bryter begge forpliktelsene på én gang.


To dokumenttyper bærer størst risiko. Bruksanvisningen (IFU), håndboken en kliniker eller pasient faktisk leser, og sammendraget av sikkerhet og klinisk ytelse (SSCP) etter artikkel 32 for implanterbart utstyr og klasse III-utstyr, som blir offentlig via EUDAMED. En feil i en av dem er en feil i dokumentasjonen, ikke et utkast du stille kan rette senere.


Lingvister bygger en termbase fra godkjent dokumentasjon

Slik setter du opp AI-dokumentoversettelse for tekniske MDR-filer


Seks trinn, i rekkefølge. Hvert trinn mater det neste, så å hoppe over de tidlige koster deg til slutt.


  1. Lås utstyrets termbase og oversettelsesminne. Hent godkjent IFU-ordlyd, utstyrsnavn og advarselstekst fra tidligere aksepterte filer inn i en termbase, og last inn oversettelsesminnet ditt så tidligere godkjenninger føres videre.

  2. Kjør styrt generering på en klienttilpasset modell. Gi termbasen og minnet til en klienttilpasset open-weight-LLM så den produserer output bundet til din godkjente terminologi i stedet for fri tekst.

  3. Bruk sertifisert etterredigering etter ISO 18587 og ISO 13485. En kvalifisert medisinsk lingvist redigerer outputet og tar ansvar for den endelige teksten, innenfor et kvalitetssystem for utstyr.

  4. Kontroller konsistens med EUDAMED og merking. Bekreft at utstyrsnavn, UDI-DI og tiltenkt formål stemmer overens på tvers av filen, merkingen og EUDAMED-oppføringen på hvert språk.

  5. Før revisjonssporet for det tekniske kontrollorganet. Registrer hvem som gjennomgikk hva, mot hvilken versjon av termbasen, så gjennomgangshistorikken kan hentes frem ved revisjon.

  6. Kjør det hele på EU-hostet infrastruktur. Hold kildefiler, minne og output på EU-servere, uten public cloud-API noe sted i løpet.


Legg merke til at modellen sitter i midten, ikke til slutt. Det siste ordet om en teknisk MDR-fil tilhører en person som signerer for den.


Lås terminologien før modellen kjører


Dette er trinnet team hopper over, og det som avgjør kvaliteten. En termbase for utstyret fastsetter hvordan en kontraindikasjon, en advarselsbildetekst eller et bestemt komponentnavn vises hver gang, så modellen ikke kan omformulere et sikkerhetsbegrep til noe en gjennomgangsansvarlig senere må fange opp. Vil du ha det fulle bildet av hvorfor styrt generering pluss sertifisert gjennomgang er det vi mener med begrepet, redegjør vi for det i hva AI-oversettelse betyr for regulert innhold. Bygg termbasen fra filer et teknisk kontrollorgan allerede har akseptert, ikke fra et nytt glossar skrevet for dette prosjektet.


Den sertifiserte gjennomgangen er det det tekniske kontrollorganet kontrollerer



ISO 18587 er standarden for full etterredigering av maskin- og modelloutput, og den pålegger en navngitt, kvalifisert etterredaktør ansvaret for den endelige oversettelsen. Revisjonen fra 2026 utvider virkeområdet til å dekke output fra AI og store språkmodeller direkte. Kombiner den med ISO 13485, standarden for kvalitetsstyring av medisinsk utstyr, og gjennomgangen slutter å være et høflig blikk og blir et kontrollert trinn som etterlater dokumentasjon.


Forordningen selv støtter dette. Vi går gjennom hvorfor MDR tillater verktøyet, men krever gjennomgangen, i tillater MDR AI-oversettelse for bruksanvisning og merking, og hvilke utstyrsdokumenter som egner seg for arbeidsflyten, i hvilke dokumenter for medisinsk utstyr som egner seg for AI-oversettelse med menneskelig gjennomgang.


Sikker, EU-hostet enhet for kontrollerte oversettelsesdata

Hold EUDAMED, merking og revisjonsspor på linje


En teknisk fil står ikke alene. Utstyrsnavnet og UDI-DI i filen må stemme overens med merkingen og EUDAMED-registreringen, på hvert språk, ellers finner en revisor gapet. Å holde disse flatene konsistente er en egen oppgave, og vi dekker fristen 28. november 2026 for det i kan AI-oversettelse holde EUDAMED-utstyrsdata konsistente før november 2026.


Revisjonssporet er leveransen kjøpere undervurderer. Under EUs AI-forordning (forordning (EU) 2024/1689) forventes et AI-system som brukes i en regulert prosess å føre opptegnelser over hvordan output ble produsert og kontrollert. En dokumentert sertifisert gjennomgang gir deg den opptegnelsen. Et uloggført maskingjennomløp gir deg ingenting å vise frem.


Der det går galt


Tre feilmønstre forklarer de fleste av de avviste MDR-oversettelsene vi blir bedt om å rette i etterkant:


  • En ustyrt modell. Kjør en generell LLM uten termbase, og den omformulerer advarsler, finner opp synonymer for utstyrsnavn og produserer flytende tekst som stryker på terminologigjennomgangen.

  • Ingen menneskelig godkjenning. Å skyve rått output inn i filen betyr at ingen kvalifisert person har tatt ansvar for det, nettopp det ISO 18587 og ISO 13485 krever.

  • Public cloud-transitt. Å sende den tekniske filen gjennom et offentlig oversettelses-API flytter kontrollerte produktdata over servere du ikke kontrollerer, og bryter EU-datalagringen som GDPR og din egen sikkerhetsgjennomgang forventer.


Vi bygde utstyrs-arbeidsflyten vår rundt disse tre fellene. AD VERBUM kjører MDR- og IVDR-filer på EU-hostede, klienttilpassede modeller med sertifisert SME-gjennomgang, og du kan se hvordan vi rangerer den tilnærmingen mot andre leverandører i beste AI-oversettelsestjenester for bruksanvisning og merking av medisinsk utstyr og beste AI-oversettelsesselskaper for MDR- og IVDR-dokumentasjon.


Våre oversettelsestjenester for medisinsk utstyr


oversettelsestjenester for regulerte sektorer kjører på ISO 27001- og ISO 42001-sertifisert, EU-hostet infrastruktur, uten avhengighet av public cloud-verktøy for kjernebehandling. Hvert prosjekt kjører gjennom vår AI+HUMAN-hybridarbeidsflyt: vi tar først inn kundens oversettelsesminner og termbaser, vårt egenutviklede LLM-baserte LangOps System genererer output bundet til kundeterminologien på klienttilpassede open-weight-modeller, og våre sertifiserte fageksperter gjennomgår for teknisk nøyaktighet og regulatorisk samsvar. Vår QA er tilpasset ISO 17100 og ISO 18587, med sektorspesifikke krav som ISO 13485 kvalitetsstyring for utstyr og språkreglene i MDR artikkel 10(11), der det er relevant. Vi betjener kunder innen Life Sciences, Juss, Finans, Forsvar og Produksjon på over 150 språk med over 3 500 faglingvister. For team som håndterer revisjonssensitivt innhold: kontakt oss for å drøfte sikkerhets- og samsvarskravene dine direkte.


FAQ


Tillater MDR AI-dokumentoversettelse for tekniske filer?


Ja. Forordningen om medisinsk utstyr (forordning (EU) 2017/745) nevner ingen verktøy og forbyr ingen. Artikkel 10(11) krever at bruksanvisning og merking er nøyaktige på hvert markeds offisielle språk, og vedlegg II krever klar, oppdatert teknisk dokumentasjon. AI-oversettelse oppfyller det når en sertifisert lingvist etterredigerer outputet etter ISO 18587 og ISO 13485.


Hva kontrollerer det tekniske kontrollorganet egentlig?


Dokumentasjonen, ikke modellen. Et teknisk kontrollorgan kontrollerer om det oversatte dokumentet er nøyaktig og oppdatert, og om kvalitetssystemet ditt styrte hvordan det ble produsert. En dokumentert sertifisert gjennomgang etter ISO 13485 og ISO 17100 svarer på det, så hold gjennomgangsansvarlig, versjonen av termbasen og godkjenningen i saken.


Hvorfor låse en termbase før modellen kjører?


Fordi termbasen er det som hindrer modellen i å omformulere et sikkerhetsbegrep. Den fastsetter utstyrsnavn, advarsler og ordlyd for kontraindikasjoner til de formene et teknisk kontrollorgan allerede har akseptert, så styrt generering produserer samsvarende tekst i stedet for flytende gjetninger som gjennomgangen så må fange opp.


Er rå maskinoversettelse det samme som AI-oversettelse her?


Nei. Rått maskin- eller NMT-output uten gjennomgang er ikke det vi mener med AI-oversettelse. AD VERBUMs AI-oversettelse er en klienttilpasset LLM bundet til termbasen din, etterfulgt av sertifisert menneskelig gjennomgang etter ISO 18587. Gjennomgangen er forskjellen, ikke et synonym.


Hvordan holder AI-dokumentoversettelse data innenfor EU?


Ved å kjøre på EU-hostet infrastruktur uten public cloud-API i løpet og uten trening på klientdata. Det holder kontrollert teknisk dokumentasjon under EU-datalagring, som GDPR og de fleste sikkerhetsgjennomganger for medisinsk utstyr krever før en fil forlater systemene dine.


Hva bryter MDR-samsvaret raskest?


Ugjennomgått output i en sikkerhetskritisk setning. En IFU-advarsel eller en SSCP-erklæring etter artikkel 32 som ingen kvalifisert lingvist har signert for, er en feil i det offentlige registeret. Ustyrte modeller, manglende godkjenning og public cloud-transitt er de tre årsakene vi ser oftest.


Anbefalt


 
 
bottom of page