'Software bij GGD's is niet geschikt voor huidig bron- en contactonderzoek'

De software die de GGD's gebruiken, heeft een aantal grote problemen waardoor die niet geschikt is voor de bestrijding van corona. Verschillende gebruikers zeggen tegen de Volkskrant dat de software vaak crasht, omslachtig is en functies mist om de pandemie te bestrijden.

De 25 GGD's in Nederland gebruiken software om onder andere gegevens over besmettingen onderling uit te wisselen en om het aantal besmettingen door te geven aan gezondheidsinstituut RIVM. De software loopt echter regelmatig vast en werkt niet altijd, en medewerkers van de GGD klagen dat de software ingewikkeld is. Dat blijkt uit een onderzoek van de Volkskrant, die onder andere met die werknemers sprak. Vooral het feit dat de GGD's decentraal werken, zou een probleem zijn. Dat bleek onder andere eind oktober, toen door twee opeenvolgende storingen geen cijfers konden worden doorgegeven aan het RIVM.

Het uitwisselen van gegevens tussen GGD's onderling en tussen de GGD's en het RIVM is bijvoorbeeld niet geautomatiseerd. De twee instituten hebben twee verschillende computerprogramma's, HPZone en Osiris. Tot april van dit jaar, midden in de eerste golf van het coronavirus, moesten GGD's uitbraken handmatig naar het RIVM-systeem doorzetten. Inmiddels is daar een koppeling tussen gemaakt, maar die zou niet altijd even goed werken, waardoor het RIVM de cijfers van de GGD's niet ontvangt.

Bron- en contactonderzoekers klagen tegen de Volkskrant ook over het gebruik van HPZone. Dat zou onlogisch en omslachtig zijn, met een lastige UI en UX. Een ander probleem is dat de verschillende GGD-regio's binnen het systeem geen informatie met elkaar kunnen uitwisselen, doordat die omgevingen van elkaar afgesloten zijn.

Bron- en contactonderzoek lijdt onder software

De medewerkers zeggen tegen de krant dat het bron- en contactonderzoek lijdt onder de ingewikkelde software. "Met dit programma kost bron- en contactonderzoek extra werk en gaat veel informatie verloren", zegt een anonieme bron tegen de krant. "En dan kan het ook nog gemakkelijk crashen en ben je soms een half uur bezig om weer te kunnen inloggen."

In de zomer werd ervoor gekozen door te gaan met HPZone voor het bron- en contactonderzoek. Dat gebeurde in aanloop naar de opschaling ervan. Vanaf begin juni van dit jaar kon iedereen met lichte klachten zich laten testen op het virus. Daarvoor was het nodig betere software in te zetten. Koepelorganisatie GGD GHOR erkende dat HPZone daar niet geschikt voor is en zocht naar een alternatief. Dat was beschikbaar met onder andere Go.Data van de Wereld Gezondheidsorganisatie, maar de afzonderlijke GGD's wilden dat niet, omdat HPZone een vertrouwd programma was. Inmiddels zijn er wel meer ict'ers in dienst genomen om de software stabieler te maken.

Door Tijs Hofmans

Nieuwscoördinator

12-11-2020 • 09:32

86 Linkedin

Reacties (86)

86
80
47
22
4
29
Wijzig sortering
Ik ben BCO medewerker op een grote BCO locatie. Het is waar dat HP-Zone af en toe eruit vliegt, nou is dit vaak niet langer dan een minuut of 10. Wat ik lees over het omslachtig en ingewikkeld zijn van HP-Zone is iets wat ik ook veel hoor op de werkvloer. Nou wil ik daar wel aan toe voegen dat het hier vaak om oudere medewerkers gaat, of medewerkers die minder begaan zijn met een computer. Persoonlijk heb ik geen problemen met HP-Zone. Een dergelijk contrast van hoe BCO-medewerkers de software ervaren verbaasd mij niet omdat er veel verschil zit in opleiding en ervaring, iets wat verder ook niet heel belangrijk is voor de functie. Overigens komen wij als BCO-Medewerkers niet in aanraking met Osiris, altans, niet op de locatie waar ik werkzaam ben. Daar wordt een voltooid HP-Zone dossier door een controleur alleen doorgestuurd naar Osiris.

Dat er dingen mis gaan is een zekerheid, zoals het artikel aangeeft zou het proces verbeterd worden door meer automatisering. Zoals het nu werkt (naar mijn weten als BCO-Medewerker) moeten de HP-Zone dossiers eerst handmatig worden ingevoerd door de GGD's en vervolgens moet daar nog een arts naar kijken. Ik heb begrepen dat er een tekort is aan deze artsen waardoor er vaak weinig dossiers beschikbaar komen voor de grote BCO locaties. Vervelend, maar toch begrijp ik waarom er eerst een arts naar moet kijken, het gaat tenslotte om een medisch dossier.
Als arts die werkzaam is vanaf het begin van de COVID-19 crisis, bij één van de grote GGD'en, kan ik hier nog wel iets zinnigs aan toevoegen. De GGD werkt met enkele systemen en het is goed om uit elkaar te halen waar men het precies over heeft om zo ook de knelpunten helder te krijgen.
  • Coron-IT (fabrikant Topicus Zorg) --> Het universele testafspraken planning en resultaten systeem voor Corona. (Software die voorheen werd gebruikt bij sommige bloedafname punten, tuberculose X-thorax centra etc., nu aangepast voor puur COVID-19). Het testafspraken nummer, de teststraten en de laboratoria werken hiermee om testen te plannen maar ook positieve/negatieve testuitslagen per monsternummer door te geven. Als mensen positief testen zal er automatisch door een koppeling een nieuw dossier worden gegenereerd in HPZone.
    Probleem: grosso modo eens per maand is er downtime. Het resultaat is dat alle teststraten dan niet meer de monsternummers kunnen verwerken maar de stroom van mensen blijft komen, de GGD heeft daarvoor een noodprocedure verzonnen. Dat werkt en eigenlijk ervaren we geen last van dit systeem.
  • Digi-D Corona portaal --> Dit is eigenlijk een koppeling, gemaakt door de overheid, om als burger toegang te krijgen tot jouw resultaten in Coron-IT.
    Probleem: geen problemen
  • HPZone (UK fabrikant Infakt Software)--> het ''ouderwetse'' systeem dat de GGD gebruikt voor alle medische informatie van patienten, denk bijvoorbeeld aan hepatitis, tuberculose. Meldingsplichtige ziekten.
    Probleem: Hier kan je dus ook informatie zien los van Corona en deze UI/UX is inderdaad een horror als je hier voor het eerst mee moet werken.
  • HPZone Lite (UK fabrikant Infakt Software)--> de afgeslankte vorm van HPZone met enkel corona patienten van de GGD regio. Een fors verbeterde UI/UX en goed werkbaar mits je een goede training ontvangt.
  • Osiris --> het ouderwetse meldpunt van infectieziekten van het RIVM. Dit was inderdaad in het begin allemaal handmatig, sterker nog, alles bij de GGD ging handmatig. Van het plannen van een afspraak, tot de verwerking van de uitslag. Tegenwoordig zit er een koppeling in HPZone waardoor je met een druk op de knop automatisch ook de positieve melding met een heel aantal andere gegevens naar Osiris/RIVM stuurt. Hier zijn het aantal besmettingen per dag in de media op gebaseerd.
Probleem: sommige dossiers blijven zweven, gebeurt niks mee (door onbekende reden) etc. Deze meldingen komen dan niet door en worden niet vermeld in de dagelijkse statistieken. Ik denk dat daar het volgende mee wordt bedoeld:
maar die zou niet altijd even goed werken, waardoor het RIVM de cijfers van de GGD's niet ontvangt.
Het is echter voor elke GGD regio te achterhalen bij welke dossiers dit niet is gebeurd, mits je een adequate dagelijkse controle inbouwt. Er is geen enkel systeem/proces wat 100% foutloos gaat, als je de fouten maar kan achterhalen en dat kan en gebeurt. Of dat in elke GGD-regio gebeurd, geen idee.
Qua downtime van Osiris heb ik geen problemen ervaren, het kan wel zo traag als stroop zijn.

In het algemeen is er bij HPZone iets vaker een storing, zeg één keer per week. Soms logt hij de sessie uit en ben je dan inderdaad je informatie kwijt maar of dit een factor is die het programma per definitie ongeschikt maakt, vraag ik mij af. Voor mij persoonlijk werkt het goed genoeg en zo ervaren velen het, dat het beter kan... zonder meer. Is het hier voor gebouwd? Zeker niet, daarom verbaast het mij dat het eigenlijk nog zo goed gaat.

Zoals velen hieronder al hebben aangegeven, je wilt niet zomaar van software veranderen tijdens piekdrukte. E.g. je kassasysteem tijdens de kerstverkopen. Dat een betere, schaalbare, efficientere software moet worden gebouwd voor een volgende pandemie, moet t.z.t. worden gepland.
Dat zou onlogisch en omslachtig zijn, met een lastige UI en UX.
Dit gaat, lijkt mij, met name om HPZone. Zoals al eerder beschreven, is HPZone Lite (waar BCO'ers mee werken) op zich een vrij helder programma in vergelijking met mijn ervaring van andere (elektronisch patienten dossier) EPD's.Met name EPIC en sommige huisartsen EPD's. Dat gaat dan denk ik voornamelijk om personeel dat nog nooit eerder heeft gewerkt met medische gegevens en zich onvertrouwd voelen in dergelijke omgeving, wellicht dat leeftijd inderdaad ook een factor is. Jan en allemaal wordt nu aangenomen en dat is hierin ook merkbaar, zeker als de training tekort schiet.
Een ander probleem is dat de verschillende GGD-regio's binnen het systeem geen informatie met elkaar kunnen uitwisselen, doordat die omgevingen van elkaar afgesloten zijn.
Dit is de bedoeling. Met dezelfde gedachten dat bijvoorbeeld ziekenhuis A, ook niet automatisch de gegevens kan inzien van ziekenhuis B maar wel werken met hetzelfde EPD zoals Hix/EPIC. De landelijke discussie/implementatie voor het uniform delen van medische informatie is nog altijd gaande maar ook voor alle GGD regio's geldt dit. Immers is een COVID-19 besmetting, nog altijd een stukje medische informatie dat dus moet worden afgeschermd.
Zoals het nu werkt (naar mijn weten als BCO-Medewerker) moeten de HP-Zone dossiers eerst handmatig worden ingevoerd door de GGD's en vervolgens moet daar nog een arts naar kijken. Ik heb begrepen dat er een tekort is aan deze artsen waardoor er vaak weinig dossiers beschikbaar komen voor de grote BCO locaties.
De automatische koppeling tussen Coron-IT en HPZone voor het gros van de nieuwe positieven meldingen loopt goed. Die koppeling werkt traag, inefficient en kan soms uren duren maar dossiers worden automatisch gegenereerd in HPZone en worden dan direct doorgezet naar een BCO'er. Zeker als bijvoorbeeld 's nachts de koppeling heeft gedraaid, dan kan het BCO personeel er gelijk mee aan de slag. M.i. gaat dat vrij goed. De vertraging die je schetst is denk ik met name bedoelt voor de controle van dossiers na het BCO (maar dan is de patient in ieder geval geinformeerd en voorzien van de correcte adviezen + omgeving in kaart gebracht). Of wat je bedoelt is voor de meldingen die handmatig binnen komen (niet via Coron-IT), dat gaat via een beveiligde verbinding (Zorgmail etc.) van bijvoorbeeld huisartsen die nog zelf testen of de inmiddels wildgroei van commerciele antigeen test labs. Die laatste groep geven doorgaans zeer slordig en laat de meldingen door maar dat heeft de volledige aandacht van IGJ/RIVM/GGD-GHOR. Het handmatige proces van een nieuwe melding via Zorgmail beooordelen, uitprinten, tekenen, nieuw dossier aanmaken, start BCO zal ongetwijfeld nog even traag blijven maar gebeurd doorgaans wel binnen 24 uur. Wat in de media wordt gezegd dat deze partijen binnenkort ook gebruik kunnen maken van Coron-IT zal, denk ik, nog even op zich laten wachten.

Bij vragen, stel ze gerust.

P.S. Grappige anekdote, ooit was HPZone gebouwd voor de Olympische Spelen (als ik het me goed herinner) voor infectieziekten bestrijding die men toen daar verwachtte.

[Reactie gewijzigd door Blackboard op 12 november 2020 14:02]

Ik heb een tijd mensen opgeleid in HPZone en nu begeleid ik de bco'ers in het gebruik. Hpzlite wat bij ons al een aantal maanden de standaard is haalt veel omslachtigheid af. Ik hoor ook veel mensen klagen over HPZone. Maar ook dit zijn ouderen die niet willen een kunnen omgaan met computers. Het probleem is dat de GUI niet simpel en mooi is zoals een app die je op je telefoon zet. Men snapt niet dat dit niet zomaar een programma is. Het probleem ligt niet bij HPZone maar bij de mensen. Er is een grote lading geneeskundestudenten aan het werk hier, en die hebben het soms lastig, maar dat komt dan omdat ze vanaf het begin worden verteld dat het een 'monster van een programma is'
Maar ook dit zijn ouderen die niet willen een kunnen omgaan met computers.
Het probleem ligt niet bij HPZone maar bij de mensen.
Grappig detail dit. M'n vriendin (midden twintig) is een tijdje BCO'er geweest en merkte deze houding tegen ouderen ook op. Het viel haar op dat ouderen amper de tijd kregen om de software te leren kennen. Bij ouderen gaat dat wat minder snel dan bij jongeren en daar was de tijd niet voor. Gevolg: veel ouderen raakten gefrustreerd en vertrokken binnen een paar weken.
Als een programma lastig in gebruik is voor de gebruikers ligt dat probleem gewoon bij het programma hoor als je het mij vraagt, dat is een tekortkoming van de UX implementatie.

Dat een programma in de business wereld er niet zo mooi uit ziet als een consumenten app is ook een gedachte die niet meer van deze tijd is.

Dat HPZone hier tekortschiet en je daar dus omheen werkt met extra training snap ik maar zeg niet dat het niet anders kan ;)
Hoe vaak is het systeem een 'minuut of 10' niet bereikbaar? Dat klinkt in mijn oren als heel disruptief. Vermenigvuldig alle medewerkers die met dit systeem werken met de tijd dat die er uit ligt. In een situatie als deze kun je je dat niet veroorloven.
Ik werk 40 uur per week als BCO'er sinds 6 weken geleden. Precieze cijfers kan ik je niet geven. Maar ik heb het zelf al een week of 2 niet meegemaakt dat het eruit lag. Toen ik begon (en het aantal BCO'ers flink werd opgeschaald) gebeurde het een aantal keer per week.
Dat klinkt verdacht veel als een schalingsprobleem van de back-end
Klopt, het is inderdaad een schalingsprobleem.

Voor Coronatijd werkten er landelijk hooguit een paar 100 man in HPZone (en het concurrent gebruik is veel lager dan deze paar 100 man). Momenteel werken er meer dan 4000 man fulltime in de applicatie. Logisch dat er schalingsproblemen zijn.
Tja als hun hele applicatie op exact 1 server tegelijk kan draaien wegens gedeeld geheugen en/of harde schijf opslag is dat idd vrij logisch. Als ze de back end van tevoren beter hadden ingedeeld hadden ze dit probleem echt niet hoeven hebben.
Goed, maar als vorig jaar de overheid een groot IT-project gestart had om een fenomenaal schaalbare infrastructuur voor een pandemie te maken had iedereen het hier belachelijk gevonden.

Achteraf komen uiteraard de mensen en vinden het belachelijk dat ze in België verlopen mondkapjes weggegooid hebben.
Nouja, eigenlijk is het ook wel een beetje tegen de stroom in zwemmen als je nu nog software zou maken die je bewust beperkt op schaalbaarheid. Er is eigenlijk geen reden de lokale schijf aan te raken of shared memory te gebruiken, en als je dat al kan vermijden kom je een heel eind.
Dat is waar, maar de software is waarschijnlijk tien of twintig jaar oud.
Da's ook weer een mogelijkheid ja. Of dat het op een klassieke infrastructuur moest draaien die dan weer met een 90's model ontworpen is, ook mogelijk. Lastig te zeggen zo van een afstand.
Ik dacht hetzelfde bij het lezen van het artikel. Wanneer je navraag gaat doen bij eindgebruikers krijg je vaak heel andere uitkomsten dan wanneer je met de beheerders gaat spreken. Ook is het vaak dat de gebruiker op een ineffeciënte manier werkt (zoals aangegeven door niveauverschil in opleiding/ervaring) waardoor de software erg slecht lijkt te werken. Vaak mis ik dan de reactie van de beheerders op de constateringen van de eindgebruikers.

Nu moet het wel zo zijn dat de basis robuust is, dus wegvallen van zo'n 10 minuten per keer klinkt niet heel stabiel en zal zeker frustratie opwekken bij de gebruikers.
Ik snap je reactie, maar het gaat er uiteindelijk toch om hoe de eindgebruiker het ervaart. Een it-specialist vindt Linux waarschijnlijk ook heel makkelijk werken, maar iemand die in drie weken (bij wijze van spreken) moet worden opgeleid snapt niks van het systeem. Dit hele verhaal lijkt me daarom ook een voorbeeld van tijdsgebrek en te weinig opleiding dan van een slecht functionerend systeem.
HP-Zone wordt door het Britse bedrijf InFact gebouwd. Alleen hun corporate website geeft een web developer al niet heel veel vertrouwen, gezien de teksten daar zelfs plaatjes zijn |:(

Hier een diapresentatie (uit 2016) waar je vanaf pagina 11 wat screenshots kan zien. Als het in de laatste vier jaar niet significant verbeterd is, dan is de UI/UX inderdaad wel een punt van aandacht...

[Reactie gewijzigd door CornéM op 12 november 2020 10:35]

Heeft de software problemen, of probeert men de software te gebruiken voor iets waar hij eigenlijk helemaal niet voor gemaakt is? Dat is een belangrijk onderscheid...
Zoals ik het begrijp is de software gemaakt voor contact-tracing, maar niet op deze enorme schaal en met de bijbehorende (andere?) werkprocessen.
Het venijn zit hem in:
Koepelorganisatie GGD GHOR erkende dat HPZone daar niet geschikt voor is en zocht naar een alternatief. Dat was beschikbaar met onder andere Go.Data van de Wereld Gezondheidsorganisatie, maar de afzonderlijke GGD's wilden dat niet, omdat HPZone een vertrouwd programma was.
Klinkt als een klassieke resistance to change.
Klinkt als een klassieke resistance to change.
Gelukkig maar.

Elke organisatie heeft momenten waarbij de IT volledig ondersteunend wordt en geen wijzigingen meer worden doorgevoerd. In de retail is dat meestal (in de aanloop naar) de feestdagen.
Bij een organisatie zoals de GGD's is dat natuurlijk tijdens een pandemie of ander grootschalig project.

Normaal draaien de GGD's 1 of 2 (kleine) teams met contact-onderzoek, een handjevol ervaren medewerkers doen dit voor voornamelijk SOA's. Vandaag de dag is dat dus een effort waarbij honderden medewerkers met een minimale training proberen de corona vloedgolf enigszins te bedwingen.
Elke medewerker met enigszins kennis van zaken zit tot over z'n oren in het werk en dat al vanaf het begin van dit jaar. Die heeft geen tijd om te gaan acceptatietesten of requirements door te nemen. Sterker nog, de GGD's waren blij dat ze enigszins vakantie hebben kunnen nemen om even stoom af te blazen, zeker bovenin die organisaties zijn er genoeg mensen die letterlijk op omvallen staan.
Nu voldoet het systeem echter ook niet en 80% van de gebruikers zijn nieuwe gebruikers. Die moesten dus toch al iets nieuws leren en dan kan je denk ik beter iets wegzetten wat.
-Beter voldoet voor het doel.
-Intuïtiever is.
-Stabieler/beter schaalbaar is.
Nu voldoet het systeem echter ook niet en 80% van de gebruikers zijn nieuwe gebruikers. Die moesten dus toch al iets nieuws leren en dan kan je denk ik beter iets wegzetten wat.
-Beter voldoet voor het doel.
-Intuïtiever is.
-Stabieler/beter schaalbaar is.
Zoals anderen hierboven al aangeven: in de retail voert men ook geen nieuw kassa-systeem meer in tijdens de November/December periode. Als je 120 km/uur op de snelweg rijd en merkt dat je linkervoorband wat zachter is ga je ook niet al rijdend de band wisselen. Dit is exact hetzelfde: je kunt je nu geen fuck-ups veroorloven, dus het is in dit soort situaties vele malen verstandiger te blijven aanrommelen met een systeem met bekende problemen dan dat je wisselt (zowieso altijd al chaos) met onbekende issues en kinderziektes. De huidige problemen moeten wel heel groot zijn wil het opwegen tegen het migreren naar een nieuwe oplossing.
met onbekende issues en kinderziektes.
Ware het niet dat je nu dus juist allerlei onbekende issues en kinderziektes te zien krijgt doordat het systeem niet gebouwd is voor resiliency en schaalbaarheid. Handelingen die normaal niet zo veel impact hebben op je gebruik worden nu 1000 keer uitvergroot doordat er ineens een hele grote groep mensen continu mee bezig zijn en dan kunnen ze ineens wel een probleem/opstopping veroorzaken waardoor je syustemen het gewoon niet meer kunnen bolwerken.

Ik begrijp je verhaal over rijdend band wisselen met 120Km/u, maar dat gaat niet op.

wat men dus aangeeft is dat er heel veel nieuwe medewerkers bij zijn gekomen en dat er een systeem wordt misbruikt wat er niet voor bedoeld is.

Dat klinkt mij in de oren als reden om te per direct over te stappen naar iets wat wel goed werkt voor het doel.

Om in jou auto analogie te blijven: De band is lek. De GGD kiest er nu voor door te rijden met 120 Km/u. Is dat dan verstandig?
[...]
Als je 120 km/uur op de snelweg rijd en merkt dat je linkervoorband wat zachter is ga je ook niet al rijdend de band wisselen.
Meestal wissel je niet gelijk een band als hij iets te zacht staat. Al is het wel aan te raden om juist langzamer te gaan rijden. Als je toch hard door wilt rijden en niet wilt dat hij teveel slijt is het waarschijnlijk beter om toch even te stoppen.

Verder moet je misschien maar even kijken naar wat Go.Data is https://www.who.int/godata
Dit is hier specifiek voor gemaakt en wordt al breed gebruikt. Niet iets waar uitgebreide tests voor nodig zijn, alleen wat scholing van het personeel. Lijkt me dan nu dus (of eigenlijk een half jaar geleden) een prima moment. Of eigenlijk afgelopen zomer toen iedereen lekker op vakantie was.
Een klassieke fuckup.
Het venijn zit hem in:


[...]


Klinkt als een klassieke resistance to change.
De spijker op z'n kop! De software ontwikkelaar van HPzone weigert de software zo aan passen dat het WEL gebruikt kan worden voor zulk grootschalig gebruik terwijl de mensen -die wel iets anders aan hun hoofd hebben dan een nieuw programma leren- met dezelfde, vertrouwde en bergrepen interface kunnen blijven werken.

Nee, de software ontwikkelaar verzet zich hevig tegen op zo'n manier met software omgaan. Geen upgrade maar een compleet nieuw programma ($$!), cursussen voor de gebruikers ($$!), nieuwe onderhoudscontracten of abonnementen ($$!).

Ook de IT wereld verandert liever niet als dat ten koste gaat van hun doorgaans dikbelegde boterham...
Helaas een belangrijk nadeel van closed source software, de afhankelijkheid van de software ontwikkelaar, die in deze situatie niet kunt hebben.
De gevolgen zijn voor de meeste hetzelfde. ik gok dat ze iets proberen waar het niet voor bedacht is.
Wel interessant dat ze op basis van we doen het altijd zo dus software pakket voor exact dit afslaan. ik vind het wel schokkend aangezien heel NL hier stakeholder in is aangezien beleid op die cijfers word gemaakt.
Eens. Wel tekenend dat de GGD GHOR blijkbaar weinig invloed heeft op wat de diverse GGD-regio's doen.

Hoorde al eens eerder (van iemand van het RIVM) dat de GGD's gewend zijn om in hoge mate autonoom te werken, en ook erg op zichzelf zijn. Zo sluipt een "not invented here" er al snel in.
De afzonderlijke GGD-en zijn volledig zelfstandig en hebben een eigen bevoegd gezag. Dit bevoegd gezag is het algemeen bestuur en wordt gevormd door de wethouders Gezondheid van de deelnemende gemeenten. Deze gemeenten nemen overigens verplicht deel aan de gemeenschappelijke GGD in hun regio. De GGD wordt vervolgens op basis van een inwonerbijdrage gefinancierd door de deelnemende gemeenten.

GGD Ghor is een ledenvereniging van de 25 directeuren van de 25 GGD-en in Nederland. Niets meer en niets minder. GGD Ghor staat dus niet boven de GGD-en, maar is dus juist eigendom van de gezamenlijke GGD-en. De GGD-en betalen een ledenbijdrage voor GGD Ghor Nederland en bepalen de koers.

GGD Ghor Nederland wordt bestuurd door de DPG-raad (raad van directeuren publieke gezondheid). Hier worden wel richtinggevende besluiten genomen), maar als het bevoegd gezag van een afzonderlijke GGD een andere koers wil varen, dan zal de betreffende GGD het besluit van de negeren van GGD Ghor nederland, aangezien deze geen gezag heeft over een GGD.
Dat verklaart een hoop. Dank voor de toevoeging en het inzicht!

EDIT: Wat dan weer wél apart is, is dat GGD GHOR (m.a.w., de ledenvereniging van de 25 GGD's) constateert dat er een alternatief is; maar dat dan die 25 leden dan toch weer zeggen dat ze geen alternatief willen.

[Reactie gewijzigd door TMDC op 12 november 2020 10:16]

GGD Ghor heeft een eigen staf en een aantal vakspecialisten. Het ministerie van VWS zoekt natuurlijk een aanspreekpunt om beleid landelijk af te stemmen met de GGD-en ipv dat ze het gesprek 25 keer moeten voeren. Dit doet VWS momenteel via GGD Ghor Nederland. Deze staf praat, analyseert en doet daardoor bepaalde conclusies (oa over HP-Zone en bespreekt dat met de DGP-raad.

Een afzonderlijke GGD-directeur heeft natuurlijk zelf intern binnen een GGD te maken met een krachtenveld, bijvoorbeeld met artsen infectieziektenbestrijding (IZB). Deze hebben een behoorlijke vinger in de pap over dit soort zaken.

Hierdoor gebeurt het dat de staf GGD Ghor de DPG-raad adviseert om afscheid te nemen van HPZone terwijl de interne IZB-artsen hier negatief op reageren. Je kan uit de kop van het artikel wel opmaken wie deze strijd heeft gewonnen :) Hierdoor ontstaat wel een zeer dubbel beeld, wat maar moeilijk uit te leggen is aan de burger.
Of dat ze het nú niet willen, kan ook. Ik kan me voorstellen dat ze met zo'n corona pandemie niet de risico's willen die een nieuwe software toch met zich meebrengt.
Inderdaad. Mijn vrouw heeft wat minderwerk ivm de Corona en ook bezig met GGD posities coordinator/planner/manager teststraten etc. We wonen op kruispunt van meerdere GGD regios en bij allen word het anders aangepakt, andere uitzendbureaus, andere benamingen niet door heen te komen. ik zou zeggen maakt daar een landelijk punt van waar iedereen zich kan inschrijven met eventueel voorkeurs locaties ofzo iets. Heb het idee dat ze ook in bepaalde mate zelfstandig zijn dat de overheid ook niet kan ingrijpen.
Ik ken iemand die leidinggevende is bij een GGD, en blijkbaar is het verouderde software die niet gemaakt is voor deze volumes. Veel handelingen, excelletjes ernaast en ook geen partij die het product kan supporten in Nederland.

edit: Typo

[Reactie gewijzigd door Baken op 12 november 2020 09:43]

Terwijl jij reageerde haalde ik dit aan uit de oorspronkelijke post:
Koepelorganisatie GGD GHOR erkende dat HPZone daar niet geschikt voor is en zocht naar een alternatief. Dat was beschikbaar met onder andere Go.Data van de Wereld Gezondheidsorganisatie, maar de afzonderlijke GGD's wilden dat niet, omdat HPZone een vertrouwd programma was.
Er was dus wel een alternatief, maar daar wou men blijkbaar ook weer niet aan.
Voordat iedereen weer gaat roepen 'overheid en ICT'. Software problemen komen overal voor en zoals @K-aroq aangeeft is het verschil dat bij de overheid dit pagina nieuws is. Ik denk eerlijk gezegd dat hier de software

a) niet geschikt is voor deze specifieke situatie
b) de decentralisatie van overheidsorganen juist het problem veroorzaakt heeft. Waarschijnlijk hebben veel van de regionele onderdelen eigen werkwijzen en eigen protocollen daarop aangepaste dingen in de software. Dat bijt nu waarschijnlijk. Misschien is dit een wake up call voor dezelfde overheid om in te zien dat decentraal werken toch niet altijd goed is en dat een bepaalde vorm van standaardisatie nodig zal zijn
b) de decentralisatie van overheidsorganen juist het problem veroorzaakt heeft
Er zijn wel meer problemen bij de GGD's geweest. In de hele keten van opschalen en pro-actief handelen lijken zij vaker de zwakste schakel.

Laatst bijvoorbeeld ook zoiets in de krant:
https://www.nrc.nl/nieuws...ositieve-uitslag-a4016677

Een GGD die klaagt dat iets 'meer tijd gaat kosten'. Dan zakt mijn broek af: alsof we niet in de grootste gezondheidscrisis sinds WO II zitten. Dan ga je toch niet zeuren over de kosten van een paar tiental call-center medewerkers meer?

Zoals jij zegt lijkt de software niet geschikt voor de specifieke situatie. Een pro-actieve handelende organisatie was begonnen om aangepaste software te maken. Goed leiderschap herkent een bijzondere situatie en weet "Never waste a good crisis". "Onder druk wordt alles vloeibaar" en dergelijke cliches.

Maar je ziet wel dat het waar is: bedrijven die hun totale businessmodel hebben omgegooid. Huisartsen en scholen die op afstand zijn gaan werken. Ik vind de reactie van de GGD redelijk timide en in schril contrast, al vanaf het begin dat ze de oerconservatieve adviezen over testen gaven. (Weet je nog: "Alleen als iemand in de specifieke provincie in China is geweest, of misschien 3 dorpjes in Italie").

[Reactie gewijzigd door Keypunchie op 12 november 2020 09:58]

Kan je reactie goed volgen. Echter, de GGD's worden in beginsel gefinancierd door de gemeenten als ik het me goed herinner.

Dat betekent dat er regio's zullen zijn waar de GGD's al jarenlang stelselmatig uitgehold zijn, want het bezuinigt lekker op iets wat weinig prestige heeft en waar niemand eigenlijk het nut van inziet. Totdat er een pandemie komt.

Zoals alle overheidsorganisaties zal e.e.a. over financiering dus waarschijnlijk een heel lang en stroperig proces door moeten maken (wie moet het betalen? Waar moet de rekening heen? Welke kostenplaats? "Nee hullie moeten betalen" etc. etc.).

Eerder al aangehaald, de GGD's zijn niet echt één organisatie, maar een cluster van op zichzelf opererende organisatietjes met een koepelorganisatie (GGD GHOR) die blijkbaar ook niet uitblinkt in daadkracht of beslissingsbevoegdheid.
Huisartsen en scholen die op afstand zijn gaan werken.
Bedoel je zoveel mogelijk op gepaste (1,5 meter of meer) afstand van de patiënt of iets dergelijks? Want thuis (wat men in de huidige omstandigheden normaal gesproken met 'op afstand werken' bedoeld) werken kan het niet zijn...

Er is geen huisarts die thuis 'het praktische huisartsen werk' (lees: patiënten zien) doet, dat kan toch echt alleen in een daarvoor ingerichte praktijk. Enkel een (relatief klein) deel van het administratief/overleg werk kan eventueel thuis.
Er is geen huisarts die thuis 'het praktische huisartsen werk' (lees: patiënten zien) doet, dat kan toch echt alleen in een daarvoor ingerichte praktijk
Nou, videconsult was toch best populair heb ik begrepen? Ik heb zelf met andere medische zorg te maken gehad en daar was heel veel telefonisch en/of op afstand. Google maar op 'huisarts videobellen' en je ziet dat er een hele waslijst aan mogelijkheden is. Utieindelijk heb je fysiek onderzoek nodig, maar tot die tijd.
Daar hoef ik niet voor te Googlen. ;)
Maar goed, er zijn misschien een klein aantal huisartsen die een klein deel (waarvan men weet dat het kan) van hun patiënten 'ziet' via video, maar er is zeker geen sprake van videobellen op grote schaal. Ook zijn de gebruikte systemen (want; patiëntgegevens) veelal niet thuis te gebruiken al zou men het willen, waar er dus bij huisartsen aan videobellen gedaan wordt zal dit nog steeds vanuit de praktijk zijn naar alle waarschijnlijkheid.
Geen idee *waar* ze werkten, zal best hun kantoor kunnen zijn, het punt is dat ik er niet was!

En misschien niet per se huisartsen, maar mijn medisch contact was zeer op afstand (behalve waar onderzoek nodig was).

[Reactie gewijzigd door Keypunchie op 12 november 2020 16:36]

HPZone is een programma dat 15 jaar ontwikkeld is, met beheer en eigendom in de UK. Er is geen Nederlandse ondersteuning beschikbaar.
Tot zover ook meteen de AVG...
Zolang het self-hosted is zonder backdoors is er geen probleem, maar dan moeten ze wel goed uitkijken welke informatie ze delen met de helpdesk.
Het is gehost in Nederland (tegenwoordig), echter het beheer en support ligt nog steeds in de UK.
Support gaat overigens door GGD Ghor Nederland overgenomen/ingevuld worden. De leverancier zal daarmee 3e-lijns support gaan leveren (via GGD Ghor Nederland) en deze niet meer rechtstreeks leveren aan de GGD-en.

[Reactie gewijzigd door gmafs op 12 november 2020 10:59]

Dat is dan zeer recent, vorige week was iedereen aan het rondrennen omdat een supportticket doorgaans 4 weken duurt omdat het via de UK moet.
Klopt. Dit is eind oktober besproken en besloten. Er is een convenant opgesteld die momenteel is/wordt getekend door alle afzonderlijke GGD-en om dit in te richten bij GGD Ghor Nederland. Dit regelt de in beheername bij GGD Hor Nederland en de ondersteuning van de gebruikersvereniging HPZone. Er komt daarmee een fyieke servicedesk bij GGD Ghor Nederland.

Het PGIM (programma informatiemanagers) krijgt de vraag/rol om dit verder te ondersteunen.

[Reactie gewijzigd door gmafs op 12 november 2020 11:45]

HPZone wordt wel gehost in de EU (tegenwoordig)
Maar niet beheerd.
Ik heb in vele IT projecten gewerkt, 1 keer bij de overheid (RVO). Dat was het enige project wat bijna op rolletjes liep, waar deadlines werden gehaald en de bevindingen in productie er vrijwel niet waren.
Slaat noch kant noch wal dit... GGD geeft aan dat HPZone niet geschikt is, onlogisch, omslachtig en veel belangrijker; onbetrouwbaar. Het aangedragen alternatief is vervolgens afgewezen omdat HPZone een vertrouwd programma is?!
Het zal je verbazen, maar de ene GGD is de ander niet.

Of dat misschien wel zo zou moeten zijn is een andere kwestie. ;)

[Reactie gewijzigd door The Zep Man op 12 november 2020 09:54]

Kan je dit een beetje toelichten?

Dit was als een reactie op 0romis bedoeld. Is helaas niet helemaal goed gegaan.

[Reactie gewijzigd door appendto op 12 november 2020 09:49]

Wel mooi dat we anno 2020 nog dit soort discussies voeren, terwijl de miljoenen om je oren vliegen bij IT projecten bij de overheid. Uitloop, op zowel budget als tijden halen ook vaak het nieuws.

Het probleem in de IT is, dat er vaak maar een as-is oplossing wordt geimplementeerd, voor iets zoals het nu is, en een vervanger van een oud systeem.
Er wordt niet gekeken naar de toekomst. Waar willen we naar toe. Wat moet het over x jaar nog aan voldoen. Immers, dat laatste zijn requirements, die geld kosten.
Dit is wel het zoveelste voorbeeld waarbij de overheid, zowel in het zwalkende beleid als in de uitvoering ervan, zich niet van de beste kant laat zien. Ondertussen wordt er wel een enorme last op de schouders van de burgers gelegd met flinke sancties en negatieve beeldvorming wanneer men daar niet aan voldoet. Daarmee wil ik zeggen dat binnen de samenleving geen vrijblijvendheid wordt getolereerd terwijl van de essentiële bestrijding niets terechtkomt vanwege gebrek aan doortastendheid.

Op dit item kan niet meer gereageerd worden.

Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee