In veel sectoren (zoals de auto- en de farmaceutische industrie, luchtverkeersleiding, banken etc.) is een strikte regelgeving bij de implementatie van IT-projecten zeer gebruikelijk. Tegelijkertijd zien we op veel plekken een trend naar strengere en nog uitgebreidere regelgeving. Op het eerste gezicht lijkt APEX, met een focus op agile en snelle ontwikkelmethodes (zoals low-code en snelle applicatieontwikkeling), daarom niet per se geschikt voor oplossingen in een starre, gereguleerde omgeving. Aan de hand van een voorbeeld van een APEX-implementatie in een strikt gevalideerde omgeving binnen de farmaceutische industrie, op het gebied van klinische ontwikkeling, laten we zien hoe deze kenmerkende uitdagingen succesvol kunnen worden overwonnen.
In dit artikel laten we aan de hand van een succesvol project dat we hebben uitgevoerd binnen een groot concern in de farmaceutische industrie zien hoe de ogenschijnlijk tegenstrijdige begrippen ‘agile’ en ‘streng gereguleerd’ toch met APEX kunnen worden gecombineerd. Om dit te doen beschrijven we eerst beide (tegengestelde) concepten, voordat we de oplossingsaanpak presenteren.
Volgens de FDA (U.S. Food and Drug Administration) is validatie:
‘Het aantoonbaar garanderen dat een proces, systeem of product consistent de gewenste resultaten oplevert en voldoet aan vooraf vastgestelde specificaties en kwaliteitsnormen.’
In de farmaceutische industrie worden wettelijke vereisten aangeduid met de term validatie en vastgelegd door de bevoegde autoriteiten in de verschillende landen.
Tabel 1 (klik door in de hoofdafbeelding) geeft een paar relevante voorbeelden. In deze context wordt onderscheid gemaakt tussen het systeem en de software. Dit is belangrijk omdat validatie altijd betrekking heeft op het gehele systeem. De software is hier slechts een (belangrijk) onderdeel. Het systeem omvat behalve de software ook de procedures en de betrokken personen (zie figuur 1).
De centrale richtlijn voor validatie is GAMP 5 (Good Automated Manufacturing Practice) [2]. Deze richtlijn beschrijft een risico-gebaseerde aanpak voor het valideren van systemen. GAMP verdeelt software in de categorieën die in Tabel 2 worden weergegeven, waarbij de benodigde validatie-inspanning toeneemt naarmate de categorie complexer is. In de farmaceutische sector is het vaak verplicht om een IT-systeem te valideren als het systeem betrekking heeft op een van de volgende onderwerpen:
In al deze gevallen moet validatie ervoor zorgen dat er zo min mogelijk bronnen met mogelijke fouten gebruikt worden en dat de betrouwbaarheid van de processen wordt gemaximaliseerd. Daarnaast moeten eventuele procesafwijkingen duidelijk herkenbaar en traceerbaar zijn. Binnen de gevalideerde omgeving van de farmaceutische industrie worden softwareontwikkelingen meestal uitgevoerd volgens het V-model. Dit is weergegeven in Figuur 2.
Vanaf linksboven wordt het volgende proces doorlopen:
Het centrale instrument binnen het hele proces is de functionele risicoanalyse (FRA). Hierbij worden de verschillende mogelijke risico’s geanalyseerd en beoordeeld. Op basis van deze beoordelingen worden maatregelen gedefinieerd die dienen om het risico te minimaliseren. Dit kan leiden tot extra testactiviteiten, procedurele oplossingen, aanvullende trainingen of zelfs aanpassingen in het ontwerp.
Het is duidelijk dat dit een zeer documentatie-intensief en inflexibel proces is. De validatie-inspanning is vaak aanzienlijk groter dan de daadwerkelijke programmeerwerkzaamheden. Aanpassingen kunnen buitensporig veel moeite kosten, vooral als ze pas laat worden ontdekt (bijvoorbeeld tijdens de acceptatietest door de vertegenwoordigers van de eindgebruikers, een vaak voorkomend scenario).
Ook het grote aantal handtekeningen dat vereist is voor de acceptatietests moet in aanmerking worden genomen. Het verzamelen van alle benodigde goedkeuringen kan veel tijd kosten wanneer verantwoordelijken niet direct beschikbaar zijn. Dit is extra kritisch omdat je binnen het V-model pas naar de volgende stap kunt als alle voorgaande stappen formeel zijn goedgekeurd.
In veel opzichten staat dit haaks op de moderne agile-aanpak, zoals Scrum, die steeds populairder wordt in de softwareontwikkeling. De klassieke validatieaanpak is daarmee grotendeels tegenovergesteld aan de flexibele en geleidelijke werkwijze die we tegenwoordig gewend zijn binnen moderne softwareontwikkeling.
Scrum is tegenwoordig in veel organisaties de voorkeursmethode voor agile softwareontwikkeling. We lichten deze methode hier kort toe om het contrast met het validatieconcept te benadrukken. De elementen van het Scrum-raamwerk worden weergegeven in Figuur 3.
Scrum is een geleidelijk proces waarbij het team werkt aan een zogenaamde backlog, in werkblokken van gelijke lengte, de zogenaamde sprints. Er ligt meer nadruk op werkende software dan op uitgebreide documentatie.
Een regelmatige Sprintterugblik en korte ‘Daily Scrum Meetings’, waarin alle problemen direct en snel worden besproken, zorgen voor betere samenwerking. Deze manier van werken verhoogt de implementatiesnelheid van het team (de zogenaamde ‘velocity’). Het vermogen om meer werk succesvol af te ronden tijdens een sprint wordt hiermee hoger.
Drie pijlers van Scrum:
Veranderende eisen vormen een grote uitdaging bij validatie. Dit is het punt waar de agile methode botst met het V-model. In een agile omgeving liggen eisen niet vast en kunnen ze voortdurend veranderen, ook tijdens een project. Deze flexibiliteit is juist de kracht van de agile aanpak. Daarentegen is de watervalmethode (V-model) gebaseerd op starre, vooraf vastgestelde eisen.
Hoe kan het gereguleerde V-model worden toegepast binnen een agile methodologie?
Een tweede uitdaging met betrekking tot APEX is de sterke nadruk op traceerbaarheid van wijzigingen binnen een gevalideerde omgeving. APEX biedt geen ingebouwde audit-trail die duidelijk laat zien wie wat, wanneer en waarom heeft gewijzigd. Bovendien maakt versiebeheer, bijvoorbeeld met Git of Subversion, geen onderdeel uit van de kernfilosofie van APEX.
Hoe kan deze situatie efficiënt worden aangepakt zodat de traceerbaarheid, die essentieel is voor validatie, gewaarborgd blijft?
We illustreren deze punten hieronder aan de hand van een klantproject.
Deze klant is een van de tien grootste farmaceutische bedrijven ter wereld. Het project vond plaats in de fase van klinische ontwikkeling.
De ondersteunde processen zijn streng gereguleerd, gezien het feit dat de software werd gebruikt binnen het goedkeuringsproces. Het vertrouwen in de verzamelde studiedata heeft directe invloed op de goedkeuring van het geneesmiddel. Bovendien kan een softwarefout tijdens een klinische studie patiënten in gevaar brengen, met alle mogelijke gevolgen van dien.
De validatiediensten die door de klant moesten worden geleverd, omvatten het opstellen van de door het V-model voorgeschreven documenten in HP ALM (Application Lifecycle Management system), het uitvoeren van code reviews (volgens het vierogenprincipe), het uitvoeren van testcycli (unit testen, met utPLSQL en OQ) en de installatie (volgens IQ).
In deze opzet kozen we voor een pragmatische aanpak, die we tijdens het project doorlopend hebben verfijnd. We maakten gebruik van MS Teams (Microsoft) om gezamenlijk aan documenten te werken en van Atlassian Jira voor het agile volgen van werkblokken en het plannen van sprints.
We verdeelden het project in tijdsintervallen, vergelijkbaar met sprints, en werkten in elk van deze periodes agile. Aan het einde van een interval definieerden we een baseline en pasten we in een validatiesprint de waterval-achtige validatie toe volgens het V-model (FS-DS-UT-IQ-OQ-PQ) om zo de formele vrijgave te bereiken (zie Figuur 4).
Vervolgens hebben we de afwijkingen en aanpassingen die werden vastgesteld tijdens de unittesten, systeemtesten (OQ) en gebruikersacceptatietesten (PQ) vastgelegd in een verandermanagement-systeem en daarna de bijbehorende risico’s beoordeeld met behulp van de Functionele Risico Analyse (FRA).
Tijdens de implementatie vonden we het belangrijk om het APEX-gedeelte eenvoudig te houden. Dit hield onder andere in:
Coderingsrichtlijnen zijn vanaf de start van het project belangrijk geweest. We hebben deze richtlijnen niet star vastgelegd, maar ze al doende verder ontwikkeld en verfijnd tijdens de sprint-retrospectives. Deze richtlijnen vormden vervolgens de basis voor het formele code review-proces.
Gedurende het project kregen we ook de kans om van fouten te leren: met name de afhandeling van fouten bleek erg belangrijk. Het bewaren van fouten, waarschuwingen en informaties bleek onmisbaar voor het debuggen. Vanuit onze ervaring kunnen we de open source software logger van OraOpenSource [3] ten zeerste aanbevelen, omdat deze de gehele foutafhandeling standaardiseert.
Verder is het zeer nuttig gebleken om een APEX-pagina, voor de informatie en het foutenlogboek, op te nemen. Met beheerdersrechten is deze pagina zichtbaar zodat de transparantie vergroot wordt.
Verder maken we gebruik van de zogenaamde ‘Build Options’ van APEX om functionaliteit flexibel te kunnen integreren (zie Figuur 5). Met een eenvoudige configuratiewijziging kunnen deze ‘verborgen’ functionaliteiten makkelijk aan- of uitgezet worden voor de eindgebruiker (zoals pagina’s, menu-items, etc.). Dit dient om nieuwe functionaliteit te kunnen verifiëren zonder dit direct beschikbaar te maken voor de eindgebruiker; op deze manier kan de introductie van functionaliteit worden losgekoppeld van het rigide kader van het V-model.
Conclusie
Dankzij deze pragmatische maatregelen konden we de agile principes succesvol toepassen in dit project, terwijl we tegelijkertijd voldeden aan de strenge regelgeving.
Dit leverde een belangrijke bijdrage aan de succesvolle uitvoering van ons project, tot volle tevredenheid van de klant. En wat we hier geleerd hebben zal zeker van waarde blijken voor vergelijkbare APEX-projecten in sterk gereguleerde omgevingen.
Auteurs: Hansjörg Grässlin, Christophe Girardey en Dr. Christian Wattinger
Vertaald naar het Nederlands door Monique van Helden
Bronnen
[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
