Vorige week heb ik geschreven over de uitdagende planning van DOT. Als alles om je heen schuift is het moeilijk zelf een planning op te stellen. Deze week is de tijd om me te verbazen over alle verder openstaande onzekerheden en hoe daarmee om te gaan. Bijvoorbeeld de hashcode
Het goede nieuws is toch nog dat de landelijke grouper door de NZa niet verplicht wordt gesteld. De zorgverzekeraars zijn natuurlijk nog wel aan het lobbyen om dit alsnog geregeld te krijgen, maar ik heb goede hoop dat dit niet doorgaat. Wat precies de gevolgen zijn van dit besluit is niet helemaal te overzien, maar het is op alle vingers uit te rekenen dat het voor ons ziekenhuizen handig is: verlaging administratieve lasten (en dat is precies de bedoeling van DOT).
Want als een landelijke grouper niet verplicht wordt gesteld kan ook een hash code niet verplicht worden gesteld. De hashcode is een beveiligingssleutel waardoor het niet mogeljk is om met de resultaten uit de grouper te rommelen zonder dat het opvalt. Lijkt een leuke beveiliging, maar dat is natuurlijk niet zo. Ik ben niet zo’n rommelaar (kan ook niet met mijn rol bij mijn type bedrijf) maar iedereen kan bedenken dat áls je wilt rommelen met je registratie (teneinde een hoger inkomsten te genereren) je dat niet hoeft te doen aan het eind van de keten. Rommelen met het resultaat van de grouper kan in bepaalde gevallen ongetwijfeld extra geld opleveren, maar als je inspanning tegen opbrengst afzet is dit het meest onbenullige moment voor fraude. Dat kan dan veel makkelijker in een veel eerder stadium.
Het grote voordeel van het wegvallen van de hashcode is het verminderen van de administratieve rompslomp. Stel dat er een fout gemaakt is in het administratieve proces, en daar komen we pas achter als de rekening al verstuurd is naar de zorgverzekeraar. Dan hangt het van de aarde van de fout af of het financieel interessant is om het proces terug te draaien, en het hangt van het type fout af of het inhoudelijk interessant is om het hele proces terug te draaien.
Terugdraaien van een proces betekent crediteren van een inmiddels betaalde rekening. Subtraject heropenen, registratiefouten verbeteren, subtraject afsluiten, opnieuw grouperen, en opnieuw naar verzekeraar en DIS. Als er sprake is van het gebruik van een hashcode moet dit hele proces bij de kleinste fout worden uitgevoerd. Als we niet gebruik makenvan een hashcode hoeven kleine fouten niet aangepast te worden. Het is dan wel verstandig met de verzekeraar af te spreken wat we wel aanpassen en wat niet.
Maar het proces naar de verzekeraar is nog niet eens zo moeilijk. De gegevens die gebruikt worden om de hashcode vorm te geven die naar de verzekeraar gaat gaan alleen over voor de factuur relevante gegevens. Dus als daar fouten in zitten is het voor alle betrokkenen relevant die aan te passen. Veel erger is de DIS: die willen heel precies tot op alle irrelevante details alles weten. De hashsleutel voor de DIS is zo uitgebreid dat elke fout onmiddelijk wordt afgestraft. En dat kan betekenen dat als er een fout zit in irrelevante gegevens (postcode van de verzekerde was fout) eerst alles naar de verzekeraar moet (zie proces boven) om vervolgens de DIT te behagen. Hoe dit loopt zonder hash kan ik nog niet overzien, maar het wordt beslist minder lastig.
Wat denkt u trouwens van de factuur op papier? Dat wil niemand maar komt nog voor. Moet een hashcode onderaan worden afgedrukt? En gaat de verzekeraar dit overtypen in hun systeem om te controleren of het juist is? Het gerucht gaat dat de hashcode 200 tekens lang is? Zo”n factuur wil ik wel eens op papier zien.
