Bronnen, bronnen en nog meer bronnen

Eind februari 2017 zijn we gestart met het project Kiezen in de ggz . Enkele weken geleden zijn we online gegaan. Kiezen in de ggz is een website die patiënten, hun naasten en (huis)artsen helpt bij het kiezen tussen zorgverleners in de ggz. We zijn gestart met een design sprint om vervolgens de website te ontwikkelen in 13 development sprints van twee weken. Een simpele rekensom doet vermoeden dat je dan zo’n 26 weken later kan opleveren. De praktijk is echter weerbarstiger en gelukkig hebben we dat vanaf het eerste moment ingezien.

We hebben het project uitgevoerd in een aantal blokken: 4 sprints in 2017, 4 sprints in de zomer van 2018 en 3 sprints eind september / oktober 2018. Tussen de sprints is de tijd genomen om gebruikersfeedback op te halen en te verwerken, deze feedback is vervolgens in de volgende serie van sprints meegenomen om de website te verbeteren. Het betrekken van toekomstige gebruikers tijdens de ontwikkeling heeft geholpen om een website te ontwikkelen die beter aansluit bij de behoeften van die gebruikers. Gebruikerstesten zijn een waardevol instrument tijdens de ontwikkeling, met name in de fase voor de lancering van het product als je nog geen feedback van echte gebruikers kan krijgen. 

Technisch laat de website zich samenvatten in één woord: bronnen. Kiezen in de ggz haalt informatie op uit veel verschillende bronnen, voegt de informatie samen en maakt dit eenvoudig en snel toegankelijk voor de gebruiker. 
We gebruiken een bron voor gegevens over instellingen, vestigingen en behandelaars, een bron met wachttijden, een bron met aanvullende informatie over behandelaars, een bron met informatie over verzekeringen, een bron met cliëntervaringen, een bron met informatie over aandoeningen en een bron met het kwaliteitsstatuut. De relevante informatie uit al deze bronnen wordt verzameld, doorzoekbaar gemaakt en gebruiksvriendelijk gepresenteerd. 

Vanaf de eerste development sprint hebben we, als ontwikkelteam, de snelheid van de website een prioriteit gemaakt. Immers, met zoveel informatie uit zoveel bronnen en waarschijnlijk een veelbezochte website, loop je al snel het risico dat de snelheid van de zoekresultaten te wensen over laat. Daarom hebben we een aantal technische keuzes gemaakt. We maken bijvoorbeeld geen gebruik van een traditioneel content management systeem (voor de tekstpagina’s binnen de website) dat verweven zit met de website. We zien content als een bron, net als alle andere bronnen. Hierdoor staat het content volledig los van de website en hoeft het CMS ook niet voor ieder request opgestart te worden. 

Een andere keuze die we hebben gemaakt is dat we de website hebben opgedeeld in een losstaande front end applicatie en een backend applicatie. Deze architectuur passen we binnen onze projecten steeds vaker toe. Het voordeel, vanuit de invalshoek performance, is dat een groot deel van de applicatie in één keer wordt ingeladen en daarna heel specifiek alleen de informatie die nodig is wordt opgevraagd. Een traditioneel opgezette webapplicatie vraagt vaak bij iedere klik die de gebruiker doet opnieuw dezelfde informatie op (denk bijvoorbeeld aan een menustructuur). Het kost deze traditionele website telkens weer tijd om deze, zelfde, informatie op te bouwen en naar de gebruiker te sturen.

De front end applicatie van kiezen in de ggz praat via een API met de backend. Hier merk je als gebruiker niets van, behalve dan dat de website sneller reageert als je klikt. In het geval van de kiezen in de ggz hebben we echter niet één backend applicatie, maar twee: een backend applicatie waarmee informatie uit de database gelezen kan worden en een specifiek (en alleen) om razendsnel te kunnen zoeken. Door deze functionaliteiten los te koppelen hebben we de zoekfunctionaliteit kunnen optimaliseren. We kunnen heel direct zoeken zonder vertraging van een backend framework dat opgestart moet worden.