Praten over eGezondheid, midden in de klim naar een nieuwe Corona piek. Heeft dat zin?
Jazeker. Want juist Corona legt de zwakste plekken van ons huidig concept van elektronische gegevensdeling bloot.

Laat vooreerst duidelijk zijn: met de inspanningen die tot nu toe geleverd zijn, hebben we al een formidabele vooruitgang geboekt.
Meer dan 9 miljoen Belgen hebben hun geïnformeerde toestemming voor gegevensdeling geregistreerd.
Mede door Corona is teleconsultatie en elektronisch voorschrijven plotseling gemeengoed geworden.
Ga naar Mijngezondheid.be en je zal versteld staan hoeveel gegevens van jezelf je kan raadplegen.
Aan ijltempo werden ook enkele nieuwe Corona tools ontwikkeld en uitgerold.
Vanaf volgende week kunnen artsen in scholen, rustoorden, bedrijven, enz. Corona testen digitaal voorschrijven.
Hopelijk heeft u ook Coronalert op uw smartphone staan?

Maar…

In 2021 loopt de “eHealth Roadmap 3.0” af. Sinds 2013 is dat de derde versie van het masterplan om België te voorzien van een goed digitaal gezondheidssysteem. We hebben nog nauwelijks een jaar om het vervolg hierop uit te schrijven.

In de beleidsnota van Frank Vandenbroucke zal hopelijk een fors hoofdstuk over eGezondheid, medische gegevensdeling en (her)gebruik van deze gegevens staan.

In tijden van pandemie is populatiemanagement meer dan ooit nodig. Ook daar heb je goede gedeelde gegevens voor nodig.

Ruim 15 jaar ervaring in dit domein en de afgelopen 7 jaar management van éénlijn.be hebben enkele inzichten bovengebracht, die ik graag op tafel breng. Elk ervan wijkt af van de lopende aanpak.
Ik pleit dus voor bezinning en een ommezwaai. Niet om alles overboord te gooien wat we al hebben gerealiseerd; wel in tegendeel !
We moeten denken aan “the next level” en eraan werken.

1. Denk, ontwerp en werk “bottom-up” en vertrek van de werkprocessen.
Gegevens die elkeen in zijn eigen dossier of journaal zet, vloeien automatisch samen in een gedeeld overzicht.

Veel van de huidige tools en platformen werden ontworpen door mensen die weinig voeling hadden met de praktijk. eGezondheid diensten werden top-down ontworpen; met focus op de dataplatformen, niet op de gebruikers-interfaces.

Om efficiënt en stelselmatig complete digitale dossiers te hebben, moeten concepten als medicatieschema, sumehr (samenvatting medisch dossier), vaccinatieschema en patiënten-journaal automatisch voortvloeien uit de gegevens die men tijdens het gewone werkproces registreert. 

Voorbeelden:

• Een huisarts moet nu “apart” (los van hun gewone workflow tijdens een raadpleging) een sumehr maken en telkens "bovenop" het gewone werkproces aanpassen.
  In feite zouden de meeste gegevens automatisch in een sjabloon van een medisch dossier moeten vloeien, inclusief de gegevens afkomstig van andere zorgverstrekkers (specialisten, ziekenhuis, labo’s, etc.). Daaruit kan (eveneens automatisch) relevante info gefilterd worden in een “gedeeld overzicht van het dossier”, dat meteen beschikbaar is voor de patiënt en voor elke andere zorgverstrekker die daar betere zorg mee kan leveren.
   
• Een arts en apotheker moeten eveneens “apart” een medicatieschema maken. Ook dit vraagt extra werk, in een aparte functie van het programma.
  Dat is dubbel zonde, want alle nodige gegevens worden bij het maken van een voorschrift of tijdens het afleveren van het medicament vanzelf al ingevuld of gescand. Momenteel moet men de vorm, posologie, toedieningswijze… manueel toevoegen. Vaak gebeurt dit niet-gestructureerd en niet gecodeerd. Terwijl die info – behoudens uitzonderingen – automatisch, gestructureerd en gecodeerd ingevuld zou kunnen worden vanuit de patiënt- en productfiche.
  Alle nodige info zit eigenlijk al vanzelf klaar om een medicatieschema te maken; het is alleen kwestie om ze automatisch in een gedeeld medicatieoverzicht te laten vloeien. Dat hoef je dan alleen even te overlopen samen met de patiënt, eerder dan laborieus een schema te moeten invullen…
• Elke vaccinatie zou verplicht in het patiëntendossier moeten worden geregistreerd. Vandaar kan het automatisch naar Vaccinet vloeien, ongeacht de vaccinator (arts, CLB, verpleegkundige en -- waarom niet -- de apotheker). Zo heeft iedereen vanzelf een complete vaccinatie historiek.
   
• Dagelijkse nota’s moeten door àlle betrokken stakeholders in hun eigen journaal worden genoteerd. Van daaruit kunnen ze automatisch gecompileerd worden in een overzicht. Zo krijgt het hele zorgteam vanzelf actuele en uniforme input, ook van mantelzorgers, welzijnswerkers en vooral van de patiënt zelf.

2. Dit veronderstelt héél andere software interfaces en databases dan we vandaag hebben.
Bestaande problemen van interoperabiliteit moet aan de bron worden opgelost.

• We hebben nood aan een extreme focus op “gebruiksvriendelijkheid” (in feite: pure UX **) en meer “intelligente” interfaces. Dat veronderstelt de ontwikkeling van standaard- of model-applicaties met professionele UX-expertise, waarbij veel gebruikers op het terrein (in elke sector) nauw betrokken worden. Die standaarden moeten gezamenlijk ontwikkeld en onderhouden worden door (alle) software vendors, in overleg met gebruikersclubs van elk softwarepakket.
   
• Softwareleveranciers mogen niet langer aan de slag gaat met een cookbook dat hoofdzakelijk functionele doelstellingen beschrijft en dus vrije interpretaties toelaat.
  Het herwerkte federale cookbook voor het medicatieschema is andermaal een ramp-in-wording, want het laat nog steeds te veel ruimte voor interpretatie toe. Zonder ingrijpen, gaan we nog eens tien jaar miserie tegemoet. (Enkele besloten werkgroepen die momenteel hierop aan het werken zijn, lossen dat waarschijnlijk niet op).
  Denk in termen van het dashboard van een auto: geen twee dashboards zijn identiek, maar functioneel zijn ze wel allemaal gelijk en interoperabel. Kruip achter het stuur en je vindt meteen je weg. Constructeurs kunnen zeer inventief en innovatief zijn, maar de bestuurders vinden wel altijd intuïtief hun weg.
   
• We moeten beschikken over databases die de zorgverstrekkers echt helpen.
  Een goede authentieke bron voor geneesmiddeleninformatie zou bij elk product een shortlist moeten aanbieden van:
  • de (± vijf) meest voorkomende posologieën;
  • de relevante (reeds SnoMed gecodeerde) indicaties;
  • de vorm en de toedieningsweg;
  • de meest voorkomende status van gebruik: chronisch, tijdelijk, ad hoc.
     
• De arts hoeft slechts aan te vinken. Hij kan afwijken indien nodig en hoeft dan alleen uitzonderlijk iets in te vullen. Door de frequentie van aanvinken van opties en de afwijkingen (anoniem) te analyseren, kan het aanvink systeem nog verbeterd worden.

3. Om dit alles te realiseren zal de overheid voldoende en vooral verstandig moeten investeren.

De enige mogelijkheid om de software vendors op één lijn te krijgen en toch de vrije markt en hun eigen inventiviteit te laten werken, is investeren in een “raamcontract”. Daarin verbinden de software vendors, enkele professionele UX-experten en een representatieve groep eindgebruikers met praktijkervaring zich contractueel en tegen betaling om bepaalde interfaces binnen een afgesproken tijd te realiseren, op basis van een gezamenlijk ontworpen model-applicatie die alle “verplichte” functionaliteiten bevat.

Dat zal voor alle zorgberoepen samen allicht algauw enkele tientallen miljoenen per jaar kosten. Geld dat van de overheid moet komen. Tot nu toe hebben de individuele eindgebruikers de meeste ontwikkelingen in de software zelf betaald, omdat het hun eigen praktijk en administratie ten goede kwam. Ze staan echter niet te trappelen om te investeren in tools om gegevens te delen met anderen, want de baten zijn niet alleen voor henzelf, maar vooral ook voor derden. Daarom moet de overheid de gezamenlijk gebruikte (eHealth) diensten en platformen blijven financieren, maar ook fors bijdragen in het gezamenlijke deel van de ontwikkeling van extreem gebruiksvriendelijke interfaces voor elke zorgverstrekker.

Alleen dat kan het veralgemeend delen van gegevens een noodzakelijke stroomversnelling geven.

4. Mobile first!
Zeker voor de patiënt.

De burgers, patiënten en mantelzorgers moeten al hun gegevens “op zak” hebben. Elke ontwikkeling moet dus vertrekken van een “mobile first” einddoel: geef de gegevens in handen van de patiënt en maak hem/haar daardoor echt de regisseur van zijn zorg.

Alleen op deze manier zal de burger zich steeds de baas blijven voelen van zijn eigen gegevens.
Men kan immers naar eigen goeddunken (al dan niet op uitnodiging van een zorgverstrekker of welzijnswerker) toegang geven of weigeren tot de gegevens, op maat van wat nuttig of nodig is in de relatie tussen het individu en elk lid van zijn zorgteam.

Dirk Broeckx
1 november 2020

**  Een UX Designer verbetert de gebruikerservaring of user experience op het vlak van websites, softwareprogramma’s, apps en games. Hij of zij heeft daarbij niet alleen aandacht voor de visuele vormgeving, maar bijvoorbeeld ook voor de interactie tussen de gebruiker en het medium.