Skip to content

Consistentie in het ontwerpdossier

26 september 2016

 

medischehulpmiddelen

Tijdens het ontwikkelen en ontwerpen van een nieuw product wordt een veelheid aan informatie geproduceerd en vastgelegd in een groot aantal documenten. Al deze informatie is gerelateerd aan elkaar omdat het geheel van de documenten aangeeft dat het ontwerp aan de essentiële eisen van veiligheid en werkzaamheid voldoet. Wat ik echter vaak tegenkom in de documentatie, is dat de onderlinge verbanden tussen de documenten niet wordt aangegeven en niet in de tijd traceerbaar is.

Het dossier kan op hoofdlijnen worden onderverdeeld in de volgende elementen:

  • De ontwerp input: de requirements
  • De ontwerp output: de specificaties van het product en het fabricage proces
  • Risicomanagement: de faal modi en de beheersmaatregelen
  • De verificatie en validatie van het ontwerp: de test cases

Maar ook buiten het dossier om, bij bijvoorbeeld klachten, CAPA’s en andere non-conformiteitsinformatie is het belangrijk om te bepalen en vast te leggen om welke requirement / specificatie het gaat. Hierdoor is de impact van een non-conformiteit beter te plaatsen en is de noodzaak voor een verbetermaatregel duidelijker vast te stellen.

In de praktijk blijkt requirements management een lastige uitdaging. Zeker als je daarbij bedenkt dat het ook nog onderwerp is van voortdurende verandering. Traceerbaarheid van requirements verwijst naar het vermogen om de levensloop van een requirement te volgen van initiële voorwaarde tot vervulde wens (of omgekeerd). Het heeft veel waarde om het verhaal van het ontwerpteam te kunnen volgen op basis van de informatie die zij hierover hebben vastgelegd. Als ontwerpbesluiten moeilijk te herleiden zijn naar de ervaringen van het team tijdens het ontwikkelen en ontwerpen van het product of het proces, dan kan men moeilijk verwachten dat het management tijdens de ontwerpbeoordeling zonder meer groen licht geeft voor de volgende projectfase. Ook de aangemelde instanties of overheidsinspecteurs willen het ingediende technische dossier op systematische wijze kunnen lezen voordat zij goedkeuring verlenen aan een markttoelating. Daarmee lijkt dat zij voldoende hebben aan de tijdsopname op moment van beoordeling, maar de aangemelde instantie beoordeelt ook alle essentiële wijzigingen in het ontwerp. Daarvoor heeft zij traceerbaarheidsinformatie nodig. Ook de eigen organisatie heeft na lancering van het product of het proces belang bij traceerbare informatie, bijvoorbeeld als zij de risico’s van een proceswijziging wil inschatten of de impact van een klacht wil beoordelen. Requirements traceerbaarheid is dus een belangrijk principe om kwaliteit te waarborgen en biedt ondersteuning bij het continue verbeteren. Mijn ervaring is dat je over het algemeen al snel het spoor kwijtraakt door ontbrekende of doodlopende verwijzingen, tegenstrijdigheden of ontbreken van noodzakelijke informatie.

Een traceerbaarheidsmatrix kan hierbij uitkomst bieden. In de traceerbaarheidsmatrix wordt op de verticale as de individuele requirement aangeven en op de horizontale as de verschillende elementen van het ontwerpdossier. Het werken met ID nummers voor de verschillende elementen is onontbeerlijk voor het naspeurbaar houden van alle items. De matrix geeft je inzicht in de onderlinge relatie tussen documenten: het is een requirement management tool. De matrix geeft echter geen inzicht in de ontwikkeling van de requirement, omdat het slechts een snapshot in de tijd weergeeft. Het is dus minder geschikt als requirement traceability tool. Het bijhouden van de matrix is door alle veranderingen ook veel werk en de vraag bij het bestuderen van de matrix is dan ook altijd of deze nog actueel is. De kans is groot dat je naar documentatie wordt verwezen die zijn validiteit al lang heeft verloren.

Daarbij wil je niet dat je bij het lezen van een document naar de matrix terug moet om te bepalen wat de context van het document is. Elk document moet verwijzingen omvatten naar de op dat moment actuele versies van relevante documenten uit een ander niveau. Zo wil je bij validatiedocumenten weten welke versie van de requirement of specificatie met de test cases is geverifieerd. Al eerder schreef ik een blog over de Traceerbaarheid van risicomanagement in het technisch dossier van medische hulpmiddelen, waarbij dezelfde principes opgaan. Document management systemen helpen om de geschiedenis van documenten te achterhalen. Ze laten door middel van de audit trail de historie van het document zien. Van wezenlijk belang is dat bij elke wijziging van het document ook wordt aangegeven wat de reden van wijziging is, om daarmee volledig inzicht te krijgen in de ontwikkeling van elke requirement. Deze reden van wijziging ontbreekt echter vaak in de registratie van de documentwijzigingen. Soms laat deze zich nog destilleren uit de inhoudelijke wijzigingen, maar vaak blijf je met vraagtekens achter omdat essentiële informatie ontbreekt.

Het is belangrijk dat onderkend wordt dat requirements management en in het bijzonder requirements traceability belangrijk is om kwaliteit te waarborgen gedurende de levenscyclus van het ontworpen systeem (product of proces). Dan wordt duidelijk dat het uniek identificeren van requirements, vastleggen van relaties en het gebruik van bijvoorbeeld een requirements traceability matrix noodzakelijk is.

Advertenties
No comments yet

Geef een reactie

Vul je gegevens in of klik op een icoon om in te loggen.

WordPress.com logo

Je reageert onder je WordPress.com account. Log uit / Bijwerken )

Twitter-afbeelding

Je reageert onder je Twitter account. Log uit / Bijwerken )

Facebook foto

Je reageert onder je Facebook account. Log uit / Bijwerken )

Google+ photo

Je reageert onder je Google+ account. Log uit / Bijwerken )

Verbinden met %s

%d bloggers liken dit: