Konfigurationsmanagement ist weit mehr ist als nur der Einsatz von Versionsverwaltungswerkzeugen wie git oder svn. Dies wird bei einem Blick in die IEC 62304 und die FDA Guidance Dokumente sofort klar.
Lesen Sie in diesem Artikel
- was das Konfigurationsmanagement umfasst,
- welche regulatorischen Anforderungen an das Konfigurationsmanagement Sie beachten müssen und
- welche typischen Fehler beim Konfigurationsmanagement Sie vermeiden sollten.
Was das Konfigurationsmanagement umfasst
Fragen wir beim Audit Firmen, wie sie das Konfigurationsmanagement durchführen, hören wir oft: „Wir nutzen SVN“ (Apache Subversion), „Das macht bei uns der TFS“ (Team Foundation Server) oder ähnliche Antworten.
Hinter solchen Aussagen verbirgt sich ein unvollständiges Verständnis von Konfigurationsmanagement. Ein fachgerechtes Konfigurationsmanagement, das den Anforderungen entspricht, beruht auf vier Säulen:
- Versionsmanagement
- Build-Management
- Change-Management
- Release-Management
Weshalb bedarf es dieser vier Säulen? Die Antwort ergibt sich aus Definition und Zielen des Konfigurationsmanagements: Umfassendes Konfigurationsmanagement bedeutet ganz allgemein, Veränderungen in ausgedehnten komplexen Systemen zu steuern, zu beherrschen und zu dokumentieren – und zwar über den gesamten Lebenszyklus. Das beinhaltet, Anpassungen, Korrekturen, Erweiterungen kontinuierlich zu lenken und zu kontrollieren. Dabei soll das jeweilige System und seine sämtlichen Bestandteile stets in einem klar definierten Zustand sein, der sich bis zu den Ursprüngen zurück verfolgen läßt. Konfigurationsmanagement ist somit grundlegend für einen systematischen und jederzeit nachvollziehbaren Produkt-Entwicklungsprozess.
Ziele des Konfigurationsmanagements in der Medizintechnik
Für Medizinproduktehersteller ist es das wichtigste (oder sollte es zumindest sein), sichere Produkte zu entwickeln, welche die versprochene Wirkung haben, also ihre Zweckbestimmung tatsächlich erfüllen.
Besonders bei aktiven Medizinprodukten, die Software sind oder enthalten, können Sicherheit und Wirksamkeit gefährdet sein. Dies kann daran liegen, daß Hersteller
- falsche Artefakte ausliefern (z.B. eigene Software, Bibliotheken von Dritten)
- Artefakte oder Versionen dieser Artefakte verwechseln,
- Artefakte unvollständig ausliefern,
- die Software aus den Artefakten falsch zusammengesetzt haben,
- vergessen haben, einen Teil der Software zu prüfen und freizugeben,
- versehentlich bereits behobene Fehler wieder einführen
- Produkte falsch konfigurieren (für gegebene Umgebung, für bestimmten Kunden)
- den Einfluss der Entwicklungs-, Build-, Test- und Produktionsumgebung auf das Produkt übersehen haben und über Änderungen nicht informiert waren (z.B. beim Kunden),
- weil ein Mitarbeiter etwas tat (Code änderte, Änderungen beantragte, Software auflieferte), wovon andere Mitarbeiter nichts wussten,
- usw.
Das Ziel des Konfigurationsmanagements besteht darin, einen Beitrag zu leisten, die Komplexität zu beherrschen und die oben genannten Fehler zu vermeiden.
Ad 1.) Versionsmanagement
Das Versionsmanagement erfasst und verwaltet die Änderungen der sogenannten Konfigurationselemente. Damit kann man nachvollziehen, wer wann was und weshalb geändert hat.
Beispiele für Konfigurationselemente sind
- eigener Source Code
- Fremdkomponenten (SOUP, OTS)
- Plattformen
- Werkzeuge
- Konfigurationseinstellungen (von Produkten, Werkzeugen, Umgebungen). Dazu zählen auch Build-Scripts und Konfigurationsdateien.
- Mediendateien (Bilder, Videos)
- Gebrauchsanweisungen
- Release-Notes
Erst die Versionsverwaltung (das Versionsmanagement) schafft die Grundlage dafür zu wissen, welches Artefakt in welcher Version Teil welcher Version des Produkts geworden ist.
Ohne ein Werkzeug müsste man diese Beziehungen von Hand (beispielsweise tabellarisch) verwalten:
| Produktversion 1 | Produktversion 1.1 | Produktversion 2 | |
|---|---|---|---|
| Datei 1 | Dateiversion 3 | Dateiversion 3 | Dateiversion 3 |
| Datei 2 | Dateiversion 1 | Dateiversion 9 | Dateiversion 11 |
| Datei 3 | Dateiversion 12 | Dateiversion 13 | Dateiversion 13 |
Entwicklungsdokumente wie Anforderungsspezifikationen, Architekturen und Testberichte müssen ebenfalls der Versionskontrolle unterliegen. Sie sind aber meist nicht Teil des ausgelieferten Produkts.
Auch die Laufzeitumgebung einer Software und Build-Scripts unterliegen der Dokumentenlenkung, werden aber ebenfalls nicht Teil des Produkts.
Ad 2.) Build-Management
Das Versionsmanagement reicht noch nicht aus, um bei gegebenen Ausgangsartefakten (z.B. Source-Code) das Produkt reproduzierbar zu erzeugen. Beispielsweise kann die Reihenfolge, in der die Artefakte verarbeitet (z.B. Abhängigkeiten aufgelöst, kompiliert, generiert, zusammengesetzt) werden, eine Rolle spielen.
Produkte reproduzierbar, vollständig und fehlerfrei zu bauen, ist das Ziel des Build-Managements.
Bei tausenden, zehntausenden und mehr Artefakten und komplexen „Produktionsvorgängen“ haben Firmen kaum eine andere Chance, als diese Vorgänge zu automatisieren. Build-Management-Werkzeuge (hier eine Liste) und Continuous-Integration-Werkzeuge sind Stand der Technik.
Die veröffentlichten Konfigurationen sind die Releases, manchmal auch als Versionen bezeichnet.
Ad 3.) Change-Management (Fokus Änderungen an Produkten, nicht an Organisationen)
Oft sind es Anforderungen der Umwelt, die Änderungen veranlassen: Fehler müssen behoben werden, die Funktion wird umdefiniert, eine neue technische Umgebung verlangt Anpassungen. Change-Management beinhaltet Entscheidungen – dokumentierte Entscheidungen – ob und in welcher Weise neue Versionen als Antwort auf solche Herausforderungen erstellt werden. Es hat zum Ziel, den Umgang mit neuen und sich ändernden Anforderungen an ein System ebenso kontrolliert zu steuern wie Anfragen nach einer Fehlerbehebung.
Das Change-Management umfasst den oder die Prozesse, um
- Änderungsanforderungen zu dokumentieren,
- Änderungsanforderungen zu bewerten,
- über Maßnahmen zu entscheiden (z.B. Behördenmeldung, Änderung am Produkt, nichts tun, Schulungen)
- Änderungen zu genehmigen,
- die Durchführung von Änderungen zu überwachen
Manche Firmen haben für die Bewertung und Freigabe von Änderungen ein Change Control Board etabliert.
Wenn dieses Board nicht nur darüber entscheidet, ob, sondern auch wann eine Änderung durchgeführt und freigegeben werden darf, hat dieses Board auch die Hoheit über das Release Management.
Ad 4.) Release Management
Das Release-Management ist der Prozess, durch den Software zur Verfügung gestellt wird. Es legt fest, in welche Version (Release) eines Produkts welche Konfigurationsänderungen einfließen. Die Entscheidungen darüber werden beeinflusst durch:
- die Bedeutung der Änderung für die Patientensicherheit
- Gesetze z.B. die Medizinproduktesicherheitsplanverordnung (MPSV), die konkrete Fristen nennt
- Dringlichkeit der Änderung aus Kundensicht
- Verfügbarkeit von Personen, die die Änderung verwirklichen können,
- Abhängigkeiten von Konfigurationsänderungen untereinander
Fazit
Auch wenn Versionsverwaltungssysteme der wichtigste und meistgenutzte Werkzeugtyp beim Konfigurationsmanagement sind, umfasst das Konfigurationsmanagement weit mehr als nur das Versionsmanagement.
Regulatorische Anforderungen
IEC 62304
Die IEC 62304 („Medical device software – Software life cycle processes“) fordert explizit das Konfigurationsmanagement. Dessen Planung muss bereits Teil des Entwicklungsplans sein. Hersteller müssen festlegen
- welche Artefakte oder Artefakt-Typen der Versionskontrolle zu unterwerfen sind,
- welche diesbezüglichen Tätigkeiten notwendig sind,
- wer (im Unternehmen) die Verantwortung dafür trägt,
- wann die Artefakte unter Konfigurationskontrolle zu stellen sind (unbedingt vor der Verifizierung) und
- wie all dies auch bei der Software-Wartung und Problemlösung geschehen soll.
Der Software-Konfigurationsmanagementprozess umfasst nach IEC 62304 genau die obengenannten Aspekte des Konfigurationsmanagements wie
- Bewertung von Änderungen (→ Changemanagement)
- Entscheidung über Maßnahmen (→ Changemanagement)
- Freigabe von Änderungen (→ Changemanagement)
- Historie der Konfigurationen (→ Versionsmanagement)
Spezifisch für die Norm ist die Forderung nach Konfigurationskontrolle explizit auch für SOUPs und die Verifizierung, dass die geplanten Änderungen erfolgreich durchgeführt wurden.
ISO 13485
Die ISO 13485 („Medical devices – Quality management systems – Requirements for regulatory purposes“) fordert kein explizites Konfigurationsmanagement. Sie sieht es aber als ein Mittel, um die Identifizierbarkeit und Traceability zu gewährleisten.
FDA
Die FDA fordert im „Software Validation Guidance Document“ ebenfalls einen Konfigurationsmanagementplan:
„A configuration management plan should be developed […] Controls are necessary to ensure positive and correct correspondence among all approved versions of the specifications documents, source code, object code, and test suites that comprise a software system. The controls also should ensure accurate identification of, and access to, the currently approved versions.“
Häufigste Fehler beim Konfigurationsmanagement
In Audits werden regelmäßig folgende Probleme offensichtlich
- Es sind nicht alle Artefakte unter Versionskontrolle
- Die Entwicklungs- und Testumgebung ist nicht unter Versionskontrolle
- Testcode und Produktcode können nicht für bestimmte Zeitpunkte und Versionen zueinander passend wieder herstellt werden.
- Der Hersteller hat sich über die Validierung der Werkzeuge keine Gedanken gemacht.
- Es fehlen Begründungen, weshalb beantragte Änderungen nicht durchgeführt werden.
- Es fehlt eine explizite Änderungsfreigabe.
- Nur der letzte Stand der Software vor Release wird „eingecheckt“.
- Der Nachweis fehlt, dass durchgeführte Änderungen tatsächlich die Anforderung erfüllen.
- Der Hersteller testet nicht die ausgelieferte Version.
Weiterführende Hinweise
Mapping zur IEEE 828:2012
Etwas umfassender (und vielleicht auch etwas akademischer) definiert die IEEE 828:2012 die Teilprozesse des Konfigurationsmanagements wie folgt:
- Configuration Identification (CI) → ein Teil ist Versionsmanagement
- Configuration Change Control (CCC) → Change Management
- Configuration Status Accounting (CSA) → z.B. Release Reports, DHF usw.
- Configuration Auditing (CA) → Analytische Qualitätssicherung.
- Configuration Release Management (CoRM) → das passt 1:1 zu der obigen Darstellung
IEEE 828:2012 und Build-Management
Das Buildmanagement erstreckt sich gemäß der Norm quer durch die CM-Disziplinen. Z.B. müssen die Build-Skripte als CI identifiziert werden. Sie stehen natürlich unter CCC und über die zu einem Release gehörenden bzw. aktuell gültigen Versionen wird Buch geführt (CSA).
Änderungen an Build-Skripten müssen geprüft werden (CA) und das für ein Release zu verwendende Build-Skript muss für selbiges zur Verfügung stehen (CoRM).
