STANDAARDBESCHRIJVING

Transcriptie

1 Externe Integratie Aanleverspecificaties DBC GGZ QG301-QG302 Versie: Versie datum: STANDAARDBESCHRIJVING [STB] Informatie bij implementatie en ingebruikname berichtbeschrijving Uitgave document: 1 Uitgavedatum Kenmerk: QG301-QG302v2.0_STBu1.pfd

2 Adres- en contactgegevens Correspondentie-adres Bezoekadres Vektis C.V. Vektis C.V. Postbus 703 Sparrenheuvel AS ZEIST 3708 JE ZEIST Telefoon: Helpdesk qstandaarden: Helpdesk dataontvangst: Helpdesk: Website: Webapplicatie WESP: Webapplicatie EI-testportaal PORTES: Webapplicatie testbestanden TOWER: De inhoud van deze publicatie is met de grootste zorgvuldigheid samengesteld. Wanneer er desondanks onjuistheden in mochten voorkomen, aanvaardt Vektis C.V. daarvoor geen aansprakelijkheid. Ook aanvaardt Vektis geen aansprakelijkheid voor enige directe of indirecte schade die zou kunnen ontstaan door het gebruik van de hierin aangeboden informatie. Verveelvoudiging en verspreiding is toegestaan mits Vektis C.V. als bron wordt vermeld, dan wel als bron herkenbaar blijft. Vektis C.V., Zeist Standaardbeschrijving Aanleverspecificaties DBC GGZ 2 / 37

3 AANLEVERSPECIFICATIES DBC GGZ Versie 2.0 van de Aanleverspecificaties DBC GGZ, versiedatum , Documentuitgave 1, Revisiehistorie aanleverspecificaties Versie Uitgave Aard / reden wijzigingen Datum uitgave document Aangepast aan: wet- en regelgeving, gewijzigde GZ311 declaratiestandaard en generieke Q-standaard Eerste uitgave van eerste versie Doelgroepen Zorgverzekeraars Vektis CV VECOZO. Status De eerste versie van de aanleverspecificaties is opgesteld in afstemming met Zorgverzekeraars Nederland en zorgverzekeraars. Beheer aanleverspecificaties De aanleverspecificaties worden functioneel beheerd door Zorgverzekeraars Nederland. Het technisch beheer wordt uitgevoerd door Vektis CV. Standaardbeschrijving Aanleverspecificaties DBC GGZ 3 / 37

4 Voorwoord Dit document betreft de standaardbeschrijving Aanleverspecificaties DBC GGZ, , QG301/QG302, versie 2.0. Het document verschijnt tezamen met de documenten: Aanleverspecificaties DBC GGZ, QG301, versie 2.0, , Berichtspecificatie [BER]; Aanleverspecificaties Retourinformatie DBC GGZ, QG302, versie 2.0, , Berichtspecificatie [BER]; Aanleverspecificaties DBC GGZ, QG301-QG302, versie 2.0, , Invulinstructie [INV]; Aanleverspecificaties DBC GGZ, QG301-QG302, versie 2.0, , Registratie bedrijf- en controleregels [RBC]. Dit document bevat de aanleverspecificaties voor het elektronische uitwisselen van schadegegevens DBC GGZ tussen zorgverzekeraars en Vektis. Bij de ontwikkeling van de Aanleverspecificaties DBC GGZ is de EIdeclaratiestandaard GZ311-GZ312, versie 2.1 als belangrijke bron gehanteerd. Het gebruik van de EIstandaard is ingegeven door de sterke relatie van de DBC GGZ gegevensvraag met de EIdeclaratiestandaard. Dit is de standaard die gehanteerd wordt voor het declaratieverkeer tussen zorgverlener en zorgverzekeraar. Een groot deel van de generieke en/of sectorspecifieke velden die in deze standaard zijn gehanteerd worden ook binnen de Declaratie DBC GGZ gegevensvraag opgevraagd. Ook qua opbouw, structuur, documentopbouw en werkwijze van de Aanleverspecificaties DBC GGZ is zoveel mogelijk aangesloten bij de EI-standaarden van Vektis. Daarnaast zullen de Aanleverspecificaties DBC GGZ, gelijk de EI-standaarden van Vektis, ook via WESP worden gecommuniceerd richting zorgverzekeraars en zal de mogelijkheid worden geboden om de (test)bestanden Aanleverspecificaties DBC GGZ te controleren via Portes. Het doel van de koppeling bij de ontwikkeling van de Aanleverspecificaties DBC GGZ met de EI-standaard is het reduceren van de werkzaamheden aan de kant van de zorgverzekeraars en het bewerkstelligen van eenheid van taal binnen de communicatie. In dit document wordt ingegaan op het communicatieproces, de functionele berichten, de algemene procedurele aspecten en de berichtopzet. Dit document is tot stand gekomen in opdracht van Zorgverzekeraars Nederland. De aanleverspecificaties zijn opgesteld in afstemming met vertegenwoordigers van Zorgverzekeraars Nederland, zorgverzekeraars en Vektis CV. De aanleverspecificaties zijn in beheer en onderhoud bij Vektis CV. Standaardbeschrijving Aanleverspecificaties DBC GGZ 4 / 37

5 Inhoudsopgave 1. Over dit document Uitgangspunten Inhoud Ontwikkeling Aanleverspecificaties DBC GGZ en, versie Aanleiding Algemeen doel Afstemming Communicatieproces Inleiding Communicatieproces Entiteiten Aanleverspecificaties DBC GGZ, versie Inleiding Objecten functioneel bericht Functioneel bericht Berichtopzet Aanleverspecificaties DBC GGZ, versie Inleiding Bericht Aanleverspecificaties DBC GGZ Bestandstructuur Inleiding Recordtypen Logische bestandstructuur Fysieke bestandstructuur Objecten per recordtype Tekenset Carriage-Return/Line-Feed Procedure uitwisselen gegevens Aanleverspecificaties DBC GGZ Algemeen Periodiciteit versturen bericht Aanleveringmedium en procedure Wijzigingen van declaratieverwerkingssysteem Bulkboekingen Informatiebeveiliging Controle kwaliteit bestand Burgerservicenummer Het aanleveren van mutaties Buitenlandverzekerden EI-retourinformatie in het kader van schadeafhandeling Inleiding Afbakening doel EI-retourinformatiebericht Beschrijving van de controleprocessen Standaardbeschrijving Aanleverspecificaties DBC GGZ 5 / 37

6 Inleiding Controles op bestandsniveau Controles op recordniveau Structuur EI-retourinformatiebericht Retourcodes en commentaar in EI-retourinformatiebericht Retourcodes op bestandsniveau Retourcodes op recordniveau Wijzigen gegevens in EI-retourinformatiebericht Afhandeling EI-retourinformatiebericht Bijlagen Afkortingen Mutatieoverzicht Standaardbeschrijving Aanleverspecificaties DBC GGZ 6 / 37

7 1. Over dit document 1.1. Uitgangspunten Bij het samenstellen van dit document zijn de volgende uitgangspunten gehanteerd: Het beschrijft de elektronische communicatie qua proces en gegevens. De lezer heeft kennis van ICT qua aanpak, ontwikkeling, implementatie en gebruik van elektronische berichten. Het beschrijft niet de eventueel noodzakelijke organisatorische veranderingen, zoals opleiding, werkprocessen, relatie tot formulieren, interne procedures, et cetera. Bedrijfsregels die in de documentatie bij de aanleverspecificaties voorkomen, maken integraal deel uit van de aanleverspecificaties en dienen dientengevolge door alle partijen gevolgd te worden Inhoud In hoofdstuk 2 wordt ingegaan op de aanleiding, het doel en de wijze waarop deze aanleverspecificaties tot stand zijn gekomen. De EI-berichten die op basis van deze aanleverspecificaties zullen worden uitgewisseld zijn bedoeld voor het proces van het aanleveren van schadegegevens DBC GGZ aan Vektis CV. Deze gegevens worden gebruikt voor spiegel- en beleidsinformatie, het uniformeren van landelijke processen en onderzoeksdoeleinden voor o.a. zorgverzekeraars en (mogelijke) uitvoering wettelijke taken. Hoofdstuk 3 gaat in op dit proces door middel van tekst en schema. De rollen van de partijen binnen het communicatieproces worden inzichtelijk gemaakt. Hoofdstuk 4 beschrijft het functionele EI-bericht en het objectenmodel op basis van de gegevens, die in het kader van de schadegegevens DBC GGZ van belang zijn. In hoofdstuk 5 wordt ingegaan op de berichtopzet. Hierin komen onderwerpen zoals bestandstructuur, beveiliging et cetera aan de orde. Het overzicht Afkortingen in de bijlage toont de belangrijkste afkortingen die in dit document voorkomen, met hun betekenis. In het mutatieoverzicht staan de belangrijkste wijzigingen in deze versie ten opzichte van de vorige versie van de aanleverspecificaties beschreven. Standaardbeschrijving Aanleverspecificaties DBC GGZ 7 / 37

8 2. Ontwikkeling Aanleverspecificaties DBC GGZ, versie Aanleiding Naar aanleiding van gewijzigde wet- en regelgeving en doorontwikkeling van de DBC-systematiek is een nieuwe EI standaard DBC GGZ opgesteld. Dit heeft geresulteerd in een nieuwe gegevensvraag DBC GGZ (QG301-QG302). Schadelastinformatie DBC GGZ biedt de mogelijkheid om op structurele wijze (detail)informatie te verzamelen ten aanzien van de DBC GGZ in Nederland. Met behulp van Schadelastinformatie DBC GGZ kunnen de volgende informatiebehoeften worden ingevuld: Het verstrekken van spiegel- en benchmarktinformatie voor zorgverzekeraars; Inzicht in de schadelastontwikkeling; Analyses ten behoeve van de zorginkoop; De ontwikkeling van beleidsinformatie; Ondersteuning van de ontwikkeling van verzekeraarbudgetten; Ondersteuning van landelijke processen; Inzicht in de (mogelijke) effecten van compartimentverschuivingen binnen de sector; Ad-hoc analyses; Leveren van broninformatie ten behoeve van het uitvoeren van wettelijke regelingen; Controles van de declaraties; Inzicht in de kostenontwikkelingen van jaar-op-jaar; NZa of andere instanties in het kader van hun wettelijke taken informatie verstrekken, zodat zij niet altijd verzekeraars daarmee hoeven belasten; Analyses in onderzoeken in het kader van controle en fraude door verzekeraars; Mogelijk toekomstig gebruik Wtcg en CER Algemeen doel De berichtstandaard heeft tot doel het realiseren van een efficiënte en effectieve uitwisseling van gegevens betreffende schadegegevens DBC GGZ tussen de administratie van een zorgverzekeraar en Vektis CV Afstemming Versie 2.0 van de Aanleverspecificaties DBC GGZ is opgesteld in afstemming met Zorgverzekeraars Nederland, zorgverzekeraars en Vektis CV. Standaardbeschrijving Aanleverspecificaties DBC GGZ 8 / 37

9 3. Communicatieproces 3.1. Inleiding De standaardbeschrijving bestaat uit een beschrijving van de elektronische communicatie qua proces en gegevens. De berichtspecificatie geeft topdown-inzicht in doel, opbouw en invulling van een EI-bericht. Deze specificaties zijn per aanleverspecificatie opgenomen in afzonderlijke BER-documenten Communicatieproces Hieronder volgt een beschrijving van het communicatieproces op hoofdlijnen, zoals dat tussen de belangrijkste betrokken partijen plaatsvindt. De belangrijkste onderdelen van het proces en de daarbij aanwezige informatiestromen zijn beknopt geschetst. Hiermee is de samenhang tussen de diverse onderdelen vanuit registratief oogpunt inzichtelijk gemaakt. Uitzonderingen in dit proces zijn mogelijk. Deze uitzonderingen zijn niet beschreven in dit document. De partijen die deelnemen aan de communicatie zijn: Zorgverzekeraar; VECOZO; Vektis CV. Het communicatieproces is globaal onder te verdelen in vier fasen: verwerking ingediende declaraties bij een zorgverzekeraar; aanlevering schadegegevens DBC GGZ aan Vektis CV via VECOZO; verwerking schadegegevens DBC GGZ in Schadelastinformatie DBC GGZ; terugkoppeling beleids- en spiegelinformatie, broninformatie processen. Rondom de schadegegevens vindt communicatie plaats tussen in het algemeen van een zorgverzekeraar naar Vektis CV. Standaardbeschrijving Aanleverspecificaties DBC GGZ 9 / 37

10 Figuur 3-1 toont de belangrijkste (toekomstige) informatiestromen en partijen in het kader van de geschetste communicatie voor de declaratie- en de schadegegevens. Eventuele retourberichten zijn niet weergegeven. Figuur 3-1 Informatiestromen declareren en landelijke gegevensaanlevering schade DBC GGZ Standaardbeschrijving Aanleverspecificaties DBC GGZ 10 / 37

11 Het digitaal berichtenmodel volgt uit het model van de informatiestromen. Voor de in dit document beschreven EI-berichten ziet het schadegegevensstromenmodel DBC GGZ eruit zoals in figuur 3-2. Figuur 3-2 Voorbeeld EI-schadestromen DBC GGZ Standaardbeschrijving Aanleverspecificaties DBC GGZ 11 / 37

12 4. Entiteiten Aanleverspecificaties DBC GGZ, versie Inleiding Doel van dit hoofdstuk is inzicht te geven in het functioneel bericht en het objectenmodel voor de gegevens in het kader van het uitwisselen van Schadelastinformatie DBC GGZ Objecten functioneel bericht Figuur 4-1 Objectmodel Declaratie DBC GGZ verzekerde UZOVI heeft prestatie heeft Tarief Een verzekerde (vrager) heeft schade bij één of meer zorgverzekeraars. Bij een verzekerde horen één of meerdere prestaties. Een prestatie heeft op zijn beurt één of meer te declareren tarieven Functioneel bericht Een functioneel bericht beschrijft de logische gegevensbehoefte ten aanzien van de informatie-uitwisseling tussen de partijen in het aangegeven proces bij het aangegeven doel. Dit bericht is de basis voor bijvoorbeeld een flatfile- of XML-bericht. In dit document is een flatfile-bericht als technisch bericht beschreven. Vektis hanteert momenteel alleen flatfile-berichten. Zolang dit het geval is wordt het specificeren van een functioneel bericht achterwege gelaten. Standaardbeschrijving Aanleverspecificaties DBC GGZ 12 / 37

13 5. Berichtopzet Aanleverspecificaties DBC GGZ, versie Inleiding Het beschrijven van één landelijke afspraak met betrekking tot de uit te wisselen gegevens en de wijze waarop het uitwisselen gebeurt, is van groot belang bij het toepassen van de Aanleverspecificaties DBC GGZ. In dit hoofdstuk wordt ingegaan op een aantal aspecten dat relevant is bij het bouwen en implementeren van de berichtenstandaard alsmede het verzenden van berichten Bericht Aanleverspecificaties DBC GGZ Eén bericht bestaat uit alle bij elkaar behorende gegevens. Eén bericht: is gekoppeld aan één bestand; heeft betrekking op dezelfde periode van gegevensuitwisseling (aanlevering); heeft één identificatieaanlevering; bevat de schade van één of meer prestaties; kan meerdere UZOVI's bevatten. De prestaties uit dezelfde periode van gegevensuitwisseling komen in één declaratiebericht (bestand) Bestandstructuur Inleiding De externe-integratievorm die wordt toegepast is de gestructureerde gegevensuitwisseling met behulp van meerdere recordtypen. Belangrijkste eigenschappen van de recordtypen zijn: de records met een vaste lengte; de velden binnen een record met een vaste veldlengte en positie. Voordelen van het toepassen van meerdere recordtypen zijn: het gebruik van kortere records; minder redundante informatie bij herhaald voorkomen van rubrieken Recordtypen In de Aanleverspecificaties DBC GGZ zijn, uitgaande van het generiek format en de objecten in het functioneel bericht, de volgende recordtypen van belang. Standaardbeschrijving Aanleverspecificaties DBC GGZ 13 / 37

14 voorkomens per bestand Prestatierecord Tariefrecord Tabel 5-1 Recordtypen en toepassing Code Betekenis Verplicht in de EI-standaard Verplicht in gebruik 01 voorlooprecord Ja Ja 04 prestatierecord Ja Ja 06 tariefrecord Ja Ja 99 sluitrecord Ja Ja De codering van de recordtypen heeft uitsluitend betekenis voor de identificatie van het recordtype; het heeft geen betekenis voor de rang- of volgorde van de records in een bestand Logische bestandstructuur De logische bestandstructuur met de relaties tussen de records is in tabel 5.2 beschreven. Tabel 5-2 Logische bestandstructuur Voorlooprecord heeft 1 Prestatierecord heeft 1 1 behoort bij 1 Tariefrecord heeft 1 Sluitrecord heeft 1 Standaardbeschrijving Aanleverspecificaties DBC GGZ 14 / 37

15 Figuur 5-1 Logische bestandstructuur Aanleverspecificaties DBC GGZ Logische bestandsstructuur: QG301 Bericht: Aanleverspecificaties QG Voorlooprecord 04 Prestatierecord PPrestatierecordPVerz 06 Tariefrecord 1 99 Sluitrecord Leesvolgorde: 1 1 van boven naar beneden, van links naar rechts Lijnverbindingen tussen records: 0 1 * Lijn zonder 'vorkje' of 'rondje': Bij één bovenste record hoort altijd één onderste record * Lijn met 'vorkje' en zonder 'rondje': Bij één bovenste record horen één of meerdere onderste records * Lijn met 'vorkje' en 'rondje': Bij één bovenste record horen geen, één of meerdere onderste records * Lijn zonder 'vorkje' en met 'rondje': Bij één bovenste record hoort geen of één onderste record Fysieke bestandstructuur Uitgangspunt voor het EI-bericht is dat de zender de logische en fysieke sleutels vult. De zender zet de records in een volgorde in het bestand, die wordt bepaald door de logisch/fysieke relatie (sleutels) tussen de records. Dit houdt in: per prestatie per detailrecord. Het bestand opent met een voorlooprecord en sluit met een sluitrecord. De logische relatie is aangegeven in de logische bestandstructuur (figuur 5-1). Hieronder volgt een voorbeeld van een fysieke volgorde van de records in een fictief bestand: Figuur 5-2 Voorbeeld fysieke bestandstructuur Voorlooprecord Prestatierecord: prestatie 1 Tariefrecord: tarief 1 Prestatierecord: prestatie 2 Tariefrecord: tarief 1 Tariefrecord: tarief 2 Prestatierecord: prestatie 3 Et cetera. Sluitrecord Figuur 5-1 en 5-2 bepalen de volgorde van de records in een bestand. Standaardbeschrijving Aanleverspecificaties DBC GGZ 15 / 37

16 Voorlooprecord Prestatierecord Tariefrecord Sluitrecord NB: de nummers van de records in het voorbeeld zijn illustratief. Het toekennen van logische/fysieke sleutelwaarden gebeurt op andere gronden. Fysieke sleutels De rubriek kenmerk record identificeert het recordtype van elk record in het bestand. Het kenmerk record is in de beschrijving van de recordlay-out te herkennen in de eerste twee cijfers van het rubrieknummer. De rubriek identificatie detailrecord geeft elk detailrecord in het bestand een volgnummer. Het veld identificatie detailrecord maakt een detailrecord in het bestand uniek Objecten per recordtype De verdeling van de objecten over de diverse recordtypen in een bestand is als volgt: Tabel 5-3 Objecten per recordtype TECH Technische gegevenselementen BERI Berichtinformatie algemeen ZVZA Zorgverzekeraar ZOVL Zorgverlener VERZ Verzekerdengegevens PRES Prestatiegegevens TARI Tarief/honorarium Tekenset Er volgt geen aanwijzing over een te gebruiken tekenset in een EI-bericht, omdat niet iedere partij de mogelijkheid heeft zich hieraan te conformeren. Het moet in principe mogelijk zijn om de meest gangbare diakritische tekens in een EI-bericht weer te geven. Met andere woorden, een "ö" mag in een EI-bericht niet geconverteerd worden naar bijvoorbeeld oe. Dit geeft problemen met het aantal posities in het desbetreffende veld. Standaardbeschrijving Aanleverspecificaties DBC GGZ 16 / 37

17 Carriage-Return/Line-Feed Achter ieder record moet een Carriage-Return/Line-Feed worden opgenomen. De posities die in beslag worden genomen door CR/LF zijn niet opgenomen in de beschreven recordlengte Procedure uitwisselen gegevens Aanleverspecificaties DBC GGZ Algemeen Voor de uitwisseling van de schadelastinformatie DBC GGZ-bestanden van zorgverzekeraar naar Vektis (via VECOZO) heeft Vektis een aantal procedures en richtlijnen opgesteld die in deze paragraaf worden uitgewerkt Periodiciteit versturen bericht Voor de aanlevering van de Schadelastinformatie DBC GGZ-bestanden gelden de volgende afspraken: Uitgangspunt zijn de verwerkte en betaalbaargestelde declaratiegegevens: dit zijn zowel de declaraties die bij een zorgverzekeraar via een EI-bericht (elektronisch) zijn aangeleverd als de declaraties die door de verzekerde zelf bij de zorgverzekeraars zijn ingediend (op papier). De aanleverperiode kan flexibel in het QG301-bericht worden aangegeven. Echter voor de QG301- standaard is vooralsnog afgesproken dat de aanlevering geschiedt op maandbasis. Omdat voor de huidige informatiebehoefte geen frequentere aanlevering nodig is. Twee weken na afloop van een maand dienen de declaraties bij Vektis aangeleverd te zijn Aanleveringmedium en procedure Het aanleveren van de bestanden aan Vektis verloopt via VECOZO. Meer informatie over deze aanleverprocedure is opgenomen in de notitie 'Ketenproces declaratieinformatie'. De aanlevering van de kwartaalbestanden vindt plaats in ASCII-formaat. De naam van het aanleverbestand is als volgt opgebouwd: VVVV_ EEJJMMDD_ EEJJMMDD_BBBBBBBBBBBB_<<code externe integratiebericht>>.asc VVVV De unieke aanduiding (4-cijferige code) van de aanleverende partij, volgens het UZOVI-register van Vektis (dit UZOVI-nummer is gelijk aan de waarde van het veld UZOVI-nummer indiener in het voorlooprecord van de QG301). _ Het underscore -teken, als herkenbaar scheidingsteken De waarde van VVVV in de bestandsnaam dient gelijk te zijn aan de waarde van het veld UZOVI indiener (0106) in het voorlooprecord van de QG301 Standaardbeschrijving Aanleverspecificaties DBC GGZ 17 / 37

18 EEJJMMDD Is de begindatum verwerkingsperiode (8 posities) waarvoor geldt: EE Eeuwaanduiding van begindatum verwerkingsperiode (2 posities) JJ Jaaraanduiding van begindatum verwerkingsperiode (2 posities) MM DD Maandaanduiding van begindatum verwerkingsperiode (2 posities) Dagaanduiding van begindatum verwerkingsperiode (2 posities) De waarde van de begindatum verwerkingsperiode in de bestandsnaam dient gelijk te zijn aan de waarde van begindatum verwerkingsperiode in het voorlooprecord van de QG301. _ Het underscore -teken, als herkenbaar scheidingsteken EEJJMMDD Is de einddatum verwerkingsperiode (8 posities) waarvoor geldt: EE Eeuwaanduiding van einddatum verwerkingsperiode (2 posities) JJ Jaaraanduiding van einddatum verwerkingsperiode (2 posities) MM Maandaanduiding van einddatum verwerkingsperiode (2 posities) DD Dagaanduiding van einddatum verwerkingsperiode (2 posities) De waarde van de einddatum verwerkingsperiode in de bestandsnaam dient gelijk te zijn aan de waarde van einddatum verwerkingsperiode in het voorlooprecord van de QG301. _ Het underscore -teken, als herkenbaar scheidingsteken BBBBBBBBBBB Het bron-id declaratieverwerkingssysteem is het unieke nummer (12 posities) dat de bron van declaratieverwerkingssysteem van de zorgverzekeraar identificeert. De uitvulspaties hoeven niet in de bestandsnaam opgenomen te worden. De waarde van BBBBBBBBBBBB in de bestandsnaam dient gelijk te zijn aan de waarde van het veld bron-id (0111) in het voorlooprecord van de QG301. (Exclusief de spaties). Code externe-integratiebericht 512 Code externe-integratiebericht (3 posities) betreffende aanleverspecificaties DBC GGZ ASC = De vaste extensie om aan te geven dat het bestand in ASCII-formaat is. De waarde van de code externe-integratiebericht in de bestandsnaam dient gelijk te zijn aan de waarde van het veld code externe integratiebericht (0102) in het voorlooprecord van de QG301 Standaardbeschrijving Aanleverspecificaties DBC GGZ 18 / 37

19 Wijzigingen van declaratieverwerkingssysteem Wanneer er overgegaan wordt naar een ander declaratieverwerkingssysteem, moet er door de zorgverzekeraar een nieuwe bron-id aan Vektis worden gemeld. In dat geval moet de schade die verwerkt is in het oude declaratieverwerkingssysteem gescheiden worden aangeleverd van de schade die verwerkt is in het nieuwe declaratieverwerkingssysteem. Dit betekent dat er in die situatie over dezelfde verwerkingsperiode twee bestanden aangeleverd moeten worden. Door het toevoegen van de bron-id declaratieverwerkingssysteem aan de bestandsnaam kunnen declaraties over een gelijke verwerkingsperiode die uit een verschillende bron komen van elkaar onderscheiden worden. De referentienummers van het schadebestand hoeven niet uniek te zijn over het declaratieverwerkingssysteem heen, dit is optioneel. Als er aangeleverd gaat worden vanuit een nieuw declaratieverwerkingssysteem heen kan er weer gestart worden bij nummer 001. In de volgende figuur is weergegeven hoe de bestandsnaam en het voorlooprecord in deze situatie gevuld dienen te worden. Situatie: Een verzekeraar (UZOVI-nummer 8888) krijgt per 1 januari 2012 een nieuw declaratieverwerkingssysteem. Voor het declaratieverwerkingssysteem dat tot 2011 gebruikt is, is de bron-id A; voor het declaratieverwerkingssysteem dat tot 2012 gebruikt is, is de bron-id B. Een verzekeraar levert twee bestanden aan van declaraties die verwerkt zijn van 1 januari 2012 tot en met 8 januari Deze declaraties zijn deels verwerkt met het oude declaratieverwerkingssysteem (bron-id A) en deels met het nieuwe declaratieverwerkingssysteem (bron-id B). Bestand 1 bevat de declaraties die verwerkt zijn met het oude declaratieverwerkingssysteem (bron-id A) en bestand 2 bevat de declaraties die verwerkt zijn met het nieuwe declaratieverwerkingssysteem (bron-id B). Het bestand wordt gemaakt op 9 januari Het zijn twee aparte bestanden dus allebei de bestanden hebben een ander referentienummer. Voor de overzichtelijkheid heeft het veld referentienummer dit schadebestand in onderstaand voorbeeld 5 posities in plaats van 30. Bestand 1: bron-id A Bestandsnaam: 8888_ _ _ A_512_ASC 0106 UZOVInummer 0107 Dagtekening aanmaak 0108 Begindatum verwerkingsperiode 0109 Einddatum verwerkingsperiode 0110 Referentienummer dit schadebestand 0111 Bron-id declaratieverwerkingssysteem indiener A Standaardbeschrijving Aanleverspecificaties DBC GGZ 19 / 37

20 Bestand 2: bron-id B Bestandsnaam: 8888_ _ _ B_512_ASC 0106 UZOVInummer indiener 0107 Dagtekening aanmaak 0108 Begindatum verwerkingsperiode 0109 Einddatum verwerkingsperiode 0110 Referentienummer dit schadebestand 0111 Bron-id declaratieverwerkingssysteem B Bulkboekingen De schadegegevens in Schadelastinformatie DBC GGZ hebben betrekking op individuele verzekerden. Indien schade niet aan individuele verzekerden kan worden toegewezen dienen deze kosten niet in Schadelastinformatie te worden opgenomen Informatiebeveiliging De International Organization for Standardization (ISO) heeft in 2000 de NEN-ISO/IEC uitgebracht op basis van de Code voor informatiebeveiliging uit Een concept van de inmiddels te vernieuwen NEN- ISO/IEC en de Code voor Informatiebeveiliging zijn gebruikt als basis voor de NEN 7510 (NL). De zorgverzekeraars hanteren de Code voor informatiebeveiliging als vertrekpunt. De NEN 7510 (NL) Medische informatica informatiebeveiliging in de zorg Algemeen van april 2004 is toegespitst op de technologie van de zorgverleners. De voorschriften voor informatiebeveiliging worden regelmatig vernieuwd, raadpleeg voor actuele voorschriften: De meeste EI-berichten hebben betrekking op financieel/administratieve gegevens. Dit document beschrijft de Aanleverspecificaties DBC GGZ, waarin met name de inhoudelijke aspecten van het elektronisch uitwisselen van berichten worden beschreven. Gezien de aard (gevoeligheid) van de te verzenden gegevens is het van belang dat aandacht wordt geschonken aan informatiebeveiliging. Bij de opzet van de aanleverspecificaties is rekening gehouden met de informatie die uitgewisseld mag worden. Dit heeft geresulteerd in de keuze van de in de aanleverspecificaties beschreven gegevens. Voor het vertrouwelijk en veilig verzenden van EI-berichten is het van belang dat de informatie aankomt bij de bedoelde persoon of organisatie, onderweg niet is veranderd of verminkt, en dat de zendende en ontvangende techniek gelijk zijn. Dit dient volgens de Code voor informatiebeveiliging op een passende wijze te worden geregeld. Hierbij spelen onderwerpen zoals: identificatie, authenticatie, versleuteling, PKI, logging, autorisatie etcetera. De aanleverspecificaties gaat niet verder op deze onderwerpen in. Betrokken organisaties dienen dit op een passende wijze te regelen. Standaardbeschrijving Aanleverspecificaties DBC GGZ 20 / 37

21 Controle kwaliteit bestand Er wordt een technische controle conform de bedrijfs- en controleregels in het bij deze EI-standaard behorende RBC-document uitgevoerd door VECOZO. Op een technisch correct bestand zal Vektis vervolgens plausibiliteitcontroles uitvoeren. Tijdens de ontwikkeling van Schadelastinformatie QG301 kunnen de technische controles ook door een zorgverzekeraar zelf worden uitgevoerd binnen Portes. Hiervoor heeft Vektis een webapplicatie beschikbaar die is te benaderen via Voor meer informatie over het gebruik van Portes kunt u op deze website de instructies benaderen Burgerservicenummer De Wet gebruik Burgerservicenummer in de zorg (Wbsn-z) is per 1 juni 2008 in werking getreden. Na 1 juni 2008 is er een invoeringsperiode van 1 jaar geweest. Vanaf 1 juni 2009 moet 1 het BSN gebruikt worden. De verplichting om het BSN te gebruiken geldt voor alle zorgaanbieders, indicatieorganen en zorgverzekeraars en AWBZ-verzekeraars. Zij moeten het BSN gebruiken bij het onderling uitwisselen van gegevens over patiënten of cliënten. De belangrijkste uitgangspunten voor het gebruik van het BSN in EI-standaarden zijn: Het BSN wordt in alle EI-standaarden ingevoerd, inclusief alle bestaande (oude) standaarden. Het BSN wordt mandatory. Dit omdat er van wordt uitgegaan dat alle personen die zorg kunnen ontvangen over een BSN beschikken. Zo zullen buitenlanders die in Nederland verzekerd worden waarschijnlijk een BSN of een Registratienummer voor niet ingezetenen (RNI) ontvangen. Het BSN wordt de belangrijkste verzekerde-identificatiesleutel in EI-standaarden. Andere bestaande verzekerde-identificaties blijven relevant zolang niet alle gebruikers van EI-standaarden het BSN in hun administratie opgenomen hebben (overgangsperiode). De verzekerde-identificatienummers krijgen een vaste volgorde in de EI-standaarden over alle EI-standaarden heen. Dit sluit aan bij de wens van gebruikers om records in de verschillende EI-standaarden zoveel mogelijk te uniformeren (generiek format). Verzekerde-identificatienummers die in een bepaalde EI-standaard niet nodig zijn worden hierin niet opgenomen. NB: in bijzondere omstandigheden kan van bovenstaande uitgangspunten afgeweken worden. Een voorwaarde voor de toepassing in de EI-berichten is dat de zender en ontvanger over het BSN van de verzekerde mogen beschikken. In deze EI-standaard is het volgende gekozen: 1 Er is een hele kleine populatie die blijvend geen BSN heeft, maar toch verzekerd is. Hiervoor geldt de verplichting tot gebruik van het BSN niet. Zie voor verdere informatie de Invulinstructie. Standaardbeschrijving Aanleverspecificaties DBC GGZ 21 / 37

22 Burgerservicenummer (BSN), verzekerdennummer, UZOVI-nummer risicodrager en UZOVI-nummer volmacht zijn de sleutel. Het BSN moet verplicht gevuld worden als het BSN bekend is in de polisadministratie van de zorgverzekeraar. Als de zorgverzekeraar constateert dat de verzekerde geen BSN (of RNI) of sofinummer heeft, dan vullen met een dummywaarde van negens (9x9). Zie het document Invulinstructie Het aanleveren van mutaties Mutaties kunnen op twee manieren aangeleverd worden: 1. Door heraanlevering van bestanden 2. Door het aanleveren van correcties op basis van de debet-credit systematiek Bij de heraanlevering van bestanden spelen de velden begin- en einddatum verwerkingsperiode en verwerkingsdatum een centrale rol. Bij de correctie op basis van de debet-credit systematiek spelen de velden identificatie prestatierecord en identificatie gerelateerd debet prestatierecord een centrale rol. Op beide methoden wordt in deze paragraaf ingegaan Heraanlevering van bestanden De mogelijkheid bestaat om een eerder aangeleverd bestand (deels) te vervangen. In geval van heraanlevering zal Vektis alle records van dezelfde verwerkingsdatum die eerder zijn aangeleverd onder hetzelfde UZOVI-nummer indiener op non-actief zetten en zullen de heraangeleverde records met dezelfde verwerkingsdatum als de actieve records gezien worden. Dit betekent dat de heraanlevering alle records van de verwerkingsdatum moet bevatten die opgenomen moeten worden als actieve records en niet alleen die records die gemuteerd zijn. Aandachtspunten bij het heraanleveren van (deelbestanden) De aangeleverde bestanden die via VECOZO naar Vektis worden doorgestuurd, worden geïdentificeerd op basis van het veld UZOVI-nummer indiener (0106) en bron id (0111). Om na te gaan of het om een nieuwe aanlevering gaat of een heraanlevering wordt nagegaan of er al records zijn aangeleverd voor deze indiener en bron, die binnen de periode van het bestand vallen (qua verwerkingsdatum). Zo ja, dan worden alle records uit het eerder aangeleverde bestand die vallen binnen deze periode afgesloten en worden de nieuwe records de actieve records. De aanmaakdatum (0107) wordt gebruikt om de volgorde van bestanden aan te geven. Om de bestanden in de juiste volgorde te kunnen verwerken is het belangrijk dat de meest actuele gegevens van de desbetreffende verwerkingdatum, de meest actuele aanmaakdatum hebben. Wijze van aanleveren Deze werkwijze stelt eisen aan de wijze waarop de verzekeraar aanlevert: In geval van heraanlevering moet de verzekeraar dezelfde UZOVI-nummer vullen in het veld UZOVI indiener als aangeleverd is in de te vervangen aanlevering Standaardbeschrijving Aanleverspecificaties DBC GGZ 22 / 37

23 De heraanlevering moet dezelfde UZOVI-nummers risicodrager en volmacht bevatten als de te vervangen aanlevering. Het te vervangen bestand wordt geïdentificeerd aan de hand van het UZOVI indiener, Bron-id, start- en einddatum verwerkingsperiode. De verwerkingsperiode moet overeenkomen, anders kan de heraanlevering niet verwerkt worden. Het is belangrijk dat de aanmaakdatum van de heraanlevering aangepast is ten opzichte van de te vervangen aanlevering. Deze wordt gebruikt om de volgorde van bestanden aan te geven. De heraanlevering moet de volledige set records voor die periode bevatten: o Ook de records die niet gecorrigeerd zijn. o Alle actuele prestatie- en tariefrecords. o De schadelastinformatie van alle risicodragers en volmachten die ook voorkwamen in het te vervangen bestand. o Ook creditrecords op voorgaand bestand. Een heraanlevering dient dezelfde UZOVI-selectie (risicodrager en volmacht) te bevatten als het bestand / de bestanden dat / die (deels) vervangen wordt / worden. Als in een heraanlevering minder risicodragers of volmachten opgenomen worden, zal dit als een verwijdering worden opgevat. Dit wordt toegelicht met een voorbeeld. Situatie 1 laat zien hoe de heraanlevering wordt verwerkt als dezelfde UZOVI-selectie aangeleverd wordt en situatie 2 als niet dezelfde UZOVI-selectie wordt aangeleverd. Situatie 1: de heraanlevering bevat dezelfde UZOVI-selectie De verwerking van de gegevens verloopt via de centrale verwerkingseenheid van CZ (9964). Er wordt op 6 februari 2012 een aanlevering gedaan voor de maand januari waarin alle drie de risicodragers (0104, 0201 en 7119) zijn opgenomen. Vervolgens wordt er op 19 februari 2012 een heraanlevering gedaan voor de maand januari waarin ook alle drie de risicodragers zijn opgenomen Datum 0108 Begindatum verwerkingsperiode 0109 Einddatum verwerkings Referentienummer dit 0106 UZOVInummer indiener 0404 UZOVI-nummer risicodrager aanmaak periode schadebestand , 0201 en , 0201 en 7119 Alle records van de UZOVI's 0104, 0201 en 7119 met aanmaakdatum worden afgesloten en worden 'vervangen' door de records van de UZOVI's 0104, 0201 en 7119 met aanmaakdatum Situatie 2: de heraanlevering bevat niet dezelfde UZOVI-selectie De verwerking van de gegevens verloopt via de centrale verwerkingseenheid van CZ (9964). Er wordt op 6 februari 2012 een aanlevering gedaan voor de maand januari waarin alle drie de risicodragers (0104, 0201 en 7119) zijn opgenomen. Vervolgens wordt er op 19 februari 2012 een heraanlevering gedaan voor de maand januari waarin alleen risicodrager 7119 opgenomen wordt Datum 0108 Begindatum verwerkingsperiode 0109 Einddatum verwerkingsperio 0110 Referentienummer dit 0106 UZOVInummer indiener 0404 UZOVI-nummer risicodrager Standaardbeschrijving Aanleverspecificaties DBC GGZ 23 / 37

24 aanmaak de schadebestand , 0201 en Alle records van de UZOVI's 0104, 0201 en 7119 met aanmaakdatum worden afgesloten en alleen de records van UZOVI-nummer 7119 worden vervangen door de records met aanmaakdatum De records met aanmaakdatum met UZOVI-nummer 0104 en 0201 worden afgesloten maar niet vervangen. NB: Als een verzekeraar in de aanleveringen niet altijd dezelfde UZOVI-selectie opneemt, dient de heraanlevering dezelfde periode te bestrijken als het bestand dat vervangen moet worden. Dit is van belang voor de verwerking van de gegevens door Vektis. Tijdstip van heraanlevering In verband met de verwerking van de gegevens kunnen heraanleveringen op basis van plausibiliteit of voortschrijdend inzicht pas plaatsvinden als de verzekeraar van Vektis een ontvangstbevestiging heeft gekregen van het bestand dat vervangen dient te worden. Doordat de aanlevering via VECOZO verloopt, heeft Vektis er geen zicht op of zij de bestanden in de juiste volgorde ontvangt. Dit geldt niet voor technische uitval op basis van een retourbestand Mutatie op basis van debet-credit systematiek De mogelijkheid bestaat om een eerder aangeleverd debetrecord te corrigeren. Bij correcties dient gebruik gemaakt te worden van de debet-creditsystematiek. De velden identificatie prestatierecord en identificatie voorgaand gerelateerd debet prestatierecord spelen een centrale rol bij de verwerking van de correcties. De waarde van het veld identificatie prestatierecord is uniek, niet alleen op bestandsniveau, maar ook over bestanden van eenzelfde Bron-id heen. Dat betekent dat de waarde van het veld identificatie maar éénmaal mag worden aangeleverd aan Vektis (via VECOZO), tenzij het om een heraanlevering van een bestand gaat. Indien er na het aanleveren van een correctie op een eerder aangeleverd debetrecord een nieuw debetrecord wordt aangeleverd, mag dit debetrecord niet met dezelfde waarde identificatie prestatierecord worden aangeleverd. Dit record heeft namelijk geen relatie met de voorgaande records die op dezelfde prestatie betrekking hebben. De debet/-creditsystematiek houdt in dat: De debetprestatie volledig wordt gecrediteerd d.m.v. een aanlevering van een creditprestatie ('Indicatie debet/credit' is C) met een nieuw 'Identificatie prestatienummer' en een verwijzing naar de te crediteren debetprestatie via vulling van het veld 'Identificatie gerelateerd debet prestatierecord'. De creditprestatie gevolgd wordt door een nieuwe debetprestatie met een nieuw 'Identificatie prestatienummer'. Deze is niet meer te relateren aan de oorspronkelijke debetprestatie. De debetprestatie vertegenwoordigt de mutatie, wanneer de oorspronkelijke debetprestatie komt te vervallen volgt geen debetprestatie (case 3 in illustratie). Voor een creditprestatie gelden de volgende regels: Standaardbeschrijving Aanleverspecificaties DBC GGZ 24 / 37

25 o o o o De samenstelling van de creditprestatie hoeft niet identiek te zijn aan de oorspronkelijke debetprestatie. Zo hoeven de bedragen niet gelijk te zijn en hoeven niet alle tariefrecords te worden aangeleverd. De 'Indicatie credit' en 'Identificatie gerelateerd debet prestatierecord' zijn voor het datawarehouse bij Vektis de triggers om de oorspronkelijke debetprestatie volledig te crediteren. Het creditprestatierecord kan in hetzelfde bestand aangeleverd worden als het voorgaande gerelateerde debetprestatierecord. Op de volgorde van aanlevering (creditprestatierecord voor of na oorspronkelijk debetprestatie) wordt niet gecontroleerd. Op een creditrecord kan geen mutatie worden uitgevoerd, een creditrecord blijft altijd een creditrecord. Standaardbeschrijving Aanleverspecificaties DBC GGZ 25 / 37

26 Onderstaand figuur illustreert voor een drietal cases hoe de aanlevering van debetprestatierecords en mutaties aan Vektis verloopt. Muteren prestaties QG301 Voor wijziging ontstaan binnen het declaratieverkeer op een debet prestatie en onderliggende tariefrecords. QG301 Schadelastinformatie Zorgverzekeraar oorspronkelijke prestatie - Prestatie id 1 Debet - Tarief a 75 euro Debet - Tarief b 25 euro Debet - Prestatie id 1 Debet - Tarief a 75 euro Debet - Tarief b 25 euro Debet wijziging tarief a? Ja: case 1 - Prestatie id 2 Debet voorg id 1 - Tarief a 50 euro Debet - Tarief b 25 euro Debet - Prestatie id 2 Credit voorg id 1 - Tarief a 75 euro Credit - Tarief b 25 euro Credit - Prestatie id 3 Debet - Tarief a 50 euro Debet - Tarief b 25 euro Debet Mutaties op prestatie nee creditering tarief a? Ja: case 2 - Prestatie id 2 Debet voorg id 1 - Tarief b 25 euro Debet - Prestatie id 2 Credit voorg id 1 - Tarief a 75 euro Credit - Tarief b 25 euro Credit - Prestatie id 3 Debet - Tarief b 25 euro Debet nee creditering prestatie 1? Ja: case 3 - Prestatie id 2 Credit voorg id 1 - Tarief a 75 euro Credit - Tarief b 25 euro Credit -Prestatie id 2 Credit voorg id 1 - Tarief a 75 euro Credit - Tarief b 25 euro Credit Standaardbeschrijving Aanleverspecificaties DBC GGZ 26 / 37

27 Voor het beschrijven van de verschillende cases zijn de volgende, eerder beschreven, ontwerpkeuzes gehanteerd: Debet- en creditprestaties worden gekoppeld aan de hand van 'Identificatie dit prestatierecord' en 'Identificatie voorgaand gerelateerd debet prestatierecord'. Een creditprestatie leidt altijd tot volledige creditering van het voorgaande gerelateerde prestatierecord inclusief tariefrecords. Een creditprestatie hoeft niet identiek te zijn aan de voorgaande gerelateerde debetprestatie, maar moet wel voldoen aan de volgende eisen: o Minimaal 1 tariefrecord; o De velden 'Indicatie credit' en 'Identificatie gerelateerd debet prestatierecord' uit het prestatierecord zijn relevant, de rest van de velden van het prestatie- en bijbehorende tariefrecords zijn niet relevant Buitenlandverzekerden Binnen de informatiesystemen van Vektis wordt geen informatie vastgelegd over personen die geen basisverzekering hebben bij een Nederlandse zorgverzekeraar. Personen die in het buitenland wonen en op grond van werk in Nederland verzekerd zijn voor Zvw en AWBZ worden meegenomen, als het gaat om zorg die in Nederland is ontvangen. Personen die in Nederland wonen, in het buitenland werken en uit dien hoofde aldaar verzekerd zijn, worden niet meegenomen. Standaardbeschrijving Aanleverspecificaties DBC GGZ 27 / 37

28 6. EI-retourinformatie in het kader van schadeafhandeling 6.1. Inleiding Door de introductie van de VECOZO-applicatie VSP-INFO (VECOZO SchakelPunt- Informatierouteringssysteem) zijn de volgende controleprocessen van belang: Het controleren van schade bij VECOZO niveau 1 t/m 6; Het controleren van schade door Vektis op plausibiliteit; In totaal spelen dan de volgende stromen een rol. Figuur 6-1 Stromen in relatie tot controle schade zorgverzekeraar VECOZO Vektis Tabel 6-1 Stromen in relatie tot controle schade Nr Van Naar Omschrijving stroom 1 Zorgverzekeraar VECOZO Schade 2.1 VECOZO Zorgverzekeraar In technisch opzicht goedgekeurd bestand met declaratieinformatie. 2.2 VECOZO Zorgverzekeraar Retourbericht voor in technisch opzicht afgekeurd bestand met declaratieinformatie Bijzonderheden Is gelijk aan de stroom met nr. 1 Als stroom 2.1 wordt verstuurd, is stroom 2.2 niet van toepassing. VECOZO verstuurt een statusbericht naar zorgverzekeraar (niet in schema) Aangegeven wordt in het retourbericht dat dit afkomstig is van VECOZO. In het retourbericht wordt in geval van afkeur op recordniveau het hele bestand afgekeurd en alleen de afgekeurde records in de retourinformatie opgenomen. In het geval van een afkeur op bestandsniveau wordt alleen het voorloopen sluitrecord in de retourinformatie opgenomen. Als stroom 2.2 wordt verstuurd, is stroom 2.1 niet van toepassing. VECOZO stuurt een statusbericht naar Standaardbeschrijving Aanleverspecificaties DBC GGZ 28 / 37

29 Nr Van Naar Omschrijving stroom 3 Vektis VECOZO Plausibiliteit rapportage 4.1 VECOZO Vektis Ontvangst bevestiging Plausibiliteit rapportage 4.2 VECOZO Zorgverzekeraar Plausibiliteit rapportage Bijzonderheden zorgverzekeraar (niet in schema). Aan de rapportage is te zien dat deze van Vektis afkomstig is. Vektis stuurt geen retourbericht QG301. Dit wordt als response via webservice gedaan Afbakening doel EI-retourinformatiebericht Het doel van een EI-retourinformatiebericht is: Zender van een EI-schadebericht informeren over de technische afkeuring beoordeling (technisch) van het bericht door de ontvanger. Een EI-retourinformatiebericht heeft niet als doel: Het sturen van een ontvangstbevestiging: de feitelijke ontvangstbevestiging geeft VECOZO af via het VSP-info middels de statusinformatie. Het doorgeven van correcties op de schadegegevens aan de zorgverzekeraar. Uit hoofde van kwaliteitsverhoging van het schadeverkeer committeren de gebruikers zich aan het gebruiken van het EI-retourinformatiebericht. Door het traceren van structurele fouten in een EI-schadebericht en het communiceren hierover, kan uitval van een EI-schadebericht gereduceerd worden Beschrijving van de controleprocessen In deze paragraaf worden de controleprocessen verder uitgewerkt. De beschrijving beperkt zich daarbij wel tot technische controles niveau 1 t/m Inleiding VECOZO als ontvanger van een EI-schadebericht voert eerst een technische/inhoudelijk controle op bestandsniveau uit (beschreven in paragraaf 6.3.2). Als deze controle positief wordt doorlopen dan wordt vervolgens een technische/inhoudelijke controle op recordniveau uitgevoerd (beschreven in paragraaf 6.3.3). Standaardbeschrijving Aanleverspecificaties DBC GGZ 29 / 37

30 De controle op bestandsniveau, gericht op de technische/inhoudelijke aspecten, heeft tot doel het bestand c.q. bericht als geheel te beoordelen. Hiertoe wordt het bestand c.q. worden alle records in het bestand als geheel benaderd. Het kan leiden tot de volgende situaties: De constatering dat het bestand totaal niet leesbaar en verwerkbaar is; het bestand wordt afgekeurd en retour gestuurd. Er volgt geen verdere controle op recordniveau. De constatering dat het format van het bestand niet correct is; het bestand wordt afgekeurd op technische gronden. Er volgt geen verdere controle op recordniveau. De constatering dat het bestand onjuist is, het bestand wordt afgekeurd op logische gronden. Er volgt geen verdere controle op recordniveau. De constatering dat de berichtgegevens in het bestand niet juist zijn of niet overeenkomen met de werkelijke aantallen records c.q. bedragen in het bestand; het bestand wordt afgekeurd op logische gronden. Er volgt geen verdere controle op recordniveau. De constatering dat het bestand leesbaar, verwerkbaar, technisch en logisch akkoord is. Er volgt een controle op recordniveau. De controle op recordniveau, gericht op technische/inhoudelijke aspecten, heeft tot doel de gegevens van een prestatie/declaratie, tarief te beoordelen. De controle op recordniveau is opgesplitst in een prestatieniveau en een tariefniveau. Het kan leiden tot de volgende situaties: De constatering dat één of meer gegevens op prestatie-/declaratieniveau niet juist zijn. De desbetreffende records op prestatie-/declaratieniveau en alle desbetreffende records van een prestatie op tariefniveau worden retourgestuurd. De constatering dat één of meer gegevens op tariefniveau niet juist zijn. De desbetreffende records op prestatieniveau en de desbetreffende records op tariefniveau worden retourgestuurd. De constatering dat alle gegevens op prestatie-/tariefniveau inhoudelijk goed zijn en daarmee het bestand volledig is goedgekeurd. VECOZO stuurt in geval van afkeur op recordniveau de afgekeurde records retour (hele bestand is hiermee afgekeurd) Controles op bestandsniveau De ontvanger van een EI-schadebericht voert diverse technische/inhoudelijke controles op bestandsniveau uit, om een antwoord te krijgen op een aantal vragen. De diverse controles zijn in tabel 6-1 weergegeven. Standaardbeschrijving Aanleverspecificaties DBC GGZ 30 / 37

31 Tabel 6-2 Controle op bestandsniveau Controle van Constatering Actie (toelichting) Horen de bij elkaar geplaatste records logisch bij elkaar? Ontbreken er records? Hebben alle records de juiste lengte? Zijn de berichtgegevens in het voorlooprecord juist? Eén of meer records horen logisch niet bij elkaar. Eén of meer relevante records ontbreken. Eén of meer records zijn onjuist qua lengte. Eén of meer relevante gegevens ontbreken of zijn onjuist. afkeuren bestand De zender zet de records in een volgorde in een bestand, die wordt bepaald door de logische/fysieke relatie tussen de detailrecords (zie figuur 5-1). Om er zeker van te zijn dat de aanwezige volgorde van de detailrecords logisch/fysiek juist is, worden de detailrecords door de ontvanger gecontroleerd via de logische/fysieke sleutelvelden. Als de fysieke relatie tussen bijvoorbeeld een prestatierecord en een tariefrecord niet juist is, wordt het gehele EI-declaratiebericht afgekeurd, aangezien het bericht technisch onjuist is en derhalve niet verwerkt kan worden. Het voorloop- en sluitrecord van het EIretourinformatiebericht worden retourgezonden. afkeuren bestand Als een verplicht record of een conditioneel record, dat op basis van de conditie (niet) van toepassing is, ontbreekt of ten onrechte is opgenomen, dan is sprake van een technische fout. In dit geval wordt het gehele EI-declaratiebericht afgekeurd. Het voorloop- en sluitrecord van het EI-retourinformatiebericht worden retourgestuurd. afkeuren bestand Als een record te kort of te lang is, dan is minimaal één rubriek niet juist van lengte. Dit kan ook meerdere rubrieken betreffen. Hiermee is sprake van een technische fout. Een technisch fout EIschadebericht kan niet verwerkt worden. In dit geval dient het gehele EI-schadebericht te worden afgekeurd. Het voorloop- en sluitrecord van het EI-retourinformatiebericht worden retourgezonden. afkeuren bestand In het voorlooprecord zijn diverse gegevens opgenomen om het schadebericht te identificeren, adresseren et cetera. Als er gegevens in het voorlooprecord ontbreken of onjuist zijn, dan is het schadebericht technisch/inhoudelijk niet juist. Voorbeelden zijn: - de indiener is onbekend; Het gehele EI-schadebericht wordt afgekeurd. Het voorloop- en sluitrecord van het EI-retourinformatiebericht worden retourgezonden. Standaardbeschrijving Aanleverspecificaties DBC GGZ 31 / 37