Das Produkt haben Sie schon. Es fehlt „nur noch“ die Entwicklungsdokumentation.

Wenn Sie ein Pro­dukt als Medi­zin­pro­dukt zulas­sen wol­len, genügt es auch in der EU nicht mehr, die Kon­for­mi­tät des Pro­dukts nach­zu­wei­sen. Seit Ein­füh­rung der Medi­cal Device Regu­la­ti­on (MDR) müs­sen Sie auch nach­wei­sen, dass Sie den Entwick­lungs­prozess beherr­schen. Dazu benö­ti­gen Sie Ent­wick­lungs­do­ku­men­ta­ti­on – von den Benut­zer­an­for­de­run­gen über Ände­rungs- und Risi­ko­ma­nage­ment bis zum Test­nach­weis. Bei Pro­duk­ten, die schon län­ger im Markt sind, oder die ursprüng­lich nicht als Medi­zin­pro­dukt geplant waren, fehlt die­se jedoch oft oder ist unvoll­stän­dig. Häu­fig wird der Auf­wand zum nach­träg­li­chen Erstel­len von Ent­wick­lungs­do­ku­men­ten unter­schätzt. Um eine Kos­ten­ex­plo­si­on zu ver­mei­den, ist ein plan­vol­les Vor­ge­hen unerlässlich.

Zunächst sich­ten Sie, wel­che Doku­men­te Sie schon haben und was Sie davon ver­wen­den kön­nen. Spä­tes­tens hier stellt sich die Fra­ge: wel­che Doku­men­te brau­chen Sie eigent­lich? Risi­ko­ana­ly­se – Anfor­de­rungs­spe­zi­fi­ka­ti­on – Test­nach­wei­se – Tracea­bi­li­ty – …. Die Norm schreibt Ihnen die Inhal­te vor, aber kei­ne kon­kre­ten Doku­men­te. Dies legen Sie in einem Doku­men­ten­plan fest. Unse­re Emp­feh­lung: Blei­ben Sie nicht all­ge­mein! Legen Sie genau fest, wel­che Doku­men­te Sie kon­kret erstel­len wol­len, wel­che Inhal­te wo ste­hen sol­len und wel­chen Zweck und Gel­tungs­be­reich das jewei­li­ge Doku­ment hat. Ein guter Doku­men­ten­plan hilft, die Über­sicht zu behal­ten und ver­mei­det unnö­ti­ge Arbeit. Sepp.med hilft Ihnen ger­ne dabei.

Eine gute Idee ist es, bereits im Doku­men­ten­plan für jedes Doku­ment auch den jewei­li­gen Review­k­reis fest­zu­le­gen. So kön­nen Sie gezielt pla­nen, wen Sie wann dafür benö­ti­gen. Den­ken Sie dar­an: selbst wenn Ihre Exper­ten die Doku­men­ta­ti­on nicht selbst erstel­len, Sie brau­chen das Wis­sen Ihrer Exper­ten! Nur die­se wis­sen, war­um etwas gera­de so und nicht anders imple­men­tiert wur­de; nur die­se wis­sen, wie­so Tole­ran­zen etc. so und nicht anders gewählt wur­den. Pla­nen Sie genü­gend Zeit ein für Work­shops, zum Beant­wor­ten von Fra­gen und Durch­füh­ren von Reviews.

Wenn Sie schon die Arbeit inves­tie­ren, Ent­wick­lungs­do­ku­men­te zu erstel­len, wol­len Sie das natür­lich mög­lichst umfas­send tun. Lei­der funk­tio­niert das in der Pra­xis nicht. Ent­we­der wird die Doku­men­ta­ti­on so all­ge­mein, dass sie nicht aus­sa­ge­kräf­tig ist, oder sie wird so ufer­los, dass Sie nicht fer­tig wer­den. Fokus­sie­ren Sie sich lie­ber auf ein Pro­dukt, evtl. auf einen Release. Hier gilt: Je kon­kre­ter, des­to besser!

Gera­de wenn ein Pro­dukt bereits exis­tiert, besteht die Gefahr, dass bereits in die Anfor­de­run­gen Details aus der Imple­men­tie­rung ein­flie­ßen. Schließ­lich wis­sen Ihre Exper­ten ja bereits bereits genau, wie die Imple­men­tie­rung aus­sieht. Dies ist aus zwei Grün­den gefährlich:

Ers­tens wird häu­fig das Wie (Design) mit dem Wozu (Anfor­de­rung) ver­wech­selt. Wenn Sie Ham­mer und Nagel kon­stru­iert haben, ver­ges­sen Sie leicht, dass es eigent­lich dar­um ging, ein Bild auf­zu­hän­gen. Im schlimms­ten Fall ent­ste­hen Requi­re­ments, die die ursprüng­li­che Anfor­de­rung gar nicht mehr erken­nen las­sen. Dar­aus folgt dann, dass das Fal­sche getes­tet wird – um im Bild zu blei­ben, Grö­ße und Gewicht des Ham­mers, anstel­le, ob das Bild an der Wand hält.

Zwei­tens besteht die Gefahr, dass alle mög­li­chen Details, weil man sie ja schon kennt, in Anfor­de­run­gen gegos­sen wer­den, auch wenn dies eigent­lich nicht not­wen­dig wäre. Dadurch wird der Test unnö­tig auf­ge­bläht. Schließ­lich müs­sen zu allen Anfor­de­run­gen Test­nach­wei­se erbracht werden.

Es ist eines der schwie­rigs­ten Din­ge, einen ange­mes­se­nen Grad an Detail­lie­rung zu fin­den und zu hal­ten. Als Leit­fa­den emp­fiehlt sich die Fra­ge: Muss die­se Eigen­schaft wirk­lich getes­tet wer­den? Wür­de eine ent­schei­den­de Funk­tio­na­li­tät feh­len oder von dem Pro­dukt eine Gefahr aus­ge­hen, wenn wir das nicht getes­tet haben.

Wenn in Ihrem Unter­neh­men bis­her kei­ne durch­gän­gi­ge Ent­wick­lungs­do­ku­men­ta­ti­on exis­tiert, haben die ver­schie­de­nen Arbeits­grup­pen meist ihre eige­ne Tra­di­ti­on und Vor­stel­lung, wie und was zu doku­men­tie­ren ist. Um ein ein­heit­li­ches Bild zu errei­chen, genügt es nicht, dass Sie Gui­de­lines erstel­len und verteilen.

Las­sen Sie Ihre Arbeits­grup­pen nicht allein! Stel­len Sie ihnen einen Mode­ra­tor an die Sei­te, der den Über­blick behält, Reviews mode­riert und bei strit­ti­gen Fra­gen ver­mit­teln kann. Dadurch ver­kür­zen sich Dis­kus­sio­nen und Reviews wer­den effi­zi­en­ter. Ein erfah­re­ner Mode­ra­tor, der wirk­lich unter­stützt, erhöht deut­lich die Bereit­schaft der Arbeits­grup­pen, die benö­tig­te Doku­men­ta­ti­on zu erstellen.

Jeder Inge­nieur ent­wi­ckelt lie­ber Neu­es, als eine Doku­men­ta­ti­on zu schrei­ben. Noch schlim­mer ist es, wenn er es im Nach­hin­ein tun muss. Zudem haben Ent­wick­ler, die ja natur­ge­mäß tief in ihr jewei­li­ges The­ma ein­drin­gen, häu­fig nicht den Blick dafür, wel­che Doku­men­ta­ti­ons­tie­fe ange­mes­sen ist. Las­sen Sie sich hel­fen: holen Sie sich Requi­re­ments- und Test­ex­per­ten hin­zu. Die bes­ten Ergeb­nis­se erzie­len Sie, wenn Ihre Exper­ten eng mit Requi­re­mentsexper­ten zusam­men­ar­bei­ten; die einen haben das Wis­sen über das Pro­dukt, die ande­ren das Wis­sen über die Methodik.

Sie möch­ten mehr dar­über erfah­ren? Neh­men Sie ger­ne Kon­takt zu mir auf.

Blei­ben Sie auf dem Lau­fen­den – mit dem monat­li­chen sepp.med Newsletter: