Sådan laver du en proces til ISO 13485
ISO 13485 gør registreringerne til dokumentation for en myndighed: verifikation mod designinputtet, validering mod brugerens behov, en port for designoverførsel og en begrundelse på hver stopgren.
En proces til ISO 13485 er en dokumenteret procedure, hvis output er myndighedsdokumentation: risiko føder hvert stadie, hvert designoutput verificeres mod sit input, og produktet valideres derefter i brug.
Kort fortalt
- Verifikation tester outputtet mod designinputtet; validering tester produktet mod brugerbehovet.
- Hver stop-, afvisnings- og omarbejdningsgren bærer en registreret begrundelse: en stoppet vej er også dokumentation.
- Designoverførsel er en port: specifikationen skal kunne produceres, ikke blot være korrekt.
- Hvor 9001 lader organisationen bestemme, navngiver 13485 en dokumenteret procedure punkt for punkt.
- Risiko er et input til hvert stadie frem for et register, der gennemgås én gang ved business casen.
Verifikation og validering er to kasser
ISO 13485 er bygget på ISO 9001 og afviger på to ting, der ændrer, hvordan en proces bliver tegnet. Risiko er ikke en måde at tænke på her, det er en fil: sporbar fra tilsigtet anvendelse over farer til restrisiko, og konsulteret ved hvert stadie. Og registreringerne skrives ikke til organisationens egen forbedring: en inspektør læser dem år senere, uden de folk, der traf beslutningerne. En proces, der er tilstrækkelig under 9001 og tavs om, hvorfor en mulighed blev forkastet, er ufuldstændig under 13485.
Verifikation og validering er ikke to navne for test. Den ene spørger om specifikationen, den anden om brugeren, og hver registreres mod sine egne acceptkriterier, og derfor er det at smelte dem sammen til én testrække det hyppigste fund på designstyring, der findes. En sammenlagt kasse giver ét udfald, hvor designfilen har brug for to, og et udfald, ingen kan hænge på et krav, er ikke dokumentation for, at kravet blev opfyldt. De fleste nedarvede udviklingsforløb står i den tilstand: heriblandt eksemplet på denne side.
Eksemplet herunder er et generelt stage-gate-forløb, og det bærer præcis én testrække: »Planlæg og gennemfør valideringstest«. Intet i det verificerer et designoutput mod specifikationen, og det er sammenlægningen i sin reneste form, så læs diagrammet som tilstanden før og tilføj den række, det mangler, efter »Byg en fungerende prototype«. Hvad det til gengæld gør rigtigt, er stopvejene: to fejl vender tilbage til »Udarbejd det detaljerede design«, og hver port beholder en Afvist-række, hvis opgave er at holde en begrundelse.
Tag en idé til et overførbart design
Et stage-gate-forløb med én testrække og intet verifikationstrin. Læs det som tilstanden før, og tilføj så den kasse, det mangler.
Regulering er et designinput
Idé, screening, gennemførlighed, koncept, og så »Afklar lovgivningsmæssige krav«. Den ligger i banen Kvalitet, mens business casen stadig bygges, frem for efter at et design findes. Tilsigtet anvendelse og den gældende lovgivning er input, der skal verificeres op imod senere, ikke en gennemgang til sidst.
Et stop kræver en begrundelse på skrift
»Gate 1: udvikl eller stop?« ankommer med begge stopveje tegnet: »Retur« sender casen tilbage til »Udarbejd business casen«, og »Stop« ender ved »Idé lagt på hylden med begrundelse«, en kasse, hvis formål er dens sidste ord. »Go« ankommer i næste stadie. En port, der kun kan bestås, er en milepæl.
To test, én række på diagrammet
Omarbejdningen går tilbage: »Er designreviewet godkendt?« sender »Omarbejd« til »Udarbejd det detaljerede design«, og grenen »Godkendt« direkte ind i »Planlæg og gennemfør valideringstest«. Den række er valideringen; ingen række verificerer outputtet mod specifikationen, og »Opfylder produktet kravene?« fejler også tilbage til designet.
Overførsel er en port, ikke en overlevering
Designoverførslen hører ved »Kør en begrænset pilotproduktion«: det punkt, hvor et design, der virker, skal vises at kunne produceres på den linje, der skal lave det. »Gate 2: godkendes lancering?« sender derefter »Forlæng pilot« tilbage til den pilot og »Stop« til »Lancering stoppet ved gate 2«.
Sådan fungerer det
Skriv designinputtene først
Tilsigtet anvendelse, brugerbehov, de gældende lovgivningsmæssige krav og de risikokontroller, der følger af dem. Det er de ting, verifikationen senere testes op imod, så et vagt input gør verifikationen ufalsificerbar. Et input, der ikke kan vises opfyldt, er et input, der bliver diskuteret ved auditten.
Beslut, hvilke registreringer filen skal holde
Skriv dem op, før I tegner noget: referater fra reviews med de tilstedeværende funktioner navngivet, protokoller og resultater for verifikation og validering, begrundelsen bag hver forkastet mulighed, dokumentation for overførslen, og risikofilen ved hvert stadie. Kortets opgave er at vise, hvor hver af dem frembringes, så hver registrering har brug for en række, der frembringer den.
Skriv stadierne ind, og tilføj så den manglende test
Én række pr. stadie i kolonnen Bokstekst. Tilføj derefter den række, dette eksempel ikke har: et verifikationstrin efter »Byg en fungerende prototype«, hvis Linje til peger på designreviewet, så reviewet læser verifikationsresultater, og »Planlæg og gennemfør valideringstest« står tilbage med brugerens spørgsmål alene.
Giv hver port en gren, der stopper den
Hver port får Beslutning i kolonnen Figur, med sine udfald i Linjetekst i den rækkefølge, numrene står i Linje til. Giv det stoppende udfald sin egen Afvist-række frem for en pil ud i luften: i en designfil er den vej, der ikke blev valgt, dokumentation, som nogen bliver nødt til at læse.
Kontrollér reviewernes uafhængighed i banerne
13485 vil have, at hvert designreview omfatter repræsentanter for de berørte funktioner og en, der er uafhængig af det stadie, der gennemgås. At skrive hver ejer ind i kolonnen Lodret bane gør det kontrollerbart: i eksemplet ligger »Er designreviewet godkendt?« i banen Udvikling / R&D, ved siden af den prototype, det gennemgår.
Følg ét krav hele vejen gennem filen
Tag ét designinput (et krav fra »Afklar lovgivningsmæssige krav«) og følg det fremad. Det bør nå frem til en række, der verificerer det mod specifikationen, en række, der validerer det i brug, og et review, der læste begge resultater. Et krav, der kun når én af de tre, er det hul, en inspektør finder.
Faldgruber du skal undgå
Verifikation og validering lagt sammen
Verifikation og validering besvarer forskellige spørgsmål op imod forskellige acceptkriterier og frembringer hver sin registrering. Lagt sammen kan filen ikke vise, hvilket krav et bestået resultat opfyldte, og det er selve fundet.
Porte, ingen kan falde igennem
Hvor ingen gren forlader en port ud over den, der fortsætter, er reviewet et statusmøde. Stop- og omarbejdningsvejene er det, der gør den til en kontrol, og ræsonnementet bag dem hører i designfilen.
En overlevering forvekslet med overførsel
At sende tegninger til produktionen er ikke overførsel. Overførsel er beviset for, at specifikationen kan produceres gentageligt med den proces, det udstyr og de mennesker, der skal producere den, og den har en acceptregistrering.
Risiko vurderet én gang, ved konceptet
En risikovurdering skrevet ved konceptstadiet og aldrig åbnet igen kan ikke tage højde for, hvad designet blev til. Konsultér risikofilen ved hvert stadie, hvor designet ændrer sig, og registrér, hvad ændringen gjorde ved den.
Lav jeres egen designstyringsproces
Åbn stage-gate-eksemplet som jeres eget diagram, tilføj den verifikationsrække, det mangler, og giv hver port et registreret udfald.
Relaterede guides
Ofte stillede spørgsmål
Hvad er forskellen på verifikation og validering?
Verifikation spørger, om et designoutput opfylder det designinput, der er angivet for det: et målt mål op imod en tegning, et testet output op imod et nedskrevet krav. Validering spørger, om det færdige produkt opfylder brugerbehov og tilsigtet anvendelse under forhold, der repræsenterer faktisk brug, og på produkt fremstillet med den tilsigtede proces. Verifikation kan bestås på et produkt, der er forkert for sin bruger; validering er det, der fanger netop det. ISO 13485 kræver planer, registreringer og konklusioner for begge, hver for sig.
Hvad kræver ISO 13485 punkt 7.3?
Planlægning, dokumenterede designinput og designoutput, reviews ved planlagte stadier, verifikation, validering, overførsel, styring af designændringer og en design- og udviklingsfil pr. produkttype eller familie. Hver af dem er lige så meget en registreringsforpligtelse som en aktivitet. Punktet kræver også, at inputtene omfatter gældende lovgivningsmæssige krav og outputtene fra risikostyringen, og det er dét, der skiller et 13485-udviklingsforløb fra et stage-gate-forløb med et kvalitetstrin sat på.
Hvad er designoverførsel i ISO 13485?
Designoverførsel er den verificerede oversættelse af et design til produktionsspecifikationer: procedurer, værktøj, kontrolmetoder, oplæring og acceptkriterier, der gør det muligt at fremstille produktet gentageligt. Standarden kræver procedurer for overførsel med registreringer, der verificerer, at designoutputtene er egnede til produktion, før produktionen begynder. At behandle det som det øjeblik, tegningerne når fabrikken, er grunden til, at de første produktionsserier fejler af årsager, ingen prototype nogensinde viste.
Er ISO 13485 strengere end ISO 9001 om procedurer?
Ja, med vilje. ISO 9001:2015 lader organisationen bestemme, hvilken dokumenteret information den har brug for; ISO 13485:2016 navngiver dokumenterede procedurer punkt efter punkt (design og udvikling, indkøb, produktionsstyring, klagehåndtering, korrigerende handling) og beholder kravet om en kvalitetshåndbog, som 9001 droppede. Den praktiske konsekvens er, at et proceskort her ikke er valgfrit støttemateriale: det er en del af den procedure, en myndighed beder om at se, i den revision, der var gældende.
