Wat houdt een testproces precies in, wat is het belang van testen en blijven testen, en waarom zijn nieuwsgierigheid en historisch besef daarbij nu zo cruciaal? Roeland Uitslager (64) is ketentester bij VZVZ en werkt vanuit die rol voor het programma Met spoed beschikbaar. Voordat hij afzwaait, deelt Roeland met ons zijn antwoorden op deze vragen – en meer.

Binnen VZVZ zijn twee testteams werkzaam. Eén team houdt zich bezig met centrale voorzieningen: het LSP en alle componenten die daarbij horen. Het andere team houdt zich bezig met de acceptatie van leveranciers en applicaties. Binnen dat laatste team houdt een groepje van twee personen zich specifiek bezig met de ketentesten. Dit gaat om het uitvoeren van testen met zorgpartijen die voor het eerst berichten gaan uitwisselen over het LSP – al dan niet in combinatie met LSDV, VPN, ZorgMail etc. – of een bepaalde uitwisseling voor het eerst gaan doen.

Roeland vertelt over zijn werk als ketentester: “Die zorgpartijen komen altijd via ons loket binnen en dan gaan wij daarnaar kijken, meestal met twee leveranciers die geaccepteerd en gekwalificeerd zijn. Maar het kan ook zijn dat de uitwisseling zo nieuw is dat er maar één leverancier is. Wij maken dan een simulator om de testen mee uit te voeren. Dat doen we voor berichten die beproefd worden en al landelijk worden uitgerold in het kader van het programma Met spoed beschikbaar, maar ook voor andere, oudere uitwisselingen. Medicatie-uitwisseling is bijvoorbeeld een stokoude toepassing en toch doen we daar nog steeds ketentesten op, want we vinden nog steeds dingen die niet goed zijn.”

“Een keten is zo sterk als de zwakste schakel.”

Roeland benadrukt dat het van belang is om verder te kijken dan uitwisselingen die via het LSP gaan: “Omdat de keten in het geval van acute zorg over meerdere uitwisselingsplatforms gaat, voeren we als VZVZ dus ook ketentesten uit voor berichtuitwisselingen die niet (alléén) via het LSP gaan. Een keten is zo sterk als de zwakste schakel en uiteindelijk komt informatie vanuit een ander uitwisselingsplatform ook op het LSP terecht. Het is dus ook van belang coalities op te zoeken om te zorgen dat de hele keten op orde is.”

Het testproces: testfases & verschillende soorten testen

Over testen is al heel veel geschreven, maar ondanks dat is er nog regelmatig verwarring over wat we nu precies bedoelen. Het testproces binnen acute zorg bestaat sinds enige tijd uit een aantal fases met verschillende testen:

• Eerste fase van testen bij Nictiz

De eerste testen zijn de testen die Nictiz laat doen van de geschreven informatiestandaard en materialen: testscripts, functioneel ontwerp, etc. De testen binnen deze fase leveren informatie op die uiteindelijk leidt tot een release van de informatiestandaard met alle materialen die daarbij horen: het test- en kwalificatiemateriaal. Dit omvat ook zelftesten voor de leverancier om te zien of je voldoet aan de informatiestandaard/zorgtoepassing en kwalificatie- en acceptatietesten* om aan te geven of je aan de eisen voor kwalificatie of acceptatie voldoet.

*Toelichting over het verschil tussen kwalificatie en acceptatie:

• Kwalificatie – Kwalificeren doet Nictiz. Dit gaat over de inhoud van wat je wilt communiceren gebaseerd op de informatiestandaard.
• Acceptatie – Accepteren doet o.a. VZVZ. Voor het LSP is het voorwaarde dat je de kwalificatie van je applicatie hebt behaald, pas dan kan VZVZ je accepteren. Bij acceptatie gaat het over alles behalve de inhoud, gebaseerd op de zorgtoepassing en de bijbehorende programma’s van eisen (PvE’s). Denk aan alles rondom de uitwisseling; in welke envelop zit het bericht (dat staat in het PvE), maar ook onder welke voorwaarden mag je uitwisselen, dus welke UZI-middelen heb je nodig. Roeland: “Als je echter gebruikmaakt van een andere infrastructuur dan het LSP, weet ik niet hoe de acceptatie er daar uitziet. Voorwaarde voor uitwisseling over bijvoorbeeld de LSDV is wel dat er een kwalificatie is, maar de rest ligt bij de beheerder van die infrastructuur.”

• Programma van eisen en acceptatiescripts

De zorgtoepassing levert de zogenaamde programma’s van eisen op, waarin staat beschreven waaraan een informatiesysteem (XIS) en uiteindelijk een Goed Beheerd Zorgsysteem (GBZ), de bij de zorgverlener geïmplementeerde versie van het XIS, moet voldoen. Er is sprake van een GBZ als het systeem voldoet aan kwaliteitseisen om medische gegevens veilig te kunnen uitwisselen via het LSP. Op andere infrastructuren heet dit anders, maar is het principe hetzelfde. Vanuit die PvE’s worden acceptatiescripts gemaakt.

• Ketentest acceptatie

Als een XIS eenmaal geaccepteerd is, vinden er ketentesten plaats op de acceptatieomgeving. Daarbij maken de testers gebruik van de scripts en scenario’s die ze uiteindelijk in de dagelijkse praktijk ook gaan gebruiken. Vaak ontdekken ze dan zaken die nog niet goed zijn ingeregeld en dat is dan wel geregeld vóórdat de zorgverleners daadwerkelijk met de berichtuitwisseling werken.

Hier horen ook de functionele acceptatietest en gebruikersacceptatietest bij. Deze zijn voor de XIS-en die worden geïmplementeerd en gaan veel verder dan de uitwisseling alleen. Ze gaan ook over de vraag ‘ondersteunt de applicatie mijn werkproces wel?’ Oftewel: is de juiste informatie beschikbaar op het moment dat het nodig is. Helaas kijken op deze omgevingen vaak alleen technische en functioneel beheerders mee bij de testen en niet de zorgverleners, die de uiteindelijke eindgebruikers zijn.

Aandachtspunt & tip: betrek wel altijd eindgebruikers bij de test, zodat het zorgproces leidend is!

• Ketentest productie

Op de daadwerkelijke productieomgeving voeren testers ook ketentesten uit, waarbij de eindgebruikers over het algemeen wél aan de knoppen zitten. In een enkel geval is dat ook de eerste keer dat een eindgebruiker ziet wat de impact van de uitwisseling is op de werkzaamheden. Roeland: “Deze ketentesten doen we met het script erbij, maar we proberen de eindgebruikers te stimuleren om zelf met testgevallen te komen, zij zijn immers de experts. Tijdens dergelijke testen blijven we kijken of de berichten valide zijn; of het semantisch en syntactisch is volgens de standaard.”

• Post-productie

Tot slot doen de testers met enige regelmaat een hertest van een bepaalde uitwisseling, als er in de praktijk iets fout gaat. Bijvoorbeeld omdat een partij een nieuwe inrichting heeft gekozen die niet strookt met de oorspronkelijk bedoelde uitwisseling. Denk aan een ziekenhuissysteem met standaardcontent waarvoor een leverancier is gekwalificeerd en geaccepteerd. Het staat een ziekenhuis vrij om een andere inrichting van die content te kiezen, maar dat leidt dan soms wel tot ‘ander gedrag’ van het systeem. Daarnaast kan het fout gaan, omdat het koppelvlak is aangepast door een release. In die gevallen vragen de testers de leverancier om een aanpassing te doen en testen ze de uitwisseling opnieuw als deze klaar is. In het uiterste geval kan een leverancier gevraagd worden om opnieuw de kwalificatie en acceptatie te doen.

Waarom testen?

Roeland: “Testen is belangrijk om zeker te zijn van een goede inrichting, gegevensuitwisseling en ondersteuning van het werkproces van de zorgverleners, met alles wat daarbij komt kijken (zoals authenticatiemiddelen). Het heeft ook vaak als doel om met elkaar vast te stellen: hebben we nou gemaakt wat we bedacht hadden en werkt het ook echt zoals we dat bedacht hadden?” Inmiddels heeft de ervaren ketentester vele voorbeelden van bijzondere bevindingen, wat er fout kan gaan als je niet of niet goed test en hoe je bevindingen om kunt zetten in oplossingen.

• Omgewisselde velden niet opgemerkt

Zo noemt Roeland een voorbeeld van een uitwisseling waarbij er in eerste instantie weerstand was om ketentesters mee te laten kijken. Dit gebeurde uiteindelijk toch. De betrokken leveranciers waren gekwalificeerd, maar tot zijn grote verbazing bleek bij de test dat twee velden waren omgewisseld. En dit dreigde op deze manier in productie te gaan!

• Niet getest bij de eindgebruiker

In een ander geval was sprake van een leverancier die, ondanks dat dit wel was geadviseerd, niet getest had met zorgverleners , want “dat hoeft niet, het werkt allemaal wel”. De zorgverleners zagen de toepassing en zeiden resoluut: “Dat gaan we niet gebruiken op die manier.” De leverancier kon toen weer terug naar de tekentafel.

• Geen logische presentatie van gegevens

Ook de presentatie van gegevens is van belang om van tevoren te testen. Roeland: “We zien helaas vaak dat de leverancier de inhoud van het gehele bericht op het scherm plaatst. Buitengewoon onhandig, want zeker in de acute setting heb je als zorgverlener maar een paar stukjes informatie nodig en die wil je direct zien. Dan wil je niet zoeken in meerdere pagina’s of diverse tabbladen openen. Ook is het per zorgverlener weer verschillend wat als eerste getoond moet worden om snel te kunnen handelen. Dat kan voor een ambulancezorgprofessional ook weer anders zijn dan voor een SEH-verpleegkundige of SEH-arts.”

• Scenario’s vanuit de praktijk meenemen

In het systeem van een zorggroep bleek dat een Praktijkondersteuner Huisartsenzorg (POH) maar maximaal aan 1 praktijk kon worden toegewezen, terwijl de meeste POH’s in meerdere praktijken werken. “Dit soort scenario’s op basis van ervaringen uit het verleden moet je dus ook meenemen op de acceptatieomgeving.” Dat is ook waarom Roeland in zijn testscripts altijd aangeeft richting de gebruiker: dit is een levend document, vul het alsjeblieft aan met de cases en scenario’s die jullie willen meenemen vanuit de praktijk, want ik sta niet op die werkvloer.

• Systeem uit de vorige eeuw

Bij de uitwisseling tussen de huisartsenspoedpost (HAP) en de meldkamer ambulancezorg was er een uitdaging om met de beperking van het systeem over te brengen wat je als huisarts bedoelde. De centralist kreeg de informatie te zien in het medisch kladblok, een systeem uit de vorige eeuw met slechts 1024 karakters. “Bij een test van HAP naar meldkamer bleek dat het kladblok al vol was toen we aan de eerste medische informatie toe waren. Tot grote frustratie van de betrokken zorgverleners. Door de indeling van de informatie zo te maken (te mappen) dat het voor de centralist herkenbaar werd, is het uiteindelijk toch een succes geworden.”

Rolverdeling testproces

Testen is een complex proces en dat vraagt om een duidelijke rolverdeling. Bij de ketentest zijn over het algemeen de leveranciers en eindgebruikers betrokken en uiteraard is er begeleiding door iemand van Met spoed beschikbaar, die vaak de rol van penvoerder heeft en een regisseur. De lead kan ook worden genomen door de regionale projectleider en soms neemt een gebruiker bij de zorgverlener dit stokje over in de loop van een project, wanneer blijkt dat hij of zij die taak van regisseur goed op zich kan nemen.

Zeker als er meerdere mensen betrokken zijn bij een testproces, is het goed om te zorgen dat het duidelijk is wie aan zet is en wat de volgende stap is. Chaos en troebele acties liggen anders op de loer, aldus Roeland. “Zo hebben mijn collega’s eens een test gedaan waarbij de informatie die werd doorgestuurd telkens niet te matchen viel met hetgeen in een eerdere stap was opgevraagd; X werd opgevraagd, maar Y werd doorgestuurd. Na verloop van tijd werd duidelijk dat bij de verwerking van de ontvangen data iets misging en het bleek dat de betrokken leverancier onder water iets aanpaste in het bericht. Dat er dingen misgaan is helemaal niet erg, daarom testen we, maar transparantie is dus wel heel belangrijk – en dat iedereen zich op één stap concentreert.”

Blijven testen

Ook als leveranciers al gekwalificeerd en geaccepteerd zijn, ook als een toepassing al beproefd is

Is testen ook nodig na kwalificatie? “Ja, zeker wel”, antwoordt Roeland stellig. “Te vaak zien we dat de opgeleverde applicatie na configuratie toch even anders reageert dan tijdens de test. Een bekend voorbeeld hiervan zijn de ziekenhuisinformatiesystemen. De kwalificatie wordt gedaan met een bepaalde configuratie, maar in de praktijk kan het bij het specifieke ziekenhuis net even anders werken. Wat in kwalificatie en acceptatie werkte, levert dan ineens allerlei rare fouten op. Dat wordt wel steeds beter, omdat steeds meer leveranciers en ziekenhuizen voor standaardcontent gaan in plaats van maatwerk. Daar wordt niet veel meer in getweakt, dus als dat de eerste keer goed gaat, dan zal dat de volgende keren ook waarschijnlijk wel goed gaan. Dat ontslaat je uiteraard niet van de schone plicht om toch te testen en het hele testrondje af te maken. Want ik heb meegemaakt dat er bij de zesde implementatie toch iets fout ging.”

Testen is dan ook niet alleen nodig bij koploperprojecten, maar ook bij berichten die al beproefd zijn en landelijk worden uitgerold. “Bij implementatie van reeds beproefde berichtuitwisselingen ga je niet meer tot in detail, maar doe je toch zo’n test, want het zijn allemaal losse componenten die het op één moment allemaal moeten gaan doen. Daarbij geldt ook dat het met testmateriaal vaak gaat om het kunnen versturen van een bericht of het ontvangen ervan, maar niet zozeer het ondersteunen van het proces in de praktijk. We doen dat overigens met de procesanalyses binnen Met spoed beschikbaar steeds beter. Maar in feite zou je bij iedere nieuwe livegang even een paar testen moeten doen. We doen in samenwerking met de Regionale Samenwerkingsorganisaties (RSO’s) voor de wat langer in productie zijnde toepassingen regelmatig ketentesten en het is opvallend hoe vaak we daar nog bevindingen hebben. Dus ja, je kunt nooit te vaak testen!”

Ondersteuning voor zorgverleners vanuit Met spoed beschikbaar

Hieronder lees je waar de ondersteuning vanuit het programma uit kan bestaan voor koplopers:

• Faciliteren van een BSN

Om te kunnen testen heb je test- en/of fictieve patiënten nodig. Die hebben vaak een BSN nodig, al zijn er uitwisselingen binnen de acute zorg die zonder BSN ook moeten werken. Dus faciliteren wij de partijen met deze soorten (fictieve) BSN’s.

• Leveren testmateriaal

Je moet weten wat je gaat testen, daarvoor leveren we per bericht testmateriaal. Daarin wordt een toelichting gegeven op de uitwisseling: tussen wie, onder welke voorwaarden, bijzonderheden en een linkje naar de richtlijn.

• Voorstel voor vulling van berichten

Verder zit er een voorstel voor de vulling van het bericht in, soms een minimale en maximale variant en tot slot testscenario’s: de happy flow, eventuele flows (die zijn soms anders maar niet unhappy) en unhappy flows (die echt niet zouden moeten kunnen). “Met name bij het dossier (de inhoud) en de testscenario’s vragen we aan de zorgverleners om eigen varianten te bedenken en te testen. Een ambulanceverpleegkundige weet veel beter wat hij zou willen zien dan een tester die als een soort dokter Bibber een dossier in elkaar schroeft”, schetst Roeland.

• Procesondersteuning teststappen en vastlegging resultaten

We bieden de mogelijkheid om het testproces in overzichtelijke teststappen op te delen en ook de vastlegging van de resultaten te ondersteunen.

• Patient journeys

Voor het geval een regio een complexe casus wil testen (bijvoorbeeld ‘patiënt wordt op straat gevonden en 112 wordt gebeld’), dan zijn er patient journeys waarbij de verschillende partijen in de keten aan bod komen. Ook die zijn beschikbaar in Interoplab en op papier.

• Simulator

Mocht je willen testen, maar je hebt nog geen partner waarmee dat kan, hebben we voor sommige uitwisselingen ook een simulator. Deze kan zich gedragen als een “echt” systeem. Het zal keurig antwoorden en opleveren op basis van ingestuurde vragen/verzoeken.

• Penvoerder of regisseur

Tot slot kunnen we vanuit Met spoed beschikbaar de rol van penvoerder of regisseur vervullen. Dan kun je ons zien als de procesbegeleider. Voordeel is dat wij dan ook het verslag schrijven en dat we ook meteen de bevindingen kunnen duiden. Dat helpt om de leverancier of zorgaanbieder op het goede spoor te zetten.

Ondersteuning landelijke uitrol (reeds beproefde berichten)

“Bij landelijke uitrol worden wij als ketentester niet meer betrokken”, vertelt Roeland verder. “Dat doen de implementatieadviseurs van Met spoed beschikbaar die de toepassingen landelijk implementeren. Die hebben een aantal keer gezien hoe zo’n ketentest loopt en die kunnen dat prima zelf. Ze maken over het algemeen wel gebruik van het testmateriaal dat wij gemaakt hebben. Ook maken ze eventueel gebruik van de BSN’s en de patiëntgegevens die beschikbaar zijn – en natuurlijk het patiëntendossier. Uit die testen komen relatief weinig bevindingen, want als een koppeling al vier keer is getest door ons, gaat dat de vijfde keer ook wel goed. Op de website van Met spoed beschikbaar zijn testscenario’s per beproefde berichtuitwisseling beschikbaar om regionale projectleiders of andere betrokkenen vanuit de zorgaanbieders te ondersteunen bij de testen tijdens hun implementaties. ”

“Het is goed om te weten waar iets vandaan komt om te begrijpen waar het naartoe gaat.”

Advies voor testers

Roeland geeft tot slot zijn advies op basis van zijn jarenlange ervaring op verschillende relevante vlakken. “Het helpt natuurlijk dat ik wat ouder ben dan de gemiddelde testcollega en dat ik zelf verschillende rollen heb gehad. Ik heb voor het ministerie van VWS gewerkt, dus heb aan de beleidskant meegewerkt. Ik heb aan de richtlijnen meegeschreven en ik heb zelf toepassingen moeten bouwen. Ik heb enorm op mijn mieter gehad van klanten, omdat het gewoon echt niet werkte. Daar heb ik veel van geleerd. En ik heb eerder in mijn loopbaan ervaring opgedaan met de communicatiekant; hoe verloopt de communicatie tussen verschillende zorgverleners.”

Nieuwsgierigheid

Uiteraard moeten testers secuur zijn, de regeltjes kennen en diplomatiek zijn, maar je moet vooral heel nieuwsgierig zijn en al die informatie tot je nemen als een spons. Vooral doorvragen als dat nodig is. Dus lees die Richtlijn, doorgrond de informatiestandaard, maak de inhoud van de PvE’s je eigen en vraag aan de leveranciers hoe ze iets gebouwd hebben en waarom, vraag aan de zorgverlener hoe zijn werkproces eruitziet en waarom.”

Historisch besef

Het is daarbij ook heel belangrijk om je af te vragen hoe een uitwisseling ontstaat: “Wij zijn als testers het eindstation, maar waar begint het verhaal? Dat begint bij de behoefte van zorgverleners om de patiëntenzorg te verbeteren, samen iets te doen en informatie uit te wisselen. Dan komt een commissie die een voorzet van een richtlijn gaat schrijven. Uiteindelijk wordt die richtlijn geschreven en dan komt er een reviewronde. Tegenwoordig wordt een richtlijn, als deze af is, gedeponeerd bij het Zorginstituut en die zegt dan of het een ‘de facto standaard’ wordt. Dan steekt Nictiz (of andere partijen) zijn vinger op om er een informatiestandaard van te maken. Vervolgens komt er een zorgpartij die de uitwisseling wil doen en wil weten hoe dat moet. Alles gebeurt met het doel: hoe kunnen we elkaar informeren over wat we met de patiënt aan het doen zijn. Bij al die voorafgaande stapjes zit informatie die interessant is om bij je test mee te nemen. Het is daarom goed om te weten waar iets historisch gezien vandaan komt om te begrijpen waar het naartoe gaat.”

Roeland, die ook graag geschiedenisleraar had willen worden, mist vaak dit historisch besef en dat vindt hij wel jammer. Hij rond de komende tijd het hoofdstuk bij VZVZ af en denkt na over mooie plannen om als pensionado zijn liefde voor geschiedenis, natuur en Utrecht te combineren.