Met het updaten van een HIS gaat er nogal eens wat mis

Huisarts Informatie Systemen(HIS-sen) zijn geen statische programma’s. Aan deze elektronische medische dossiers vindt continu onderhoud plaats. De leverancier zorgt regelmatig voor updates van het HIS. Daarbij loopt niet altijd alles vlekkeloos. Een bekend verschijnsel bij meerdere HIS-sen is dat na een update de “performance” soms opeens achteruit gaat. Daarmee wordt de snelheid bedoeld, waarmee de schermopbouw plaats vindt na aanklikken van een keuze. Ook vliegt de gebruiker dan soms ongewild uit het programma, waardoor opnieuw opstarten nodig is. Eén en ander is betekent een enorme verstoring van de workflow in de praktijken. De problemen lost men na kortere of langere tijd op. Het leidt echter tot veel irritatie op de werkvloer. Ondanks uitgebreid testen van een update door leverancier en huisarts-testers blijkt het toch mis te kunnen gaan. De hoofdreden is dat een HIS een soort kerstboom geworden is met wat eigen ballen, maar ook heel veel andersoortige ballen.

Kerstboom

In de jaren 90 van de vorige eeuw, toen huisartsautomatisering op gang kwam, was er sprake van losse systemen bij praktijken zonder externe koppelingen. Je had dan een betrekkelijk kale kerstboom waar maar enkele ballen in hingen. Behoudens het updaten van het HIS moest hooguit regelmatig een nieuw medicijnbestand ingeladen worden, de zogenaamd G-Standaard. Later zijn er aan de HIS-sen veel hulpprogramma’s gehangen plus allerlei externe verbindingen. Bij de hulpprogramma’s denk ik dan aan NHGDOC. Dat is een beslis-ondersteunend programma. Bij de externe connecties moet je denken aan verbindingen met apotheken om recepten en medicatiegegevens uit te wisselen. Verder bijv. Zorgdomein, een digitaal platform waarop zorgverleners zorg vragen, zorg aanbieden en op een snelle, veilige manier patiëntinformatie kunnen uitwisselen. Dat gaat dan bijv.  om verwijsbrieven die elektronisch naar de specialist gaan of het kunnen zien van wachttijden voor poliklinieken.

Dieper gaande koppelingen

De laatste tien jaar zijn er nog dieper gaande koppelingen tot stand gebracht in het kader van het uitwisselen van zorgdata via het Landelijk SchakelPunt(LSP). I.v.m. het beveiligen van de toegang kwam daar op elke werkplek een kaartlezer bij voor de UZI-pas . Daarvoor is dan ook weer apart connectieprogramma nodig. Voor het declaratieverkeer dat vanuit het HIS plaatsvindt is ook weer een met een certificaat beveiligde verbinding nodig van het HIS met VECOZO, het declaratie-portaal van de zorgverzekeraars. Los daarvan zijn er de verschillende configuraties waarmee huisartsen met hun HIS werken: op een eigen server, op een met anderen lokaal gedeelde server of met een ASP-provider die het HIS op een serverpark draait en waarbij de huisarts met een beveiligde verbinding werkt. Het zijn steeds meer ballen die aan dezelfde boom hangen. Bronnen voor problemen te over dus.

Recente voorbeelden  

Elk HIS kent dit soort problemen. Het vinden van de oorzaak kan soms van korte duur zijn, maar ook veel langer duren. Enkele voorbeelden van de afgelopen 12 maanden:

• Medio 2019 blijkt na een update Promedico ASP plotseling zeer traag te werken. Op Twitter is dat te zien. Tot in oktober 2019 blijkt het probleem voort te duren getuige een Tweet.
• MicroHIS kende in januari 2020 voor een aantal gebruikers een plotse vertraging van de performance vlak na een update. Systemen met de server in eigen beheer hadden het probleem niet. Onder ASP-werkende systemen weer wel. Inmiddels lijkt na anderhalve weken het lek boven water: de koppeling met een extern systeem. Nu wacht men op een update waarin het euvel verholpen wordt.
• Medicom kende op 29 januari 2020 het probleem dat een aantal huisartsen niet meer konden inloggen in hun systeem, dus er niet meer mee konden werken. Men had een “achtergrondproces” gewijzigd. Ondanks testen bleek er toch een flinke verstoring te zijn die gelukkig maar enkele uren duurde.

Problem-shooting en -solving     

Door de veelheid van ballen die in de kerstboom zijn komen te hangen en de verschillen in configuratie is het soms zeer lastig om het lek boven water te krijgen. Vaak is het een oplettende programmeur die het licht ziet, soms zijn het gebruikers die opeens de “clue” zien. Gevallen van serendipiteit dus. Zo kan ik me uit eind jaren ’90 me een zeer weerbarstig probleem herinneren met MicroHIS. Ik weet niet meer hoe het probleem eruit zag, maar de ene praktijk had er wel last van en de andere niet. Uiteindelijk was er een opmerkzame huisarts die ontdekte dat het probleem op een werkstation met Windows 95 zich wel voordeed en niet op één met Windows 98. Het letten op verschillen in performance tussen praktijken met verschillende hard- en softwareconfiguratie blijft nog steeds belangrijk bij de probleemoplossing.

Wordt vervolgd

Het moge uit het voorgaande duidelijk zijn dat ondanks grote inspanningen van leveranciers, pakketcommissies, testers en gebruikers, problemen met het updaten van elektronische medische dossiers, zoals de HIS-sen onvermijdelijk blijven. Het blijft uiteindelijk mensenwerk.

W.J. Jongejan, 4 februari 2020

Afbeelding van Gerd Altmann via Pixabay