Het laatste half jaar hebben veel ziekenhuizen hun handtekening gezet onder de invoering van een nieuw Elektronisch Patiënten Dossier (EPD) systeem van de 5e generatie (in de definitie van het Gartner generatiemodel). Veel eindgebruikers zullen op een bepaald moment in de tijd naar het nieuwe EPD-systeem worden gemigreerd, zoals bij het UMCU (8000 eindgebruikers), het Albert Schweitzer (2500 eindgebruikers) of het Erasmus Ziekenhuis (> 7000 eindgebruikers). Onder eindgebruikers wordt verstaan de behandelende artsen, de verpleging, laboratorium assistentes. Wat opvalt in de berichtgeving en in de persoonlijke gesprekken is, dat het continu om EPD-functionaliteit gaat waar de Raad van Besturen, CIO’s en programma directeuren/managers zich druk over maken. Performance QA ofwel een goede eindgebruikerservaring vanuit performance en stabiliteit wordt echter niet genoemd, terwijl het juist een punt is waar de EPD-implementaties niet in uitblinken en voor de nodige vertragingen zorgen in de diverse primaire zorgprocessen. Ziekenhuizen vinden dat het de verantwoording is van de EPD-leveranciers om performance problemen op te lossen. EDP-leveranciers zijn echter niet de expert op de systemen en infrastructuur van het ziekenhuis en kunnen geen performance garantie geven voor iets waar ze niet voor verantwoordelijk zijn. Hoe zouden ziekenhuizen deze impasse in de Performance QA spiraal kunnen doorbreken en performance en stabiliteit van het EPD ter harte moeten nemen?

600 seconden consult

De pijn binnen ziekenhuizen ten aanzien van slecht performante EPD-systemen is de befaamde 600 seconden consult van de behandelend arts. Het is een belangrijke eXperience Level Agreement (XLA), omdat in deze 600 seconden de patiënt te woord gestaan moet worden. Daarna dienen er vervolgafspraken met diverse ziekenhuispartijen gemaakt te worden en wil de arts van het consult zijn factuur kunnen schrijven. Als het EPD niet performant is of niet beschikbaar is,  dan kan de patiënt terugkomen, kan de arts zijn factuur niet schrijven, stagneert de voortuitgang om de patiënt te helpen en dit alles leidt tot inefficiëntie waar vele Nederlanders (on)terecht over klagen.

Confrontatie

Laten we direct met de deur in huis vallen: in de laatste 7 jaar dat de auteur in de zorgsector zich begeeft rondom performance, wordt de Performance QA (Quality Assurance) van Ziekenhuis Informatie Systemen (ZIS) nog steeds met een korreltje zout genomen. De Performance QA en het bijbehorende budget valt in het niet ten aanzien van het miljoenen budget om het EPD-systeem te implementeren. Dat is op zijn minst apart te noemen, gezien tijd belangrijk is bij het efficiënt en effectief kunnen uitvoeren van de primaire zorgprocessen (de 600 seconden consult van de behandelend arts of het direct kunnen ophalen van je medicijnen na het consult).

Het bovenstaande komt tot uiting in de volgende observaties:

  • De EDP-leveranciers maken niet aantoonbaar dat hun applicatie performant is. Zijn er code reviews gedaan op de EPD applicatie code, heeft de EPD-leverancier zelf performance testen uitgevoerd, hoe hebben ze het uitgevoerd, is het fact-based onderbouwd en in welke context? Waaruit blijkt dat de door de EPD leverancier geadviseerde hardware en configuratie instellingen van de betrokken componenten de gewenste performantie bieden? Als het alsnog aan de EPD-applicatie ligt, dan moet het ziekenhuis voor de kosten opdraaien om de softwarefouten eruit te halen. Blijkbaar is het normaal om software te kopen waar fouten in zitten en deze fouten uit eigen zak te betalen om ze opgelost te krijgen.
  • Diverse gesprekken met de EPD-leveranciers geven aan dat ze vinden dat zij niet het juiste signaal afgeven naar de ziekenhuizen als hun EPD geleverd wordt met een gereedschapkist aan diagnostische tooling om performance problemen aan te pakken.
  • De EPD-leverancier zegt dat de performance problemen en instabiliteit niet aan zijn applicatie ligt, maar aan de infrastructuur van het ziekenhuis. Het ziekenhuis is niet in staat om zelf fact-based aan te tonen waar het dan wel exact aan ligt en huurt dure externe hulp in.
  • EPD-leveranciers geven een dusdanige hardware sizing af met ruime resource marge wat volgens hen voldoende is om eventuele performance problemen op te vangen. De oorzaak van performance problemen hoeven niet per definitie te wijten te zijn aan de onderliggende hardware.
  • Bij EPD selecties wordt niet gevalideerd of het EPD te diagnosticeren en te monitoren is met moderne Application Performance Management A(PM) tooling.
  • Bij EPD contractonderhandelingen wordt performance onvoldoende meegenomen en smart gemaakt. Hierdoor ontstaat een hiaat waardoor het ziekenhuis en de EPD-leverancier niet op aan gesproken kan worden.
  • Er is een EPD leverancier die contractueel vastlegt dat andere partijen geen APM-tooling mag gebruiken om performance problemen te diagnosticeren op het EPD-systeem! Alleen de EPD-leverancier mag de performance problemen oplossen, ofwel de slager keurt zijn eigen vlees en de EPD-leverancier is gegarandeerd voor extra consultancy uren! Deze EPD-leverancier lost zijn performance problemen onder andere op met stagiaires, wat niet rijmt met de miljoenen die verdiend worden met EPD-verkoop. Nog erger, het ziekenhuis is niet in staat om zelfstandig volledige grip en controle te hebben over haar EPD-keten.
  • Een CIO heeft letterlijk gezegd dat hij te ver van de operatie verwijderd is om performance problemen rondom het EPD te beoordelen. Daarvoor heeft hij een intern persoon verantwoordelijk gemaakt, die helaas niet presteert, zich verschuilt achter dienstverleners en er persoonlijk voor zorgt,  dat performance problemen ernstig stagneren. Dit gedrag wordt om onbegrijpelijk redenen niet aangepakt.
  • Performance metingen van eindgebruikershandelingen worden uitgevoerd met een stopwatch op gezette tijden, omdat men geen adequate tooling in huis heeft om de eindgebruikerservaring real-time te meten. Performance problemen worden hierdoor niet fact-based, objectief en adequaat aangepakt en zijn niet reproduceerbaar. Het vingerwijzen blijft.
  • Geen regie op performance. Bij de test managers of test coördinatoren ontbreekt het aan diepgaande performance kennis en ervaring om sturing te geven op performance zaken rondom het EPD.
  • De verkeerde rollen zonder performance achtergrondkennis gaan met performance problemen aan de slag, en moeten uiteindelijk bakzeil halen, verschuilen zich achter de EPD-leverancier. Vervolgens worden low-hanging  fruit problemen opgelost, de complexe problemen blijven.
  • Performance validaties worden veel te laat in het project opgepakt. Hierdoor komt de noodzakelijke hersteltijd in het gedrang, worden noodzakelijke test types zoals capaciteits testen, endurance testen en resilience testen achterwege gelaten die juist het inzicht geven wat het ziekenhuis aangaande het EPD op performance vlak kan verwachten en wat het moet doen om te zorgen dat de performance conform SLA blijft.
  • Over de strategie van de performance testen is onvoldoende nagedacht.
  • De gebruikte tooling is inadequaat om snel de root cause van performance problemen te vinden.
  • Performance testen zijn  momentopnamen, ofwel ben je afhankelijk van de situatie waarin de performance test op dat moment was uitgevoerd. Als je niet weet in welke situatie je hebt getest, hoe weet je dan dat je test resultaten betrouwbaar zijn?
  • Ziekenhuizen maken gebruik van monitoring tooling dat resources monitort. Tooling vendors verkopen gouden beloftes, maar de oplossingen lossen niet de daadwerkelijke pijn op of lossen de low-hanging fruit problemen op. Resource monitoring lost echter niets op, actieve monitoring objectiveert slechts eindgebruikers responstijden maar lost niets op!
  • EPD-implementaties kosten miljoenen, maar ziekenhuizen zijn niet bereid te investeren in de noodzakelijke tooling om performance QA te garanderen tijdens de life cycle van het EPD.
  • Het meten van de performance stopt na de performance testen, terwijl het om het echie gaat in de productie omgeving. Hoe worden eindgebruikers SLA’s bewaakt en hoe zorg je voor fact-based stuurinformatie richting de EPD leverancier als blijkt dat de oorzaak van incidenten aan het EPD ligt?
  • Geen performance borging binnen de applicatie life cycle van het EPD-systeem.

In de volgende punten wordt ingezoomd op een aantal kenmerken in de Zorgsector ten aanzien van EPD performance en waarom het van belang is dat meer aandacht noodzakelijk is om EPD-systemen op performance vlak first-time fit te laten presteren.

Een complexe en lange keten

Het EPD maakt onderdeel uit van een complexe en lange keten van applicaties die met elkaar communiceren om elkaars data te raadplegen en afhankelijk van elkaar zijn. Zo wordt laboratorium data uit PACS gedeeld met het EPD-systeem. Geen beschikbaarheid of geen performante applicatie zorgt voor congestie in de diverse schakels van de primaire zorgprocessen.

De diverse schakels in de applicatie keten maken gebruik van verschillende technologieën op ICT-vlak.  Veel ziekenhuis werkplekken bieden het EPD aan via een werkplek met Citrix of zijn opvolger, VDI.  Citrix kan op een thin of een fat desktop draaien, in beide gevallen hebben de beschikbare resources op de werkplek invloed op de eindgebruikerservaring. De werkplek wordt middels het netwerk aangeboden op diverse fysieke locaties waarbij netwerkkoppelingen een bepaalde netwerkbandbreedte hebben. De bandbreedte bepaalt hoeveel data per tijdseenheid verstuurt kan worden. Data wordt opgeslagen op data storage systemen en wellicht wordt her en der gebruik gemaakt van virtualisatie. Alles is aan elkaar geknoopt waardoor een IT-landschap zich als een spaghetti ontvouwt en complexiteit overheerst. Performance problemen zijn in de spaghetti kluwe dan ook moeilijk te analyseren, kosten heel veel tijd, er zijn veel disciplines bij betrokken waarbij het gericht zoeken met performance regie ontbreekt.

Kortom, de vele schakels en toegepaste technologieën tezamen bepalen hoe de eindgebruiker de performance ervaart. Door de vele changes die een EPD-migratie met zich meebrengt, is het het zoeken naar de speld in de hooiberg bij performance problemen. Ligt het aan het nieuwe EPD, de werkplek, of het netwerk?

Technische SLA’s ontoereikbaar

Customer Centric Monitoring - Bottom-Up Performance QASLA’s gebaseerd op de technische beschikbaarheid van systemen snijden geen hout, omdat het niet vanuit het eindgebruiker perspectief (eXperience Level Agreement a.k.a. XLA) is gedefinieerd. Bekend zijn de dashboards van de interne ziekenhuis ICT en dienstverleners die allemaal groene stoplichten laten zien van de systemen die ze monitoren. De systemen zijn beschikbaar, maar de eindgebruiker klaagt over de performance (responstijd).

Goed om te weten, is ook dat de beschikbaarheid van de keten een lagere beschikbaarheidspercentage heeft dan de technische beschikbaarheid van de individuele systemen. Dat wil zeggen, dat eindgebruikers alle verstoringen en onbeschikbaarheid ervaren die iedere schakel met zich meebrengt. Als het ziekenhuis een keten beschikbaarheid percentage heeft gedefinieerd van 99,8%, zoals De Nederlandse Bank (DNB) heeft uitgevaardigd waar de banken vanaf 2016 aan moet voldoen, dan moet ieder ziekenhuis van zeer goede huize komen om deze SLA waar te maken.

Huidige monitoring in-adequaat

Customer Centric Monitoring - Top-down - Performance QAVeel ziekenhuizen monitoren nog steeds bottom-up ofwel vanuit een technisch perspectief. Men meet de componenten van de EPD-keten hoofdzakelijk los van elkaar (geen samenhang), gefragmenteerd met verschillende tooling en vanuit een technisch perspectief (CPU, memory, disk).  Ook performance testers , ook van externe test partijen, maken gebruik van deze metingen om te trachten performance problemen te verklaren. Het gevolg is dat er geen keten overzicht en inzicht is vanuit een eindgebruikersperspectief, er geen correlatie is tussen de metingen om tot snelle root cause analyse te komen.

Technische monitoring is de traditionele monitoring waar veel ICT-ers mee bekend zijn en waar elke leverancier wel een suite heeft aan producten. Deze monitoring is op samples gebaseerd, omdat het anders een extra belasting op het systeem gegenereerd wat weer ten koste gaat van de eindgebruikerservaring.  Samples zijn metingen op bepaalde tijdstippen (dus niet real-time). Deze sampling zorgt voor gaten in de metingen en dus onvoldoende grip en controle, want wat gebeurt er tussen de samples door? Een goede metafoor hiervoor is het vliegen onder de radar: je ziet het niet.  En meten is weten. Eindgebruikers time-outs als gevolg van bepaald resource gedrag op het systeem vallen de beheerders niet op, maar de eindgebruikers ervaren het wel!

Met technische monitoring zijn de low hanging fruit problemen wellicht op te lossen, de complexere problemen blijven ongrijpbaar en dooretteren. Dat komt door het ontbreken van de juiste context waarin problemen optreden. Bij technische monitoring ontbreekt het aan het inzicht in de applicatie laag, de laag die juist door eindgebruikers wordt geconsumeerd om de functionaliteit te kunnen uitvoeren in hun dagelijks werk. De applicatie laag is dé laag dat altijd ontbreekt bij performance QA, de laag waar EPD-leveranciers het liefst geen inzicht in willen geven. Ook de ervaring van de echte eindgebruiker kan niet real-time gemeten worden, men weet niet onder welke eindgebruikersbelasting en met welke achtergrondruis de performance of instabiliteit is ontstaan.

Hierdoor zijn afspraken over oplostijden een wassen neus en dienstverleners/outsourcers weten dit al jaren. Men is niet in staat om een snelle Mean Time To Identify te bewerkstelligen, als gevolg van de toegepaste monitoring.

Performance QA en hersteltijd

Er zijn ziekenhuizen die wel hebben nagedacht over Performance QA. Men valideert de EPD-migratie met behulp van performance testen, maar men hanteert de verkeerde teststrategie.

Tegen de adviezen in van de performance experts test men het nieuwe EPD direct via Citrix (of VDI) in plaats van eerst zonder Citrix ontsluiting te testen waardoor men onnodig tijd verliest aan waar het werkelijk omgaat. Het realiseren van een performance test voor het Citrix protocol is geen sinecure. In verhouding kost het maken en onderhouden van een op Citrix protocol test script minimaal 5x meer tijd dan het maken en onderhouden van een web gebaseerd script. Een van de hoofdoorzaken is, dat het Citrix protocol resolutie georiënteerd is. Er hoeft maar een pixel verkeerd te staan in het beeld, en het testscript faalt. Ook het feit dat het Windows Operating Systeem onverwacht kan reageren, helpt niet bij het stabiel krijgen van een Citrix test script. Het genereren van een aanzienlijke gebruikersbelasting kost bovendien heel veel test licenties (virtuele gebruikers) en zware load generatoren.

In de teststrategie worden bepaalde test types gedaan die een ander doel hebben. Load testen worden uitgevoerd om de responstijd te bepalen op piekmomenten. Stresstesten hebben baat om te bepalen als de belasting groter is dan wat men verwacht had. Volume testen beantwoorden de capaciteits management vraag: wat moet er gedaan worden als het EPD systeem uit zijn voegen barst?). Endurance valideert de stabiliteit van het EPD over langere tijd waarbij gekeken wordt of er geen lekkende resources worden waargenomen.  De resilience testen bekijken hoe veerkrachtig het EPD is ofwel wat gebeurt er met de eindgebruikersperformance als in een active-active database configuratie een van de databases uitvalt.

De testaanpak houdt ook onvoldoende rekening met het oplossen van findings, de zogenaamde hersteltijd. Niet van alle findings is de root cause klip-en-klaar, laat staan de oplossing. Regie voeren om de vaart erin te houden , de juiste inhoudelijke discussies te voeren etc kost tijd.

Applicatie Life Cycle management

Ziekenhuizen concentreren zich op de live-gang, maar verliezen performance management gedurende de applicatie life cycle uit het oog. De applicatie life cycle bestaat uit het doorlopen van diverse stadia in de OTAP-straat, van ontwikkeling naar test naar productie. Na live-gang zal nieuwe applicatie functionaliteit toegevoegd worden, zullen EPD core patches en fixes aangebracht worden, zijn er changes op gedeelde en dedicated infrastructurele en systemen die allemaal invloed kunnen hebben op de eindgebruikers performance. Performance metingen op productie moeten terugvertaald kunnen worden naar eerdere fases van de applicatie life cycle om bij te kunnen sturen aangaande performance. Efficiency in testen kan bereikt worden door automatisch regressie performance testen uit te voeren met geavanceerde diagnostische tooling, een trend die in 2016 in de top 3 staat van CIO’s in de wereld om te realiseren.

Budget kwesties

QA dienstverleners lopen bij ziekenhuizen tegen de bekende muur op van budgetten waarbij de logica van beslissingen ontbreekt. Het wrange is, dat ziekenhuizen zeggen dat hun budgetten voortdurend onder druk staan, maar voor EPD-systemen lijkt de Rode Zee vanuit zich zelf open te gaan. Je kunt je ook afvragen, wat de redenen zijn dat ICT-budgetten continu onder druk staan.

Een voorbeeld: een ziekenhuis in Nederland kampt met aanzienlijke performance problemen rondom het EPD systeem, moet binnenkort live, en benadert externe dienstverleners of tool vendors om het performance probleem te tackelen. Reden is dat de beschikbare tooling het performance probleem niet (snel) kunnen vinden in de keten. Er wordt onderhandeld over de prijs, de tool vendor heeft zoveel korting gegeven dat er geen vet meer op de botten zit en uiteindelijk gaat de deal niet door, omdat het ziekenhuis toch vindt dat de EPD-leverancier het performance probleem moet oplossen. Zoal eerder gezegd, is de stelling van de EPD-leverancier dat het een verkeerd signaal afgeeft als zij met diagnostische tooling aankomt. Immers,  de EPD-leverancier redeneert dat je als leverancier eigenlijk zegt dat je performance problemen verwacht met hun software. De verwachtingen van elkaar op performance vlak zijn schijnbaar niet gealigned tijdens de contractbesprekingen.

Daarnaast is de waardebalans tussen EPD-systeem en adequate en noodzakelijke QA-tooling compleet zoek. Het garanderen dat een EPD op performance vlak first-time fit live kan en daarna performance als een rode draad door de applicatie life cycle loopt, maakt dat QA-tooling een duurzame investering is. Blijkbaar mag dit totaal geen geld kosten. De inkoper van het ziekenhuis kijkt bij elke investering terecht naar wat voor beschikbare QA tooling er is om het probleem eventueel op te lossen, niet gehinderd door enige kennis dat de huidige tooling niet afdoende is, en constateert dat er al veel tooling aanwezig is in het ziekenhuis. Het project of ICT-afdeling is te laat met het aanvragen van budget, probeert 5-voor-12 iets te regelen met onvoldoende bewijslast en de cirkel is rond.

Raad van Bestuur, ICT, externe testpartijen

Belangrijk bij performance awareness is de rol van zowel de Raad van Bestuur als de ICT-afdeling. De aanname is dat de Raad van Bestuur de business vertegenwoordigt. De Raad van Bestuur tekent het contract met de EPD-leverancier en kan contractueel sturen op de inhoud van het contract aangaande performance eisen. De Raad van Bestuur zal een beroep doen op haar ICT-afdeling, EPD-leverancier, of externe test partijen aangaande performance. Als nu keer op keer blijkt dat er performance problemen zijn met het EPD, wat zijn dan de redenen dat het performance QA schip onbestuurbaar is en er niemand wakker wordt om de spiraal te doorbreken om tot adequate performance QA te komen? Kunnen de externe testpartijen wel voldoen aan wat anno 2016 geëist wordt ten aanzien van performance QA? Het EPD op performance laten testen is niet het expertise gebied van de EPD-leverancier. Belangrijker is het gebrek aan objectiviteit; de EPD-leveranciet gaat echt niet vertellen wat er aan de hand is met zijn code.

The way ahead

Wat zouden de eerste stappen en aandachtspunten moeten zijn om Performance QA adequaat aan te pakken bij een EPD-migratie?

  1. Gebruik een onafhankelijke Application Performance Management partij met aantoonbare expertise op performance consultancy in plaats van het inhuren van een performance test partij.
  2. Huur vanaf de start van het programma een performance regisseur in om alles rondom performance in goede banen te leiden. Performance QA is een apart vakgebied waarbij een performance regisseur de spil in het web is namens de organisatie op strategisch, tactisch en operationeel gebied.
  3. Start zo vroeg mogelijk met performance testen om te voorkomen dat het in een later herstellen van de problemen veel geld kosten. Wacht niet totdat de gehele keten beschikbaar is, maar test al componenten (schakels) in de keten, voer bila-testen uit. Met de feedback kan men al aan de slag om tot verbeteringen te komen.
  4. Start met performance testen buiten Citrix of VDI om. Het gaat om het EPD, de functionaliteit en de onderliggende hardware en infrastructuur. Bedenk use cases die zoveel mogelijk van deze betrokken componenten raken.
  5. Uitvoeren van testen via Citrix doen op klein aantal Citrix servers in plaats van op het gehele Citrix park. Houd het aantal use cases klein in verband met grote onderhoudbaarheid van Citrix scripts.
  6. Start met het maken van een inhoudelijk goed testplan waarin beschreven staat: use cases, smart gedefinieerde Non Functional Requirements, die getoetst zijn met de praktijk, welke metrieken van de betrokken systemen en infrastructuur in de gaten gehouden moeten worden die iets zeggen over de gedragingen ervan onder belasting, gebruikersprofielen, gezonde mix tussen raadpleeg en mutatie handelingen, up-to-date technisch plaatje, achtergrondruis, netwerk statistieken, systeem configuratie testomgeving, totaal aantal gebruikers vs concurrent gebruikers, toegepaste technologie bij de applicatie (Dot net, Java, JDBC, fat client etc), test scenario’s en test typen.
  7. Bij performance testen gaat het om context. Welke omstandigheden zijn er geweest ten tijde van de performance test. Performance testen waarbij de deliverable een responstijden tabel is, is echt niet genoeg bewijsvoering en dat is helaas nog steeds waar de meeste externe test dienstverleners mee weg komen. Een standaard performance test (performance test 1.0) laat zien dat de responstijden slecht zijn, maar men weet niet wat de oorzaak is, of men alle onderdelen van de technische infrastructuur gebruikt heeft etc.
  8. Gebruik diagnostische software om real-time snel root causes van performance problemen te achterhalen. Dit kan alleen aantoonbaar gedaan worden door 3e generatie APM tooling (Application Performance Management) in te zetten.
  9. Zorg voor real-time eindgebruikers monitoring om tijdens live-gang van het EPD en erna te bewaken (responstijd en beschikbaarheid).