Na negatieve ervaringen met ‘te slechte, te dure en te late software’ besloot de GGD Amsterdam om voortaan alle software die de medewerkers nodig hebben zelf te ontwerpen, ontwikkelen en beheren. Onder andere een forensisch artsensysteem dat nu bijna landelijk in gebruik is en sinds dit jaar zelfs een heuse ‘GGD AppStore’ zijn het voorlopige resultaat. Een blik in de ontwikkelkeuken van de GGD Amsterdam.
‘Een GGD is eigenlijk een soort bedrijfsverzamelgebouw’, schetst Michiel Hauptmeijer, bij de GGD Amsterdam manager ITforCare. De Amsterdamse GGD bestaat onder andere uit een afdeling voor Jeugdgezondheidszorg (JGZ), een Reizigersadvies- en Vaccinatiebureau, een SOA-poli en forensische geneeskunde. ‘Die verschillende disciplines hebben allemaal verschillende behoeften en voeren allerlei onderzoeken uit waarvoor ze applicaties nodig hebben die vaak niet in de markt beschikbaar zijn.’
‘In het verleden heeft de GGD Amsterdam veel ellende gekend met slechte, dure en te late commerciële software’, vervolgt Ben Reuling, systeemontwerper bij de GGD Amsterdam. ‘Meer dan dertien jaar geleden is daarom besloten om de software die we gebruiken zelf te ontwikkelen. Sindsdien proberen we alles zelf te bouwen.’
GGD AppStore
Zo bouwden de ontwikkelaars van de GGD Amsterdam onder andere de webapplicatie Tatoeus voor het registreren en inzien van de vergunningsaanvragen van tatoeëerders en piercers. Ook kwamen er nieuwe systemen voor de afhandeling van reizigersvaccinaties en voor de SOA-poli.
Daarnaast tekende de GGD Amsterdam voor de bouw van de GGD AppStore die begin 2016 werd gelanceerd. Via www.ggdappstore.nl zijn alle gezondheidsapps te vinden die voldoen aan de door de GGD opgestelde criteria en die zijn voorzien van een GGD-keurmerk. Deze AppStore wordt nu ondersteund door alle 25 GGD’en, koepelorganisatie GGD GHOR Nederland en de bureaus voor de ‘Geneeskundige Hulpverleningsorganisatie in de Regio’.
Landelijke ambities
Het forensisch registratiesysteem Formatus is een ander voorbeeld van een door de GGD Amsterdam gebouwde applicatie die nu bij meerdere GGD’en in gebruik is. ‘Veertien andere GGD’en gebruiken Formatus en dat verbetert de communicatie’, aldus Reuling. ‘Als een cliënt de ene week onwel wordt in Groningen en een week later in Maastricht, dan vinden de registraties plaats in hetzelfde systeem en is het proces exact hetzelfde. Het zou nog beter zijn als Formatus landelijk wordt gebruikt, want dan heb je ook landelijke cijfers over bijvoorbeeld suïcide.’
‘Een voordeel van de GGD Amsterdam in de rol van softwareontwikkelaar is dat er geen problematiek denkbaar is die in Amsterdam niet speelt en bijvoorbeeld in Drenthe wel’, stelt Reuling. ‘Dat is handig als je applicaties bouwt die ook door andere GGD’en worden gebruikt. Alle denkbare behoeften zitten er al in.’
Hauptmeijer haast zich wel om te benadrukken dat de eigen medewerkers van de GGD Amsterdam, de ‘klanten’ van zijn ITforCare-afdeling, altijd het uitgangspunt zijn bij de bouw van een nieuwe applicatie. ‘98 procent van de applicaties is gebouwd voor de GGD Amsterdam en is eigendom van de GGD Amsterdam. Bij de bouw van een nieuwe applicatie houden we er in het achterhoofd wel rekening mee dat andere GGD’en er eventueel ook gebruik van gaan maken.’
Achthonderd schermen
‘We hebben hier bij de GGD Amsterdam te maken met primaire processen en bijbehorende behoeften, en daar bouwen we de systemen voor’, vervolgt Hauptmeijer. ‘In het geval van Formatus zijn we telkens samen met de forensisch arts van de GGD Amsterdam achter de computer gaan zitten om te vragen: wat is nu je probleem? En als ik het scherm voor de gebruiker zo inricht, wat vind je daar dan van? Zullen we die ene knop nog wat naar links of naar recht verplaatsen? Of zullen we nog een extra tabblad toevoegen? Op die manier ontwikkelen we een applicatie samen met de eindgebruiker.’
De door Hauptmeijer geschetste ‘doorontwikkeling’ van een applicatie samen met de eindgebruiker en andere belanghebbenden heeft in het geval van Formatus geleid tot maar liefst achthonderd schermen. ‘Maar onze forensisch arts is al gaan testen toen er nog maar vier schermen waren, en zeker met ons ontwikkelplatform van Magic Software zijn aanpassingen een fluitje van een cent.’
Kracht van Magic
Toen de GGD Amsterdam ruim dertien jaar geleden het besluit nam om voortaan alle software zelf te ontwikkelen, koos het ook resoluut voor het ontwikkelplatform van Magic Software. ‘De kracht van Magic zit in de tussenlaag tussen in ons geval de sql-database en de ‘voorkant’ van de applicatie die bijvoorbeeld in html of JavaScript is geschreven’, stelt Reuling. ‘De code op die tussenlaag leest in Magic heel eenvoudig. Waar een Magic-programmeur tien regels code nodig heeft, zijn er dat voor een php-programmeur al snel tienduizend. Een Magic-programmeur kan heel snel zien hoe code in elkaar zit; er zit niets verstopt.’
Die eenvoud van de code biedt volgens Reuling en Hauptmeijer meerdere voordelen. Zo zijn applicaties met Magic snel te ontwikkelen, makkelijk aan te passen en eenvoudig te beheren en onderhouden. Hauptmeijer: ‘Als je op een applicatie die je in vierhonderd uur bouwt per jaar 24 uur voor beheer inplant, dan verbruik je die niet. Applicaties die zijn gebouwd met Magic vergen echt bijzonder weinig beheer.’
Opvallend snel
De snelheid waarmee de GGD Amsterdam zijn applicaties ontwikkelt, is ook opgevallen bij de Amsterdamse ‘ketenpartners’. ‘Ik zal nooit vergeten dat ik op 13 december 2011 uit de kroeg werd gebeld’, zo haalt Reuling een herinnering op. Vlak voor het telefoontje aan Reuling was er in een extra nieuwsuitzending aandacht voor de Amsterdamse zedenzaak waarin Robert M. werd beschuldigd van kindermisbruik op een aantal kinderdagverblijven. ‘Nadat de politie een telefoonnummer voor bezorgde ouders had getoond, crashte het politiesysteem. De vraag aan ons was hoe snel we iets nieuws konden bouwen om meldingen van ouders te registreren. Een paar dagen later hadden we een vervangend systeem draaien.’
‘Die snelheid is echt een groot pluspunt van Magic: we kunnen binnen een paar dagen iets opleveren waar andere partijen eerst een paar maanden over na moeten denken’, besluit Hauptmeijer, om te benadrukken dat de GGD Amsterdam in ieder geval heeft afgerekend met ‘te late software’. ‘Uiteraard is ook de kwaliteit van de mensen die met Magic werken doorslaggevend, want ‘a fool with a tool is still a fool’. Dat kunnen overigens ook mensen zijn met een goed analytisch vermogen maar zonder programmeerervaring, want Magic werkt zo eenvoudig dat we het ook uit kunnen leggen aan iemand die helemaal geen programmeur is.’
GGD Amsterdam
De GGD Amsterdam is de grootste en oudste Gemeentelijke Gezondheidsdienst van Nederland en heeft een breed scala aan werkzaamheden op het terrein van de volksgezondheid. Het werkgebied omvat de gemeenten Amsterdam, Amstelveen, Uithoorn, Ouder-Amstel, Diemen en Aalsmeer, een gebied met circa een miljoen inwoners. Ongeveer duizend GGD-medewerkers, verspreid over meer dan dertig gebouwen in de regio, zijn iedere dag druk in de weer om de gezondheid van de inwoners te bewaken en te bevorderen.
Zorg & ICT 2017
Zorginstellingen moeten steeds meer vanuit de behoefte van de patiënt gaan denken. Met alle gevolgen van dien. Van sociale innovatie tot bedrijfsvoering en IT. Op de vakbeurs Zorg & ICT 2017 staat dit jaar het thema ’De patiënt als partner’ centraal. Laat u zich ook inspireren van 14 t/m 16 maart 2017? Zet Zorg & ICT 2017 in uw agenda. Ga voor meer informatie en het volledige programma naar www.zorg-en-ict-nl.
Quote: slechte, dure en te late commerciële software
– Als Commerciele software slecht is, en je die toch aangeschaft hebt, dan heb je als inkoper je requirements niet goed opgesteld. Software is niet slecht. Ofwel je hebt vooraf je eisen niet goed vastgelegd, of je komt er achteraf achter dat de software niet aan je eisen voldoet. In dat laatste geval heb je niet goed getest.
– Als commerciele software te duur is, heb je slecht gebudgetteerd. Voor commerciele software is de prijs per gebruikseenheid (Licentie) vooraf duidelijk bekend. Als je er achteraf achter komt dat het toch duurder uit valt is ofwel je contract niet goed, of je hebt verkeerd gerekend.
– Hoe kan Commerciele software nou ’te laat’ zijn ? Een commercieel pakket ala Office of Epic, of SAP is toch al klaar voordat je het koopt ?
Of bedoeld deze meneer hier ‘de ontwikkeling van op maat gemaakte software door een derde, commerciele partij’
En ook dan gelden de bovenstaande commentaren Slecht functioneren van maatwerk software is in 95% van de gevallen te wijten aan slecht opgestelde eisen of slecht testen. Te duur is te wijten aan slechte afspraken, en te laat ook.
Maar doe het maar lekker zelf 😉
Als de klant zegt dat het niet goed is gegaan, dan is dit een keihard feit. Wat er mis is gegaan, wanneer, bij/door wie, waarom, et cetera, dat kan ik niet beoordelen. Maar bij uitbesteding, maatwerk van commerciële pakketten, worden door ook opdrachtnemers vaak ernstige fouten gemaakt. Veel verkopers zijn vooral bezig met binnenhalen van de opdracht, te weinig bezig met wat de klant nodig heeft, met begeleiding en als het mis gaat dan zijn ze niet zelden de grote afwezige. Vooral bij launching customers wil het in de beginfase vaak al misgaan. Dan mogen techneuten de in wezen organisatorische knelpunten zoal het opstellen van de juiste requirements, budgettering, planning, testen, enz. oplossen, wat meestal mislukt. Dus de opmerking “En ook dan gelden de bovenstaande commentaren” dient flink genuanceerd te worden.
Het door de GGD gebruikte type oplossing is geschikt om een bepaald soort organisatie goed te betrekken bij de automatisering.
Als je eigen IT expertise intern zelf gebruikt heb je het voordeel dat sneller en meer doeltreffend kan schakelen.