QA - Bloggen

Det här ska du tänka på när du testar produkter inom Medtech

Skriven av Olof Klason | 2024-06-26 17:57

Medtech-produkter. Phu tänker du med all rätt, jag tänkte detsamma. Jag kom in helt grön på test av Medtech-produkter och min uppgift var att sätta upp en End-to-End verifieringsplan i ett projekt som innefattade utveckling av både hård och mjukvara. Det finns en del saker som är bra att känna till samt tänka på vid testning av produkter inom Medtech och det tänkte jag gå igenom i denna artikel.

 

EU:s förordning MDR och standarder vid testning inom Medtech

 

CE-märkning & Regulatory Classification Plan

Det första som är viktigt att känna till är att alla tillverkare som ska lansera en medicinteknisk produkt på den europeiska marknaden måste CE-märka sin produkt för att visa att de följer EU:s förordning MDR, Medical Device Regulations.

 

EU:s regelverk kräver även att tillverkaren ska ha en Regulatory Classification Plan och minst en person som är sakkunnig inom det medicintekniska området, som också ansvarar för att ta fram denna plan. I planen ska det framgå vilka standarder som är aktuella att följa samt vilken klassificering produkten kommer få. Den regulatoriska planen påverkar givetvis produktutvecklingsstrategin och teststrategin vilket gör det viktigt att alla som jobbar inom produktutveckling av MDR läser den och förstår den.

 

Läs igenom tillämpliga standarder

Det finns inget strikt lagkrav på att du måste följa en viss standard under testningen men det blir lättare för dig att påvisa att produkten följer MDR-förordningen genom att följa de ISO/IEC standarder som finns. Det kan vara bra att vara påläst kring standarden som ska följas och hur du bäst tillämpar den mot just din produkt. Lägg även ner tid på att läsa igenom och förstå standardens definitioner, dess nyckelord. Det finns troligtvis skillnader mellan ordens betydelse hos dig och vad som avses i standarden.

 

Ta hjälp av ett certifieringsorgan

För att bevisa att standarden följs behöver ni att ett certifieringsorgan granskar all dokumentation och i vissa fall utför de även certifieringstester såsom Lågströmsdirektivet (EN 62479:2010), IP-klassning (IEC 60529), Safety-tester (IEC 60601-1- 2:2104).

 

Hantera era krav

 

Gå igenom utvecklingsprocessen i ledningssystemet

Det finns krav inom MDR att det ska finnas ett ledningssystem och troligtvis har ni redan ett på plats. Dra inspiration av processer, rutiner och mallar som ni redan har.


Finns det några guldkorn som ni kan tillämpa omedelbart?
Vilka måste ni använda?
Vad saknas som ni måste komplettera med eller behöver uppdatera?

 

Definiera eller förstå ert Intended Use

”Intended use” dvs produktens avsedda användning lägger grunden för testplanering och testaktiviteterna eftersom den berättar vad produkten syftar till och hur den ska användas. Om ni utvecklar en ny produkt måste en ”Intended Use” definieras från börjar och alla krav som ni skriver behöver ta produkten i den riktningen. Jobbar ni med en befintlig produkt så har den redan ett ”Intended Use” definierat, detta behöver alla förstå och verka för.

 

Granska och förstå kraven väl

Granska funktions-, prestanda-, säkerhets- , hållbarhets- och andra krav för er produkt så att de är tydliga och konsekventa. Det ska gå att spåra alla ändringar i kraven genom hela processen från ”Intended Use” till testfallen och dess utfall. Gå även igenom arkitekturen löpande med projektets arkitekt för att förstår hur systemet är uppbyggt, hur förändringar påverkar systemet och om något behöver djupare testning.

 



Testplanering

 

Utveckling är mer än bara produkten

Utveckling av nya produkter är inte bara utveckling av själva produkten. På samma sätt som en byggnad behöver byggnadsställningar under tiden bygget pågår behövs olika testsystem och testfixturer finnas. Det kan till och med vara så att enskilda testsystem behöver utvecklas för den produkten som ska tas fram vilket blir en viktigt faktor som kan påverka tidplanen, budgeten och kan behöver framförhållning samt viss övertalning mot beställarna.

 

  • Testsystem för att testa hårdvara
    När ni testar hårdvara måste ni ha rätt utrustning på plats. Behöver något testsystem byggas? Hur lång tid tar det? Kan det återanvändas? Kan det automatiseras eller behöver det viss manuell hantering?

    Produkten ni ska testa kanske har knappar som ska tåla 10 000 knapptryckningar. Att låta testarna trycka in knapparna 10 000 gånger är inte bara ett slöseri med tid utan det blir till slut ett arbetsmiljöproblem med utslitna fingrar. Kan ni istället bygga en knapptryckarmaskin som gör jobbet åt er så sparar ni troligtvis tid och slitage, och kanske kan maskinen återanvändas till ett annat typ av test med lite modifiering.

  • Testsystem för att testa mjukvara
    I vissa fall saknas befintliga system som har förmåga att testa av just er produkt, då behöver ni kanske även ta fram specialanpassade testsystem som gör jobbet rätt. Det kan vara en mjukvara som simulerar sensordata, andra mjukvaror eller integrationer.

    Exempelvis en IOT-produktkedja där alla komponenter ännu inte finns tillverkade, men behöver simuleras tidigt i utvecklingsprocessen, så att ni kan skapa er en så verklighetstrogen end-to-end-kedja så tidigt som möjligt för att upptäcka stora problem. Men eftersom er produkt är en Medical Device så behöver även dina testsystem valideras, på liknade sätt som vi gör med fysiska system för att säkerställa att vi kan lita på dem.

 

Externa tester påverkar tidsplan och teststrategi

Glöm inte att räkna in de externa testerna i era testplaner, då de påverkar din teststrategi och kräver längre ledtider innan ni kan slutföra produkten för produktion eller lansering. Vissa typer av tester måste göras av ett certifieringsorgan i ett kontrollerat labb för att påvisa att de följer standarden. Det kan vara en lång väntan innan ni får tid till att utföra dessa tester så för att se till att produkten håller rätt kvalitet kan ni göra Pre-Compliance tester innan, antingen själva eller med hjälp av något annat externt labb.

 

Förstå produktens komplexitet

Prata med utvecklingsteamet och be dem förklara sina processer, hur de arbetar och hur de själva testar. Få koll på vad som kommer vara komplext i lösningen, det kan ge dig värdefull information för var du ska fokusera dina tester för att minska riskerna att någon bugg slinker igenom. Ta även reda på hur mycket som automatiseras och vilken typ av prestanda och säkerhetstester som de kommer utföra. Då kan du planera kompletterande test istället för att testa dubbelt eller riskera att delar av systemet inte testas alls.

 

 

Validering

 

Validera kraven kontinuerligt

Kraven bör valideras kontinuerligt så att ni säkerställer att ni bygger rätt produkt och uppfyller det som avses med produktens ”Intended use”. Validering av krav ger alla inblandade en bättre förståelse av produkten kan bli innan den har byggts. Det ger även information om vilka typer av tester och testmetoder som kommer behövas.

 

Testmetoder behöver vara validerade

Att utveckla en ny testmetod och få den validerad kan ta tid.

I exemplet med knapptryckarmaskinen - varje gång maskinen trycker på knappen så trycker den faktiskt in knappen in varje gång och inte bara hälften av gångerna eller bara när den är på bra humör. Att metoden är validerad betyder att den går att lita på, metoden gör vad den är avsedd för och den har en tillräckligt hög noggrannhet.

Exempelvis, efter validering av din knapptryckarmaskin så har den lyckats trycka knappen 9 987 gånger på 10 000 försök. Med den kunskapen om maskinens noggrannhet kan du skruva upp antalet repetitioner lite grann så att 10 000 lyckade knapptryckningar uppnås. Du måste också kontrollera maskinen både före och efter tester och säkerställa att den går att använda och att den inte gick sönder under testet.

 

Dokumentation

Utvecklingsprocessen (som ska finnas beskriven i ledningssystemet) ska visa hur flödet från Intended Use - User needs - krav - design input - design output - verifiering - validering går till och dokumenteras.I praktiken innebär det att en extern part ska (när som helst) kunna hitta fullständig och vattentät spårbarhet kring förändringar som har skett i systemet. Dokumentationen ska svara på de klassiska fem frågorna: Vem?, vad?, varför?, hur? och när?. Här är några saker som är bra att tänka på gällande dokumentation:

 

  • Upp till 10 år efter att produkten slutat sälja behöver nödvändig dokumentation finnas tillgänglig. Det sätter krav på var och hur du dokumenterar samt förvarar testdata samt testutrustning. Dokumentationssystemet och testdatan behöver alltså hållas vid liv under en lång tid.
  • Märk alla testenheter, så det tydligt framgår vilken enhet som är vilken och hur den var konfigurerad i respektive test.
  • Fundera på och dokumentera vilka testenheter som behöver sparas respektive destrueras efter test. Vissa hårdvaror innehåller farliga ämnen och får inte lagras.

 

I testrapporterna krävs det att alla versioner på alla ingående komponenter finns dokumenterade samt vilken testutrustning som användes och när den senast kalibrerades så att tester går att återskapa.

 

 

Sammanfattning

 

Att planera och testa en medicinskteknisk produkt kan verka överväldigande men med tålamod och systematik kommer ni att nå målet med att skapa en kvalitativ och säker produkt. För att underlätta er testprocess är det bra att knyta kontakter med alla inblandade. Gå igenom berörda standarder tillsammans med de som ansvarar för den regulatoriska planen och att ta reda på vilka delar som är lämpliga för just er produkt och välj testmetoder efter det. Planera in certifieringsorganets tillgänglighet tidigt i testplanen och gå igenom er utvecklingsprocess från ledningssystemet.

 

Sist men inte minst, var noga med att dokumentera, säkerställ att det finns tillräckligt med testenheter och använd validerade testmetoder samt testutrustning.