Uitbreiding DBC Systeem Specificaties en toelichting bij de registratie, validatie en declaratie

Transcriptie

1 Uitbreiding DBC Systeem 2007 Specificaties en toelichting bij de registratie, validatie en declaratie Utrecht, 10 juli 2006

2 Inhoudsopgave Uitbreiding DBC Systeem Inhoudsopgave Inleiding Doelstelling Aanpassingen per Aanpassing Typeringslijsten van Urologie Implementatie van de CTG beleidsregel of het voorkomen van uitval van verrichtingen Oplossing MDL problematiek Opnemen van indicatie machtiging vereist in de Eindklassetabel Kleinere tabel aanpassingen ter bevordering van de consistentie Sleutelgegevens DBC-tabellen Inleiding Achtergrond Tegen de achtergrond van de door de Branche- en Onderhoudspartijen samen met VWS genomen besluiten over de verbeteringen van de DBC Methodiek die met ingang van 1 januari of 1 juli 2007 kunnen worden ingevoerd heeft een specificatieronde plaatsgevonden. Vanuit de partijen is een aantal voorstellen gedaan waarvan na ampel overleg een viertal is overgebleven voor invoering per 1 januari 2007 en die consequenties hebben voor de ICT systemen. Hiervoor worden in deze notitie de functionele specificaties voor de ICT aanpassingen vastgelegd. Deze zijn ontstaan na een brede toetsing van de verschillende aspecten van de onderhavige voorstellen. Daarnaast zijn enkele tabel aanpassingen doorgevoerd die de consistentie binnen het totaal van de tabellen verbeteren. Proces In de periode van half mei 2006 tot begin juni 2006 zijn in een aantal sessies de ICT consequenties door genomen met de ICT deskundigen. Het voorliggende voorstel is als resultaat van die besprekingen voorgelegd aan de volgende gebruikers groepen: 1. de Expert gebruikersgroep van DBC Onderhoud op dinsdag 14 Juni 2. het ICT Overleg op donderdag 16 juni. 3. het Afstemmingsoverleg van de Onderhoudspartijen op vrijdag 17 juni. 4. het Branche Overleg op donderdag 22 juni In deze notitie zijn de commentaren van dit overleg verwerkt en aan het bestuur van DBC Onderhoud voorgelegd. Besluitvorming 1. De definitieve versie is door het bestuur van DBC Onderhoud in de vergadering van 5 juli 2006 vastgesteld. 2. Na overleg met VWS op 10 juli 2006 is besloten de vastgestelde specificaties te publiceren op de website van DBC-Onderhoud. 2

3 3. Na de bestuursvergadering van het CTG ZA io op 16 september 2006 zullen de specificaties worden gepubliceerd als onderdeel van de betreffende CTG beleidsregel. 2. Doelstelling De doelstelling van deze notitie is functionele specificaties te bieden van de verbeter voorstellen die geagendeerd staan voor In het afstemmingsproces dat aan de vaststelling vooraf is gegaan, is vastgesteld dat elk van de voorgestelde oplossing technisch realiseerbaar is en invoering van deze software aanpassingen voor operationeel gebruik vanaf 1 jan 2007 haalbaar is. 3. Aanpassingen per Aanpassing Typeringslijsten van Urologie Aanleiding In de afgelopen tijd hebben er op de typeringslijsten van een aantal specialismen mutaties plaatsgevonden in de diagnosecodering, daarbij is gebleken dat het aantal posities voor sommige specialismen uitbreiding niet meer toestond. Dit wordt veroorzaakt doordat enerzijds diagnoses worden toegevoegd en anderzijds eenmaal obsoleet geworden codes niet opnieuw kunnen worden gebruikt. Als er al ruimte voor uitbreiding bestaat, gaat het gebruik daarvan vaak ten koste van het logische verband tussen de diagnoses (nieuwe diagnoses krijgen een code uit een andere code reeks). Voor het specialisme Urologie is de situatie dermate nijpend dat gevraagd wordt om het aantal posities voor de diagnose code van 2 naar 3 posities uit te breiden. Oplossing Voor het specialisme URO wordt het aantal posities op de typeringslijst voor de diagnosecode op 3 posities gebracht. Om te voorkomen dat alle bestaande codes en de daarvan afgeleide prestatiecodes veranderen, zullen bestaande codes links worden aangevuld met een 0, dus 21 wordt 021. De nieuwe codes krijgen drie posities. Een nieuwe code uit de range zou dus 120 kunnen worden, gekoppeld aan de bestaande subgroep van de range, waardoor de diagnoses wel logisch geordend blijven Consequenties ICT Systemen Om de uitbreiding te realiseren zijn voor de ICT systemen geen aanvullende specificaties nodig. In de bestaande specificaties wordt voor de o.a. de diagnose as uitgegaan van maximaal 6 posities. Binnen de uit de typeringen samengestelde prestatiecode wordt voor de diagnose maximaal 4 posities aangehouden, dus ook daar geen aanpassing. Tabellen De wijziging betreft alleen een uitbreiding van de diagnoses binnen de typeringslijst. 3

4 2. Implementatie van de CTG beleidsregel of het voorkomen van uitval van verrichtingen. Inleiding In de beleidsregel van het CTG ZA io staat geschreven dat de ziekenhuizen per het ordernummer dienen te implementeren. Daarbij is tevens duidelijk vastgesteld dat de doelstelling van deze beleidsregel is het voorzien van elke verrichting van het (juiste) zorgtrajectnummer waardoor de kosten van de DBC zo goed mogelijk in kaart worden gebracht. Met het CTG is in dit proces een tweetal stappen onderscheiden : 1. het koppelen van alle verrichtingen aan een DBC 2. het koppelen van de verrichtingen aan de juiste DBC. De belangrijkste reden om hier toe over te gaan is het kunnen toewijzen van alle ziekenhuis activiteiten aan DBC s en behandeltrajecten met andere declarabele prestaties, waardoor de juiste profielen en daarmee de juiste tarieven kunnen worden vastgesteld. Ook voor de prijsbepaling van de DBC s in het B segment is het kunnen koppelen van verrichtingen aan DBC s een belangrijke doelstelling. Naast de doelstelling van het CTG geldt in toenemende mate dat ziekenhuizen worden geconfronteerd met verrichtingen die plaats vinden in een behandeltraject naast de volgens een ander declaratie modaliteit te declareren prestaties, zoals bijzondere trajecten, OP s, OVP s en overige verrichtingen. Het betreft verrichtingen zoals contacten, diagnostiek en in sommige gevallen ook therapie. Voor deze situaties worden geen DBC s geopend waardoor deze verrichtingen niet gekoppeld kunnen worden en tot uitval leiden. De bekendste voorbeelden zijn de Scopie voor huisartsen, de opname van patiënten op de Intensive Care, de kaakchirurgie behandeling of de uitvoering van het pre, peri- en postoperatieve onderzoek door de Algemene Anesthesie. NB Het gaat hier om een verruiming van de registratie mogelijkheden, en niet om het uitbreiden van de huidige declaratie mogelijkheden. Analyse Oplossingsrichting In de werkconferentie van 21 Maart is vastgesteld wat onder het DBC ordernummer verstaan dient te worden, namelijk het zorgtrajectnummer, het ordernummer van de DBC. En dat het bij de implementatie van de beleidsregel gaat om het gebruik van dat zorgtrajectnummer om verrichtingen aan een zorgtraject te koppelen. In de afgelopen weken is uitgebreid stilgestaan bij de manier waarop de beleidsregel kan worden geïmplementeerd. Allereerst is vastgesteld dat de beleidsregel niet impliceert dat de ziekenhuizen ordermanagement systemen dienen in te voeren. Het kan wel helpen maar is niet de doelstelling van de beleidsregel. Vervolgens is bepaald dat het concept zorgtraject, dat een onderdeel vormt van het huidige DBC datamodel, nu geïmplementeerd is in combinatie met de DBC trajecten, en dat de koppeling van verrichtingen aan zorgtrajecten alleen betrekking zou hebben op als DBC gedeclareerde behandelingen. Er zijn ook behandelingen die door poort specialismen worden verricht die niet als DBC worden gedeclareerd, maar 4

5 bv als Overig Product, of als Bijzonder Traject of als Overige Verrichting. Bij deze behandelingen is sprake van een profiel dat bestaat uit contacten, diagnostiek en soms ook therapie. Het is dan ook logisch om ook hier te spreken van een zorgtraject. Ook kan er sprake zijn van ondersteunende behandelingen door medisch specialismen, zoals de algemene anesthesie, de scopie voor een ander specialisme en de medische psychologie. Voor deze specialismen is het voor de post lumpsum periode van belang dat hun productie ook binnen de DBC systematiek zichtbaar wordt. Vastgesteld werd dat door ook voor deze situaties een zorgtraject te openen en het traject te typeren conform de DBC systematiek, er een oplossing geboden kan worden voor : i. Het gebruik maken van één structuur voor alle behandelingen ii. Het kunnen koppelen van alle verrichtingen aan een behandeltraject iii. Het daarmee structureel opbouwen van profielen voor alle behandelingen die in het ziekenhuis plaatsvinden uitgevoerd door medische specialismen, al of niet poort specialismen iv. Het vereenvoudigen van de registratie want er wordt voor alle behandelingen een zorgtraject geopend. v. Alle trajecten worden via de DBC systematiek getypeerd, het zorgtype zorgt voor het onderscheid tussen behandelingen die als DBC worden gedeclareerd en die via de andere declaratievormen worden gedeclareerd. vi. De declaratie van DBC s, OVP s, Bijzondere trajecten en Overige verrichtingen kan vanuit een registratie plaatsvinden. vii. Het biedt een oplossing voor de al jaren slepende kwestie van de scopie declaratie voor huisartsen. viii. Het koppelalgoritme voor verrichtingen aan zorgtrajecten hoeft niet of nauwelijks te worden aangepast. ix. Deze oplossing kan gefaseerd worden ingevoerd. Uitwerking In nauw overleg met de ICT expertgroep is het volgende model ontwikkeld, waarbij er de volgende dimensies worden onderscheiden : 1. Behandelend specialisme 2. Soort Zorg a. Poort specialismen b. Ondersteunende medische specialismen 3. Uitgevoerde zorgactiviteiten a. Contacten b. Diagnostiek c. Therapie 4. Declaratie modaliteit a. DBC b. OVP c. OP d. Bijzondere trajecten e. Overige verrichtingen. 5

6 In het volgende schema wordt in globale termen de verschillende soorten behandelingen in relatie gebracht met zorgtrajecten en hun zorgtypering, de daar aan te koppelen zorgactiviteiten en de bijbehorende declaratie modaliteiten. Behandelend Specialisme Poorter Interventie Radiologie, Anesthesie (pijnbestrijding) Poorters Poorter Overige DBC specialismen Niet DBC Specialismen b.v. Kaakchirurgie Ondersteunende specialismen b.v. MDL, Chirurg Internist Algemene Anesthesie Intensivisten Poorter Overige DBC specialismen Soort Zorg Reguliere Zorg Voor de eerste lijn / derden Bijzonder Traject Verkeerde Bed, GZ, GM Reguliere Zorg Reguliere Zorg Geleverd aan een ander DBC specialisme b.v. Scopie Bijzonder Traject IC, Brandwonden Zorgtype 11/21 12/13 Trajectkoppeling Declaratiemodaliteiten DBC Overige declaratie Declaratie Zelfstandig Ja Nee 41 Zelfstandig Nvt OVP 42 Zelfstandig Nvt Bijzonder traject 43 Zelfstandig Nvt Overige verrichtingen 51 Verplicht Nvt Nvt 52 Optioneel Nvt Bijzonder traject 6

7 Patient datamodel Specialisme Zorgtraject Zorgtraject Zorgtraject Zorgtraject Zorgtraject verzekeraar DBC Zorg DBC Ondersteunende Zorg / Bijzondere trajecten Zorg voor 1e lijn Bijzondere traject Zorg Overige Zorg Uitgevoerde Verrichtingen Uitgevoerde Verrichtingen Overige Verrichtingen (CF DIS) Overige Verrichtingen (CF DIS) Overige Verrichtingen (CF DIS) Toelichting Op basis van dit schema kan worden vastgesteld dat het mogelijk is om voor alle ziekenhuis behandelingen een zorgtraject aan te maken en voor deze behandelingen een profiel op te bouwen en te komen tot de correcte declaratie. Bij de typering wordt gebruik gemaakt van de nieuwe zorgtypes 41, 42, 43, 51 en 52. Terwijl voor de nieuwe trajecten geldt dat er gebruik gemaakt zal worden van een default typering voor de overige assen van de DBC die met nullen worden gevuld. Het aantal nullen zal worden bepaald door het aantal posities dat voor dat specialisme voor dat item in gebruik is. Het aanmaken van deze nieuwe zorgtrajecten kan geschieden door een simpele administratieve handeling. Ten aanzien van de koppeling van deze trajecten met lopende DBC s wordt gesteld dat deze relatie voor de trajecten met zorgtype 51 verplicht gesteld wordt voor zorgtype 52 is dat optioneel. Dat betekent in de praktijk alleen voor het bij een DBC vastleggen van het leveren van een Scopie door een MDL arts, internist of een chirurg op aanvraag van een ander specialisme of het koppelen van de anesthesie screeningstrajecten aan de DBC van de aanvrager dus meestal de chirurg. Voor de andere trajecten is de koppeling niet verplicht. De vastlegging van de koppeling tussen de twee zorgtrajecten wordt gebaseerd op de uitwerking van het uitgebreide datamodel. (2005) De structuur is zo opgezet dat deze kan worden toegepast voor alle voorkomende vormen van zorg in het ziekenhuis, waaronder ook de nog niet volgens de DBC systematiek te declareren zorg, zoals die van de eerste lijns verwijzing voor OVP s (Scopie), de bijzondere trajecten, maar ook de kaakchirurgie en andere buiten de DBC systematiek vallende behandelingen. De declaratie van deze zorg blijft plaatsvinden volgens de huidige beleidsregels. Dus o.a. aan de zorgverzekeraar waar de patiënt ten tijde van het leveren van de prestatie verzekerd was. Doordat er nu sprake is van een zorgtraject wordt er ook een profiel opgebouwd, waardoor er inzicht ontstaat in de kosten van deze zorg. Dat is een randvoorwaarde voor de verdere integratie van deze zorg in de DBC systematiek. Deze informatie gaat ook naar de DIS zodat daarmee voor alle behandelingen er inzicht ontstaat in de totale 7

8 kosten, op basis waarvan de integrale DBC tarieven kunnen worden bepaald. Door LogicaCMG zal een aanpassing van de aanleverstandaard worden opgeleverd, die vanaf zal moeten worden gebruikt. Het is een belangrijke basis voor de verdere ontwikkeling van het DBC systeem en van groot belang voor de honorering van de medisch specialist in het postlumpsum tijdperk, mogelijk door interne verrekening op basis van de geleverde deelprestaties. Door de opbouw van de profielen wordt ook de informatie noodzakelijk voor de nacalculatie en de lumpsum verdeling op een eenduidige manier opgebouwd. Bij de invoering van deze systematiek wordt een fasering aangebracht, waarbij de oplossing voor de eerste lijnsverwijzing per dient te worden geïmplementeerd. Doordat de DIS in haar aanpassing het mogelijk maakt dat beide modellen worden gebruikt voor de aanlevering is partiele implementatie per mogelijk. Uit het overleg met het veld komt het volgende voorstel naar voren : Invoering 1. de voorgestelde oplossing voor de introductie van zorgtrajecten met onderscheidende zorgtypes is geaccepteerd, waarmee de hoofdlijn wordt bepaald 2. Per 1 januari 2007 is implementatie van zorgtrajecten voor zorgtype 41 verplicht, 3. Voor de zorgtypes 51, 52, 42 en 43 wordt de implementatie van de zorgtrajecten nog niet ingevoerd op 1 januari 2007, maar worden de processen voor de registratie in overleg met partijen nader uitgewerkt. Invoering zo mogelijk per 1 juli Consequenties ICT aanpassingen Om deze faciliteit te realiseren is het noodzakelijk dat de volgende aanpassingen worden gedaan. 1. Naast de bestaande DBC s moet het mogelijk zijn om voor de volgende zorgvormen zorgtrajecten aan te maken, die zich onderscheiden door het zorgtype. Per verplicht a. Zorgtype 41 Voor de diagnostiek voor de eerste lijn. Deze leiden tot OVP declaraties. Nader wordt uitgewerkt a. Zorgtype 42 voor de Bijzondere trajecten,gezonde Zuigelingen, Gezonde moeders en Verkeerde Bed. Deze zorg wordt via de Bijzondere traject prestaties gedeclareerd b. Zorgtype 43 voor de behandelingen die niet onder de DBC systematiek vallen zoals de kaakchirurgie, de revalidatie. Deze zorg wordt onder de categorie Overige verrichtingen gedeclareerd. c. Zorgtype 51 voor de niet declarabele ondersteunende zorgproducten zoals preoperatieve screening door de algemene anesthesie, de scopie door een poortspecialisme voor een ander poortspecialisme en 8

9 de Medische Psychologie. Deze behandelingen zijn niet declarabel en leiden dus niet tot te declareren prestaties. Voor deze trajecten geldt dat deze gekoppeld dienen te worden aan de DBC van de aanvrager van deze zorgprestatie. d. Zorgtype 52 voor de Bijzondere trajecten, IC opname, Deze zorg wordt via de Bijzondere traject prestaties gedeclareerd. Voor deze trajecten geldt dat deze gekoppeld kunnen worden aan de DBC van de aanvrager van deze zorgprestatie (Optioneel). 2. Het openen en sluiten van deze DBC s kan zoveel mogelijk automatisch plaatsvinden. Per soort zal per specialisme de default duur van deze trajecten dienen te worden vastgelegd. 3. Naast het zorgtype geldt dat de typering in principe met defaultwaardes 0..0 plaatsvindt. Deze defaultwaarden gelden alleen in combinatie met zorgtrajecten uit de range De DBC codering van deze bijzondere trajecten wordt om controle en consistentie doeleinden wel in de DBC eindklasse tabel opgenomen, met als dummy (declaratie )codes , , , en Voor de toewijzing van verrichtingen aan deze DBC trajecten geldt het bestaande toewijzigingsalgoritme. Met dien verstande dat bij parallelliteit van een DBC en een DBC traject met zorgtype geldt dat deze laatste trajecten prevaleren. 5. De declaratie van de binnen de nieuwe trajecten geregistreerde verrichtingen zal conform de bestaande regels plaatsvinden. Het belangrijkste verschil is dat deze verrichtingen nu wel aan een zorgtraject gekoppeld moeten worden. DIS aanlevering 1. de aanleverstandaard voor de DIS wordt aangepast om het mogelijk te maken de overige verrichtingen gerelateerd aan een zorgtraject of aan de patiënt aan te leveren. 2. de relatie van een zorgtraject met een DBC traject aan te kunnen geven Tabellen 1. in de elektronische typeringslijsten en de papieren versies dienen de zorgtypes 41,42,43, 51 en 52 te worden opgenomen voor de specialismen waarvoor dat relevant is. Voor deze specialismen moeten ook de default typeringen van de andere assen worden opgenomen. Voor 1 januari 2007 zal dat alleen ZT 41 betreffen. De andere zorgtypes volgen op een later moment. Zie Invoering punt In de tabel Afleiding behandelas zal voorzien moeten worden in het toestaan van de nieuwe zorgtypes, bovenstaande in acht genomen, zonder dat er verder inhoudelijke eisen aan deze zorgtypen gesteld worden. Wel zal een systeem controle aanwezig moeten zijn die geheel lege trajecten (zonder een enkele zorgactiviteit) voor de zorgtypes 41, 42, 43, 51 en 52 afkeurt. Dit wordt niet in de tabel Afleiding behandelas geregeld. 3. In de DBC eindklasse tabel dienen de nieuwe combinaties te worden opgenomen met dummy declaratiecodes. 4. Mogelijk moeten de tabellen DBC-diagnose Combinatietabel, Relatie Specialisme-Verrichting_Diagnose tabel, de Referentie doorlooptijdentabel en de Productgroepen eigenschappen tabel moeten worden aangepast. 9

10 Implementatie Aspecten Ziekenhuizen 1. Aanpassen instructies m.b.t. de registratie van de bijzondere trajecten. 2. Afspraken maken over de default duur van deze trajecten Implementatie aspecten Zorgverzekeraars Voor de zorgverzekeraars heeft deze aanpassing geen consequenties, de declaratie blijft ongewijzigd. DIS De DIS zal de aanleverstandaard moeten aanpassen om : 1. Accepteren van trajecten inclusief daaraan gekoppelde verrichtingen met daarbij de gedeclareerde prestaties 2. Het vastleggen van de relatie naar het traject bij de overige verrichtingen 3. Het opnemen van verwijsgegevens bij trajecten met zorgtype 51 en 52. LogicaCMG heeft de aanpassingen in een apart document beschreven. 3 Oplossing MDL problematiek Aanleiding De Scopie voor huisartsen kan volgens de CTG ZA io beleidsregels sinds alleen nog worden gedeclareerd als OVerig Product (OVP). Tot dusverre werd de OVP als één prestatie (verrichting) gezien, namelijk alleen de scopie. Uit de discussies met de wetenschappelijke verenigingen van de Maag Darm Lever specialisten, de Internisten en de chirurgen is duidelijk komen vast te staan dat er sprake is van een traject met de scopie als hoofdactiviteit, maar waarbij ook een consult of dagbehandeling en aanvullend diagnostisch onderzoek plaatsvindt. Probleemstelling Voor de registratie van de scopieën bestaan nu verschillende regelingen, als deze wordt uitgevoerd in het kader van de behandeling van de patiënt door de MDL arts wordt er een DBC geopend en wordt de scopie daar als verrichting aan toegekend, terwijl als deze door de huisarts wordt aangevraagd er alleen een verrichting kan worden geregistreerd en alle andere activiteiten niet kunnen worden gekoppeld. Bovendien ontbreken de FB parameters op basis waarvan de MDL artsen in veel ziekenhuizen een deel van hun lumpsum aandeel verwerven. Oplossing De structurele oplossing voor de registratie van de diagnostiek op verzoek van de eerste lijn wordt geboden met het boven uitgewerkte generieke model. Het levert voor de scopieen een 41 traject met daarbinnen de declarabele OVP (de Scopie) en het profiel waaronder de voor de interne lumpsum verdeling en de nacalculatie relevante parameters. 10

11 Voor de scopieen die door Scopisten worden gedaan op verzoek van een ander DBC specialisme kan een 51 traject worden aangemaakt, dat gekoppeld wordt aan de DBC van de aanvrager. 4 Opnemen van indicatie machtiging vereist in de Eindklassetabel Op verzoek van partijen zal er, voor de relevante producten, in de Eindklassetabel een indicatie worden opgenomen die aangeeft dat voor dat product een machtiging vereist is door de Zorgverzekeraars. Het betreft een beperkte, door ZN opgestelde en onderhouden landelijk geldende lijst. De gegevens voor deze indicatie zullen worden aangeleverd door ZN volgend een nog nader vast te stellen procedure. Voor de distributie wordt de Eindklassetabel zodanig aangepast dat in veld 9 de indicatie machtiging vereist zal worden opgenomen. Hierdoor worden de veldnummers van de overige attributen met 1 verhoogd. Voorbeeld tabel wordt opgenomen. Procedures rondom het gebruik van deze indicatie zal in overleg tussen Zorgverzekeraars en Ziekenhuizen worden vastgelegd en maakt geen deel uit van deze specificaties. De DBC Eindklasse tabel Deze tabel bevat de indelingen van de DBC-typering (mogelijke combinatie van componenten) naar de productgroepen, declaratie codes en prestatiecodes. Kolom Naam Type, max. Opt. Omschrijving nr. lengte 1. Specialisme code AGB AN4 Unieke code voor het specialisme (AGB-codering) 2. Zorgtype code AN2 Zorgtype-component van de DBC 3. Zorgvraag code AN..3 Opt. Zorgvraag-component van de DBC 4. Diagnose code AN..6 Typerende diagnose-component van de DBC 5. Afgeleide behandeling AN..6 Afgeleide behandel-as van de DBC. 6. Productgroep code AN..10 Opt. Code van de productgroep, Niet gevuld als het een niet declarabele DBC betreft. Nu zijn er 7 posities in gebruik. 7. DBC declaratiecode verzekerde zorg AN..10 Opt. Code waaronder de verzekerde zorgprestatie gedeclareerd mag worden. Codes startend met 15 betreffen prestaties uit segment B, codes startend met code 14 betreffen segment A en overig. Nu zijn er 6 posities in gebruik. 8. Aanspraakcode AN4 Opt Code van de Aanspraak op de basisverzekering 9. Indicatie machtiging vereist A1 Opt J (ja) indien een machtiging vereist is. N (nee) of leeg als de machtiging niet vereist is. 10. WBMV code AN4 Opt Code van de WBMV vergunning noodzakelijk voor deze DBC 11

12 Kolom Naam Type, max. Opt. Omschrijving nr. lengte 11. Indicatie volledige prestatiecode A1 Opt. J (ja) indien de prestatiecode volledig op de declaratie vermeld moet worden (segment B en een deel van segment A); N (nee) indien een afgeleide prestatiecode moet worden gepresenteerd. De diagnosecode is dan alleen op hoofdlijnen opgenomen (het andere deel van segment A); Voor DBC s geopend vanaf zal de Prestatie code voor alle DBC s volledig op de factuur worden vermeld. 12. DBC prestatiecode AN12 Opt. Prestatiecode zoals bedoeld in attribuut 10: samentrekking van zorgtype, zorgvraag, diagnose en behandeling tot 12 posities. Voor DBC s geopend voor kan de diagnose code gemaskeerd zijn, voor DBC s geopend vanaf wordt de prestatiecode niet meer gemaskeerd. 13. Lekenvertaling AN..132 De leken omschrijving van de DBC, zoals die op de factuur aan de patiënt, in de tekst staan om aan te geven waar de tekst afgebroken kan worden. 14. DBC declaratie code onverzekerde zorg AN..10 Opt Deze kolom bevat de declaratiecode voor indien de DBC onverzekerde zorg betreft. Bij een Oranje prestatie code is zowel 7 als 13 gevuld en moet op basis van de aanspraak criteria de juiste worden gekozen. De onverzekerde zorg voor DBC s geopend vanaf heeft tariefgroep 16. Segment B DBC s krijgen tariefgroep 17. DBC s geopend voor houden de declaratiecode uit de 14 of 15 groep. 15. Ingangsdatum N8 Datum ingang geldigheid regel, (EEJJMMDD) 16. Afloopdatum N8 Opt. Datum einde (t/m) geldigheid regel, (EEJJMMDD) 17 Mutatie N1 Opt. Geeft aan welke soort wijziging of correctie is uitgevoerd tov vorige formele oplevering 1 Nieuw 2 Gewijzigd 3 Logisch verwijderd Aanpassingen In de tabel zijn de volgende wijzigingen aangebracht 1. Recordlengte is met 1 positie verlengd 2. Op positie 9 is de kolom Indicatie machtiging vereist toegevoegd. 3. De veldnummers van de oorspronkelijke velden 9 t/m 16 zijn met 1 verhoogd. 12

13 5 Kleinere tabel aanpassingen ter bevordering van de consistentie. Typeringslijsten De aanpassing betreft: Toegevoegd Veld 20 en betreft de mutatiecode. Hiermee worden de typeringslijsten op dit punt consistent met de overige tabellen. Kolom Omschrijving Type & max Opt. Toelichting nr. lengte 1. Specialisme code AGB AN4 Unieke code voor het specialisme (AGB-codering) 2. As code N1 Code van één van de vier DBCcomponenten: 1 = zorgtype, 2 = zorgvraag, 3 = diagnose, 4 = behandeling. 3. As omschrijving A..11 Omschrijving die hoort bij de as code: 1 = zorgtype, 2 = zorgvraag, 3 = diagnose, 4 = behandeling. 4. Component code AN..6 Code waarop gerapporteerd moet worden. Dit is de exacte code. De codes worden links aangevuld met voorloop nullen tot de maximale lengte van een code binnen de as, dus bijvoorbeeld 02 indien ook de code 35 voorkomt en 002 indien ook de code 335 voorkomt. Indien de component code bestaat uit louter 000 dan mag deze code niet gerapporteerd worden. Het betreft dan een hulpcode voor de registratie, bv Component omschrijving kort AN..30 Omschrijving behorend bij de componentcode, afgekort. 6. Component omschrijving lang AN..500 Volledige omschrijving behorend bij de componentcode 7. Subgroep code AN..5 Opt Indeling van de component in de subgroep 8. Subgroep omschrijving kort AN..30 Opt Omschrijving subgroep, afgekort 9. Subgroep omschrijving lang AN..500 Opt Volledige omschrijving van de subgroep 10. Hoofdgroep code AN..5 Opt Indeling van de component in de hoofdgroep 11. Hoofdgroep omschrijving kort AN..30 Opt Omschrijving hoofdgroep, afgekort 12. Hoofdgroep omschrijving lang AN..500 Opt Volledige omschrijving van de hoofdgroep 13. Ingangsdatum N8 Datum waarop de code ingaat., (EEJJMMDD) 13

14 14. Afloopdatum N8 Opt Datum waarna de code vervalt. Datum tot en met, (EEJJMMDD) 15. Mutatie reden N1 Opt Reden van mutatie: 1 = nieuwe toevoeging; 2 = wijziging omschrijving of groepsindeling; 7 = beëindiging, code opgesplitst; 8 = beëindiging, code overgegaan in andere code of samengevoegd 9 = beëindiging, code verwijderd 16. Vervangende component code AN..6 Opt Bij een beëindiging, waarbij de code overgaat in andere code of wordt samengevoegd met een andere code (mutatie reden = 8), wordt in dit veld de nieuwe component code aangegeven. Dit kan worden gebruikt voor automatische omzetting bij de registratie in het ZIS. Let wel, dit veld wordt alleen gebruikt bij een simpele overgang van oude naar nieuwe code van hetzelfde DBC-component. Bij complexere situaties wordt dit toegelicht in het veld mutatie toelichting 17. Mutatie toelichting AN..100 Opt Toelichting bij de mutatie, bijvoorbeeld om bij een beëindiging met splitsing van codes aan te geven in welke codes deze is overgegaan. 18 Behandelsetting N1 Opt Behandelsetting als handreiking voor het kunnen onderscheiden van de setting van de behandelingscodes. 1 = Poliklinisch; 2 = Dagbehandeling 3 = Klinisch 4 = Onbekend 19 Automatisch verlengen toegestaan AN1 Opt Indicatie geeft aan dat bij deze diagnose de DBC automatisch verlengd mag worden. Als er een 0 of een 2 staat betekent dit niet dat deze code niet in een vervolg DBC mag voorkomen, het betekent alleen dat een DBC met deze Diagnose niet automatisch mag worden verlengd. 0 nvt 1 Ja 2 Nee 20 Mutatie N1 Opt Geeft aan welke soort wijziging of correctie is uitgevoerd tv vorige formele oplevering 1 Nieuw 2 Gewijzigd 3 Logisch verwijderd 14

15 Aanspraak tabel De aanpassing betreft: Het type van veld 1 Aanspraak_code is gewijzigd van N4 naar AN4. Kolom Naam Type, max. Opt Omschrijving nr lengte. 1. Aanspraak_code AN4 Code van de Aanspraak 2. Aanspraak_code_om- Schrijving AN..200 Omschrijving van de aanspraak code 3. Wettekst AN..120 Hyperlink naar document 4. Aanvullende informatie AN..120 Hyperlink naar document 5. Aanspraak validatie regel N..10 Verwijzing naar aanspraak beslissingsregel 6. Ingangsdatum N8 De ingangsdatum van de betreffende regel, (EEJJMMDD) 7. Einddatum N8 Opt De afloopdatum geldigheid (tot en met) van de betreffende regel, (EEJJMMDD) 8. Mutatie N1 Opt Geeft aan welke soort wijziging of correctie is uitgevoerd tov vorige formele oplevering 1 Nieuw 2 Gewijzigd 3 Logisch verwijderd WMBV tabel De aanpassing betreft: Het type van veld 1 WMBV_code is gewijzigd van N4 naar AN4. Kolom Naam Type, max. Opt. Omschrijving nr lengte 1. WBMV_code AN4 Code van de WBMV 2. WBMV_code_omschrijving AN..200 Omschrijving van de WBMV code 3. Betreffende Regeling AN..120 Hyperlink naar document 4. Aanvullende informatie AN..120 Hyperlink naar document 5. Ingangsdatum N8 De ingangsdatum van de betreffende regel, (EEJJMMDD) 6. Einddatum N8 Opt De afloopdatum geldigheid (tot en met) van de betreffende regel, (EEJJMMDD) 7. Mutatie N1 Opt Geeft aan welke soort wijziging of correctie is uitgevoerd tov vorige formele oplevering, 1 Nieuw 2 Gewijzigd 3 Logisch verwijderd 15

16 6 Sleutelgegevens DBC-tabellen. Doelstelling Met deze paragraaf wordt duidelijkheid verschaft in het gebruik van sleutelgegevens binnen de DBC-tabellen. Waarom sleutelgegevens? Voor geautomatiseerde verwerking van gegevens zijn sleutelgegevens van cruciaal. In het kader van de DBC-tabellen zijn deze in ieder geval van belang voor: 1. het gebruik van de mutatiecodes Met de mutatiecodes, die vanaf juni 2006 in alle tabellen worden ingevoerd, is het mogelijk om gewijzigde records uit de DBC-tabellen te selecteren en deze te verwerken in eigen tabellen. De sleutelvelden tezamen zijn uniek en zorgen ervoor dat het juiste record kan worden geselecteerd. Bij een mutatiecode 2 en 3 zal een reeds bestaand record worden gemuteerd resp. worden verwijderd.. Het betreffende record kan worden gevonden op basis van de sleutelvelden. Met een mutatiecode 1 wordt een nieuw record (met nieuwe sleutelvelden toegevoegd). Er zijn 2 soorten wijzigingen. a. In de meeste gevallen zullen wijzigingen worden doorgevoerd in de toekomst. In dat geval zal een nieuw record (mutatiecode 1) worden toegevoegd met een begindatum gelijk aan het moment waarop de wijziging van kracht wordt. Het oude record zal een einde datum krijgen, dat een dag voor de begindatum ligt. (mutatiecode 2) b. Er komen ook situaties voor dat een wijziging (correctie) met terugwerkende kracht worden aangebracht. Bijvoorbeeld, er staat een aanspraak fout in de eindklassetabel en deze wordt gecorrigeerd of er was een verrichting toegevoegd in de zorgactiviteitentabel, die nooit had mogen bestaan. In deze gevallen is het van belang vast te stellen of dat er een sleutelgegeven of een overig veld wordt gewijzigd: i. Bij een correctie van een veld dat NIET tot de sleutelvelden behoort wordt de wijziging in het record aangebracht en krijgt het betreffende record mutatiecode 2. (Het oude record wordt dan dus overschreven) ii. Bij wijziging van een veld dat WEL tot de sleutelvelden behoort, kan niet op dezelfde wijze worden gewerkt. In deze gevallen zal het betreffende record een mutatiecode 3 krijgen (komt dus te vervallen) en wordt meteen een nieuw record (met een gewijzigd sleutelgegeven) en met een mutatiecode 1 weer opgenomen. 2. de sortering van de DBC-tabellen. De tabellen worden doorgaans geautomatiseerd verwerkt, maar toch bestaat soms de behoefte om even in de tabellen te kijken. Het is dan handig als de tabel op een herkenbare manier is gesorteerd. De tabellen worden gesorteerd op de volgorde van de sleutelvelden. N.B. Zie voor meer informatie betreffende de mutatiecodes de specificaties

17 Sleutelvelden per tabel sleutelvelden nr Tabel Elektronische typeringslijst Specialismecode As code AGB DBC-zorgactiviteitentabel Zorgactiviteit_code Ingangsdatum 3 Dis-verrichtingen stamtabel DIS-code Ingangsdatum Component code Ingangsdatum 4 DBC eindklasse tabel Specialismecode AGB Zorgtype code Zorgvraag code Diagnosecode Afgeleide behandeling 5 Tarieventabel Declaratiecode AGB AGB uitvoerder Kostensoort Soort Specialisme honorarium 6 Productgroepen Productgroepcode Ingangsdatum eigenschappen tabel 7 Aanspraakcode tabel Code aanspraak Ingangsdatum 8 WBMV code tabel WBMV_code Ingangsdatum 9 10 Afleiding behandelas Specialismecode Regelnr Ingangsdatum AGB DBC-diagnose Combinatietabel Specialisme code Diagnose_DBC1 Diagnose_DBC2 Ingangsdatum 11 Relatie Specialisme- Verrichting_Diagnose 12 DBC referentie doorlooptijden tabel Specialisme code Zorgtype Zorgvraag Diagnose afgeleide behandeling Ingangsdatum Ingangsdatum ingangsdatum 17