Panic coronavirus

Case: RIVM buigt zich over pandemie-IT

© CC0 - gebaseerd op Pixabay.com,  Geralt en iXimus (Vektor Kunst)
4 november 2011

RIVM en NVI wilden een rechttoe, rechtaan oplossing voor de IT-ondersteuning van de vaccinatie tegen de jaarlijkse seizoensgriep. Die campagne verloopt elk jaar hetzelfde, toekomstvastheid was dus geen vereiste. Maar de Mexicaanse griep zette betrokkenen aan het denken.

De vaccinatie tegen de Mexicaanse griep liep in Nederland gesmeerd. Onder meer dankzij zeer professioneel projectmanagement bij RIVM en SNPG (Stichting Nationaal Programma Grieppreventie), maar ook dankzij een handige online bestelapplicatie. Zo’n maatwerkoplossing omvat genoeg functionaliteit om team van ontwerpers en Java-programmeurs maanden zoet te houden. Toch hadden ConQuaestor en Sogeti de hele zaak binnen twee weken ‘up and running’. De truc: het was een aangepaste versie van een op dat moment toevalligerwijze onder constructie zijnde webapplicatie voor de distributie van seizoengriepvaccins. Met wat overwerk in de weekeinden, kon een ontwikkelteam van Sogeti de circa 15 vereiste functionele aanpassingen trefzeker doorvoeren. Uiteindelijk koste aanpassing opdrachtgevers RIVM en SNPG ruim 25 procent aan meerkosten op een aanneemsom voor de oorspronkelijk bestelde applicatie van ongeveer een ton. Een opmerkelijke prestatie; te meer daar functionele flexibiliteit/aanpasbaarheid geen deel uitmaakte van het oorspronkelijke eisenpakket.

Bestelsysteem

Het aanvankelijk gewenste bestel­systeem was bedoeld voor ruim 5000 huisartsen die griepvaccins bestellen. Omdat deze doelgroep weinig affiniteit heeft met computers, zou de bestelpagina van de webapplicatie zo veel mogelijk moeten lijken op de papieren formulieren die worden vervangen. In de achtergrond zou het systeem functies en mogelijkheden moeten toevoegen, zoals:

  • elektronisch declareren
  • controle op identiteit van de besteller
  • de mogelijkheid om te kiezen uit een aantal voorraadtechnisch haalbare aflevermomenten
  • verfijning van de signalering van afwijkende bestellingen (de definitie van afwijkend was ‘meer dan 5000 stuks’ en wordt ‘meer dat 10 procent afwijking ten opzichte van vorig jaar’.)
  • diverse managementrapportages

De primaire bedrijfskundige reden voor de invoering van het online bestellen was echter vooral efficiëntie: het in SAP overnemen van de door de artsen op de formulieren gekrabbelde informatie kost tijd en brengt onvermijdelijk fouten met zich mee. Alleen al op basis van het wegvallen van personele inzet voor dit karwei werd de terugverdientijd voor het project op minder dan drie griepseizoenen geschat.

Open source

Feitelijk was het beoogde bestelsysteem niet veel meer dan een ‘web-voorkant’ oftewel een ‘eindgebruiker-interface’ voor de SAP-omgeving van het Nederlands Vaccin Instituut (NVI). Gebruik van de webinterface van SAP werd door RIVM en SNPG om diverse redenen niet wenselijk geacht. Zo stelde men weinig vertrouwen in de mogelijkheden om deze zo gebruiksvriendelijk te maken dat de huisartsen er goed mee overweg zouden kunnen. Maar er was nog een reden om ‘iets anders’ te willen: het opdrachtgeversduo wenste per se een technology-lock-in te vermijden en eiste daarom dat het systeem in principe geschikt zou zijn om op ERP-systemen van diverse pluimage aan te sluiten. Mede om die reden werd een voorkeur uitgesproken voor open source.

Aanpassing van een bestaand open­source CMS of EMS of ERP bleek vanwege de complexiteit geen begaanbare weg. Daarom werd uiteindelijk gekozen voor realisatie als volledig maatwerk op basis van een open source Java-ontwikkelomgeving. Ofschoon de ontwikkelde applicatie zelf ook als open source zal worden vrijgegeven, lijkt het programma coördinator Marie-Louise Heijnen van RIVM niet erg waarschijnlijk dat zich op korte termijn nog andere gebruikers dan het NVI zullen melden: “Bij mijn weten is de Nederlandse aanpak van de vaccinaties, via huisartsen onder centrale regie van RIVM, tamelijk uniek. Ofschoon het uitstekend werkt, verwacht ik niet dat het het één op één kan worden overgenomen door bijvoorbeeld een van onze buurlanden, maar je weet nooit.”

De realisatie van de webapplicatie is onder projectmanagement van ConQuaestor door Sogeti uitgevoerd. De uiteindelijke programmering van de applicatie verliep door strakke sturing en nauwe samenwerking binnen budget en conform planning. Dat wil zeggen niet zonder verrassingen, maar wel zonder echte problemen. Het door ConQuaestor opgestelde functioneel ontwerp – in Word-bestanden – bevatte volgens De Koning nog wel enkele onduidelijkheden. Sogeti loste dat op door het ontwikkelteam, bestaande uit een projectleider, een systeemarchitect en twee Java-programmeurs, uit te breiden met een functioneel ontwerper. Deze zou de ontbrekende informatie bij elkaar sprokkelen via overleg met ConQuaestor, regievoerder RIVM, opdrachtgever SNPG, NVI en een testgroep van circa tien huisartsenpraktijken. De samenwerking met dit grote aantal organisaties (met mogelijk tegenstrijdige deelbelangen) werd door zowel ConQuaestor als Sogeti aanvankelijk geïdentificeerd als belangrijkste risicofactor voor het project, maar pakte achteraf gezien goed uit. Daarnaast gold de slechts op hoofdlijnen uitgewerkte specificatie van de interface met de SAP-omgeving als een risico, maar ook dat leverde Sogeti uiteindelijk geen echte problemen op.

Mexicaanse griep

Achteraf bezien is de onverwachte ‘nevenproductie’ van een variant voor de Mexicaanse griep dan ook zonder twijfel het meest uitdagende aspect van het hele project. Vooral vanwege van het onvoorziene en tijdkritieke karakter. Aanpasbaarheid was tot dusverre geen vereiste. Toekomstige geschiktheid om behalve griepvaccins ook andere niet aan de seizoensgriep gerelateerde producten te kunnen bestellen, was in het programma van eisen meegenomen als ‘would have’-optie. Dat wil zeggen: ‘wenselijk’, maar met de laagste prioriteit.

De aanpassingen die voor de Mexicaanse griep vereist waren, betroffen onder meer een herdefiniëring van de groep bestellers. Bij de seizoensgriep mogen alleen huis-, verpleeghuisartsen en artsen-geestelijkgehandicapten vaccins bestellen, maar bij de Mexicaanse griep zou een prominentere rol zijn weggelegd voor de zorginstellingen en GGD’s. Andere aanpassingen betroffen onder meer het feit dat het hier om twee prikken per patiënt zou gaan. Ook leidde de onzekerheid over het verloop van de pandemie tot een behoefte aan diepgaandere managementinformatie om zodoende sneller en gedifferentieerder inzicht te krijgen die ontwikkeling van de vaccinatiegraad per groep van de bevolking. Artsen dienden daartoe aan te geven hoeveel vaccins ze per patiëntcategorie dachten in te zetten. De voor de seizoensgriep gewenste (en op dat moment nog niet gerealiseerde) ‘twee-richtingskoppeling’ met het SAP-systeem van NVI was voor de Mexicaanse griep niet nodig.

Enthousiast geworden door het succes van de ‘Mexicaanse aanpassing’, en wellicht ook onder invloed van de Q-koortscommotie, heeft het RIVM inmiddels de vraag opgeworpen of het wellicht niet verstandig is om op korte termijn een versie te ontwikkelen die kan worden ingezet bij toekomstige epidemieën, die niet noodzakelijker wijze aan de griep verwant zijn en in principe uit totaal onverwachte hoek kunnen komen. Heijnen wil zelfs nog wel een stapje verder gaan: “Eigenlijk zou je aan calamiteiten in nog ruimere zin moeten denken, dus ook bij bedreigingen voor de volksgezondheid waarbij besmettelijkheid misschien niet direct een rol speelt.”

Geschiktheid voor toekomstige niet voorzienbare campagnes zou in feite neerkomen op een radicale omkering van de eisen ten aanzien van flexibiliteit; van ‘prettig, maar niet belangrijk’ naar ‘moet per se’. Java geldt echter niet als een programmeeromgeving die snelle functionele aanpassingen op ontwerpniveau eenvoudig mogelijk maakt. De Koning van Sogeti denk dat daar tot op zekere hoogte wel een mauw aan te passen zal zijn door de programmacode goed te modulariseren: “Dan kun je voor verschillende onderdelen van het proces verschillende modules ontwikkelen die naar keuze zijn te combineren tot een applicatie die voor die specifieke situatie geschikt is. Ook kun je die modules configureerbaar maken, zodat de gebruiker bepaalde opties aan of uit kan zetten.”

Alternatieven

De vraag blijft uiteraard of op die wijze ook alle functionaliteit is in te bouwen die RIVM in geval van toekomstige calamiteiten nodig kan hebben. Is het eigenlijk wel mogelijk om een applicatie te maken die in die zin is voorbereid op het onvoorzienbare? Zou het niet verstandiger zijn om te zorgen dat je in geval van een dreigende calamiteit heel snel een unieke op die situatie toegesneden maatwerkoplossing kunt genereren? Er bestaan immers geïntegreerde analyse/ontwerp/engineering-omgevingen, waarin functionele specificaties grafisch worden vastgelegd, automatisch op hun (interne) consistentie worden gecontroleerd en met een ‘druk op de knop’ worden omgezet in een één op één uitvoerbare (c.q. compileerbare) applicatiecode.

Als snelle aanpasbaarheid voor toekomstige calamiteiten-bestrijdingen vanaf het begin een eis zou zijn geweest, was dan de keuze eveneens op Java gevallen? Schapendonk: “Dat is een wat academische vraag. Eest gaan we gewoon deze Java-applicatie implementeren. Over die aanpasbaarheid aan het onvoorspelbare, daarover moeten we echt nog nadenken. Willen we het? Kunnen we het? Ja, en als we die vragen dan bevestigend beantwoorden, gaan we kijken wat dan de meest geschikte technische omgeving is, en dan hoeft natuurlijk niet opnieuw Java te zijn.”

Gelukkig toeval

De aanpassing voor de Mexicaanse griep was relatief eenvoudig te maken. Stel nu dat het verzoek voor deze functionele aanpassing later was gekomen. Bijvoorbeeld in 2012. Het oorspronkelijke team was dan niet meer beschikbaar geweest. Nieuwe mensen zouden zich moeten inwerken op (drie jaar) oude code en documentatie die ze niet zelf hebben opgesteld. Welke impact zou dat gehad hebben op de doorlooptijd en kosten?

Schapendonk: “Ja, die toevallige omstandigheid heeft natuurlijk enorm geholpen, maar ik denk niet dat het allesbepalend is geweest. Als we over twee jaar weer een vergelijkbare aanpassing moeten doorvoeren, verwacht ik dat dat nog steeds kan. Sogeti neemt immers ook een verantwoordelijkheid voor onderhoud van de door hen gemaakte code op zich.”

Onafhankelijk (dat wil zeggen; niet bij RIVM of het griep-project betrokken) IT-consultant Peter Noordam van Bisnez bevestigt desgevraagd dat ook zonder business process management-suite in het algemeen wel degelijk een behoorlijke mate van flexibiliteit voor de toekomst realiseerbaar is, maar: “De doorlooptijd van functionele aanpassingen zal dan wel eerder in maanden dan in dagen moeten worden berekend.” Een luxe die RIVM zich in het geval van een dreigende pandemie wellicht moeilijk zal kunnen veroorloven.

 
Lees het hele artikel
Je kunt dit artikel lezen nadat je bent ingelogd. Ben je nieuw bij AG Connect, registreer je dan gratis!

Registreren

  • Direct toegang tot AGConnect.nl
  • Dagelijks een AGConnect nieuwsbrief
  • 30 dagen onbeperkte toegang tot AGConnect.nl

Ben je abonnee, maar heb je nog geen account? Laat de klantenservice je terugbellen!