De hierna opgesomde opmerkingen zullen vrijdag 19.6 gebracht worden.

Transcriptie

1 De software leveranciers verenigd in ProRecBE vergaderden op ter voorbereiding van de Consolidatiemeeting op Gelieve hierbij kennis te nemen van een aantal suggesties in verband met de Ronde Tafel voorstellen. ProRecBE en de softwareleveranciers beschouwen het niet als hun taak om bepaalde opties aan te vechten of te verwerpen. In eerste instantie wensen wij het team "Ronde Tafel" te feliciteren met de indrukwekkende documentatie. De ambities zijn groot en snelheid van uitvoering lijkt niet altijd realistisch, rekening houdende met de onderliggende afhankelijkheid van bepaalde taken. Het ware wenselijk alle taken in één groot tijdschema onder te brengen. Wij stellen wel vast dat de meeste documenten niet in beide landstalen beschikbaar zijn. Ook is er onvoldoende aandacht besteed aan de nietartsen. De meeste taken worden als enige en op zichzelf staande actiepunten beschreven. Graag een duidelijk stappenplan. Indien in 2015 voor alle pakketten efac en de lab migratie naar Loinc codes prioritair is dan heeft dat een impact op de beschikbare middelen. De hierna opgesomde opmerkingen zullen vrijdag 19.6 gebracht worden. SUMEHR (AP 1) Basis functies goed beschreven. Uitbreidingen veronderstellen nieuwe / aangepaste use cases Zeker Beperkt Zo goed als geen Bestaan. Nodig om het raadplegen van de Sumehr te stimuleren. Ja, in principe behoudens nieuwe gebruikscenarios die operationeel zouden worden 6 maanden na definitie van de dienst en de toegangsrechten Sumehr wordt beschikbaar voor 2 e en 3 e lijn, wachtposten, spoeddiensten. Toegang naar Sumehr voor deze categorieën moet in use cases gegoten worden en gepaard gaan met reglementaire bepalingen die het effectief raadplegen bevorderen. 1/1/16 is heel optimistisch. Bijvoorbeeld voor wachtposten is 1/1/16 niet haalbaar. Voorstel: datum van vastlegging en documentatie + 6 maanden Wij stellen voor om de locatie van de opslag van de SumEHR te laten afhangen van de keuze van de zorgverlener via één simpele instelling van zijn/haar software. De patiënt zelf laten

2 beslissen, zorgt voor extra complexiteit in de huisartsenpakketten en is een functie die niet voorzien is in de laatste labeling. Alternatief is een keuze gebaseerd op de woonplaats van de persoon. De Sumehr is essentieel bedoeld voor het verlenen van zorgen door een andere zorgverstrekker dan de gebruikelijke zorgverstrekker. Natuurlijk erkennen wij dat de patiënt in toenemende mate betrokken kan worden bij zijn/haar zorgdossier. Wij vinden niet dat het eenvoudigweg openstellen van de Sumehr in de kluizen (en indirect via de hubs, zie bijv. COZO & RSW) een geschikte evolutie is om dit doel te bereiken. In tegenstelling, wij vrezen zelfs dat de huidige positieve evolutie van de publicatie en gebruik van Sumehrs in het gedrang komt, door deze simpelweg zwart/wit open te stellen of niet op basis van patient consent. De optie "alles of niets" is op termijn niet verdedigbaar. Huisartsen hebben tijd nodig om de juiste niveaus van confidentialiteit te registreren voor de zorggegevens. Het is volgens ons aangewezen dat de zorgverlener kan aangeven dat een gegevenselement niet automatisch gedeeld mag worden met de patiënt, maar wel met andere zorgverleners, al ware het op verzoek van de patiëntzelf. Wie mag de Sumehr opladen? Indien enkel door GMD houder is dit eenvoudig te implementeren. Indien concept referentiearts gekozen wordt (wat volgens ons een waardevol concept is), dat dient dit verder uitgeklaard te worden hoe we technisch kunnen weten wie die referentiearts is. Onvoldoende aandacht besteed aan de andere beroepsgroepen. Zouden leesrechten moeten hebben op bepaalde gedeelten van de Sumehr. Ook hier is de optie "alles of niets" op termijn niet verdedigbaar.

3 Huisartsen software leveranciers worden in toenemende mate geconfronteerd met de situatie waarbij dezelfde informatie via verschillende wegen aan de eindgebruiker getoond worden. Wij streven ernaar om dezelfde informatie slechts op één plaats aan de arts te tonen. We vragen dan ook dat de ziekenhuishubs géén gegevens uit Vitalink (dubbel) doorgeven aan huisartsen. De leveranciers van huisartsen software vragen een verbetering van de meta die via de hub web services gecommuniceerd worden. In de praktijk komt het er nu soms op neer dat de websites van de hubs zinvollere lijsten van documenten tonen dan de mogelijkheden die de huisartsen hebben binnen hun eigen dossier. Web services hebben als toegevoegde waarde dat het geïntegreerd is in het EMD (werkomgeving van de arts) en dat er singlesign- on is.

4 Standaard en Terminologie (AP13) De gevolgen van een dergelijke beleidswijziging worden onderschat evenals de vereiste inspanningen en budgetten. Zeer veel twijfels Groot indien opgelegd zoals voorligt Groot en gevaarlijk De beschikbaarheid van gevalideerde "tools" en mapping tabellen zal van essentieel belang zijn Niet haalbaar binnen de gestelde termijnen. 1. De producenten wijzen er op dat zij door overheid verplicht geworden zijn (en nog verplicht zijn) om de Thesaurus te implementeren. Het komt aan de overheid toe om de beleidswijziging te "begeleiden", inbegrepen wat volgt. 2. De overheid moet instaan voor een gevalideerde mapping van de Thesaurus naar SNOMED. 3. Intern moeten de bestaande pakketten hun huidige terminologielijsten en codes kunnen verder gebruiken. Gekoppeld aan die codes zijn allergiebewaking, preventie, dosiscontrole, statistieken, listings, tegenaanwijzingen voor behandelingen en zelfs koppelingen naar externe ondersteuning gekoppeld. 4. Bij uitvoer van gegevens lijkt een conversie naar SNOMED onvermijdelijk indien opgelegd. Dit lijkt ons dan ook de gepaste strategie om SNOMED stapvoorstap in te voeren, namelijk per gegevensstroom/domein. 5. De moeilijke en gevaarlijke conversie van bestaande gestructureerde patiëntgegevens is een bijkomend argument voor opmerking SNOMED is niet de beste codering / terminologie voor alle domeinen: lab en pharma 7. De bepaling onder 13.7 verbaast de aanwezige leveranciers van verpleegkundige software met verbazing. Zij zijn (nog) niet op de hoogte van een evolutie naar Snomed. De termijn (1/1/16) lijkt hen moeilijk haalbaar. 8. Gezien de enormiteit van de opdracht wordt aangedrongen dat van meet af aan duidelijke budgettering afgesproken om te verhinderen dat het proces halverwege blijft steken? 9. Het vooruitzicht zou verlammend kunnen werken op de markt.

5 Medicatieschema (AP3) Verschillende schema's Indien een perfecte synchronisatie gerealiseerd kan worden tussen medicatiebeheer in het EMD en het medicatieschema lijken de principes haalbaar Redelijk groot Impact analyse gewenst Eén lijn initiatief Niet haalbaar binnen de gestelde termijnen. 1. Het beschikbaar zijn van medicatiegegevens op het net net (Vitalink (Vl) / Sumehr (Wal) lijkt nuttig te zijn. 2. De bidirectionele interactie biedt interessante voordelen voor de arts a. Weet bij substitutie wat effectief afgeleverd is b. Krijgt zicht op OTC producten c. Kan beter een addictie inschatten 3. Een en ander lijkt te wijzen op (minstens) een tendens om de medicatiegegevens uit het EMD te halen. Daar bij moet rekening gehouden worden met de volgende aspecten is niet aanvaardbaar om de volgende redenen: a. Medicatie interageert met dossiergegevens (die niet aanwezig zullen zijn in het apotheekdossier) voor i. Dosisberekening op basis van de nierfunctie ii. Idem.. leverfunctie iii. Medische contraindicaties (actuele pathologie, antecedenten) iv. Allergie b. Het EMD bevat links tussen medicatie en indicatie c. De dossierbeheerder moet een chronologisch geïntegreerd dossier kunnen opbouwen (journaal) omwille van juridische of andere redenen (PMF/SMF). Trouwens hoe zit dat met de historiek van het schema? d. Voorschrijfdatum is niet gelijk aan de afleverdatum. Een journaal op arts niveau is op voorschrijfdatum. De apotheeklogica is gebaseerd op de afleverdatum. e. De arts is en blijft de uiteindelijke verantwoordelijke voor de medicatie. De beste bewaking dient te gebeuren "at the point of prescription" f. Het afzonderlijk bijhouden van de medicatiegegevens maakt België ongeschikt voor wetenschappelijk onderzoek, clinical trials en pharmacovigilance. 4. Er dienden duidelijke gebruiksscenario s bepaald te worden ivm het samen bestaan van het medicatieschema in de Sumehr en Vitalink. Het is voor de softwareleveranciers niet duidelijk hoe beide naast elkaar moeten bestaan. Wat is de authentieke bron? 5. Details a. Opbouw en afbouw schema b. Overbodige complexiteit van het schema (meer bepaald het verband met de maaltijden)

6 Recipe diensten (AP4) De dienst zelf lijkt goed te functioneren Bewezen Nu niet meer Impact analyse gewenst Eén lijn initiatief Nieuwe diensten: zes maanden na vastleggen specificaties 1. Gebrek aan win/win speelt de dienst parten 2. Zinloos vasthouden aan papieren document maakt de dienst "minder noodzakelijk" 3. Kine voorschrift; 6 maanden na vastleggen formaat 4. Verpleging: idem 5. PMF dikwijls niet geadresseerd: kandidaat voor Recipe

7 Ehealth diensten (AP5) De dienst zelf lijkt goed te functioneren bewezen Nu niet meer Eén lijn initiatief Nieuwe diensten: zes maanden na vastleggen specificaties 1. Gewenst: optimalisatie van de respons tijd voor technische ondersteuning 2. Nodig: Web service(s) voor vernieuwing van de certificaten 3. Pragmatische oplossingen gewenst, ook ivm nieuwe Europese regelgeving voor privacy bescherming

8 mhealth (AP21) Beperken ons tot het mobiel beschikbaar zijn van de patiëntgegevens (van uit het patiëntendossier, weze het een EMD of een EVD Niet erg duidelijk wat bedoeld wordt, anderzijds al bestaande in de verpleegsoftware Problemen meer ter hoogte van de infrastructuur dan de toepassing Weinig Zo goed als geen Opgenomen in de criteria Nieuwe diensten: zes maanden na vastleggen specificaties Opmerking 1. Toevoegen van Astrid 2. Blue Light Mobile onderzoeken als streefdatum lijkt haalbaar 4. Zie het nut niet in van vijf pilootdomeinen..; één zal wel volstaan De use cases in actiepunt 21.3 zijn eenzijdig gericht op telemonitoring/coaching. Er zijn vele andere domeinen van mhealth die belangrijk zijn om verder te ontwikkelen. Vanuit de eerste lijn softwareleveranciers denken wij dan aan mogelijkheden om de zorgverlenerpatiënt communicatie mogelijk te maken via elektronische weg en ideaal via mobiele toestellen ( mobile first ). We denken hier bijvoorbeeld aan: use case: elektronisch consult use case: verlengen voorschrift use case: feedback op labo resultaten

9 Hospital EHR MULTIDISCIPLINAIR Wij hebben het alleen over het multidisciplinair dossier Eindenlijk nog niet gedocumenteerd / beschreven bijv. ivm leesrechten / schrijfrechten Ja, afhankelijk van de opties Het is niet zo dat een multi dossier zomaar gelijk is aan de som van de drie beroepspecifieke dossiers De aard van de oorsprong van een gegeven is belangrijk. Niet onmogelijk. prematuur 1. Maken onderscheid tussen een multidossier 'in loco' en een 'virtueel multidisciplinair dossier" is nodig. 2. In loco a. Zal steeds een beroeps eigen luik omvatten o.a. een werkfiche b. Duidelijk te bepalen welke gegevens gemeenschappelijk zijn c. Concept "zorgteam" moet beheerd worden, ook wat toegang tot de gegevens betreft 3. Virtueel Denken eerder aan een tijdelijke "view" gebaseerd op het PHR

10 Personal Health Record Een beetje "sloganesk" Ja Beperkt None 2018? 1. In de opsomming van PHRfuncties zien we vele items staan die op verschillende manieren en door verschillende partijen ingevuld kunnen worden, soms ook door leveranciers van software voor eerstelijnsactoren. Wij vinden het geen probleem dat dezelfde mogelijkheden op verschillende plaatsen aangeboden worden aan patiënten. 2. De softwareleveranciers voor zorgverleners willen zelf de mogelijkheid om éénopéén communicatie met de patiënten als dienst aan te bieden aan hun zorgverleners. Dit is nu bijvoorbeeld al het geval voor online agenda, maar zal zich ongetwijfeld uitbreiden naar inzage in de dossiers, invullen van vragenlijsten, en vele andere diensten. 3. Wij zijn van het standpunt dat het voorstel om tot één centraal PHR voor alle burgers te komen tegengesteld is aan de principes waarop het Belgische ehealth en privacygebeuren momenteel gestructureerd is. 4. Bestaat uit een "professioneel" gedeelte" en een "patiënt" gedeelte. 5. Professioneel deel a. Gebaseerd op Sumehr, eventueel aangevuld met enkele factuele gegevens (meetwaarden / lab) b. Bevat ook een luik verpleging en kine c. Professionele luiken worden automatisch aangevuld van uit de professionele dossiers d. Niet editeerbaar 6. Patiënt luik a. Medicoadministratieve gegevens b. Meetwaarden c. Symptomen, klachten, narratieve d. Arts heet inzage en kan gegevens overbrengen naar professioneel dossier

11 Informatie & Opleiding van de Zorgverstrekkers (AP12 )De softwareleveranciers voor zorgverleners spelen zelf een belangrijke rol in de ondersteuning en opleiding van hun eindgebruikers. Wij worden graag betrokken bij een integrale aanpak waarbij overheidsinitiatieven maximaal afgestemd worden op de eigen opleidingen. Wij denken dat er een betere synergie mogelijk is tussen algemene opleidingen en de doorstroming naar gespecialiseerde (en soms betalende) opleidingen van de software leveranciers zelf.