Die erste Frage, die Menschen außerhalb der Medizinproduktebranche in der Regel stellen, lautet: Verlangsamt die Arbeit nach den Normen IEC 62304 und ISO 13485 Ihre Arbeit? Das ist die falsche Frage – aber sie ist verständlich. Die richtige Frage lautet: Wie wirkt sich der regulierte Prozess auf das Ergebnis Ihres Projekts aus?
Abschnitte in diesem Artikel:
Zwei Standards, ein Team | Die Erkundungsphase | Dreistufiger Prozess | Abschluss und Genehmigung des Verfahrens | Werkzeugvalidierung | Umsetzung | Was sich tatsächlich ändert | Praktische Hinweise für Teams
Die Einhaltung der Normen IEC 62304 und ISO 13485 ist kein Kompromiss. Bei Software für das Gesundheitswesen gibt es keine Variante von „Wir haben schnell gehandelt und dabei ein paar Dinge kaputtgemacht“. Es gibt nur Software, die den Standard erfüllt, und Software, die nicht in einem Medizinprodukt enthalten sein sollte. Was sich ändert, sind die Abfolge und Struktur der Entwicklungsaktivitäten, die Dokumentation, die parallel zum Code entsteht, sowie die Entscheidungen, die ein Team eigenständig treffen kann und welche nicht.
Dieser Artikel beschreibt, wie das aus der Perspektive eines Entwicklungsteams aussieht. Wir entwickeln seit 25 Jahren IEC 62304-konforme Software. Was folgt, ist ein Erfahrungsbericht aus der Praxis – keine Zusammenfassung der Norm, sondern eine Beschreibung dessen, was sie tatsächlich von den Personen verlangt, die den Code schreiben.
Zwei Standards, ein Team. Was jeder einzelne erfordert
IEC 62304 und ISO 13485 werden oft in einem Atemzug genannt, regeln jedoch unterschiedliche Bereiche. Es ist wichtig, den Unterschied zu kennen, da er darüber entscheidet, wo eine Entscheidung getroffen wird – im Entwicklungsteam oder im Qualitätsmanagementsystem.
Standard | Was es regelt | Wo man es spürt |
| IEC 62304 | Software für Medizinprodukte und Prozesse des Software-Lebenszyklus – Entwicklung, Wartung, Risikomanagement, Konfigurationskontrolle, Problemlösung | Der technische Alltag: Wie Code geschrieben, überprüft, getestet und geändert wird |
| ISO 13485 | Qualitätsmanagementsystem – Konstruktionskontrolle, Dokumentenkontrolle, Rückverfolgbarkeit, CAPA-Prozesse | Wie Dokumente genehmigt werden, wie Änderungen freigegeben werden, wie Probleme eskaliert und abgeschlossen werden |
Für einen Softwareentwickler legt die Norm IEC 62304 den technischen Prozess fest. Die Norm ISO 13485 definiert den organisatorischen Rahmen, in dem dieser Prozess abläuft. In der Praxis ergänzen sich beide Normen: Die Norm IEC 62304 schreibt vor, dass ein Softwareentwicklungsplan geführt werden muss; die Norm ISO 13485 legt fest, wie dieser Plan versionsverwaltet, genehmigt und referenziert werden muss.
RomSoft ist nach ISO 9001 zertifiziert und erfüllt die Anforderungen der Normen IEC 62304 und ISO 13485 – im Rahmen unserer Entwicklungspartnerschaften arbeiten wir nach den durch IEC 62304 und ISO 13485 geregelten Prozessen, wobei die entsprechenden IEC-Zertifizierungen bei unseren Partnern liegen. Da wir seit über zwei Jahrzehnten im Rahmen des Qualitätsmanagementsystems (QMS) eines zertifizierten Partners arbeiten, haben wir diese Standards nicht als externe Auflagen, sondern als die Art und Weise verinnerlicht, wie wir Software entwickeln.
Die Norm IEC 62304 definiert drei Risikoklassen für Software in Medizinprodukten: Klasse A (keine Verletzung), Klasse B (möglicherweise nicht schwerwiegende Verletzung) und Klasse C (möglicherweise schwerwiegende Verletzung oder Tod). Im Laufe der Jahre haben wir an Projekten gearbeitet, die allen Arten von Risikoklassen unterliegen. Je höher das Risikoniveau, desto umfangreicher müssen die Dokumentation und die Maßnahmen zum Risikomanagement sein.
Die Entdeckungsphase – strukturierte Freiheit, bevor der formelle Prozess beginnt
Eines der Dinge, die Ingenieure aus nicht regulierten Umgebungen überrascht, ist, dass die formale Entwicklung nicht gleich am ersten Tag beginnt. Es gibt eine bewusst angelegte Anfangsphase – die Erkundungsphase –, in der das Team den Problemraum erkundet, ohne dass die Norm in vollem Umfang zur Anwendung kommt.
Warum ist diese Phase notwendig? Das Verfahren, das die formale Entwicklung regelt, muss auf der Grundlage eines echten Verständnisses des Produkts – seiner Architektur, seiner Risiken und seiner technischen Einschränkungen – verfasst werden. Wird dieses Verfahren geschrieben, bevor das Team das Problem erkundet hat, führt dies zu Verfahren, die nicht der Realität entsprechen. Ein Verfahren, das nicht der Realität entspricht, ist schlimmer als gar kein Verfahren, da es eine falsche Papierspur hinterlässt.
In der Erkundungsphase kann das Team Prototypen erstellen, Architekturvarianten bewerten und die technischen Entscheidungen ermitteln, die im weiteren Verlauf festgeschrieben werden müssen. Der hier geschriebene Code dient der Erkundung – er wird möglicherweise, muss aber nicht zwangsläufig zum Produktionscode werden und unterliegt etwas anderen Regeln als der spätere Code.
Einblick in das TeamIn vielen unserer Projekte dauert die Analysephase bereits mehrere Monate. Diese Arbeit trägt zum gesamten Entwicklungsaufwand eines Projekts bei, das sich über mehrere Jahre erstreckt – ein gerechtfertigter Aufwand angesichts der damit verbundenen architektonischen Komplexität. Der in diesem Zeitraum entwickelte Code wurde nach denselben Best Practices der Softwareentwicklung geschrieben, die auch im restlichen Projekt zum Einsatz kommen, darunter Codierungsstandards, Code-Reviews und Testaktivitäten. Das Ziel ist nicht eine schnelle Entwicklung ohne Kontrollen, sondern vielmehr die Validierung architektonischer Optionen und die Minderung technischer Risiken vor Abschluss des regulären Prozesses. Die Arbeit selbst ist greifbar: die Erstellung eines Prototyps eines Architekturmusters, das Testen der Kommunikation mit externen Systemen und die Abbildung des Datenverarbeitungsablaufs, wobei jede wichtige Entscheidung in Architekturentscheidungsprotokollen (Architecture Decision Records, ADRs) festgehalten wird. Diese ADRs fließen direkt in das formale Verfahren ein – die Softwarearchitektur, die technische Risikoanalyse und die Entwicklungsregeln, die die regulierte Phase bestimmen –, wobei sich alles auf die hier gewonnenen Erkenntnisse zurückführen lässt. |
Dreistufiger Prozess
Nach der Entdeckungsphase folgt die Entwicklung in einer strukturierten Abfolge von drei Phasen. Jede Phase ist mit einem bestimmten Meilenstein verbunden. Der Übergang zur nächsten Phase ist erst möglich, wenn die aktuelle Phase abgeschlossen und genehmigt wurde. Durch diese Abfolge stellt der Standard sicher, dass das, was entwickelt wird, mit den Spezifikationen, Tests und Validierungen übereinstimmt.
Phase I: Fertigstellung und Genehmigung des Verfahrens
Das Verfahren legt fest, wie die Software entwickelt wird: welche Aktivitäten erforderlich sind, in welcher Reihenfolge sie durchgeführt werden, welche Ergebnisse dabei anfallen und welche Freigabeschritte zu durchlaufen sind. Es basiert auf den Erkenntnissen, die das Team in der Discovery-Phase gewonnen hat, und muss genehmigt werden, bevor auch nur eine einzige Zeile Produktionscode geschrieben wird.
Das Verfahren ist projektspezifisch. Es verweist auf die geltende Softwaresicherheitsklasse, definiert die Entwicklung des Lebenszyklusmodells, legt die für jede Aktivität erforderliche Dokumentation fest und benennt die zu verwendenden Werkzeuge. Der letzte Punkt ist entscheidend, da diese Werkzeuge vor Beginn der Entwicklung validiert werden müssen.
Einblick in das TeamDie größte Herausforderung bestand darin, einen einheitlichen Prozess zu entwickeln, der konsistent auf mehrere Produkte angewendet werden konnte, die alle im Rahmen desselben Programms entwickelt wurden. |
Phase II: Validierung des Tools
Bevor Produktionscode geschrieben wird, muss jedes Tool in der Entwicklungskette validiert werden. Das Team muss überprüfen, ob das Tool für den vorgesehenen Verwendungszweck ordnungsgemäß funktioniert und ob etwaige Fehlfunktionen erkannt werden können, bevor sie sich auf das Endprodukt auswirken. Dies umfasst Compiler, Tools zur statischen Analyse, Test-Frameworks und Versionskontrollsysteme. Ebenfalls einbezogen sind Bibliotheken und Frameworks von Drittanbietern.
Open-Source-Software wird in der Entwicklung medizinischer Geräte im Allgemeinen nicht akzeptiert. Der Grund dafür liegt in der Rückverfolgbarkeit und im Support: Wird in einer Open-Source-Bibliothek ein Fehler entdeckt, der sich auf das Medizinprodukt auswirkt, kann der Hersteller weder die Behebung des Fehlers garantieren noch den Zeitplan kontrollieren und auch nicht immer die Validierungskette nachweisen. Das bedeutet, dass Teams manchmal eigene Implementierungen von Komponenten schreiben müssen, die in jedem anderen Kontext Bibliotheken von Drittanbietern wären. Wie in einem früheren Artikel beschrieben, kann dies eine echte technische Herausforderung sein, aber auch eine Chance, eine Lösung zu entwickeln, die genau auf das jeweilige Problem zugeschnitten ist.
Die zweite Einschränkung bei der Tool-Validierung ist die Versionsstabilität. Angenommen, ein Projekt basiert auf einer bestimmten Version eines Frameworks. Wenn eine neue Version veröffentlicht wird, ist ein Upgrade nicht einfach nur eine technische Entscheidung. Es erfordert möglicherweise eine erneute Validierung des Tools, die Wiederholung von Tests und in einigen Fällen die Überarbeitung klinischer Studien. Die Kosten für ein Upgrade sind in einem regulierten Umfeld um ein Vielfaches höher als in der Standard-Softwareentwicklung. Dies erzeugt einen starken Druck in Richtung Stabilität und bedeutet, dass die Auswahl des Tools zu Beginn eines Projekts eine größere Bedeutung hat als bei nicht regulierten Projekten.
Phase III: Umsetzung
Die Entwicklung erfolgt gemäß dem genehmigten Verfahren, wobei ausschließlich validierte Werkzeuge zum Einsatz kommen. Alle technischen Entscheidungen, die in anderen Kontexten als Routine gelten – das Hinzufügen einer Abhängigkeit, das Refactoring eines Moduls, die Änderung einer Schnittstelle –, durchlaufen einen festgelegten Prozess: Änderungsantrag, Bewertung der Auswirkungen auf Risiken und Anforderungen, Genehmigung, Umsetzung, Überprüfung.
Code, der während der Discovery-Phase geschrieben wurde, kann in die Produktions-Codebase übernommen werden, jedoch erst, nachdem er gemäß dem festgelegten Verfahren validiert wurde: Überprüfung anhand der Anforderungen, Bewertung der Risikoauswirkungen und Genehmigung durch denselben Prozess wie bei jedem anderen Code. Die Discovery-Codebase wird als Quelle behandelt, nicht als Abkürzung.
Hier zeigt sich auch am deutlichsten das Zusammenspiel zwischen IEC 62304 und ISO 13485. Jede wesentliche Änderung zieht eine Reihe von Dokumenten nach sich: den Änderungsantrag, die Folgenabschätzung, gegebenenfalls die aktualisierten Anforderungen, die Prüfprotokolle und die Genehmigung. Die ISO 13485 regelt, wie diese Dokumente verwaltet werden. Die IEC 62304 legt fest, was sie enthalten müssen.
Einblick in das TeamNehmen wir als Beispiel eine Code-Umgestaltung. In einem nicht regulierten Projekt entdeckt ein Entwickler eine ineffiziente Funktion, schreibt sie um und eröffnet einen Pull-Request. Hier hingegen eröffnet der Entwickler, bevor er auch nur eine Zeile des Produktionscodes anfasst, einen formellen Änderungsantrag, verknüpft diesen mit einer bestimmten ID der Software-Anforderungsspezifikation und lässt die Auswirkungen bewerten – um nachzuweisen, dass die Änderung keine neue Gefahr für Patienten mit sich bringt. Erst nachdem ein technischer Leiter diese Bewertung genehmigt hat, beginnt die eigentliche Programmierung. Die gleiche Vorgehensweise gilt auch über Komponentengrenzen hinweg. Bevor beispielsweise eine gemeinsam genutzte Komponente der Plattform geändert wird, muss der Entwickler prüfen, ob die Änderung Auswirkungen auf die darauf aufbauenden Anwendungen haben könnte – dabei sind nicht nur der Code selbst, sondern auch die betroffenen Anforderungen, das Risiko, die Testabdeckung und die Rückverfolgbarkeit zu berücksichtigen. |
Was ändert sich tatsächlich? Und was nicht?
Das Wichtigste, was man beim Entwickeln nach IEC 62304 verstehen muss, ist, dass sich die technischen Entscheidungen selbst nicht ändern. Man wählt nach wie vor die Architektur aus, schreibt Algorithmen, behebt Leistungsprobleme und überarbeitet den Code. Was sich ändert, ist die Steuerung dieser Entscheidungen – wie sie getroffen, dokumentiert und auf Anforderungen und Risiken zurückverfolgt werden.
Die Analogie, die bei Ingenieuren, die sowohl in regulierten als auch in nicht regulierten Kontexten arbeiten, am meisten Anklang findet, lautet: Es ist nicht so, dass man andere Arbeit leistet, sondern dass jede Entscheidung eine dokumentierte Spur hinterlässt. Nach einer Weile empfindet man das nicht mehr als Mehraufwand, sondern als Klarheit – denn wenn sechs Monate später ein Fehler auftritt, kann man genau nachvollziehen, welche Entscheidung dazu geführt hat und warum sie getroffen wurde.
Einblick in das TeamFür Ingenieure, die neu im Bereich der Medizinprodukte sind, wirkt der formale Prozess zunächst wie eine Einschränkung – jede Änderung muss begründet, dokumentiert und auf die Anforderungen und die Verifizierung zurückgeführt werden. Diese Wahrnehmung ändert sich in der Regel nach einer Eingewöhnungsphase, sobald der Prozess Klarheit schafft: Was muss getan werden, wer genehmigt es und wie wird die Korrektheit nachgewiesen? Ein Vergleich, der in unserem Team immer wieder auftaucht, ist der mit dem Bau eines Rennwagens. Von außen betrachtet wirkt er überkonstruiert, voller Regeln, Prüfungen und Kontrollen. Doch genau diese Mechanismen sind es, die es ihm ermöglichen, schnell und zuverlässig zu fahren. Der regulierte Prozess funktioniert genauso: Er schränkt die technische Freiheit nicht ein, sondern schafft den Rahmen, der es ermöglicht, technische Entscheidungen schnell und mit der Gewissheit zu treffen, dass sie Bestand haben werden. |
Wo der Prozess wirklich hilft
Es gibt einen Grund dafür, dass regulierte Branchen nach der Veröffentlichung geringere Fehlerquoten aufweisen als bei Standardsoftware – der Prozess deckt Probleme früher auf, wenn ihre Behebung noch kostengünstiger ist. Bei Software für Medizinprodukte kostet ein Fehler, der bereits in der Phase der Anforderungsprüfung entdeckt wird, nur einen Bruchteil dessen, was es kosten würde, wenn er erst in einer klinischen Studie oder – schlimmer noch – in einem bereits im Einsatz befindlichen Gerät auftritt.
Die Disziplin, die für die erfolgreiche Entwicklung medizinischer Software erforderlich ist – strenge Anforderungen, nachvollziehbares Risikomanagement, formale Änderungskontrolle –, erweist sich als die Disziplin, die für die erfolgreiche Entwicklung jeder komplexen Software erforderlich ist. Diese Disziplin wenden wir bei allen unseren Projekten an, nicht nur bei den regulierten.
Einblick in das TeamIm Rahmen der Risikoanalyse tauchte irgendwann ein Szenario auf, das das Team ursprünglich nicht eingeplant hatte: eine kurze Netzwerkunterbrechung, die genau in dem Moment auftritt, in dem ein Arzt versucht, eine wichtige Patientenakte zu speichern. Die Funktion selbst hätte den ursprünglichen Anforderungen zuwidergelaufen. Glücklicherweise ergab die formelle Risikoprüfung, dass ein unbemerktes Aussetzen der Netzwerkverbindung den Benutzer in dem Glauben lassen könnte, die Daten seien gespeichert worden, obwohl dies tatsächlich nicht der Fall war, was möglicherweise dazu führen könnte, dass klinische Entscheidungen auf der Grundlage veralteter Informationen getroffen werden. Dieser einzelne Befund führte zu einer Reihe von Maßnahmen zur Risikokontrolle: der Implementierung eines lokalen Status-Caches, der Einbindung expliziter Synchronisationsstatus-Anzeigen in die Benutzeroberfläche und der Entwicklung automatischer Wiederholungsprotokolle. Daher wurden die Anforderungen, Tests und Verifikationsprotokolle aktualisiert, um deren Funktionsfähigkeit nachzuweisen. Dies ist ein gutes Beispiel dafür, wie der Prozess ein echtes Risiko bereits während der Entwurfsphase aufdeckt – lange bevor es bei der Integration oder, schlimmer noch, im Einsatz hätte auftreten können. |
Wo der Prozess die größte Reibung verursacht
Aus Sicht eines Ingenieurs besteht eine der größten Herausforderungen darin, dass scheinbar geringfügige Änderungen nicht ausschließlich unter technischen Gesichtspunkten bewertet werden, sondern unter vielen verschiedenen Gesichtspunkten, die sich darauf auswirken, wie die Änderung angegangen wird.
Einblick in das TeamDas wirklich Frustrierende daran: Eine Änderung, die bei einem normalen Projekt noch am selben Tag implementiert würde – etwa eine kleine Anpassung, die nichts mit der Architektur zu tun hat –, kann in einem regulierten Umfeld eine umfassende Folgenabschätzung in Bezug auf Anforderungen, Risiken, Architektur, Tests und Dokumentation auslösen. An manchen Tagen hat man wirklich das Gefühl, dass dieser Prozess die Arbeit verlangsamt. Doch das Muster bestätigt sich im Laufe der Zeit: Die Stunden, die im Vorfeld für die Folgenabschätzung aufgewendet werden, machen sich später in der Regel bezahlt – in Form von weniger Überraschungen bei der Integration, weniger spät entdeckten Fehlern und weitaus weniger unkontrollierten Änderungen, die sich in den Code einschleichen. |
Warum bei medizinischer Software andere Herausforderungen bestehen?
Es lohnt sich, klar zu sagen, wovor Compliance letztendlich schützt. Bei herkömmlicher Desktop-Software ist ein Absturz lediglich ein Ärgernis – man startet die Anwendung neu und macht weiter. Die Messlatte für das, was als „akzeptabel“ gilt, wird durch die Toleranz der Nutzer und den Wettbewerbsdruck bestimmt.
Bei medizinischer Software wird die Messlatte dadurch bestimmt, was passiert, wenn die Software während eines klinischen Eingriffs ausfällt. Der Standard existiert, weil die Folgen eines Ausfalls grundlegend anders sind.
Einblick in das TeamEin kritischer Befundbericht, der aufgrund eines unbehandelten Hintergrundfehlers nicht auf dem Dashboard eines Arztes aktualisiert wird, kann eine zeitkritische Behandlung verzögern. Durch ein angemessenes Risikomanagement im Rahmen der Architektur- und Entwurfsprüfung wird dieses Synchronisationsverhalten von Anfang an mit Ausfallsicherungen und expliziten Benutzerwarnungen ausgestattet. Die Software muss den Patienten nicht direkt behandeln, um eine so große Rolle zu spielen. Sie ist Teil der Informationskette, auf die sich das klinische Personal verlässt: Ein Fehler, ein Systemabsturz oder ein falscher Wert können eine klinische Entscheidung genauso sicher beeinflussen wie eine Fehlfunktion eines Geräts. Genau vor diesem Unterschied sollen die Standards schützen. |
Praktische Hinweise für Teams, die in die regulierte Entwicklung einsteigen
Aufgrund unserer mehr als zwei Jahrzehnte langen Erfahrung mit Projekten, die der Norm IEC 62304 unterliegen, sind dies die Dinge, von denen wir uns gewünscht hätten, dass sie uns zu Beginn klar und deutlich mitgeteilt worden wären:
1. Investieren Sie in die SondierungsphaseDie Versuchung ist groß, diese Phase zu verkürzen und schnell zum formellen Prozess überzugehen. Es lohnt sich jedoch, dieser Versuchung zu widerstehen. Eine gründlich durchgeführte Anfangsphase führt zu einem besseren Verfahren, und ein besseres Verfahren sorgt im weiteren Verlauf für weniger Änderungswünsche und Nacharbeitszyklen.. |
2. Betrachten Sie die Auswahl der Werkzeuge als eine architektonische EntscheidungDie von Ihnen gewählte Version, das Lizenzmodell und die Verfügbarkeit von Hersteller-Support – all dies hat in einem regulierten Umfeld Auswirkungen über mehrere Jahre hinweg. Ein Tool, das für ein sechsmonatiges Projekt ausreicht, wird zu einer Belastung bei einem Produkt, das über Jahre hinweg gewartet werden soll.. |
3. Behandeln Sie die Rückverfolgbarkeit als Teil des DesignprozessesViele Teams betrachten die Rückverfolgbarkeit zunächst als etwas, das erst nach der Implementierung zum Tragen kommt. In der Praxis lässt sich jedoch durch die frühzeitige Festlegung der Zusammenhänge zwischen Anforderungen, Risiken, Architektur, Implementierung und Verifizierung im Projektverlauf später erheblicher Nacharbeit vermeiden. Eine gute Rückverfolgbarkeit ist in der Regel das Ergebnis einer guten Planung und nicht das Ergebnis eines zusätzlichen Dokumentationsaufwands.. |
4. Den Entwicklungsprozess am Produkt ausrichten…und nicht umgekehrt. Ein sehr häufiger Fehler besteht darin, einen generischen Prozess einem Produkt aufzuzwingen, das andere Architekturebenen, Zuständigkeiten oder Entwicklungsstränge aufweist. Der Prozess sollte widerspiegeln, wie die Software tatsächlich entwickelt, getestet und gewartet wird. Ein Prozess, der der Realität entspricht, sorgt für Klarheit und verleitet die Mitarbeiter nicht dazu, ihn zu umgehen. |
5. Risikomanagement ist wertvoller, als die meisten Teams erwartenTeams betrachten das Risikomanagement oft als eine Maßnahme zur Einhaltung von Vorschriften. In der Praxis deckt die Risikoanalyse jedoch häufig fehlende Anforderungen, architektonische Schwachstellen und Ausfallszenarien auf, die andernfalls erst bei Integrationstests oder der Validierung entdeckt würden. Das wertvollste Ergebnis ist oft nicht das Risikoprotokoll selbst, sondern die durch die Analyse ausgelösten technischen Diskussionen. |
6. Sobald der Prozess zur Routine wird, empfindet man ihn nicht mehr als MehraufwandFür Teams, die in die regulierte Entwicklung einsteigen, erscheint der Prozess zunächst einschränkend. Mit der Zeit werden die Anforderungen, Prüfschritte, Genehmigungswege und Qualitätskontrollen jedoch Teil des normalen Arbeitsablaufs. Der Hauptvorteil liegt nicht in zusätzlicher Dokumentation, sondern in einer höheren Vorhersehbarkeit: Entscheidungen sind leichter nachvollziehbar, Änderungen lassen sich einfacher bewerten und Fehler lassen sich leichter bis zu ihrer Ursache zurückverfolgen.. |
Abschließende Anmerkung
Die Arbeit nach IEC 62304 und ISO 13485 verändert die Struktur der Entwicklungsarbeit – die Abfolge der Phasen, die Entscheidungsfindung sowie die Einschränkungen hinsichtlich der Werkzeuge und Abhängigkeiten. Was sich nicht ändert, ist die Qualität der technischen Arbeit, die erforderlich ist, um Software zu entwickeln, die das tut, was sie tun soll.
Wenn überhaupt, dann führt die Disziplin, die der Prozess auferlegt, dazu, dass Probleme früher und in einer Form zutage treten, die leichter zu beheben ist. Die Teams, die im Rahmen dieser Normen gut arbeiten, sind diejenigen, die diese als technische Praxis verinnerlicht haben und nicht als zusätzlichen Aufwand zur Einhaltung von Vorschriften betrachten – wobei das Verfahren widerspiegelt, wie das Team tatsächlich Software entwickelt, anstatt einen idealisierten Prozess zu beschreiben, der nur in Dokumenten existiert.
Gerne sprechen wir darüber, wie wir dies in unseren Entwicklungspartnerschaften angehen, oder tauschen uns mit Teams aus, die ihr erstes reguliertes Produkt entwickeln. Die Lernkurve ist real – aber sie flacht schneller ab, als die meisten Menschen erwarten.
Möchten Sie Ihr eigenesreguliertes Softwareprodukt entwickeln?Seit 25 Jahren entwickeln wir Software für zertifizierte Hersteller medizinischer Geräte. Wir kennen die Abläufe aus erster Hand – und beraten Sie gerne darüber, was das für Ihr Projekt bedeuten würde. |