Worstelingen met een hybride 3D-applicatielandschap in het Sociaal Domein
Geschreven door Tim Hartog op 16-06-2017

Ditmaal een blog uit de oude doos, maar nog zo actueel... Eén jaar geleden schreven we onderstaande blog. We gaven hierin, gebaseerd op onze ervaringen, weer welke informatiebehoefte tussen front- en backoffices in het Sociaal Domein gewenst is, indien van meerdere ondersteunende applicaties gebruik wordt gemaakt.

Veel gemeenten hebben met de komst van de 3D hun applicatielandschap opgezet met een reeds gebruikte backoffice-applicatie in combinatie met een nieuwe frontoffice-applicatie (ook wel: regiesysteem). Doordat de markt van regiesystemen nog volop in ontwikkeling was, zijn vaak kortdurende contracten met leveranciers gesloten. Voor veel gemeenten is het nu de tijd (gewenst of verplicht) opnieuw te oriënteren en te contracteren.

De afgelopen periode worden we veel benaderd door gemeenten die onze ondersteuning wensen bij het vertalen van hun organisatiekoers met betrekking tot het Sociaal Domein naar een bijpassende duurzame informatiestrategie. Om te duiden welke behoefte er zou kunnen bestaan, komt onderstaande blogpost nog vaak uit de tas. We hopen met herplaatsing van deze blog bij te dragen aan het vraagstuk van gemeenten die zich ook in deze situatie bevinden.

Een kritische blik doet ons bekennen dat de blog toentertijd wel heel '2D' is opgesteld en onvoldoende recht doet aan laatste D met betrekking tot Participatie. Onderstaande is onverminderd bruikbaar, maar wanneer Participatie, en vaak ook Schuldhulpverlening, ook bezien worden, maakt dit de situatie meer complex. Hoe zorg je ervoor dat een regiesysteem ook de informatiebehoefte voor deze domeinen afdekt? En wat is de toegevoegde waarde? In onze recente opdrachten buigen we ons met name over deze vraagstukken. We houden u geïnformeerd...

De trein van de 3 Decentralisaties dendert voort. Gemeenten hebben de continuatie van zorg aan hun cliënten en financiering van zorgaanbieders voorrang gegeven en grotendeels veilig gesteld. Gemeenten die wij ondersteunen hebben nu verdere optimalisatie van de dienstverlening en bedrijfsvoering bovenaan hun verlanglijstje staan.

In veel gemeenten treffen wij de aanwezigheid van een hybride applicatielandschap aan ter ondersteuning van de domeinen Participatie, WMO en Jeugdzorg. Een logisch gevolg van het feit dat er 2 jaar geleden weinig aanbod was vanuit de traditionele leveranciers van het Sociaal Domein voor adequate ondersteuning van de zogenaamde frontoffices 3D, vaak organisatorisch vormgegeven in Centra voor Jeugd en Gezin (CJG’s) en Sociale Wijkteams (SWT’s). Veel nieuwe spelers hebben toen met een innovatief pioniersproduct de markt betreden.

Deze automatiseringsoplossingen voor de voorkant hebben inmiddels grote ontwikkelingen doorgemaakt. Met name vanuit het perspectief dienstverlening hebben deze systemen zich ontwikkeld tot volwaardige samenwerkingsomgevingen waarin gezamenlijk een klantbeeld kan worden gevormd, informatie kan worden gedeeld en een onderling afgestemd zorgpakket aan de cliënt en zijn  / haar gezin kan worden aangeboden.

De ketenautomatisering tussen een traditioneel backofficesysteem, waarbinnen alle drie de D’s te registreren en financieel af te wikkelen zijn, en deze frontofficesystemen is echter de kwetsbare schakel. Wij treffen veel suboptimale situaties aan waarbij gegevens van de frontoffice naar de backoffice en vice versa worden uitgewisseld. Denk hierbij aan papieren stromen, e-mail, telefonisch en persoonlijk contact. Een zeer arbeidsintensieve, diffuse en kwetsbare procesgang waar veel gemeenten vanaf willen.

Alle gemeenten, die in een dergelijke hybride situatie zitten, geven aan grote behoefte te hebben aan een koppeling waarmee front- en backofficeprocessen beter op elkaar aansluiten, bij voorkeur natuurlijk geautomatiseerd wat betreft de benodigde overdracht van gegevens. Maar welke gegevens betreft het dan? Wij hebben onze ervaringen van meerdere gemeenten gebundeld in de volgende globale behoefte:

Van frontoffice- naar backoffice-applicatie:

• Indicatiegegevens voor maatwerkvoorzieningen, bestaande uit ten minste: BSN, aanbieder, product, volume, eenheid, frequentie en geplande start- en einddatum.

Let op: vaak wordt het delen van klantbeeldinformatie ook genoemd. De backoffice heeft deze echter in vrijwel alle gevallen niet nodig voor hun verwerking van zaken. Privacy-technisch is deze uitwisseling van informatie vaak wettelijk niet toegestaan.

Van backoffice- naar frontoffice-applicatie:

• De backoffice ontvangt vaak de start- en stopberichten van de aanbieder op basis van het berichtenverkeer iWMO en iJW. De frontoffice heeft behoefte aan deze informatie om te weten of en wanneer zorg is gestart of beëindigd met reden;
• Het ontvangen en afhandelen van een 315-bericht (verzoek tot toewijzing) maakt onderdeel uit van het berichtenverkeer iWMO en iJW. Dit is echter typisch informatie die men op de frontoffice nodig heeft om een indicatiebesluit wel of niet te verlenen;
• Front- en backofficesystemen gebruiken een product-diensten-catalogus (PDC) om een juiste selectie te kunnen maken uit het zorgaanbod. Men heeft behoefte aan één PDC, dan wel een synchronisatie tussen PDC’s, om ketenproblemen te voorkomen;
• Uitnutting van geïndiceerde zorg wordt meestal enkel in een backofficesysteem vastgelegd. Voor het toekennen van nieuwe zorg en herindicering is deze uitnutting van grote waarde om de specifieke zorgbehoeften van een cliënt te beoordelen;
• Vaak is aan het contractmanagement met aanbieders in de backofficeorganisatie vormgegeven. De kwalitatieve beoordeling over het presteren van aanbieders is echter van grote waarde voor de frontoffice om de beste zorg in te kunnen zetten;
• Ook wordt door het contractmanagement ook zicht gehouden op wachtlijstontwikkelingen bij aanbieders. De frontoffice heeft behoefte aan deze informatie om cliënten niet onnodig te laten wachten en tijdige zorg aan te bieden.

Let op: vaak wordt het delen van financiële informatie ook genoemd. De frontoffice heeft deze echter nauwelijks nodig voor hun werkzaamheden. Privacy-technisch is deze uitwisseling toegestaan maar van weinig toegevoegde waarde (over-informatisering).

Vaak wordt – bij gebrek aan een gedetailleerd beeld van de eigen behoefte - het standpunt ingenomen dat alle informatie uitgewisseld dient te worden. Informatie-technisch is dit echter een onlogische keuze. Indien de applicaties immers volledige informatie-overlap zouden vertonen is de logische gevolgtrekking één van de applicaties zo spoedig mogelijk uit te faseren en met één van beide applicaties door te gaan.

Met name verschil in perspectief tussen een front- en een backoffice-applicatie maakt dat de werelden dienstverlening versus bedrijfsvoering vrij lastig in één systeem onder te brengen zijn. Inmiddels komen steeds meer integrale systemen op de markt die een modulaire opbouw hebben om zowel de front- als de backoffice te ondersteunen. Echter: de best-of-breed gedachte zal de komende jaren nog wel het boventij voeren omdat veel gemeenten nog niet bereid zijn concessies te doen op kwaliteit en functionaliteit ten gunste van integraliteit. Wij vermoeden dat dat de komende jaren steeds meer zal veranderen.

Ook aanbieders hebben natuurlijk besef van deze situatie en bieden steeds meer koppelingsvormen om de keten te automatiseren. Vaak betreft het dan echter één-richting-koppelingen met de focus om indicatiegegevens van de front- naar de backoffice te distribueren. Ontsluiting van backoffice-informatie in frontofficesystemen staat nog in de kinderschoenen. En let op: er is een gebrek aan standaarden. Verdiep je aldus goed – ten minste functioneel en bij voorkeur technisch – voordat je dit speelveld betreedt.

Wilt u eens van gedachten wisselen over uw “knip” tussen de frontoffice en backoffice rondom de 3D: benadert u ons gerust om vrijblijvend te bekijken wat we voor elkaar zouden kunnen betekenen.

Dit laatste aanbod staat natuurlijk ook vandaag nog open....