Unter Design Transfer versteht man den Prozess, mit dem die Entwicklungsergebnisse in abgestimmter Weise an die Produktion übergeben werden, damit diese das Produkt spezifikationsgemäß herstellen kann.
Auf Deutsch spricht man vom „Design- und Entwicklungstransfer“ oder von der „Übertragung der Entwicklung“. Welche Anforderungen an den Design Transfer Sie als Medizinproduktehersteller erfüllen müssen, erfahren Sie in diesem Beitrag.
Ziele des Design Transfers
Die Entwicklungsabteilung hat die Aufgabe, Medizinprodukte zu entwickeln und zu spezifizieren, die den Patienten den versprochenen Nutzen liefern, und produktbedingte Risiken für Patienten, Anwender und Dritte zu minimieren.
Hingegen hat die Produktion die Aufgabe, die Produkte gemäß diesen Spezifikationen zuverlässig herzustellen. Und der Einkauf hat die Aufgabe, Materialien, Einzelteile, Baugruppen oder ganze Geräte zu beschaffen, die den Anforderungen genügen.
Der Design Transfer soll sicherstellen, dass die Produktion über alle Informationen verfügt, um dieses Ziel – die spezifikationsgemäße Herstellung – zu erreichen. Teil dieses Prozess ist oft die Industrialisierung.
Beispiel 1: Verfahren und Technologien auswählen
Die Entwicklung spezifiziert ein Gehäuse mit allen Maßen und Vorgaben für dessen Belastbarkeit. Ob dieses Gehäuse gemäß diesen Spezifikationen hergestellt werden kann und ggf. wie – das gilt es im Design Transfer zu bestimmen. Beispielsweise stehen Verfahren wie Spritzguss, CNC-Fräsen aus einem Vollmaterial oder der 3D-Druck zur Auswahl.
Beim Design Transfer ist deshalb auch zu prüfen, ob überhaupt ausreichend Informationen bereitstehen, um die verschiedenen Verfahren bewerten und daraus Spezifikationen für die Produktion ableiten zu können.
Beispiel 2: Fähigkeiten der Produktion sicherstellen
Die Produktion muss beispielsweise Folgendes prüfen:
- Kann das Produkt in der gewünschten Menge hergestellt werden?
- Sind die Bauteile und Werkstoffe in der gewünschten Stückzahl, in der benötigten Qualität, mit den gewünschten Lieferzeiten und Kosten verfügbar?
- Stehen die notwendigen Maschinen und Personen zur Verfügung?
- Gestatten es die zur Verfügung stehenden Verfahren und Technologien, die von der Entwicklung spezifizierten Toleranzen zu erreichen?
Besonders kritisch ist der Design Transfer, wenn die Produktion an eine externe Organisation ausgelagert wird.
Regulatorische Anforderungen an den Design Transfer
Forderungen der ISO 13485
Die ISO 13485 (Qualitätsmanagementsysteme für Medizinprodukte) enthielt vor der 2016er Ausgabe nur die Forderung, dass die Organisation angemessene Design Transfer Aktivitäten festlegen muss.
Die ISO 13485:2016 widmet dem Design Transfer ein eigenes Teilkapitel (7.3.8). Sie fordert explizit ein dokumentiertes Verfahren für den Design Transfer. Sie fordert weiter Aufzeichnungen der Ergebnisse und Schlussfolgerungen des Design Transfers.
Auch die Ziele ergänzt die ISO 13485:2016. Die Vorgängerversion wollte „nur“ sichergestellt haben, dass die Entwicklungsergebnisse daraufhin geprüft werden, ob sie für die Herstellung geeignet sind, bevor daraus Spezifikationen für die Produktion werden.
Nun muss auch sichergestellt werden, dass die Produktion überhaupt in der Lage ist, die Produkte so herzustellen, dass die Anforderungen an die Produkte erfüllt sind.
Forderungen der FDA
Die FDA schreibt im Kapitel zu den Design Controls (21 CFR part 820.30 (h)):
“Each manufacturer shall establish and maintain procedures to ensure that the device design is correctly translated into production specifications.”
Damit schlägt die FDA den Bogen noch etwas weiter als die ISO 13485: Der Design Transfer muss gewährleisten, dass die Produktionsspezifikationen der Entwicklung gerecht werden. Bei der ISO 13485 ging es „nur“ um die Prüfung der Entwicklungsergebnisse bevor daraus Produktionsspezifikationen werden.
Die Dokumentation des Design Transfers (Planung, Ergebnisse) ist kein verpflichtender Teil des Design History Files. Vielmehr muss der Device Master Record die Produktionsspezifikationen enthalten.
Tipps zum Design Transfer
a) Produktion frühzeitig mit einbeziehen
Der Design Transfer sollte nicht erst am Ende der Entwicklung erfolgen. Wenn dann die Produktion abwinkt, weil etwas nicht so hergestellt werden kann, wie sich das die Entwicklung vorstellt, ist es zu spät.
b) Design Transfer nicht als punktuelle Übergabe am Ende der Entwicklung durchführen
Folglich sollte die Produktion an mehreren Entwicklungsschritten beteiligt sein, beispielsweise bereits bei der Spezifikation der Produktanforderungen.
Die Design Review Meetings bieten sich an, um die Produktion frühzeitig einzubeziehen.
c) Design Transfer planen
Nicht nur weil die Regularien es fordern, sollte der Design Transfer genauso wie die Entwicklung geplant werden. Fordern Sie in Ihren Verfahrensanweisungen, wann wer in welcher Form den Design Transfer planen und durchführen muss. Die Verfahrensanweisung sollte auch festlegen, wie dieser Plan und wie diese Ergebnisse zu dokumentieren sind und wie bei Änderungen während der Entwicklung verfahren werden soll.
d) Produkt- und Produktionsanforderungen priorisieren
Die Produktion muss verstehen, welche Anforderungen der Entwicklung entscheidend sind, um den Nutzen durch das Produkt für den Patienten sicherzustellen und Risiken für Patienten, Anwender und Dritte zu minimieren.
Beispielsweise spezifizieren Entwickler manchmal Toleranzen, die unnötig eng sind, um den Nutzen und die Sicherheit zu erreichen, die aber die Produktionskosten in die Höhe treiben. Umgekehrt darf es nicht sein, dass die Produktion eigenmächtig Bauteile auswählt oder austauscht, ohne dass die Folgen im Risikomanagement bewertet werden.
Der Design Transfer muss diesen Wissensübertrag sicherstellen.
e) Design Transfer nicht als unidirektionale Kommunikation verstehen
In manchen Firmen versteht man den Design Transfer als einen Informationsübertrag von der Entwicklung zur Produktion. Der Rückkanal ist aber genauso entscheidend:
Die Produktion muss die Entwickler auf Konsequenzen von Design-Entscheidungen oder fehlende Spezifikationen und Vorgaben aufmerksam machen. Sie muss die Entwicklung bei Änderungen des Produktionsverfahrens oder anderer Produktionsparameter einbinden.
f) Validierung (auch) nach dem Design Transfer
Die Validierung der Produkte kann erst mit den final produzierten Geräten abgeschlossen werden. Das sind oft die Geräte der Null-Serie. Erst dann lässt sich die Konformität abschließend bewerten.
g) Nicht nur die Entwicklung und die Produktion beteiligen
Der Design Transfer sollte die Aufgabe eines Teams sein. Beispielsweise sollte der Einkauf intensiv beim Design Transfer beteiligt werden. Gemeinsam mit der QM-Abteilung sind bei externer Produktion entsprechende Qualitätssicherungsvereinbarungen mit den Lieferanten zu unterzeichnen. Diese sollten aber nicht dem Lieferanten „übergestülpt“ werden. Besser ist es, die Lieferanten einzubinden, wie oben bei der Produktion geschildert.
Die Vorgaben für den Einkauf sind oft schwerer zu spezifizieren. Solange man im eigenen Haus mit guten eigenen Mitarbeitern fertigt und prüft, wird bei den Prüfungen auffallen, wenn beispielsweise Vorgaben wie Zeichnungen nicht ausreichend präzise sind oder wenn einzelne Herstellungsschritte Probleme bereiten. Diese doppelte Netzt fällt weg, wenn man die Fertigung nach außen vergibt.
h) Design Transfer als kontinuierlichen Prozess verstehen
Selten wird ein Produkt einmalig spezifiziert und dann unverändert produziert. Die Entwicklung verbessert das Produkt, und die Produktion möchte die Effizienz erhöhen, Verfahren oder Bauteile ändern oder verbessern.
Beispielsweise sind die Hersteller von vernetzten Medizinprodukten, die Software enthalten oder Software sind, verpflichtet, die IT-Security zu gewährleisten und entsprechende Patches zur Verfügung zu stellen.
Der Design Transfer muss sicherstellen, dass diese Änderungen reibungslos an die Produktion übertragen werden und keine Beeinträchtigung der Steigerung des Nutzens und der Sicherheit des Produkts erfolgt. Gleichzeitig dient der Design Transfer auch dazu, die Kreativität mancher Entwickler zu kanalisieren.
Viele Fehler unterlaufen den Firmen beim Einkauf: Bauteile werden durch günstigere ausgetauscht, ungeeignete Bauteile beschafft.
i) Design Transfer bei stand-alone Software
Bei stand-alone Software gibt es keine Produktion physischer Produkte. Allerdings kennt man auch dort die Trennung von Entwicklung und Produktion (z.B. Rechenzentrumsbetrieb) und die Notwendigkeit einen nahtlosen Übergang zwischen beiden Bereichen zu gewährleisten. DevOps hilft, den Design Transfer zu standardisieren.
Folgende Aktivitäten entspräche einer Produktion:
- Software wird ggf. für eine oder mehrere Zielplattformen kompiliert
- Sie wird für Kunden individuell parametriert oder konfiguriert
- Das Produktivsystem (Hardware, Betriebssystem, Software-Installation usw.) wird vorbereitet.
- Die Artefakte werden auf Produktionssysteme hochgeladen (und dort betrieben)
- Software wird auf Datenträger kopiert bzw. gebrannt (USB-Stick, DVD, CD) oder für den Download bereitgestellt (z.B. auf einer Webseite, in einem AppStore)
- Handbücher werden gedruckt oder in anderer Form bereitgestellt
Diese Aktivitäten müssen mit der Entwicklung abgestimmt sein. Denn das sind die Aktivitäten, die als Design Transfer zu verstehen sind.
j) Dokumentation aktuell halten
Jede Änderung in der Entwicklung führt zu Änderungen der Dokumentation wie z.B.
- Entwicklungsakte
- Risikomanagement (nicht nur die Entwicklung, sondern auch die Produktion betreffend)
- Produktionsspezifikationen
- Prüfspezifikationen
- Qualitätssicherungsvereinbarungen
- Device Master Record
Achten Sie darauf, dass die Dokumentation für jedes Produkt bzw. jede Produktversion klar zugeordnet werden kann (Konfigurationskontrolle).
Zunächst einmal vielen Dank für den ausführlichen und informativen Blogbeitrag. Was mich zusätzlich interessiert: Wie können die Forderungen der Norm hinsichtlich der Medical App Entwicklung interpretiert werden; wenn es sich also um reine Softwareprodukte handelt?
Sehr geehrte Frau Hall,
danke für Ihre freundliche Rückmeldung! Der Design Transfer ist bei standalone Software wie bei Apps oft weniger aufwendig. Dennoch ist auch hier der Design Transfer zu leisten.
Was Sie dabei machen sollten, habe ich Ihnen im neuen Unterkapitel „i) Design Transfer bei standalone Software“ ergänzt.
Besten Dank für die Anregung!
Herzliche Grüße, Christian Johner
Sehr geehrter Herr Johner,
vielen Dank für die Ergänzung!
Beste Grüße
Tanja Hall
Hallo ein toller Blog weil ich mich als Prozess Coach mal wieder mit dem Thema beschäftigen muss.
Aber den Satz verstehe ich nicht:
„Der Design Transfer muss gewährleisten, dass die Produktionsspezifikationen der Entwicklung gerecht werden.“
Ist das von der FDA wirklich so gefordert, das wäre ja dann schon eine unidrektionale Sicht oder?
Gruß Reiner
Lieber Herr Rygiel,
ich freue mich sehr über Ihr positives Feedback. Ich würde den Design Transfer als eine Aktivität sehen, die Entwicklung und Produktion bidirektional verknüpft. Ich wollte jedenfalls keine Unidirektionalität ausgedrückt haben.
Den Design Transfer fordern sowohl die FDA als auch die ISO 13485.
Nochmals besten Dank!
Herzliche Grüße
Christian Johner
Sehr geehrter Herr Dr. Johner,
ich habe aufmerksam Ihren Tipp „i) Design Transfer bei stand-alone Software“ gelesen und bin damit leider nicht ganz zufrieden.
Wenn ich aber versuche, Ihre Beispiele 1 und 2 auf ein medizinisches Softwareprodukt zu übertragen, dann würde ich die Norm so interpretieren, dass die Konzeption die Entwicklung ist und die Implementierung die Produktion.
D.h. bei der Konzeption der Software muss mit einbezogen werden, ob die Implemtierung überhaupt möglich ist:
* Gibt es überhaupt Schnittstellen, um den Wunsch zu erfüllen?
* Erlauben die Randbedingungen der Klinik die Implementierung?
* Haben wir im Unternehmen das Personal, welches die Implementierung vornehmen kann?
Auch Ihr Tipp „a) Produktion frühzeitig mit einbeziehen“ beschreibt genau das. Der Vertrieb tut gut daran, zunächst die „Produktion der Software“ also die Softwarentwickler zu fragen, bevor er dem Kunde etwas verspricht.
So ziemlich jeder Ihrer Tipps zeigt, dass es deutlich mehr Aktivitäten der Produktion in Tipp „i)“ geben muss ODER die Begriffe Entwicklung und Produktion beim QM von Softwareprodukten vermieden werden müssen und durch passendere ersetzt werden müssen.
Ich habe leider oft den Eindruck, dass die Norm ziemlich gut für „anfassbare Medizinprodukte“ passt, aber die Übertragung auf medizinische Software viel Interpretationsspielraum offen lässt.
Viele Grüße
Markus Misselwitz
Sehr geehrter Herr Misselwitz,
es tut mir sehr leid, dass Sie Hinweise als nicht hilfreich erachten. Ihr Kritik, dass die Beispiele einen Fokus auf physischen Medizinprodukten haben, nehme ich absolut an. Bei diesen Produkten ist der Design Transfer auch besonders wichtig. Insofern ist Ihr Eindruck, dass die Norm dafür besonders gut anwendbar ist, absolut zutreffend.
Bei Software entspricht die Implementierung nicht der Produktion. Die Produktion wäre beispielsweise das Brennen der Software auf DVD oder das Bereitstellen der Software für einen Upload. Das könnte ggf. das „Verpacken“ als Installer oder RPM-Datei usw. beinhalten. Auch die Anfertigung der Handbücher (falls es physische gibt) wären Aspekte der Produktion.
Die Produktion ist auch nicht mit dem Betrieb (beim Kunden) gleichzusetzen.
In der Hoffnung, doch noch etwas geholfen zu haben, und mit den besten Grüßen
Christian Johner
Sehr geehrter Herr Dr. Johner,
vielen Dank für die Klarstellung, was unter Produktion zu verstehen ist und dass dieser Begriff nicht beliebig interpretierbar ist.
Ich würde es daher so formulieren, dass Design-Transfer nicht nur zwischen Entwicklung und Produktion, sondern auch in den einzelnen Entwicklungsphasen stattfindet.
„Produktion“ so wie Sie es beschreiben, würde ich dem Installations- und Konfigurationsmanagement zuschreiben, so wie es Softwareengineering es versteht.
Danke auch für die Klarstellung, dass der Betrieb nicht zur Produktion gehört. Hierbei müsste aber die Klammer „(und dort betrieben)“ bei Ihrem Tipp i, Punkt „Die Artefakte werden auf Produktionssysteme hochgeladen (und dort betrieben)“ entfernt werden. Oder sehe ich das falsch?
Ist das Erstellen des Inhalts von Handbüchern ebenfalls eine Aktivität der Produktion?
Viele Grüße
Markus Misselwitz
Danke für Ihr Nachhaken, lieber Herr Misselwitz!
Die Produktion kann i.d.T. auch im Installations- und Konfigurationsmanagement bestehen. Ich würde nur den Design-Transfer nicht als zwischen den Entwicklungsphasen ansiedeln. Da haben wir eher das Design Review.
Bei dem Punkt i) hängt es davon ab, ab wann und wie die Inverkehrbringung erfolgt. Wir müssten unterscheiden, ob der Hersteller auch der Betreiber ist oder der Hersteller an einen Betreiber ausliefert.
Das Erstellen des Inhalts von Handbüchern, sprich das Schreiben ist kein Teil der Produktion, sondern Teil der Entwicklung. Die Begleitmaterialien sind regulatorisch betrachtet Teil des User Interfaces. Die Verifizierung und Validierung des Produkts, die den Abschluss der Entwicklung bildet, muss die Begleitmaterialien umfassen.
Viele Grüße, Christian Johner