Ervaringen van een systeemontwikkelaar in de jeugdzorg

Met veel plezier hebben wij Jeunesse ontwikkeld en er ligt nu een prachtig pakket, dat de administratie van de hele jeugdzorg dekt.  Alle berichten worden nu voor 100% ondersteund en een zorgaanbieder kan met minimale inspanning een maximum aan resultaat boeken.

Tijdens de ontwikkeling ervan kregen we wel te maken met een aantal hindernissen in de toepassing van de specificaties. Enkele voorbeelden.

Gemeentelijke herindeling per 1 januari 2016

Vanaf 1-1-2016 zijn er weer gemeentes bijgekomen en verdwenen. De vraag rees wat je hiermee moest doen in je systeem. Moeten lopende zorgtrajecten worden omgezet naar een nieuwe gemeentecode of niet? De vraag gesteld en het antwoord was: Tja, gemeentes weten het ook nog niet precies en in ieder geval zijn ze er niet klaar voor. Het zou kunnen dat dit ergens in de loop van 2016 zijn beslag krijgt. Lijkt een kleinigheid, maar het vormt de ruggengraat  van het berichtenverkeer, want met een onjuiste gemeentecode wordt het bericht niet bezorgd.

Communicatie

Elektronisch berichten uitwisselen betekent naar onze mening dat je op eenvoudige wijze in staat bent wederzijds gegevens aan elkaar te knopen. Dit vereist echter wel dat je aan beide kanten een 'haakje' en een 'oogje' moet hebben om dit voor elkaar te krijgen. Helaas alle specificaties zijn er op gericht dat er aan gemeentezijde haakjes én oogjes aanwezig zijn, maar men heeft niet stilgestaan dat dit ook het geval moet zijn aan de zorgaanbiederskant. Dus als de zorgaanbieder bijvoorbeeld een 'verzoek zorgtoewijzing'  stuurt, is er geen gegeven in de zorgtoewijzing aanwezig, dat aangeeft welke zorgtoewijzing bij welk verzoek hoort. Natuurlijk is er een BSN beschikbaar, maar dat is lang niet altijd niet voldoende om te kunnen matchen.

Maandelijks of per 4 weken declareren

In de specificaties wordt beschreven dat er maandelijks of per weken moet worden gedeclareerd. Met alle respect maar dit veroorzaakt een onwerkbare situatie aan de zijde van de zorgaanbieder. Dit betekent dat je per gemeente moet gaan vastleggen welke frequentie moet worden toegepast en als je pech hebt lopen ook de 4 wekelijkse periodes niet synchroon.

Codetabellen

Het systeem staat stijf van de codetabellen. Op zich niets mis mee, maar de diverse codetabellen tussen Vektis, ZIN en het CBS zijn niet tot matig op elkaar afgestemd. De meeste schrijnende is wel de code 'beëindigen zorg'.  Deze matchen niet en zijn bij elke instantie anders. Dit betekent dus dat een zorgaanbieder in feite 3 keer moet aangeven met welke reden de zorg is beëindigd.

Een ander voorbeeld betreft de eenheid waarin de zorg wordt verleend (bijvoorbeeld: uren, dagdelen). ZIN en Vektis hebben besloten hiervoor beide een eigen tabel te hanteren, welke maar op één code verschilt. Bij het declareren moet je dus een omzetting doen van die ene code naar de andere code. Argument: Ze hebben niet dezelfde betekenis en dus verschillen ze van elkaar. Volgens ons is er geen gebruiker te vinden die dit begrijpt.

Codetabellen zijn bijzonder handig om informatie te structureren. Ze worden pas echt handig als wijzigingen heel systematisch worden vastgelegd. Dus geen spreadsheet, waarin met bv. rood staat aangegeven 'Nieuw' o.i.d. Maar alle codes voorzien van een start- en  einddatum, zodat de ontwikkelaar alleen de gegevens opnieuw hoeft te laden en klaar is kees.

Conclusie

Elektronisch berichtenverkeer tussen zoveel partijen wordt pas een succes als er zeer gestructureerde en duidelijke keuzes worden gemaakt en er wordt samengewerkt tussen alle partijen. Het moet toch tot nadenken stemmen dat er nog geen gemeente in Nederland te vinden is die al deze processen netjes op orde heeft en anderzijds dat je leest dat zorgaanbieders hulpverleners ontslaan en extra medewerkers in de administratie aantrekken.