Een blik achter de schermen van het LSP met VZVZ-leaks

Elk jaar houdt de Vereniging van Zorgaanbieders Voor Zorgcommunicatie(VZVZ), die verantwoordelijk is voor het Landelijk SchakelPUNT(LSP) een leveranciersdag. Zo ook op 7 oktober 2016. Tijdens die dag wisselden prominente werknemers van VZVZ van gedachten met leveranciers over technische en organisatorische zaken rond het LSP. Het programma van die dag is openbaar, maar de inhoud van dat overleg is normaliter niet openbaar. Ook niet voor de op het LSP aangesloten zorgaanbieders, die een ledendag hebben daags voor de leveranciersdag. Ook de notulen van de leveranciersdag zijn nooit openbaar geweest. Dankzij een VZVZ-medewerker die de notulen van deze dag op een hoekje van zijn privé-website zette, is nu een inkijk in de ontwikkelingen en de problemen rond het LSP mogelijk. Deze notulen zijn normaliter alleen met behulp van een gebruikersnaam en wachtwoord toegankelijk op de VZVZ-website.  Ik zal puntsgewijs de zaken langslopen die in de notulen aan de orde komen. Laat ik ze maar de VZVZ-leaks noemen

Versiebeheer met bouwstenen

In de discussiesessie met bovenstaande titel gaat het om de opbouw van berichten en de manier waarop met het versiebeheer van de onderdelen ervan omgegaan moet worden. De opbouw van via het LSP verstuurde berichten gaat volgens zogenaamde zorginformatiebouwstenen waarover Nictiz het beheer voert. Die hebben in de loop der tijd telkens een andere versie. Het blijkt dat ondanks vijf jaar privaat LSP-gebruik en daarvoor drie jaar publieke ontwikkeling dat nog steeds discussie bestaat over het versiebeheer van alle bij het LSP gebruikte software. Bij het versiebeheer is telkenmale van belang dat de software backwards compatible is, omdat niet iedereen tegelijk dezelfde versie in gebruik heeft.

Aanmelden Bronsysteem

In deze discussiesessie gaat het om de vraag op welke wijze gegevens worden aangeboden aan de centrale verwijsindex. Dat is dat deel van het LSP dat bijhoudt waar wat van wie in een broncomputer staat. Dat aanmelden kan op bouwsteen-, op zorgtoepassing- en op dossierniveau. Men blijkt gekozen te hebben voor het bouwsteenniveau, maar dat heeft ook weer consequenties voor het functioneren van het systeem en heeft ook forse  juridische en politieke aspecten. Dat is op te maken uit de uitgebreide discussie daarover. Eén en ander heeft te maken met de verwijsindex die zo kaal mogelijk moet zijn en zelf geen medische data mag bevatten of iets wat daarop lijkt. Met de keuze voor bouwstenen als basiselement bij het versturen van data zou het  wel zo zijn dat er medische content in de verwijsindex komt. De verwijsindex hoeft alleen maar te weten wie iets weet over een patiënt, maar dan is er met een recent geïntroduceerde signaalfunctie een probleem. Die moet ervoor zorgen dat gebruikers een signaal krijgen als er nieuwe data zijn aangemeld en is bedoeld om nu onnodig vaak voorkomende raadplegingen te beperken. Men lijkt er nog niet helemaal uit te zijn.  Bij VZVZ  zijn ze als de dood om onderwerp te worden van een politieke discussie.

Gebruik UZI-pas

Uit de notulen van deze sessie blijkt dat het LSP-gebruik in ziekenhuizen helemaal niet van een leien dakje loopt. Het blijkt dat de er een grote inzet nodig is van leveranciers om problemen op te proberen te lossen. Men loopt o.a. aan tegen problemen met Citrix-software die gebruikt wordt bij het netwerkverkeer in de zorginstelling en tegen de aanwezigheid van veel werkstation die  zogenaamde “thin clients” zijn. Het is een naam voor kleine, relatief zwakke computers die de hoofdmoot van de benodigde computercapaciteit van een centrale computer betrekken en één gebruiker tegelijk bedienen. De kleine computer fungeert daarbij  als client (‘klant’) van de centrale computer. Blijkbaar vereist onder andere de software voor het gebruik van een UZI-kaart-lezer per werkstation te veel systeembronnen daarvan om goed te kunnen werken. Ook de Terminal Server-software die op de werkstations draait geeft problemen.  Men zoekt trouwens de grens op van wat mag, want VZVZ-medewerker Marcel Settels beschrijft namelijk een gerealiseerde situatie waarmee op één werkstation verschillende sessies van meerdere medewerkers draaien. Daarbij loggen die medewerkers achter elkaar in met verschillende passen. De vraag daarbij is uiteraard of na inloggen op deze wijze medewerkers niet in elkaars sessie kunnen gaan werken. Ik denk van wel.

Commerciële pas?

In dezelfde sessie komt het NUZI-project ter sprake. Nergens op het internet is uitleg over deze afkorting te vinden, maar ik denk dat NUZI-staat voor Nieuwe UZI-pas. Al de acties van NUZI zijn gericht op de ontlasting van de leveranciers bij het werken met verschillende authenticatiemiddelen.  Uit de discussie over de UZI-pas blijkt overduidelijk dat ook de leveranciers door hebben dat het gebruik van de UZI-pas door zorgverleners als hinderlijk wordt ervaren gezien de tijd die het kost om in te loggen. Alternatieven passeren de revue. Marcel Settels zegt dat de UZI-pas over drie jaar een herijkingsmoment krijgt en het UZI-register mogelijk een andere rol. Er zou dan mogelijk geen UZI-pas pas meer van overheidswege meer komen, maar een commerciële pas met specifieke voorzieningen. Interessant is het te lezen dat in oktober 2016 50.000 UZI-passen voor LSP-verkeer uitgegeven zijn en nog eens 50.000 die gebruikt worden voor het inloggen bij instanties als VECOZO en SBV-Z.

Prefetchen

Het niet realtime, maar voor-ophalen van medische data via het LSP neemt nog een zeer grote plaats in. Dat blijkt ook uit een hele discussiesessie over dit onderwerp. Men kan eigenlijk in een aantal gevallen niet anders. Zoals ik al eerder publiceerde gaf Marcel Settels van VZVZ op de leveranciersdag aan dat je in een als realtime bedoeld systeem eigenlijk niet aan dat prefetchen zou moeten doen.  De conclusie bij deze discussiesessie is toch dat prefetching nodig is en blijft. Zeer openhartig is trouwens de opmerking dat de opvrager bij het prefetchen veel foutmeldingen terug krijgt die hij zelf moet oplossen.

Verstoringen

Het berichtenverkeer via het LSP loopt vaak niet vlekkeloos. Dat blijkt uit de speciale discussiesessie over dit onderwerp. Het blijkt deels te gaan om te voorkomen verstoringen maar ook om lokale verstoringen die door de aangesloten zorgverlener gepercipieerd worden als “het LSP werkt niet”.  Foutmeldingen zijn er met exotische afkortingen zoals  RTEDEST (de apotheek of huisartsenpraktijk is niet bereikbaar of QABRTITI (er is een fout opgetreden tijdens de opvraging (time-out). Het bronsysteem (de huisartsenpraktijk of apotheek) reageert niet binnen 60 seconden). Blijkbaar moet een opvragende zorgverlener tot een minuut wachten tot er antwoord komt!!

Iets met DUO???

In de brainstormsessie met de titel “Wat kan beter?” blijken allereerst een aantal zeer basale onderwerpen de revue te passeren, zoals:

• Wanneer moet er iets echt af zijn?
• Wanneer begint iets, wanneer eindigt iets?
• Releasekalender?
• Werkplan?

Het is in mijn ogen vreemd dat na drie jaar publiek en vijf jaar privaat werken met het LSP dit soort vragen nog steeds bestaan. Men komt tenslotte tot de conclusie dat VZVZ zich meer moet profileren naar de leden toe en haar rol duidelijker moet maken voor eindgebruikers en zorgkoepels. Wat betreft toekomstige samenwerking blijkt men niet alleen te denken aan het Nederlands Centrum voor Jeugd en Gezin, maar ook aan de stichting DUO die studiefinanciering regelt voor studenten, scholieren en leraren. Hiermee gaat men zich toch echt  buiten de zorg begeven en is sprake van een enorme function-creep van een zorgcommunicatiesysteem.

Conclusie

Het lezen van deze notulen bevestigt mijn gevoel dat ondanks een half miljard euro aan uitgaven aan het LSP het nog steeds niet is wat het lijkt te zijn. Het is één en al werk in uitvoering, zelfs bij reeds gerealiseerde functionaliteit. Basale zaken, als wat leveranciers en VZVZ van elkaar verwachten en weten bij het uitvoeren van werkzaamheden zijn nog steeds onderwerp van discussie tussen deze partijen.

W.J. Jongejan

Voor de geïnteresseerde lezer hier alle notulen op een rijtje: A, B, C, D, E, F, G, H, I, J, K, l, M, N, O, P, Q.