Discussiethema Huidige toepassingen

Transcriptie

1 Discussiethema Huidige toepassingen Bij dit onderdeel kunnen een aantal onderwerpen worden besproken over de werking van huidige toepassingen, onderdelen of processen: 1. Actualiteitscontrole - what's new 2. Gebruik UZI-pas 3. Omgaan met de LSP Signaalfunctie 4. Pre-fetchen 5. Voorkomen van verstoringen 1. Actualiteitscontrole De actualiteitscontrole ( What s new ) is een nieuwe functie op het LSP. Hiermee kan een systeem voor een bepaalde patiënt aan het LSP vragen: zijn er nieuwe gegevens bekend sinds een bepaalde datum? Er zijn een aantal vragen / punten die om een antwoord vragen: Er is een aantal beperkingen gesteld om potentieel misbruik te voorkomen; zo is het verboden om batchgewijs te bevragen. Dit mag alleen aan de hand van bepaalde triggers. Wat zijn de gevolgen in het proces? o Hoe zeker ben je van de informatie? o Waar moet je rekening mee houden? o Wat zijn de gevolgen voor het gebruik in combinatie met queryparameters? Wat zijn de voorwaarden (zoals bijvoorbeeld verplicht automatisch (her)aanmelden voor alle bronsystemen)? Ook is er een relatie met het begrip bouwstenen. Deze discussie wordt bij het discussiethema bouwstenen behandeld Werking Actualiteitscontrole Kern De abonnee/signaalfunctie kent een aantal bezwaren waardoor er een behoefte is om op een alternatieve wijze een indicatie te verkrijgen of er nieuwe gegevens zijn ten opzichte van de gegevens die in de lokale administratie zijn opgeslagen Toelichting Op dit moment wordt de abonneefunctie op diverse manieren ingezet en is ook op een aantal verschillende manieren geïmplementeerd. In sommige systemen is het mogelijk om voor specifieke groepen een abonnement te nemen; in een aantal Discussiethema Huidige toepassingen 1 van 6

2 systemen is deze selectie niet mogelijk en wordt voor een te ruime populatie een abonnement afgesloten. Dit heeft een aantal nadelige gevolgen: 1) Er is een te groot aantal opvragingen waarbij het moment van opvragen los staat van een eventueel patiëntencontact. 2) Het is steeds lastiger om misbruik te constateren. 3) Er is een toenemend aantal klachten waarbij patiënten aangeven dat er is bevraagd door een apotheek, waarbij er geen actuele behandelrelatie bestaat (tot zelfs 8 jaar geen contact en reeds verhuist naar een andere gemeente). 4) De signaallijst is in sommige situaties zo groot, dat het voor de zorgverlener te veel tijd kost om de signalen te verwerken. 5) Er is een toenemende vraag van zorgverleners die aangeven dat zij niet verantwoordelijk willen zijn voor de gevolgen van het gebruik van de signaalfunctie, namelijk dat ze zouden moeten acteren op eventuele nieuwe informatie, maar wél inzicht willen hebben dát er iets is gewijzigd. Daarnaast speelt de wens om te komen tot een situatie waarbij wordt voorkomen dat het LSP bevraagd wordt, met een UZI-pas en wachttijd op het antwoord, terwijl er geen nieuwe of relevante informatie beschikbaar is gekomen. Deze wens wordt mede ingegeven door het feit dat er op dit moment nog te veel verstoringen in de keten zijn. Hierdoor treden soms fouten op terwijl het systeem feitelijk geen relevante (lees: nieuwe) gegevens heeft. In het geval van een time-out (QABRTITI) levert dit voor de opvragende zorgverlener ook nog een niet noodzakelijke wachttijd op. Er is een aantal manieren waardoor het eigen dossier effectiever up-to-date kan worden gehouden. Hierbij wordt een just-in-time principe gevolgd. Voor een deel van de patiëntpopulatie is de abonneefunctie een zeer geschikt middel: 1) Er zijn wel reguliere verstrekkingen, maar er geen patiëntcontact is, dat wil zeggen er is geen standaard handeling waarbij het patiëntendossier wordt geopend. Denk hierbij aan de zogenaamde baxterpatiënten. Het is weinig zinvol om elke week voor alle baxterpatiënten het LSP te raadplegen. 2) Patiënten die proactief bewaakt dienen te worden. Dit geldt voor individuele patiënten waarbij er vaker en op verschillende plaatsen medicatie wordt geleverd en waarbij de zorgverlener een vinger aan de pols wil houden. 3) Polypharmacie patiënten met een zeer complex dossier. Voor patiënten die buiten bovenstaande categorieën vallen, is een alternatief nodig om de hoeveelheid aan onnodige bevragingen te minimaliseren. Discussiethema Huidige toepassingen 2 van 6

3 Logische vraag Resultaat Methode Trigger Doel Zijn er nieuwe (her)aanmeldingen sinds een bepaalde datum? Ja / Nee Met servercertificaat (op laag ) Bijvoorbeeld binnenkomst van recept of een afspraak Snelle controle of er nieuwe gegevens zijn, zonder dat er een UZI-pas nodig is Doel Beperking belasting reagerende systemen (kleinere berichten) Beperking qabrtiti. Aandachtspunten AORTA v8 Met de invoering in AORTA v8 van de generieke query zullen de functies op basis van de context-id kunnen worden uitgevoerd. Dit heeft natuurlijk complicaties, omdat dan ook de SDS bij het proces zal moeten worden betrokken. Het proces zal dan ook iets genuanceerder moeten plaatsvinden. Op een positief resultaat van de actualiteitscontrole zal immers een generieke vraag worden gesteld, terwijl er dan veel gerichter aan het bronsysteem kan worden bevraagd. In de eerste versie zal geen rekening worden gehouden met de generieke query, omdat op dit moment nog niet duidelijk is hoe het (her)aanmelden van bouwstenen in combinatie met de actualiteitscontrole/signaalfunctie zal moeten gaan functioneren. De regiogrenzen De regiogrenzen vormen een probleem om de updatestatus correct te zetten. Echter dit is een beperkt probleem. Wanneer blijkt dat voor een deel (vanaf 2 patiënten) de regiogrens een blokkade vormt, is het legitiem om de regio te laten uitbreiden en het is dan ook geen blijvend probleem. Zaak is om aan de eindgebruiker duidelijker te maken welke regio s interessant zijn om in uit te breiden Werking Een agerend systeem vraagt aan de ZIM of er sinds een bepaalde datum nieuwe (her)aanmeldingen zijn geweest die door het systeem kunnen worden opgevraagd. Het resultaat is een Ja of Nee antwoord, en de (standaard) foutmeldingen, zoals Key204 ( patiënt niet gevonden ), niet geautoriseerd, etc. Proces Na een bepaalde trigger (bijvoorbeeld een elektronisch recept in de apotheek, of een afspraak in de huisartsenpraktijk) wordt een bericht naar de ZIM gestuurd, met als peildatum de laatste geslaagde bevraging van de betreffende gegevenssoort. Wanneer het antwoord Ja is dan kan daarna het LSP worden bevraagd, met UZIpas, om de nieuwe gegevens op te halen. Discussiethema Huidige toepassingen 3 van 6

4 Bijwerken verwijsindex Zodra er een nieuw gegeven wordt geregistreerd, zal de VWI worden bijgewerkt. Dit gebeurt zowel voor nieuwe gegevens bij een reeds aangemeld dossier, als in het geval wanneer er een nieuwe aanmelding plaatsvindt. Systeemrollen Aan de hand van de systeemrollen wordt bepaald welke gegevens opgevraagd kunnen worden. Zo zal een systeem in de rol Medicatiebewakend Systeem medicatieverstrekkingen en contra-indicaties kunnen opvragen. Dit kan worden beoordeeld aan de hand van het APR (Applicatieregister) en het Applicatie-id. Aan de systeemrol zijn de VWI gegevenssoorten gekoppeld. Bijvoorbeeld voor een medicatiebewakend systeem zijn de gegevenssoorten Medicatieverstrekking, Conditie en Overgevoeligheid gekoppeld. Een systeem kan natuurlijk meerdere systeemrollen vervullen. Datum controle Op de VWI moet worden gezocht naar aanmeldingen die op of na de datum, die in de query parameter is opgegeven, zijn bijgewerkt. Voorbeeld: In de query staat als datum Alle (her)aanmeldingen die op of na zijn gedaan moeten in het resultaat worden meebeoordeeld. Er mogen geen lege datums worden meegegeven in de vraag Kanttekeningen Bij een query met de einddatum als parameter kan niet de laatste succesvolle opvraagdatum worden gebruikt als referentiedatum. Er zijn situaties waarbij er verstrekkingen in de toekomst worden geregistreerd. Een query hoeft altijd niet tot een resultaat te leiden. Er kan een update zijn gedaan op gegevens die niet worden opgeleverd binnen de queryparameters die zijn gevraagd. De interactie is op laag. Dat betekent dat er geen natuurlijk mechanisme is om de autorisatie te controleren Voorwaarden Het agerende systeem zal een correcte logging moeten bijhouden en rekening houden met foutmeldingen. Alle systemen zullen het automatische her-aanmeldproces moeten ondersteunen. Om te kunnen voldoen aan de risicobeperking dat niet voor alle patiënten een query wordt uitgevoerd, zijn een aantal aanvullende eisen gesteld. Discussiethema Huidige toepassingen 4 van 6

5 GBZ-Eis: Het mag niet mogelijk zijn om voor alle patiënten een actualiteitscheck te doen. Dat wil zeggen er mag geen functionaliteit worden ontwikkeld die het batchgewijs bevragen voor alle patiënten ondersteund. Dit wordt gecontroleerd tijdens de kwalificatie en steekproefsgewijs in het veld. 2. Gebruik UZI-pas Hoe om te gaan met de UZI-pas in de zorgtoepassingen? De GBZ-eisen zijn helder, maar niet sluitend genoeg. Zo is er het mandateringsvraagstuk. Worden er op 1 UZI-pas alle vragen gesteld? Welke problemen zijn er? Wat zijn nieuwe mogelijkheden? Wat zijn de wensen? Met de NEN7510/ 7512 in de hand kan veel bedacht worden voor de verplichte 2-factorauthenticatie voor toegang tot het medisch dossier. Is hier een uniforme(re) handreiking voor implementatie voor te bedenken? Ook is er nieuwe UZI-software in de maak. Wat zijn hier de gevolgen van? 3. Omgaan met de LSP Signaalfunctie Door de grote hoeveelheid aan signalen is de signaalfunctie minder effectief dan in het begin was bedacht. De 'what's new' functie is voor een aantal situaties een bruikbaar alternatief; Een dossier wordt alleen opgevraagd wanneer daar ook een relevante aanleiding voor is. Echter blijven er een aantal uitdagingen over om de signaalfunctie ook goed in te zetten: Hoe kunnen we de signaalfunctie in het artsendomein inzetten? Bijvoorbeeld als vervanger van het edifact-retourbericht. Betekent dat bijvoorbeeld dat er een abonnement op 'toedienafspraken' moet komen, of moeten er betere referenties in de verstrekkingen komen, zodat er in het HIS goed gekoppeld kan worden? Hoe kunnen we voorkomen dat er signalen worden gegenereerd, terwijl er functioneel geen nieuwe informatie is (bijvoorbeeld het technisch heraanmelden)? Het is niet de bedoeling om hier de discussie over de effecten van de bouwstenen te gaan voeren, die vallen onder een ander discussiethema. Discussiethema Huidige toepassingen 5 van 6

6 4. Pre-fetchen Pre-fetchen wordt nu veelal s nachts door een aantal ziekenhuizen gedaan: Dit leidt tot veel overbodig verkeer. Kan dit efficiënter (bijvoorbeeld door gebruik te maken van de what s new functie) of een betere vraagstelling (filteren op datum op de ZIM waardoor alleen die systemen worden bevraagd die ook nieuwe informatie hebben)? En wat zijn andere tips-en-tricks? 5. Voorkomen van verstoringen Er is het afgelopen jaar al een aantal keer gesproken over het effect van de verstoringen in de communicatie op het gevoel van de eindgebruiker. In de top-10 van verstoringen staan de rtedest en qabrtiti erg hoog en dat zijn voor een groot deel fouten die te voorkomen zijn. Daarnaast is er een groot aantal lokale verstoringen die ook worden gezien als 'het LSP werkt niet': Wat zijn de oorzaken van de RTEDEST-en en QABRTITI s? Hoe kunnen we verstoringen gaan voorkomen? o Automatisch vervangen van servercertificaten, zodat systemen niet op onderhoud staan? o Beperking verkeer? o Slimmere queries (voorkomen time-outs)? Discussiethema Huidige toepassingen 6 van 6