Agil unterwegs mit APEX in einem stark regulierten Umfeld

Von Hansjörg Grässlin, Christophe Girardey und Dr. Christian Wattinger

 

Viele Branchen haben strenge Vorschriften (Autoindustrie, Pharma, Flugsicherung, Banken usw.), was die Umsetzung von IT-Projekten betrifft, und es gibt vielerorts eine Tendenz zu mehr und strengeren Regulierungen. APEX mit seiner Ausrichtung auf agile und schnelle Entwicklungsansätze (z.B. Low Code, Rapid Application Development) scheint auf den ersten Blick nicht per se für Lösungen in einem starren, regulierten Umfeld geeignet zu sein. Am Beispiel einer APEX-Implementierung in einer streng validierten Umgebung in der pharmazeutischen Industrie im Bereich der klinischen Entwicklung (Clinical Development) zeigen wir, wie diese inhärenten Probleme erfolgreich überwunden werden können.

 

In diesem Artikel möchten wir am Beispiel eines erfolgreichen Projekts, das wir in einem Großkonzern in der Pharma-Branche durchgeführt haben, darstellen, wie man die auf den ersten Blick widersprüchlichen Konzepte „agil“ und „streng reglementiert“ mit APEX zusammenbringen kann. Dazu werden zuerst die beiden gegenüberstehenden Konzepte beschrieben, bevor der Lösungsansatz dargestellt wird.

 

Validierung ist...

…gemäß der amerikanischen Food and Drug Administration (FDA):

„Die Etablierung dokumentierter Nachweise, die ein hohes Maß an Sicherheit dafür bieten, dass ein bestimmter Prozess ein Produkt herstellt, das seinen vorgegebenen Spezifikationen und Qualitätsmerkmalen entspricht.“

In der Pharma-Industrie werden die regulatorischen Anforderungen als Validierung bezeichnet und in den verschiedenen Ländern von den entsprechenden Ämtern vorgegeben.

 

 

In Tabelle 1 sind einige relevante Beispiele aufgeführt: In diesem Zusammenhang unterscheidet man zwischen System und Software. Dies ist wichtig, denn eine Validierung bezieht sich immer auf das ganze System, in dem die Software nur ein – wenn auch wichtiger – Teilbereich ist. Das System beinhaltet unter anderem aber auch die Prozeduren und Personen, die involviert sind (siehe Abbildung 1).

 

 

Zentraler Leitfaden der Validierung ist GAMP 5 [2] (Good Automated Manufacturing Practice), der einen risikobasierten Ansatz beschreibt, um Systeme zu validieren. GAMP teilt Software in die in Tabelle 2 aufgeführten Kategorien auf, wobei der Validierungsaufwand mit der Kategorie ansteigt. Im Pharma-Bereich ist es in folgenden Fällen angezeigt und vorgeschrieben, ein IT-System zu validieren, falls das System eines der folgenden Themen betrifft:

• Sicherheit von Personen, insbesondere Patienten
• Produktqualität
• Daten-Integrität und damit letztlich das Vertrauen in die Daten (wichtig zum Beispiel bei klinischen Studien für die Zulassung eines Medikaments)

 

 

In allen diesen Fällen soll eine Validierung sicherstellen, dass Fehlerquellen minimiert werden und die Zuverlässigkeit der Prozesse maximiert wird. Des Weiteren müssen auftretende Prozessabweichungen klar erkennbar und nachvollziehbar sein. Im validierten Umfeld der Pharma-Industrie werden Software-Entwicklungen meist nach dem V-Modell durchgeführt. Dieses ist in Abbildung 2 dargestellt.

 

 

Beginnend oben links wird der folgende sequenzielle Prozess durchlaufen:

• Erstellen und Abnahme eines Validation- Plans (VP), der beschreibt, wie das System validiert werden soll.
• Erstellen und Abnahme der User Requirements Specification (URS), die beschreibt, welche Nutzeranforderungen an das System gestellt werden.
• Erstellen und Abnahme der Functional Specification (FS), die erläutert, wie die URS funktional umgesetzt wird.
• Erstellen und Abnahme der Design Specification (DS). Hier wird genau dargestellt, wie die Funktionalitäten aus der FS technisch implementiert werden.
• Dann – ganz unten im V-Modell – wird die Software programmiert. Am Ende der Implementierung erfolgt ein Code Review, um die Programmierung durch das 4-Augen-Prinzip einem Qualitätscheck zu unterwerfen. Hieraus wird eine zu testende Installationsanleitung (IQ) erstellt und abgenommen.
• Auf der rechten Seite, einen Schritt hoch, erfolgt dann die Ausführung der Unit-Tests, um die akkurate Umsetzung gemäß DS zu überprüfen. Test-Abweichungen müssen formell behandelt und am Ende müssen alle Test-Resultate abgenommen werden.
• Erst dann geht es wieder einen Schritt hoch, wo die funktionalen Tests (OQ) die korrekte Umsetzung der Funktionalität gemäß FS überprüfen. Wiederum gilt hier wie oben: Test-Abweichungen müssen formell behandelt und am Ende alle Test-Resultate abgenommen werden.
• Erst dann wird der Abnahme-Test (PQ) durch die Benutzer durchgeführt!
• Ganz am Ende wird ein Validation-Report (VR) erstellt, der darstellt, wie alle geplanten Prüfungs- und Abnahmeschritte erfolgreich durchlaufen wurden; er beweist so die nachvollziehbare Qualität des Resultats – also der fertigen Software. Die formale Freigabe des Validation- Reports führt zur Freigabe des Systems für die produktive Verwendung.

 

Zentrales Werkzeug des gesamten Prozesses ist die funktionale Risiko-Analyse (FRA). Hierbei werden die verschiedenen möglichen Risiken analysiert und bewertet. Auf Basis dieser Bewertungen werden Maßnahmen festgelegt, die dazu dienen, das Risiko zu minimieren. Dies kann zu zusätzlichen Testaktivitäten, prozeduralen Lösungen, zusätzlichem Training oder gar zu Designänderungen führen.

Es wird unmittelbar klar, dass dies ein sehr dokumentationslastiger, unflexibler Prozess ist. Der Validierungsaufwand ist oft viel höher als die effektive Programmierung und Anpassungen können mit unverhältnismäßig großem Aufwand verbunden sein, vor allem, wenn sie spät erkannt werden (z.B. erst im Abnahmetest durch die Endbenutzervertreter – ein durchaus typischer Fall). Dabei sind auch die vielen Unterschriften für die Abnahmen zu berücksichtigen; das Sammeln aller nötigen Unterschriften kann oft lange dauern, wenn Verantwortliche nicht verfügbar sind. Dies ist insbesondere darum kritisch, da man im V-Modell nicht mit dem nächsten Schritt beginnen darf, bevor nicht alle vorhergehenden Schritte durch Unterschriften abgenommen sind.

Dies widerspricht in vielfältiger Weise dem modernen agilen Ansatz – zum Beispiel von Scrum –, der sich in der Software-Entwicklung wachsender Beliebtheit erfreut, und ist somit fast das genaue Gegenteil von dem flexiblen und iterativen Vorgehen, das wir in der modernen Softwareentwicklung eher gewohnt sind.

 

Scrum

Scrum ist unterdessen in vielen Organisationen die Methodologie der Wahl für die agile Software-Entwicklung. Hier wollen wir diese Methodologie daher nur kurz umreißen, um die Gegensätzlichkeit zum Konzept der Validierung herauszustreichen. Die Elemente des Scrum-Frameworks sind in Abbildung 3 dargestellt:

 

 

Scrum ist ein iterativer Prozess, in dem es darum geht, dass das Team in jeweils gleich langen Arbeitsblöcken – „Sprints“ – ein sogenanntes Backlog abarbeitet. Dabei wird mehr Wert auf funktionierende Software als auf extensive Dokumentation gelegt.

Regelmäßige Retrospektiven und tägliche kurze „Daily Scrum Meetings“, in denen jeweils alle Probleme direkt und zeitnah angesprochen werden, dienen der Verbesserung der Teamarbeit und somit der Erhöhung der Umsetzungs- Geschwindigkeit („Velocity“) des Teams, also der Kapazität, während eines Sprints mehr Arbeit erfolgreich zu erledigen.

Drei Grundpfeiler von Scrum sind daher:

1. Offenes und direktes Ansprechen von Hürden – „Transparency“
2. Selbstüberprüfung des Teams und der Prozesse – „Inspection“
3. Anpassungen und Verbesserung des Teams – „Adaption“

 

Die Herausforderungen der Validierung mit Oracle APEX

In der Validierung sind sich ändernde Anforderungen eine große Herausforderung. Hier kollidiert die agile Methodologie mit dem V-Modell. Im agilen Umfeld sind Anforderungen nicht festgelegt, sie können sich während des Projekts laufend ändern. Dies ist eine Stärke des agilen Ansatzes. Umgekehrt basiert die Wasserfall-Methode (V-Modell) auf starren Anforderungen.

Wie also kann man das regulierte VModell mit einer agilen Methodologie umsetzen?

Eine zweite Herausforderung in Zusammenhang mit APEX ist die starke Betonung der Nachvollziehbarkeit von Anpassungen im validierten Umfeld. APEX bietet kein eingebautes Audit Trail, woraus direkt ersichtlich ist, wer, wann, was aus welchem Grund geändert hat. Versionskontrolle – zum Beispiel mit Git oder Subversion – ist nicht in der APEX-Kernphilosophie enthalten.

Wie kann dieser Umstand effizient adressiert werden, sodass die für die Validierung kritische Nachvollziehbarkeit gewährleistet werden kann?

Diese Punkte zeigen wir im Folgenden anhand eines Kundenprojekts auf.

 

Ein validiertes Kundenprojekt mit Oracle APEX

Der Kunde ist eine der zehn größten Pharma-Firmen der Welt. Das Projekt war in der klinischen Entwicklung angesiedelt.

Die unterstützten Prozesse sind stark reglementiert, da die Software innerhalb des Zulassungsverfahrens eingesetzt wurde. Das gewonnene Vertrauen in die erhobenen Studiendaten hat eine direkte Auswirkung auf die Zulassung des Medikaments. Außerdem könnte ein Software- Fehler während einer Studie Patienten gefährden – mit allen sich daraus ergebenden Konsequenzen.

Die vom Kunden vorgegebenen zu erbringenden Validierungs-Services beinhalteten das Erstellen der vom V-Modell vorgeschriebenen Dokumente in HP ALM (ein Application Lifecycle Management System), das Durchführen von Code Reviews (4-Augen-Prinzip), die Durchführung der Testzyklen (Unit-Tests – mit utPLSQL, OQ) und die Installation (gemäß IQ).

 

Der pragmatische Approach

In dieser Konstellation haben wir uns für eine pragmatische Herangehensweise entschieden und diese während des Projekts laufend verfeinert. Für das gemeinsame Arbeiten an Dokumenten verwendeten wir die Kollaborationstools von Microsoft (MS Teams) sowie Atlassian Jira für das agile Tracking der Arbeitsblöcke und zum Planen der Sprints.

Wir haben das Projekt in Zeitintervalle eingeteilt, analog Sprints, und in diesen Intervallen jeweils agil gearbeitet. Am Ende eines Intervalls haben wir eine Baseline definiert und darauf die Wasserfall-artige Validierung gemäß V-Modell (FS-DS-UT-IQ-OQ-PQ) in einem Validierungs-Sprint angewendet, um die formale Freigabe zu erreichen (siehe Abbildung 4).

 

 

Die festgestellten Abweichungen und Anpassungen aus Unit-Tests, System-Tests (OQ) und Benutzer-Akzeptanz-Tests (PQ) haben wir dann in einem Change-Management- System erfasst und anschließend die damit verbundenen Risiken durch das Functional Risk Assessment (FRA) bewertet.

Bei der Umsetzung haben wir starken Wert darauf gelegt, den APEX-Teil einfach zu halten. Das heißt unter anderem:

1. den Source Code möglichst gering zu halten durch Ausnutzen des Low-Code-Ansatzes von APEX,
2. PL/SQL-Code in APEX wurde konsequent auf DB-Packages ausgelagert (z.B. pipelined functions in APEX Interactive Reports (IR), Datenbankfunktionsaufrufe in APEX-Prozessen, Berechtigungssteuerung in Datenbankfunktions-Aufrufen),
3. alle Datenbankobjekte (Packages, Functions, Views etc.) wurden konsequent der Versionskontrolle in Git unterworfen. Git wurde dabei als single source of truth definiert.

 

Coding Guidelines sind sehr wichtig, schon zu Beginn des Projekts. Diese Richtlinien hatten wir nicht starr fixiert, sondern laufend in den Sprint Retrospectives weiterentwickelt und verfeinert. Diese Guidelines dienten dann als Basis für den formellen Code-Review-Prozess.

Im Laufe des Projekts hatten wir auch Gelegenheit, aus Fehlern zu lernen: Das Error Handling hat sich als sehr wichtig herausgestellt. Das Persistieren von Fehlern, Warnungen und Informationen stellte sich für das Debugging als unverzichtbar heraus. Hier ist aus unserer Sicht die Open-Source-Software Logger von OraOpenSource [3] sehr empfehlenswert, da es das gesamte Error Handling standardisiert. Des Weiteren hat es sich als sehr nützlich erwiesen, eine APEX-Seite für das Information- und Error- Log einzubauen, die mit Admin-Berechtigung sichtbar ist, um die Transparenz zu erhöhen.

Wir setzten die sogenannten „Build Options“ von APEX ein, um flexibel Funktionalitäten einbauen zu können (siehe Abbildung 5). Durch einen einfachen Configuration Change konnten diese „versteckten“ Funktionalitäten für den Endbenutzer einfach ein- und ausgeschaltet werden (Pages, Menü Items etc.). Dies diente zur Verifizierung der neuen Funktionalitäten ohne deren Bereitstellung für die Endbenutzer; so konnte das Einführen von Funktionalität vom starren Gerüst des V-Modells entkoppelt werden.

 

 

Fazit

Durch diese pragmatischen Maßnahmen gelang es uns, die agilen Prinzipien erfolgreich zum Vorteil für das Projekt zu nutzen und gleichzeitig den strengen regulatorischen Anforderungen zu genügen.

Dies hat entscheidend dazu beigetragen, unser Projekt erfolgreich und zur Zufriedenheit des Kunden umzusetzen.

Die gezogenen Lehren können auch für ähnlich gelagerte APEX-Projekte in streng regulierten Umgebungen hilfreich sein.

 

Quellen

[1] Components of a validated computerized system, PIC/S Quelle: PIC/S (2007)
[2] GAMP5, A Risk based Approach to Compliant GxP Computerized Systems, ISPE (2008). Tampa, Fla. ISPE Headquarters [u.a].
[3] Logger, OraOpenSource, https://github.com/OraOpenSource/Logger