Ein Gegensatz in der Softwareentwicklung?
In allen Computer-Compliance Projekten der vergangenen Jahre war das Stickwort agil präsent – entweder ganz offiziell als Beratungsauftrag oder als Diskussionsthema vor der Kaffeemaschine: Über die Möglichkeiten, den Sinn und Unsinn agiler Softwareentwicklung im GXP und CSV Umfeld wurde immer gesprochen. Digitale Trends (1) befeuern diese Diskussion, besonders dann, wenn die Kaffeemaschine im digitalen Zeitalter selbstständig nach Bohnen und Milch ruft. Aber auch ohne die Notwendigkeit von gutem Kaffee ist die agile Softwareentwicklung in den Unternehmen (oder ein anderer WO-Bezug) angekommen und wird von der Individualentwicklung bis zum Greenfield SAP Hana Projekt eingesetzt.
Key-Elemente der agilen Computer System Validierung (CSV)
Die Meinungen zu „agil“ reichten dabei von „no-way / geht nicht“ bis hin zu „Wo ist das Problem?“. Momentan polarisiert keine Frage mehr die Community als „Wenn ja, wie geht agile CSV?“. Dabei haben beide Methoden diametral unterschiedliche Prioritäten:
Das agile Manifest (2) priorisiert „Funktionierende Software mehr als umfassende Dokumentation“. Im GxP-Umfeld ist es jedoch genau umgekehrt: Ich kann Fehler akzeptieren, wenn diese bekannt sind, bewertet wurden und das mit dem Fehler einhergehende Risiko (für den Patienten und die Produktqualität) entweder akzeptiert oder mitigiert ist. Dieser Prozess ist zu dokumentieren – so fordert der Annex 11 gleich in Abschnitt §1: „validation and data integrity controls should be based on a justified and documented risk assessment of the computerised system” (3). Deutlicher geht es nicht.
Unterschiede zwischen „User Story“ und „User Requirement“
Die gute Nachricht: Es gibt auch Gemeinsamkeiten, allein schon in den Begrifflichkeiten. Was liegt näher als eine Verwandtschaft zwischen einer „User Story“ (Agile) und einem „User Requirement“ (GxP) zu vermuten? Doch hier liegt der Teufel im Detail. Die meisten agilen Methoden verwenden die User-Story als Einweg. Einmal abgearbeitet wird sie archiviert und nicht weiter versioniert. Im GxP-Umfeld existieren verschiedene Versionen einer Anforderung, bei denen sich Änderungen über eine Historie nachverfolgen lassen. So genügen auch die bekannten agilen Tools nicht den Anforderungen an Revisionssicherheit und Data Integrity. Einige Konzepte, wie etwa die Risikoanalyse, fehlen vollständig.
Hier müssen die agilen Methoden nachgearbeitet werden, um GxP-Anforderungen und Best Practises zu erfüllen. Hybride Ansätze sind dabei aus der Not geboren: Die Validierungs-Deliverables werden in das agile Definition-of-Done übernommen, womit die Computer-System-Validierung selber von der Methode zum Deliverable wird. In der Praxis kommt es zu einer Teilung des agilen Sprints in eine freie und agile Entwicklungs- sowie eine folgende Dokumentationsphase. In letzterer wird rückwirkend der Sprint nach den Regeln der CSV nachdokumentiert, verschriftlicht und unterschrieben. Hier kommt es häufig zum Cut & Paste durch Validierungs- und Dokumentationsmanager, der Informationen aus dem agilen Tool in die CSV-Templates überträgt. Ein Fall von Verschwendung und im traditionellen Sinn ein No-Go.
GxP-Anforderungen erfüllen mit Hilfe agiler Prozesse
Die Lösung liegt in der Anpassung agiler Prozesse, so dass GxP-Anforderungen inhärent erfüllt werden. Die User Story ist im Best Case versionierbar, es gibt einen Ticket-Typen für die Risikoanalyse, die Tests sind hochgradig automatisiert und haben einen Bezug zu Nutzeranforderungen, Risiken und technischen Objekten. Andere GxP-Dokumente wie der Source-Code-Review-Berichte sind voll automatisiert in den SDL eingebunden und werden nicht mehr als eigenes Dokument unterschrieben, sondern nur noch versioniert mit Bezug zur versionierten Software abgelegt. Durch die der Regeln für diesen automatisierten Bericht entfällt hier die Genehmigung des einzelnen Berichtes.
Wir als msg industry advisors ag unterstützen Sie in diesem zukunftsweisenden Thema dabei, das Gleichgewicht zwischen Digitalisierung, Agilität und Compliance zu finden und einen erfolgreichen GoLive Ihrer Projekte zu erzielen!
Quellen
(2) https://agilemanifesto.org/iso/de/manifesto.html
(3) https://ec.europa.eu/health/sites/health/files/files/eudralex/vol-4/annex11_01-2011_en.pdf
