Structurele registratie van data gericht op triage en beoordeling (23 januari 2018)

Transcriptie

1 Structurele registratie van data gericht op triage en beoordeling (23 januari 2018) 1. Inleiding Tijdige en kwalitatief goede acute psychiatrische hulpverlening is van essentieel belang voor de patiënt, zijn naasten en hulpverleners. Begin 2017 is de generieke module Acute Psychiatrie opgesteld. De module is opgesteld door vertegenwoordigers van álle partijen die betrokken zijn in de keten van de acute psychiatrische zorg. De generieke module beschrijft de inhoud en organisatie van hulpverlening voor personen in een crisissituatie, waarbij vermoed wordt dat er sprake is van een acute psychiatrische stoornis. Onderdeel van de generieke module Acute Psychiatrie is de Triagewijzer. In de maanden juli tot en met december 2017 hebben 15 crisisdiensten in een pilot deze Triagewijzer toegepast. Tijdens deze pilots hebben twee interventies plaatsgevonden. 1. Trimbos-instituut heeft gedurende de pilot gemonitord over hoe de Triagewijzer wordt gebruikt en onderzocht of en hoe de Triagewijzer doorontwikkeld dient te worden. Een belangrijk onderdeel van de pilot was het registreren van data over het proces van triage en eerste beoordeling. Iedere crisisdienst heeft geanonimiseerd op casusniveau data bijgehouden welke het Trimbos-instituut heeft geanalyseerd (zie verder paragraaf 2). 2. Significant heeft het proces van de implementatie van de Triagewijzer in de pilots begeleid. Op basis van de begeleiding van de implementatie zijn inzichten over stimulerende en belemmerende factoren voor een goede implementatie gebundeld in een handreiking Implementatie Triagewijzer acute GGZ. Naast de begeleiding van de implementatie is Significant gevraagd te inventariseren hoe de te registreren gegevens van de Triagewijzer kunnen aansluiten bij de ICT-systemen die de crisisdiensten gebruiken. Voorliggende notitie gaat in op deze specifieke vraag waarin we een voorstel doen over de mogelijkheden die er zijn om de registratie van data gericht op triage en eerste beoordeling te koppelen aan bestaande ICTsystemen. De notitie is als volgt opgebouwd: We schetsen de huidige situatie en ervaren knelpunten hierin, ten aanzien van de registratie van data in het proces van triage en beoordeling bij de crisisdiensten. Deze schets is gebaseerd op de 15 crisisdiensten die participeerden in de pilotperiode. Dit is circa de helft van het totaal aantal crisisdiensten dat Nederland telt. We schetsen scenario s gericht op de vraag hoe structureel data gericht op triage en beoordeling in ICTsystemen verankerd kunnen worden. Voorliggende notitie is opgesteld als onderdeel van de opdracht van Significant gericht op de ondersteuning van de implementatie van de Triagewijzer. De notitie is opgesteld door Significant en Stichting Koppeltaal. De inhoud van de notitie is afgestemd met betrokkenen van GGZ Nederland. 2. Analyse huidige situatie Onderstaand kader bevat een overzicht van gegevens die tijdens de pilot zijn geregistreerd door de medewerkers van de crisisdiensten. Het is belangrijk om hierbij te benoemen dat deze set aan gegevens is bijgehouden gedurende de pilotperiode. Bij eventuele toekomstige registratie verdient het aandacht om te bekijken welke data wenselijk is voor structurele registratie. Dat kan een deel van de data in het kader betreffen, maar eventueel ook aanvullende data betreffen. Ter illustratie de gegevens die tijdens de pilot zijn geregistreerd: Datum en tijdstip triage afgerond Verwijzer (politie, huisarts, etc.) Gekozen urgentie Urgentie uit Triagewijzer Indien gekozen afwijkt van advies Triagewijzer: reden Datum en tijdstip start beoordeling datum en tijdstip einde beoordeling Aantal personen dat de beoordeling uitvoert Locatie van beoordeling (thuis, GGZ instelling, elders) Vervolgbeleid

2 We merken een aantal knelpunten op in de huidige wijze van registratie bij crisisdiensten. Dat betreft: a. Geen uniforme registratiewijze bij de crisisdiensten ten aanzien van triage en eerste beoordeling; b. Dataregistratie in het kader van de pilot vraagt om een extra handeling; c. Managementinformatie over triageproces ontbreekt; d. Relevante data over personen die in beeld zijn bij crisisdiensten is in verschillende systemen aanwezig. In onderstaande alinea s lichten we deze knelpunten toe. a. Zoveel crisisdiensten, zoveel verschillende registratiesystemen De crisisdiensten werken met verschillende ICT-systemen. Voor de 15 crisisdiensten die participeerden in de pilot hebben we al 5 verschillende systemen gezien: PsygisQuarant, Webraap, User, XmCare en M Console. De inrichting en werking van deze systemen verschilt en gegevens zijn niet onderling uitwisselbaar. We concluderen op basis van de 15 participerende crisisdiensten in de pilot, dat crisisdiensten niet uniform werken wat betreft registratie. Iedere crisisdienst kent zijn eigen wijze waarop registratie van de meldingen die binnen komen bij de crisisdienst plaatvinden. Dit varieert van aantekeningen op papier tot registraties in daarvoor bestemde software (hetgeen niet per definitie hetzelfde systeem betreft als het Elektronisch Patiënten Dossier (EPD)). b. Dataregistratie in het kader van de pilot vraagt om een extra handeling Het registreren van data bleek gedurende de pilot bij de meeste crisisdiensten een grote investering te zijn (in tijd en capaciteit). De oorzaak hiervoor is gelegen in het feit dat de registratie van de gevraagde data geen onderdeel van de standaard registratie van crisisdiensten betreft. Een uitzondering hierin zijn de crisisdiensten die werken met het systeem Webraap. Voor de pilots is Webraap aangepast waardoor de gevraagde gegevens voor de pilotperiode geïntegreerd zijn in dit systeem. In de ideaalsituatie zou iedere crisisdienst in het registratiesysteem waarmee wordt gewerkt tijdens triage en beoordeling, die data willen registreren die relevant zijn. (zodat de registratie is geïntegreerd in de werkwijze en handelingen die worden uitgevoerd). Hier dient dan wel eerste een afspraak gemaakt te worden over welke data precies nodig zijn om de triage zorgvuldig uit te kunnen voeren. Tegelijk speelt het probleem van administratieve lasten in de sector waardoor er kritisch moet worden gekeken naar de noodzaak van registratie, ook voor de kwaliteit van de triage. c. Structurele managementinformatie over triageproces ontbreekt Het management van crisisdiensten heeft aangegeven dat de data zoals geregistreerd tijdens de pilot erg bruikbaar is voor het gesprek intern met professionals én goed bruikbaar is voor het gesprek extern met bijvoorbeeld verwijzers. Managers van de crisisdiensten geven aan dat zij voor start van de pilot niet over deze data beschikten. Daardoor hadden zij ten aanzien van de triage en eerste beoordeling onvoldoende of geen managementinformatie beschikbaar over de totale werkzaamheden die plaatsvinden op een crisisdienst. De dataregistratie is vanuit dat perspectief dan ook als waardevol ervaren. d. Relevante data over personen die in beeld zijn bij crisisdiensten / GGZ instelling in verschillende systemen aanwezig Alleen voor de groep personen voor wie een behandeling of opname volgt, wordt na de registratie gericht op het proces van triage (zie b) in een EPD van de GGZ-instelling een dossier aangemaakt. Dit EPD-systeem betreft meestal een ander registratiesysteem dan het systeem dat wordt benut bij de triage. Voor de groep personen waar na de triage en eerste beoordeling geen opname of behandeling volgt, wordt niet altijd een (nieuw) dossier in het EPD geopend. De gegevens over deze personen ten aanzien van triage en eerste beoordeling blijven daarmee alleen beschikbaar in de registratie van de triage. Dit kan dus ook blijven bij een 'papieren invulformulier'. Voor de groep personen waar wel een wel opname of behandeling volgt, worden gegevens geregistreerd in het EPD. De bijgehouden registratiegegevens bij de crisisdienst over triage en eerste beoordeling worden dan voor een deel overgeschreven of overgenomen in het EPD (soms via een ICT-koppeling). Pagina 2 van 5

3 Samenvatting en conclusies Crisisdiensten uiten al langere tijd de wens om data te registreren t.a.v. het triageproces en de eerste beoordeling. Deze data biedt namelijk de mogelijkheid om continuïteit van zorg te bieden en managementinformatie te ontsluiten gericht op aantal uitgevoerde triages, verdeling over type verwijzers, aanrijdtijden, et cetera. Deze informatie draagt bij aan het voeren van zowel het gesprek intern (met professionals) als extern (met verwijzers). Iedere crisisdienst heeft een eigen werkwijze ontwikkeld om data t.a.v. het proces en eerste beoordeling bij te houden. Dit varieert van handmatig op papier gegevens registeren tot aan ICT systemen die al dan niet gekoppeld zijn aan bijvoorbeeld het EPD binnen de GGZ instelling. Om structureel data te registeren gericht op het proces van triage en eerste beoordeling (denk aan tijdsduur tussen triage en beoordeling, verwijzer, duur van de beoordeling, urgentiegraden, etc.) is voor vrijwel alle crisisdiensten een aanpassing in de huidige wijze van registratie nodig. Het is op de eerste plaats belangrijk dat de registratie digitaal plaatsvindt, zodat data kunnen worden uitgewisseld en als managementinformatie met behulp van queries ontsloten kunnen worden. Daarnaast biedt het registeren in een systeem de mogelijkheid om systemen die binnen een GGZ instelling gebruikt worden aan elkaar te koppelen, zodat data over een patiënt automatisch worden doorgezet en er een volledig beeld ontstaat van het gehele proces dat de patiënt heeft doorlopen (van triage tot en met behandeling of opname). De huidige praktijk die in de pilots is onderzocht toont aan dat het structureel kunnen ontsluiten van data nog niet mogelijk is. Onderstaande paragraaf gaat in op mogelijke oplossingsrichtingen om ICT systemen aan te passen en/of te koppelen, zodat data gericht op triage (aansluitend op de Triagewijzer) ontsloten kunnen worden. 3. Scenario s met oplossingsrichtingen Met ICT deskundigen zijn scenario s verkend om de data structureel te kunnen registeren en ontsluiten. Scenario 1: Iedere crisisdienst organiseert en implementeert dataregistratie en het daaraan gekoppeld genereren van managementinformatie in hun eigen registratiesysteem Iedere individuele crisisdienst organiseert dat de gevraagde data gericht op het proces van triage en eerste beoordeling wordt bijgehouden in een registratiesysteem. (Daarmee wordt dus afgestapt van handmatige registraties of registraties in aparte Excel-formulieren). Iedere crisisdienst dient hiervoor bilateraal met de beheerder van het ICT-systeem dat wordt gebruik bij de crisisdienst of GGZ-instelling, af te stemmen over de mogelijkheid om het systeem aan te passen zodat de gevraagde data worden geregistreerd. Potentieel moeten circa 35 crisisdiensten (en daarmee circa 35 GGZ-instellingen) de gegevensuitwisseling en rapportage in hun systemen implementeren. Dit zou kunnen leiden tot hoge kosten als iedere GGZ instelling voor zich de integratie tussen systemen moet regelen. Scenario 2: Gebruik maken van Koppeltaal GGZ Koppeltaal is een standaard en een applicatie waarmee GGZ- en verslavingszorgaanbieders hun informatiesystemen (met ROM en EPD), serious games, apps en andere toepassingen met elkaar kunnen integreren. Koppeltaal stelt GGZ-instellingen in staat cliënten toegang tot e-health modules van verschillende leveranciers te geven. Door het verbinden van informatiesystemen via Koppeltaal ontstaat meerwaarde voor GGZ-instellingen en ICT-leveranciers. Het doel is het openen van gesloten systemen en het verbinden van losse eilanden in de zorg, zodat zorgconsumenten en behandelaren over de noodzakelijke gegevens voor zorg kunnen beschikken en daarvoor the best of breed in e-health kunnen gebruiken. Stichting Koppeltaal bestaat sinds Het team bestaat uit een technische community, vertegenwoordigers van GGZ-instellingen, ICT-leveranciers en Zorgverzekeraars. Inmiddels gebruiken diverse GGZ-instellingen Koppeltaal. Hun behandelaars bieden hun cliënten e-health oplossingen aan van verschillende ICTleveranciers. Daarnaast benutten de grote EPD-leveranciers Koppeltaal om EPD- en ROM-applicaties te koppelen. Onderstaande figuur geeft weer wat Koppeltaal doet. Pagina 3 van 5

4 Na aansluiting van een GGZ-instelling bij Koppeltaal heeft de instelling de beschikking over elke module van elke ICT-leverancier die bij Koppeltaal is aangesloten. Dit vergroot de portfolio, waarmee de instelling haar cliënten keuzevrijheid en optimale zorg kan bieden. Door gebruik van Koppeltaal kunnen de leveranciers de ontwikkelde e-health modules ook gemakkelijk bij andere GGZ-instellingen aanbieden en koppelen aan reeds bestaande ICT-platformen binnen de verschillende instellingen. Ondanks dat Koppeltaal actief is in het GGZ-domein en het daarmee een mogelijke technische oplossing biedt voor het voor het hiervoor beschreven vraagstuk rond de Triagewijzer, is dit het niet geval. En wel om de volgende redenen: Het toepassingsdomein van de Triagewijzer afwijkt van het toepassingsdomein van Koppeltaal GGZ. Het is geen ehealth uitwisseling in de driehoek EPD, ROM, ehealthplatform. De bij de triage betrokken applicaties (PsygisQuarant, Webraap, User, XmCare en M Console) zijn (nog) niet aangesloten op Koppeltaal. Het is niet zeker dat de Koppeltaal Server de best passende technische infrastructuur is voor de uitwisseling van de gegevens. Alleen in het geval van overdracht, in combinatie met de situatie dat er een verschil is tussen Triageapplicatie en EPD, zou de koppeltaal infrastructuur een goede mogelijkheid bieden. Voor rapportage en alle andere gevallen lijkt deze route minder geschikt. Scenario 3: Gebruikmaken van de onderliggende HL7 FHIR standaard van Koppeltaal Hoewel Koppeltaal op dit moment vooral voor de uitwisseling van data en beschikbaar stellen van ehealth applicaties wordt gebruikt, en de Triage daar van afwijkt doordat een wezenlijk ander aspect van het zorgtraject wordt bedient, zou een oplossing gemaakt kunnen worden door dezelfde onderliggende technologie als Koppeltaal te gebruiken, en deze te ontwikkelen via een zelfde proces als waarmee Koppeltaal ontwikkeld is. Op basis van Health Level 7 (HL7) Fast Interoperable Health Resources (FHIR) kan de aanpak die Koppeltaal gebruikt wel voor Triage worden toegepast. De werkzaamheden zouden dan bestaan uit: 1. het beschrijven van de Use Case (gebruiksfunctie van de oplossing) op basis van de Triagewijzer 2. het beschrijven van alle betrokken stakeholders 3. het beschrijven van het proces van informatieverwerking en de typen systemen die hierin een rol spelen. 4. Het in detail beschrijven van de data set en hier met elkaar als crisisdiensten consensus over bereiken. 5. Het selecteren van Zorg Informatie Bouwstenen (ZIBs) die beschikbaar zijn voor deze data set en waar nodig de ontbrekende ZIBs maken 6. Het specificeren van HL7 FHIR resources, maken van Triage profiles en indien noodzakelijk maken van extensies. Pagina 4 van 5

5 7. Het opstellen van een FHIR uitwisselingsspecificatie en deze uitproberen op werkzaamheid 8. Het implementeren hiervan in de systemen en testen of dit aan de specificaties voldoet en voor gebruikers en management de juiste informatie op de juiste plek brengt op het juiste moment. Samenvatting en conclusies De twee hiervoor beschreven oplossingsrichtingen 1 en 2 (iedere crisisdienst organiseert zijn eigen ICTaansluiting óf de systemen worden gekoppeld middels Koppeltaal GGz) zijn beide geen oplossingen voor vraagstuk hoe de ICT-systemen te koppelen aan de Triagewijzer met als doel structureel data te registreren en te kunnen ontsluiten. Scenario 3, conform de werkwijze en standaard van Koppeltaal een gelijkwaardige oplossing maken voor Triage, biedt dan meer perspectief. Ons advies is om als stap 1 richting structurele dataregistratie een informatiestandaard voor de gegevensuitwisseling rond het proces van triage en beoordeling te ontwikkelen op basis van de Zorg Informatie Bouwstenen. Een informatiestandaard betreft een verzameling afspraken die er voor moeten zorgen dat de zorginformatie met de juiste kwaliteit kan worden vastgelegd, opgevraagd, gedeeld, uitgewisseld en overgedragen. GGZ Nederland zou hier het voortouw in kunnen nemen en dit samen met Stichting Koppeltaal verder vorm kunnen geven. Pagina 5 van 5