Natuurlijk is de ziekenhuisomzet 2011 gestegen

Verbazing alom dat de omzet van de zorg het afgelopen jaar zo snel is gestegen (http://bit.ly/sjMwGc). Je kan je over alles wel verbazen.

Een van de projecten dat het afgelopen jaar in elk ziekenhuis in Nederland is uitgevoerd is het project BROO: basisregistratie op orde. Omdat het voor de DBC 2.0 (het nieuwe systeem dat vanaf 1 januari live gaat) van nog groter belang is om alle geleverde zorg ook goed vast te leggen, is de kwaliteit van de registratie van de zorg enorm toegenomen.

Veel van de geleverde zorg werd vroeger niet in de administratieve systemen vastgelegd (hopelijk wel in het medisch dossier) omdat dit voor de DBC (of eigenlijk, de FB parameters) toch niet (echt) uitmaakte.
Omdat dit straks wel van belang is is de registratie verbeterd.

Dan is het toch ook niet zo verwonderlijk dat het aantal DBC’s is gestegen. Ons ziekenhuis is ook bezig geweest met het verbeteren van de administratie. Met als logisch gevolg meer DBC’s.

Om daar nu verbaasd over te zijn klinkt wel gek. Dat hadden we zien aankomen.

Lachen om de hash code

Om zeker te weten dat wij als ziekenhuizen straks de Grouper echt gaan gebruiken moeten wij hash codes gaan meesturen. Op Wikipedia staat een bruikbare uitleg van de hash.

Een en ander is een nogal omslachtige behandeling om vast te stellen dat wij als ziekenhuizen niet frauderen. En dat terwijl het moment van factureren een heel onhandig moment van frauderen. Je kan met fraude meer winst maken als je dat eerder in het administratieve proces doet. Maar dit alles terzijde (het lijkt me wijs hier niet verder op in te gaan :-)

Maar nu moeten we die hashcode ook op een papieren factuur gaan zetten. Dus als wij een rekening direct naar een patiënt sturen (in tegenstelling tot wat gebruikelijker is direct naar de zorgverzekeraar) dan moet op deze factuur ook de hashcode die wij van de grouper hebben ontvangen.

Dat ziet er ongeveer zo uit:

Qwertgbnmkghajlkfsljf824uorehjljnluqoprijp0plajdnlanlwjq092iu34-0825-uy7309y298u42ejwfhankjsdhfajshQwertgbnmkghajlkfsljf824uorehjljnluqoprijp0plajdnlanlwjq092iu34-0825-uy7309y298u4 2ejwfhankjsdhfajsh

ergens onder op een factuur.

Dit lijkt me niet helpen aan de verbetering van de Nederlandse gezondheidszorg. Waar staat DOT ook weer voor?

En het grootste probleem: wij krijgen de vragen van de patiënten hierover, niet de zorgverzekeraars.

Kijk, ik verkneukel me natuurlijk wel bij het idee alleen al dat iemand bij een zorgverzekeraar (een nog aan te stellen stafmedewerker hashcode) dit gaat overtypen in hun hashcode controlemodule. Alleen mag zo iemand geen typefouten maken (daar wordt ie ook op aangenomen :-) want anders wordt een factuur afgewezen vanwege een typefout, en moet mijn controlemedewerker hashcodes dat weer gaan uitzoeken.

Ik stel dus voor dat we nadenken over een oplossing. Bijvoorbeeld dat we een eigen database maken waar we hashcodes gaan opslaan, met het factuurnummer als sleutel. Ook een onzinnige actie hoor, maar als dan een ZV bij ons komt vragen naar de hashcode bij een bepaalde factuur kunnen we die (in de mail?) opsturen.

Al typend vind ik het steeds leuker worden, overigens ook steeds onzinniger. De ZV willen weten of wij de grouper geraadpleegd hebben en ze denken dat dit alleen maar kan door een hashcode op papier mee te sturen. Wellicht zijn er ook andere, meer serieuze mogelijkheden. Ik hoor ze graag.

DOTalk: ICD-10 of DBC diagnoses

Een van mijn opdrachten is nadenken over de invoering van ICD-10 in Nederland, in relatie tot de invoer van DOT, omdat er veel raakvlakken tussen de twee verandertrajecten zijn. Vanuit die vraag doe ik mee met de overige projectleiders van pilotziekenhuizen aan het landelijk project.

Er zijn nog heel veel vragen rond de invoer van ICD-10 in Nederland. Die zal ik hier niet meteen allemaal stellen. Ik wil me nu concentreren op de relatie met ICD-10 met de DOT Grouper.

Een van de uitgangspunten van het DOT programma is dat er sprake gaat zijn van een eenmalige (zorg) registratie aan de bron. Dat komt wat betreft de diagnose neer op een eenmalige registratie van de diagnose door de dokter in ICD-10 codering. En er komt dan een moment dat er geen sprake meer is van een eigen ziekenhuis diagnose code, of een DBC diagnose code, maar elke dokter legt de gestelde diagnose vast in ICD-10 codes.

Ik wil de dokter niet belasten met dubbel werk. Enerzijds omdat dit de genoemde doelstelling van eenmalige registratie onderuit haalt, anderszijds omdat dokters voor dubbel werk niet echt te motiveren zijn (en terecht). Dat betekent wat mij betreft, dat als ICD-10 ingevoerd wordt op het moment dat ook DOT wordt ingevoerd (beiden per 1 januari 2011) we ICD-10 diagnoses aan kunnen bieden aan de Grouper.

Ik heb begrepen dat dit voorlopig niet mogelijk is. DBC-Onderhoud komt wel met een vertaaltabel zodat wij als ziekenhuizen zelf voor de vertaling kunnen zorgen. Dat betekent wel dat 100 ziekenhuizen weer een extra tabel moeten opnemen, en een extra conversie, met alle ruimte voor fouten. Die elk ziekenhuis mag maken. Ik zie hier ruimte voor een verbetering: laat DBC-Onderhoud zelf voor de conversie zorgen: geef de ziekenhuizen de ruimte om diagnoses zowel in ICD-10 als in DBC diagnose codes aan te leveren. Dat zou de ziekenhuizen én de ICD-10 introductie echt vooruit helpen.

DOTalk: turbulentie

Het stormt in DOT land. Waar in het ene ziekenhuis het DOT plan van aanpak wordt vastgesteld, met als doel er als geheel ziekenhuis er beter van te worden, wordt in een ander ziekenhuis alle activiteiten gestopt want DOT gaat toch niet door.

DOT, ofwel DBC’s op weg naar transparantie, is het DBC verbeterprogramma voor de ziekenhuizen. Met nog heel veel te doen, heel veel onzekerheden en dus risico’s en heel veel belanghebbenden.

En van deze combinatie worden veel mensen zenuwachtig. En omdat het vrij menselijk is om tegen veranderingen te zijn (elke verandering kost altijd moeite, energie, extra inspanning en flexibiliteit) gaan er stemmen op om met DOT te stoppen. Of in ieder geval voorlopig.

En dat zou vreselijk jammer zijn. Want er zit al enorm veel tijd van enorm veel mensen in de verbetering van de DBC systematiek die met DOT zou worden ingevoerd.

Hoewel er heus nog veel onduidelijkheden zijn, hebben de wetenschappelijke verenigingen samen met DBC-Onderhoud en ongetwijfeld nog veel meer belanghebbenden tijd en energie gestoken in de verbetering van de DBC systematiek. Althans, zo is het mij wijs gemaakt en ik geloof dat.

Fouten die nu nog in de DBC’s zitten zijn eruit gehaald, nieuwe inzichten zijn toegevoegd en onhandige registratieregels zijn gelijkgetrokken.

Maar wil dit allemaal gaan vliegen, dan moeten we wel de overstap maken naar de nieuwe zorgproducten. We stappen af van het principe van valideren, en gaan afleiden met behulp van de Grouper. En nemen afscheid van de DBC.

En veel is nog uit te zoeken  maar uiteindelijk leidt het tot een betere systematiek. Zie ook het interview met Hans den Hollander, bestuurslid van de NVZ en directeur bedrijfsvoering  van het Diaconessenhuis in Leiden, hierover.

Maar dit gaat alleen maar werken als we de weg tot het doel aflopen. En niet halverwege gaan dwalen, beetje links, beetje rechts, stukje terug, paar passen voorwaarts, even halt houden en zo voort. Dat haalt de vaart eruit, introduceert nog meer onduidelijkheid, en iedereen die vol enthousiasme bezig was stopt ook maar, want aan een dood paard trekken levert niemand iets op.

Heb ik belang bij DOT, dat ik zo graag door wil?

Ja, maar niet echt. Natuurlijk vind ik het jammer als alle inspanningen die wij voor de NVZ hebben gedaan voor niets waren. Maar mijn salaris heb ik toch gekregen, en het hoort bij het leven van een extern adviseur dat je soms een project doet dat uiteindelijk de eindstreep niet haalt (gebeurt ongetwijfeld ook bij interne medewerkers). Mijn huidige projecten gaan gewoon door. De ziekenhuizen waar ik werk hebben DOT aangegrepen om hun bedrijfsprocessen te verbeteren. Als DOT stopt is dat nog steeds nuttig. Wellicht komt de prioriteit iets anders te liggen.

Maar ik zie ruime mogelijkheden voor verbetering van de administraties in ziekenhuizen waar DOT een enorme boost aan geeft. En iedereen die in de zorg werkt weet dat hier nog veel winst te halen is. Turbulentie om de turbulentie heeft niemand wat aan. Laten we er een succes van maken.

DOTalk: ICD-10 vanaf 2011

1 januari 2011 wordt een gedenkwaardige dag. Niet alleen is dat het moment dat de Nederlandse ziekenhuizen gaan werken met zorgproducten, het is ook het moment dat wij in Nederland de ICD-10 codering ingevoerd willen hebben.

Dit is een bijzondere samenloop van hoogtepunten die ongetwijfeld anders bedoeld is geweest. Oorspronkelijk stond de invoerdatum van DOT gepland voor 1 januari 2009. Omdat een en ander toch ingewikkelder was dan voorzien, is deze datum met twee jaar opgeschoven. Waarmee deze invoerdatum opeens samenkomt met die van ICD-10.

De international Statistical Classification of Diseases and Related Health Problems is de opvolger van ICD-9. Beide codestelstels zijn iets geheel anders dan de D(iagnose) code uit de DBC. In Nederland wordt nu door een dokter een DBC getypeerd met een Nederlands Diagnose stelsel, en na afloop van een medisch traject coderen medisch codeurs in een ziekenhuis alles om naar het internationale codestelsel ICD-9.

De doelstelling van de landelijke invoer van ICD-10 is om alle medisch codeurs bij te scholen op het nieuwe codestelsel zodat vanaf 1 januari 2011 aan de achterkant niet meer ICD-9 maar ICD-10 wordt gecodeerd.

Tegelijkertijd is de doelstelling van het DOT project om te komen tot eenmalige registratie aan de bron, te gebruiken voor meer doeleinden. En dat is dus wat anders dan de dokter te laten coderen in stelsel 1 en vervolgens iemand anders te laten vertalen naar stelsel 2.

Ofwel, wat we eigenlijk willen is niet alleen de invoer van DOT, met nieuwe zorgactiviteiten (per afgelopen 1 juli), nieuwe zorgproducten (in plaats van DBC’s) en nieuwe tarieven, maar ook een nieuw codestelsel voor het vastleggen van de diagnoses. 2010 wordt een bijzonder jaar.

DOTalk – pregrouperen

Ik krijg regelmatig vragen over het begrip pre-grouperen. Dat dit toch wel gewenst is en of de softwareleverancier van het ziekenhuis (dat de vraag stelt) dit mogelijk maakt.

Voor iedereen buiten de ziekenhuiswereld, of zelfs voor iederin in de zh-wereld maar nog niet bezig met de nieuwe DBC wordt het verhaal hierna buitengewoon abracadabra. Niet verder lezen zou ik zeggen.

Er is geen exacte door iedereen geaccepteerde uitleg van pre-grouperen, maar een algemeen beeld is er wel: door ziekenhuizen wordt het aanleveren aan de Grouper gezien als het aanleveren van ziekenhuisinformatie aan een black-box. Zonder dat je als aanleverende partij weet wat de Grouper oplevert. Daarom willen ziekenhuizen pre-grouperen om eerst zelf te bepalen wat de Grouper zou moeten opleveren, voordat ziekenhuisinformatie ‘voor het echt’ aan de Grouper (van DBC-Onderhoud) wordt aangeboden.

Je zou dit kunnen lezen als het in je eigen ziekenhuis nabouwen van de landelijke Grouper. Dan bepaal je met een eigen kopie van landelijke software welk zorgproduct straks (ook) door de Grouper wordt afgeleid.

Dit is om meer redenen geen goed idee:

1) het is zonde van de investering om de landelijke afleiding voor lokaal gebruik na te laten bouwen;

2) als de landelijke Grouper een ander zorgproduct oplevert dan de eigen lokale Grouper: wie heeft er dan gelijk?

3) als de landelijke Grouper wel hetzelfde oplevert als de lokale Grouper, is bewezen dat de beide software pakketten hetzelfde werken (maar wat wil je in je ziekenhuis met deze informatie?)

4) als de registratie in het ziekenhuis onvolledig is, levert een eigen grouper een te goedkoop zorgproduct op, en de landelijke grouper ook. Dus pregrouperen is geen controle op volledigheid van de registratie.

Een tweede invulling van het begrip pre-grouperen is het vooraf (voor het moment van declareren) opsturen van ziekenhuis informatie naar de officiele Grouper. Om ‘alvast’ te bekijken wat de registratie tot nu toe oplevert. Het verschil tussen ‘grouperen’ en ‘pre-grouperen’ vervaagt dan omdat in beide gevallen de landelijke grouper wordt aangeroepen. In het ene geval ter informatie, in het andere geval in het kader van het declaratieproces. Met moeite kan ik me voorstellen dat hier in een ziekenhuis behoefte aan is. De vraag is of de ziekenhuis infrastructuur er op gericht moet zijn om op elk moment in een zorgproces ook even de Grouper aan te kunnen roepen. Om te kijken wat voor zorgproduct wordt afgeleid op basis van de registratie tot nu toe.

Waar het echt om gaat is de controle van volledigheid van de registratie binnen het ziekenhuis. Vrijwel zonder uitzondering is elk ziekenhuis van mening dat de eigen (basis)registratie beter kan, ofwel nu nog onvolledig is. En dat betekent dat de Grouper een onvolledig (zorg)product zal afleiden. Immers, als niet alles wat aan activiteiten bij een patiënt is uitgevoerd ook is vastgelegd, kan een Grouper nooit het juiste product vaststellen.

Het issue is dus niet of we moeten pre-grouperen of niet, maar hoe we controleren dat de interne ziekenhuis registratie volledig is. Pre-grouperen is daar niet de methode voor. Ik kom hierop terug.

DOTalk 19 juli

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.

DOTalk 12 juli

Deze week heb ik het plan van aanpak DOT besproken in de stuurgroep. Het plan is natuurlijk gebaseerd op het standaard plan van aanpak dat wij begin dit jaar voor de ziekenhuizen hebben opgeleverd. Maar inmiddels weten we wel veel meer. Vandaag richt ik me op de planning.

Veel deadlines doorgeschoven ten opzichte van een half jaar geleden, behalve die ene: de datum dat we op basis van DOT gaan declareren is nog steeds 1 januari 2011. Maar ondertussen is de grouper nog steeds niet klaar, zijn de registratieregels nog in concept, wordt het moment dat de normtijden en tarieven worden opgeleverd beetje bij beetje uitgesteld en ontbreekt een ketentest voor de nieuwe declaratiestandaard in het geheel in de masterplanning van de landelijke projectleider. Een planning opstellen met deze gegevens in het achterhoofd is daarom best lastig.

En toch kan het wel. Ik ben uitgegaan van data die ik als deadline beschouw voor een succesvolle introductie van DOT: • 1 oktober 2009 moet de grouper geheel gereed zijn om te gaan schaduwdraaien. Dat betekent dat voor die tijd de koploperziekenhuizen al hebben getest met hun softwareleveranciers en dat de eerste fouten er al uit zijn. • 1 januari 2010 moeten de tarieven bekend zijn zodat we kunnen gaan rondrekenen: zorgproducten vs DBCs. Hierna volgen nog meer deadlines maar dit wordt al moeilijk genoeg.

De vraag is natuurlijk waarom ik zo nodig nu al wil gaan schaduwdraaien. Dat kan toch volgende zomer ook wel. NEE, natuurlijk niet. We moeten met alle ziekenhuizen ervaring gaan opdoen met de kwaliteit van de basisregistratie en vervolgens afgeleide zorgproducten naast DBCs gaan leggen. Want als we dat niet doen wordt 2011 wel een hel grote gok. En ongetwijfeld komt er wel een soort van vangnet, maar laten we eerlijk zijn: dat is natuurlijk geen optie voor de zelfbewuste ziekenhuismanager.

 

DOT Planning volgens Caj Oosters

DOT Planning volgens Caj Oosters

DOTalk 5 juli

De eerste steen is gelegd. Op 1 juli is de nieuwe zorgactiviteitentabel life gegaan. Voor de ziekenhuizen een hele prestatie. Natuurlijk is het niet de eerste keer dat er veranderingen optreden in de CTG codes. Dat gebeurt regelmatig. Maar zo’n grote wijziging, die zo laat is opgeleverd, waarvoor de validatiemodule halsoverkop nog moest worden aangepast vroeg toch een forse investering. In het ziekenhuis waar ik projectleider ben heeft het projectteam de inspanning becijferd op 75 dagen. En dan maken wij nog niet eens gebruik van de CBV tabellen. Die pas 3 weken van te voren werden opgeleverd. Waarmee het tegen alle verwachtingen in pas echt complex werd.

Of die 75 dagen gemiddeld is weet ik (maar hoor ik graag van de lezers). Als we uitgaan van 100 ziekenhuizen in Nederland, die allemaal 75 dagen nodig hadden was de eerste investering in DOT 7500 dagen. Tegen een makkelijk rekentarief (intern en extern) van 500 euro per dag was dat nog geen 4 miljoen euro. En DOT moet nog beginnen.

DOTalk inleiding

Voor mijn werk als senior manager in de gezondheidszorg bij Deloitte ben ik nu druk bezig met het programma DOT. Dit staat voor DBCs op weg naar Transparantie. In verschillende ziekenhuizen ben ik projectleider voor de invoering, en regelmatig word ik gevraagd over DOT te adviseren of te presenteren. Tegelijkertijd is er in den lande veel rumoer over DOT: “Moeten we meedoen?”,  ”Wat betekent het voor ons?”,  ”Worden we er beter van?”,  ”Het gaat toch niet door.” zijn voorbeelden. Ik kom in mijn werk leuke, opmerkelijke, vervelende, grappige en andere zaken tegen die ik graag wil delen. Daarvoor is mijn blog natuurlijk heel geschikt. Of ik dat volhoud moet blijken. Helemaal als ook de vakantieperiode nog eens aanbreekt. Maar wie weet.

Als ik ook reacties krijg op wat ik te melden heb is zowiezo de kans dat ik blijf schrijven groter. Een discussie is altijd nog leuker dan alleen je eigen belevenissen opschrijven.