Architectuurontwerp e-declareren

Transcriptie

1 Architectuurontwerp e-declareren Status : Concept Versie : 1.1 Ref : ADPD.007 Postbus 262, 2260 AG Leidschendam Datum : Overgoo 11, 2266 JZ Leidschendam telefoon: (070) info@nictiz.nl /

2

3 Inhoudsopgave 1. Inleiding Doel en doelgroep Scope van dit architectuurontwerp Beschrijvingsmodel Opbouw 8 2. Uitgangspunten voor dit architectuurontwerp 9 3. De businesslaag Achtergrond declaratiecasus Globaal overzicht Procesaspecten Welke processen Identificatie en authenticatie Tijdigheid van processen Beveiliging Eenduidige berichtspecificaties en codestelsels Organisatorische aspecten Zorgaanbieder Zorgverzekeraar Tussenschakels Vierde domein partijen De Registerhouders De basisinfrastructuur en het Landelijk Schakelpunt Het declaratieportaal Het informatieportaal voor codestelsels Benodigde infrastructurele diensten Beveiligde communicatie Het declaratieportaal Het informatieportaal voor codestelsels Inrichtingsaspecten Geen gegevens vastleggen bij portaal Vinden van een zorgverzekeraar Gebruik AGB code Eisen aan zorgsystemen Informatielaag Berichten Coderingsstelsels Identificatie, authenticatie en autorisatie Functionaliteit Functionaliteit van het declaratieportaal Functionaliteit van aangesloten systemen Functionaliteit van het informatieportaal voor codestelsels 32 Architectuurontwerp e-declareren - 1

4 4.4.4 Infrastructuur Beveiliging Interactieprincipes declaratieverkeer Interactieprincipes informatieportaal codestelsels De technische laag Invulling van het service model Netwerkniveau en transport Interoperabiliteit/berichtcommunicatie Infrastructurele toepassingen Toepassingen Beveiliging, continuïteit en beheer Vertrouwelijkheid Identificeren en authenticeren Integriteit en onweerlegbaarheid Technische eisen PKI Technische eisen aan aangesloten systemen Migratieaspecten Introductie BSN Introductie identificerend stelsel Autorisatie voor declaratieverkeer RINIS AGB en UZI HL7 als berichtstandaard Testfaciliteiten Concurrentieneutrale architectuur Architectuurontwerp e-declareren

5 Management Samenvatting Het onderzoeksinstituut EIM heeft in opdracht van de Commissie de Beer in 2001 de omvang van de administratieve lasten en het maximale besparingspotentieel van het declaratieproces berekend. Een herevaluatie door KPMG BEA in opdracht van CVZ heeft de berekeningen van EIM in grote lijnen bevestigd. De omvang van de administratieve lasten is uiteindelijk becijferd op 460 miljoen per jaar. Het besparingspotentieel is geschat op miljoen per jaar. De jaarlijkse exploitatiekosten van implementatie van de geformuleerde verbetervoorstellen zijn in bovengenoemd onderzoek ingeschat tussen de 3 en 30 miljoen per jaar. Dit vormt de businesscase voor de declaratiecasus. Om deze casus te realiseren is een programma opgestart voor het realiseren van de businesscase. Het programma kent een aantal deelprojecten. Een van deze deelprojecten is het project architectuur declaratiecasus dat door NICTIZ wordt uitgevoerd. Dit project heeft tot doel om a) de referentieprocessen op te stellen, b) plannen op te stellen voor verbetering van de codestelsels die in het declaratieberichtverkeer toegepast worden en c) een architectuurbeschrijving op te stellen voor de declaratiecasus. Het voorliggende document betreft de architectuurbeschrijving. Het uitgangspunt is om zoveel mogelijk aan te sluiten bij het AORTA-architectuurontwerp voor een basisinfrastructuur in de zorg 1. Om echter per de doelstellingen van de declaratiecasus te kunnen halen, is het nodig geweest om op punten af te wijken van dit architectuurontwerp en aan te sluiten bij bestaande voorzieningen. Belangrijk voorbeeld hiervan is om gebruik te maken van bestaande EI-standaarden 2 voor declaratieverkeer. Op termijn is het doel om de architectuur voor e-declareren te integreren met het AORTA architectuurontwerp. Het architectuurontwerp e-declareren beschrijft de verschillende onderdelen van de declaratiecasus en de onderlinge samenhang. Dit betreft de infrastructuur, het identificerend stelsel dat benodigd is voor betrouwbare en veilige communicatie en de benodigde voorzieningen voor het declaratieverkeer zoals een declaratieportaal. Deze beschrijving bevat niet de referentieprocessen of de verbeterplannen voor de codestelsels. Hiervoor wordt verwezen naar de projecten 'referentieprocessen e-declareren' en 'effectief codebeheer'. Het architectuurontwerp gaat uit van een hoog beveiligingsniveau. Deze keuze is gemaakt om de volgende redenen: In de berichten die uitgewisseld worden in het kader van de declaratiecasus is zorginhoudelijke informatie aanwezig. Om privacyredenen dient deze informatie goed beveiligd te worden; Voor identificatie van de patiënt wordt gebruik gemaakt van het Burger Service Nummer (BSN). Vanuit de Wet BSN in de Zorg worden eisen gesteld ten aanzien van de beveiliging, zoals een identificerend stelsel met authentieke registers voor identificatie en authenticatie van de communicerende partijen. 1 Zie 2 EI-standaarden staat voor standaarden voor externe integratie. Architectuurontwerp e-declareren - 3

6 Dit identificerend stelsel zal bestaan 3 uit de volgende registers: Het UZI-register voor zorgaanbieders; Het UZOVI-register voor zorgverzekeraars; Het VDZ-register (Vierde Domein in de Zorg) voor partijen die buiten het domein van UZI en UZOVI vallen; Het SBV (Sectorale Beheers Voorziening) voor BSN voor patiënt/verzekerde. Voor de infrastructuur ter ondersteuning van het berichtverkeer wordt aangesloten bij de basisinfrastructuur in de zorg, die wordt gerealiseerd op basis van het architectuurontwerp en specificaties van NICTIZ (AORTA). In 2006 wordt het nieuwe zorgstelsel ingevoerd. De impact van deze ontwikkeling op de declaratiecasus wordt nader onderzocht. In dit ontwerp zijn de gevolgen hiervan nog niet opgenomen, hoewel al zoveel mogelijk rekening gehouden is met dit nieuwe zorgstelsel. Als de impact van dit nieuwe zorgstelsel in kaart is gebracht, zal dit als nog verwerkt worden in een revisie van deze architectuurbeschrijving. 3 Merk op dat op het moment van schrijven van dit architectuurontwerp deze registers nog in ontwikkeling zijn (en besluitvorming op punten nog noodzakelijk is). Merk op dat het begrip 'stelsel' ook het beheer en de regels omvat Architectuurontwerp e-declareren

7 Documenthistorie Versie Datum Toelichting december 2004 Eerste concept december 2004 Verwerking commentaar projectteam december 2004 Concept t.b.v. interne NICTIZ-toets januari 2005 Eerste versie t.b.v. besluitvorming februari 2005 Feedback van programmacommissie verwerkt Architectuurontwerp e-declareren - 5

8 1. Inleiding Het onderzoeksinstituut EIM heeft in opdracht van de Commissie de Beer in 2001 de omvang van de administratieve lasten en het maximale besparingspotentieel van het declaratieproces berekend. Een herevaluatie door KPMG BEA in opdracht van CVZ heeft de berekeningen van EIM in grote lijnen bevestigd. De omvang van de administratieve lasten is uiteindelijk becijferd op 460 miljoen per jaar. Het besparingspotentieel is geschat op miljoen per jaar. De jaarlijkse exploitatiekosten van implementatie van de geformuleerde verbetervoorstellen zijn in bovengenoemd onderzoek ingeschat tussen de 3 en 30 miljoen per jaar. Het proces waarlangs en de inhoudelijke afwegingen en beslissingen die gemaakt moeten worden om de geprojecteerde besparingen te kunnen realiseren heet 'de Declaratiecasus'. Deze architectuurbeschrijving maakt onderdeel uit van het programma Declaratiecasus. Het opstellen van de architectuurbeschrijving is uitgevoerd in de fase van het Ontwerp Architectuur binnen het project Architectuur van het programma Declaratiecasus. Onder architectuur wordt, conform het Architectuurontwerp Basisinfrastructuur, in dit document verstaan de fundamentele organisatie van een systeem, uitgedrukt in zijn componenten, hun onderlinge relaties en met de omgeving én de principes die het ontwerp en de evolutie ervan bepalen. Een infrastructuur is de concrete neerslag van de architectuur in onder meer netwerken, bijbehorende systemen, de software en het dagelijks beheer hiervan. De doelstelling van het project is dus om voornoemde componenten, relaties en principes (gedragen) vast te stellen. Tegelijkertijd moet een architectuur ook uitvoerbaar zijn qua infrastructuur, waarbij zo veel mogelijk gebruik gemaakt wordt van hetgeen reeds in de zorgsector voorhanden is. Tegelijkertijd is de vraag, vooruitkijkend naar realisatie van eventueel benodigde infrastructuur, welke partij(en) voor deze infrastructuur zorgdragen. Dit is met name relevant omdat er reeds partijen actief zijn die (delen van) infrastructuur en / of diensten aanbieden die in de huidige declaratieprocessen gebruikt worden. Zoals eerder aangegeven is één van de uitgangspunten dat zoveel als mogelijk aangesloten wordt bij hetgeen reeds voorhanden is. 1.1 Doel en doelgroep Dit rapport beschrijft de architectuur van de declaratiecasus. Het doel hiervan is het vastleggen van de principes en uitgangspunten voor de realisatie van de declaratiecasus. De architectuur vormt verder een kader voor de nadere specificatie van de infrastructurele componenten en het berichtenverkeer. De architectuur van de declaratiecasus gaat uit van de principes en richtlijnen van het AORTA Architectuurontwerp. Dit architectuurontwerp is beschreven in het document "Architectuurontwerp Basisinfrastructuur in de zorg (versie 4.0)" en "Specificatie van de Basisinfrastructuur in de zorg (versie 2.1)" plaats. Het AORTA architectuurontwerp richt zich op de basisinfrastructuur in de zorg met daarbij de toepassing van het elektronisch patiënt dossier. Dit document refereert waar mogelijk naar het AORTA Architectuurontwerp e-declareren

9 architectuurontwerp. Daarom wordt van de lezer verwacht dat zij bekend is met, en beschikt over 4 het AORTA architectuurontwerp. De doelgroep voor deze architectuurbeschrijving wordt gevormd door de leden van het programma declaratiecasus en alle overige betrokken partijen. 1.2 Scope van dit architectuurontwerp De uitwerking van de processen is een aparte activiteit in het deelproject architectuur binnen de declaratiecasus. Alleen de hoofdlijnen van de referentieprocessen zullen in dit document worden overgenomen. De principes die (mede) ten grondslag liggen aan dat referentieproces worden wel beschreven in dit document (zie de businesslaag). De bovengenoemde referentieprocessen worden uitgewerkt in het project 'referentieprocessen e-declareren'. Dit project zal tevens de te gebruiken berichten per proces in kaart brengen. Deze worden in dit document niet beschreven. De codestelsels die gebruikt worden in de berichtstandaarden worden in een apart project 'effectief codebeheer' verbeterd. De declaratiecasus omvat niet de processen van het inschrijven van een patiënt/verzekerde. Tevens vallen de financiële processen achter de declaratie buiten de scope van de declaratiecasus. Wel wordt de impact op deze processen als gevolg van de invoer van e-declareren beschreven. Het zogenaamde vierde domein in de zorg (VDZ, partijen die niet in het UZI- of UZOVI-register zitten) maakt onderdeel uit van de scope van de declaratiecasus. Voor identificatie en authenticatie van zorgaanbieders in dit domein is een (nu nog niet voorzien) register noodzakelijk. Momenteel moet nog besluitvorming plaatsvinden rondom dit domein en dit register 5. Er wordt vanuit gegaan dat voor het VDZ-register dezelfde (functionele en technische) principes gelden als voor het UZI-register en dat deze beschikbaar is per De tussenschakels in de keten worden in het ontwerp meegenomen. De communicatie tussen zorgaanbieder/zorgverzekeraar en de tussenschakels valt buiten de scope van dit document. De architectuur beschrijft de functionaliteit en samenhang die benodigd is om de declaratieprocessen te ondersteunen. De architectuur is concurrentieneutraal, dat wil zeggen dat er geen belemmeringen zijn voor zorgpartijen om deel te nemen in e-declareren. De invoering van DBC heeft impact op berichtstandaarden, codestelsels en de referentieprocessen, maar geen impact op de architectuur. Zie verder de projecten 'effectief codebeheer' en 'referentieprocessen e-declareren'. 1.3 Beschrijvingsmodel Dit rapport beschrijft net als het AORTA architectuurmodel de architectuur vanuit drie gangbare invalshoeken. Elke invalshoek is een beschrijving van aspecten die van belang zijn voor verschillende stakeholders: Businesslaag: beschrijving van de bedrijfsmatige, organisatorische aspecten en van de gerelateerde bedrijfsprocessen; 4 Deze architectuurbeschrijving kan op de website gedownload worden. 5 Doordat besluitvorming nog plaats moet vinden kan de toepassing van het VDZ nog veranderen. Dit zal in een revisie van dit architectuurontwerp verwerkt worden Architectuurontwerp e-declareren - 7

10 Informatielaag: beschrijving van de relevante aspecten van de informatiehuishouding, inclusief functionaliteit van applicaties en infrastructuurvoorzieningen m.b.t. de informatieverwerking; Technieklaag: concrete benoeming van componenten en hun interacties (protocollen); beschrijving van applicaties, middleware, communicatie. Business Proces Informatie Techniek De verschillende lagen worden verder uitgewerkt in de hierna volgende hoofdstukken. Hoofdstuk 3 gaat in op de principes en uitgangspunten voor de businesslaag. Op het informatieniveau gaat het over het vastleggen van de betekenis (semantiek) van gegevens en de methoden om de structuur van informatie (syntax) vast te leggen. Bovendien wordt de vereiste functionaliteit van applicaties en infrastructuurvoorzieningen voor de informatieverwerking beschreven. Zie daarvoor hoofdstuk 4. Op het techniekniveau gaat het over de concrete benoeming van componenten en hun interacties. Zie hoofdstuk 5. Relatie e-declareren en AORTA Voor de architectuur van e-declareren wordt zoveel mogelijk geïntegreerd in het AORTA architectuurontwerp. In dit document worden alleen specifiek voor e-declareren beschreven welke onderdelen van AORTA benodigd zijn en welke onderdelen, die geen onderdeel uitmaken van AORTA, benodigd zijn. Op termijn is het doel om de architectuur voor e-declareren samen te voegen met het AORTA architectuurontwerp. 1.4 Opbouw Na de inleiding in dit hoofdstuk is het document gestructureerd naar het hierboven beschreven beschrijvingsmodel. In hoofdstuk 2 zullen de algemene uitgangspunten beschreven worden. Hoofdstuk 3, 4 en 5 zullen respectievelijk de businesslaag, de informatielaag en de technische laag beschrijven. Ten slotte is in hoofdstuk 6 een beschrijving opgenomen van de migratieaspecten. Hierin wordt beschreven welke maatregelen zijn genomen in de architectuur om per tot implementatie te komen. Ook wordt beschreven welke maatregelen tijdelijk van aard zijn Architectuurontwerp e-declareren

11 2. Uitgangspunten voor dit architectuurontwerp Bij het opstellen van het architectuurontwerp zijn de volgende uitgangspunten gehanteerd: Het Architectuurontwerp Basisinfrastructuur in de Zorg (versie 4.0, AORTA) en de Specificatie van de Basisinfrastructuur in de Zorg (2.1) zijn het uitgangspunt voor de infrastructuur voor declaratieverkeer; Er wordt uitgegaan van de bestaande Vektis EI-standaarden. Bij het opstellen van de referentieprocessen worden de voor de declaratiecasus benodigde aanpassingen in kaart gebracht; Alle berichtverkeer in het kader van processen binnen de scope van declaratiecasus zullen verlopen via een centraal en neutraal portaal. Dit portaal zal deze berichten routeren naar de juiste ontvanger (zorgaanbieder of zorgverzekeraar); Intramurale beveiliging (beveiliging binnen de muren van een zorginstelling) valt buiten de scope van de architectuurbeschrijving, omdat hiervoor reeds bestaande wetten en normen van toepassing zijn. De extramurale beveiliging (elektronisch uitwisseling tussen zorginstellingen en tussenschakels) vormt wel onderdeel van de scope; De UZI-pas en certificaat zijn per beschikbaar voor zorgaanbieders; Het UZOVI-register met verstrekking van certificaten voor beveiligde communicatie is per beschikbaar; Het BSN-nummer is vanaf beschikbaar voor alle deelnemers in het declaratieverkeer en is technisch het (huidig) Sofi-nummer. In 2005 mag het sofinummer alleen voor experimentele doeleinden gebruikt worden; Alle zorgverzekeraars en zorgaanbieders die deelnemen aan het declaratieverkeer zijn aangesloten op de basisinfrastructuur; De berichten en te gebruiken codestelsels en de interfaces worden gestandaardiseerd; Er wordt gestreefd naar eenheid van taal van beleid, regels, standaarden (ook EIstandaarden), codes, proces en systemen (binnen de scope van de processen van de declaratiecasus); Per is het nieuwe zorgstelsel van toepassing. De impact van deze ontwikkeling op de declaratiecasus dient nog te worden onderzocht. In het ontwerp wordt al zoveel mogelijk rekening gehouden met het nieuwe zorgstelsel; Er zal zoveel mogelijk gebruik gemaakt worden van bestaande standaarden. Alleen als nodig zullen nieuwe standaarden opgesteld worden of bestaande standaarden aangepast worden; Daar waar nuttig en mogelijk zal gebruik gemaakt worden van de voorzieningen van het Landelijk Schakelpunt 6 (LSP); De organisatorische invulling en financiering van e-declareren is geen onderdeel van dit architectuurontwerp. Het project 'referentieprocessen e-declareren' en het project 'effectief codebeheer' zijn bij oplevering van deze architectuurbeschrijving nog niet afgerond. Bij het opstellen van deze architectuurbeschrijving is uitgegaan van de stand van zaken van deze projecten van begin januari Voorheen Shared Service Centre (SSC) Architectuurontwerp e-declareren - 9

12 3. De businesslaag 3.1 Achtergrond declaratiecasus Motivatie De afhandeling van de declaratie voor een medische behandeling kost zorgverleners en zorgverzekeraars tijd en geld, en leidt ook tot ergernissen door de fouten die moeten worden hersteld. Onderzoeken - van Commissie De Beer in 2002 en het College voor zorgverzekeringen (CVZ) in laten zien dat de kosten omlaag kunnen worden gebracht en fouten kunnen worden uitgebannen. Op diverse onderdelen van het declaratieverkeer zijn er al initiatieven om deze kosten- en foutenvermindering te realiseren. Een groot aantal partijen in de zorg meent dat het mogelijk is deze initiatieven te versnellen en te verdiepen. De besparingen (inclusief controle verzekering) bedragen naar schatting zo n 100 miljoen euro per jaar. Casebeschrijving Het declaratieproces kent een lange weg. De zorgverlener legt gegevens vast over de verzekerde en over de behandeling. Voor de declaratie moeten minimaal polisnummer, geboortedatum, geslacht, verzekeringsmaatschappij en de verrichting(en) 7 geregistreerd worden. Daarna vindt controle op verzekering (COV) plaats. De declaratie wordt vervolgens opgemaakt en op papier via de post of digitaal per diskette, tape, regionaal netwerk of internet aangeboden aan de zorgverzekeraar of een intermediair. De zorgverzekeraar of derde partij verwerkt en betaalt de declaratie of wijst deze af. Ingeval van afwijzing kan de zorgverlener zonodig de declaratie corrigeren of eventueel overleg voeren met de zorgverzekeraar, om ervoor te zorgen dat de declaratie alsnog door de zorgverzekeraar wordt geaccepteerd en betaald. In het declaratieproces worden ook zorgverleners geconfronteerd met verscheidene administratieve lasten. Zo is de controle op verzekering tijdrovend, omdat het ontbreekt aan één loket voor controle op verzekering van alle verzekerden. Bovendien is de controle niet sluitend. Gegevens van verzekerden kunnen bijvoorbeeld met elkaar worden verward, omdat het ontbreekt aan uniek identificerende middelen. Ook stellen niet alle verzekeraars hun bestanden voor raadpleging beschikbaar. En de bestanden die wel beschikbaar worden gesteld, zijn niet altijd actueel. Dit komt onder meer door de toenemende mobiliteit van verzekerden. Daarnaast is het opmaken en indienen van declaraties bewerkelijk. Ook hier ontbreekt het aan één loket waar zorgverleners alle declaraties kunnen aanbieden. De praktijk is nu veelal dat zorgverleners bij tien tot vijfentwintig zorgverzekeraars declaraties moeten indienen. Dat is lastig, te meer omdat zorgverzekeraars afwijkende berichten retour sturen wanneer een declaratie wordt afgewezen. Retourberichten worden bovendien nog maar zeer beperkt elektronisch verstuurd. Daar komt nog bij dat zorgverleners de beleidsregels en tariefrichtlijnen ten aanzien van declaraties vaak als multi-interpretabel ervaren. 7 In dit rapport wordt 'verrichting' gebruikt voor zowel 'verrichting', 'prestatie' en 'verstrekking' Architectuurontwerp e-declareren

13 ICT kan een oplossing bieden om de administratieve lasten die het declaratieproces met zich meebrengt te verlichten en het zorgverleners en zorgverzekeraars zo gemakkelijk mogelijk te maken. Om de veranderdoelstelling van het programma te kunnen realiseren zal het declaratieproces tussen zorgaanbieder en zorgverzekeraar volledig elektronisch moeten gaan plaatsvinden met een afwijzingspercentage lager dan 1%. Er dient voor te worden gezorgd dat de verschillende zorgaanbieders, te weten ziekenhuizen, tandartsen, fysiotherapeuten, overige paramedici, huisartsen, hulpmiddelen leveranciers, met alle zorgverzekeraars (ziekenfondsen, particuliere zorgverzekeraars) elektronisch informatie kunnen uitwisselen. Doelstelling programma declaratiecasus Om de veranderdoelstelling te kunnen realiseren zijn twee operationele doelstellingen geformuleerd: Breng het foutpercentage in het declaratieproces terug tot maximaal 1%; 100% Externe integratie: alle berichtenuitwisseling tussen zorgaanbieders en zorgverzekeraars met betrekking tot het declaratieproces (COV, de declaratie en het retourbericht) gebeurt elektronisch. De doelstelling van het project Architectuur, waarvan deze architectuurbeschrijving een resultaat is, is het beschrijven van de benodigde architectuur dat 100% elektronisch declaratieproces tussen zorgaanbieder en zorgverlener met een afwijzingspercentage lager dan 1% mogelijk maakt. 3.2 Globaal overzicht De declaratiecasus houdt zich bezig met vier processen, namelijk: het controleren of een patiënt verzekerd is (tot op verrichtingniveau); het indienen van declaraties; het ontvangen van retourinformatie op deze declaraties; het indienen van verzoek tot machtigingen en het antwoord op dit verzoek. Dit zijn in principe processen die verlopen tussen zorgaanbieders en zorgverzekeraars. Ook tussenschakels maken deel uit van de processen. Tussenschakels zijn partijen die namens een zorgaanbieder of zorgverzekeraar (delen van) de processen van die partij uitvoeren. Een zorgaanbieder moet zijn declaraties indienen bij de juiste zorgverzekeraar. Hierdoor bestaat in feite een relatie van de zorgaanbieder met alle zorgverzekeraars. Voor elektronische communicatie is dit een complexe situatie. Om deze situatie eenvoudiger te maken voor zowel zorgaanbieders en zorgverzekeraars, wordt een centraal loket voorzien, de declaratieportaal, waarlangs alle zorgaanbieders en zorgverzekeraars hun elektronische berichtenverkeer in het kader van e-declareren (declaraties, retourinformatie, controle op verzekeringsrecht, machtigingen) laten verlopen. Dit portaal zorgt voor (efficiënte) routering van de berichten naar de juiste ontvanger. Een zorgaanbieder die op het portaal een declaratiebericht wil indienen, kan dit handmatig (interactief) doen via een webinterface bij het portaal. Daarnaast is er de mogelijkheid om de informatiesystemen van de zorgaanbieders 8 geautomatiseerd het bericht bij het portaal aan te leveren (onderwaterkoppeling voor applicatie-portaal communicatie). 8 Vaak afgekort met XIS Architectuurontwerp e-declareren - 11

14 Een zorgverzekeraar heeft een online koppeling met het portaal. Berichten van zorgaanbieders worden door het portaal doorgegeven aan de juiste zorgverzekeraars. Afhankelijk van het proces kan dit in batch of per stuk. (Dit wordt verderop nader gespecificeerd.) Alle communicatie zal verlopen over een goed beveiligde communicatie-infrastructuur. Hierbij wordt aangesloten bij de AORTA infrastructuur 9 en de daarin beschreven (componenten in een) Landelijk Schakelpunt (LSP) Voorwaardelijk voor het goed verlopen van deze processen zijn eenduidige standaarden voor berichten en daarbij een eenduidig stelsel van codes die in deze berichten gebruikt worden. Ter verbetering van dit stelsel wordt een centraal informatieportaal voorzien waardoor alle partijen op één plek (via verwijzingen naar de juiste beheerder) alle informatie kunnen vinden over berichtstandaarden en codestelsels. 3.3 Procesaspecten Welke processen De referentieprocessen worden in het programma declaratiecasus in detail uitgewerkt. Voor deze uitwerking wordt verwezen naar het project "referentieprocessen e- declareren". De volgende processen worden daarin uitgewerkt: Controle op verzekeringsrecht (COV); Declaratieproces; Retourinformatie; Machtigingen. De volgende processen vallen buiten de scope van de declaratiecasus: Aanmelding/afmeldingsprocessen bij zorgaanbieder en zorgverzekeraar (de impact van BSN op deze processen wordt wel beschreven); Financiële processen bij de zorgverzekeraar. In de retourinformatie wordt wel informatie opgenomen dat (en hoeveel) er betaald wordt op basis van de declaratie. Vanuit het project 'effectief codebeheer' worden de beheerprocessen van, en het informeren over de codestelsels verbeterd. Deze 'ondersteunende' processen worden hier niet nader beschreven. Zie hiervoor de rapporten van het project. Ter ondersteuning van het informeren over de codestelsels wordt een informatieportaal voorzien. Deze is wel opgenomen in deze architectuurbeschrijving. Controle op Verzekeringsrecht In dit proces kan een zorgaanbieder controleren of de patiënt wel of niet verzekerd is en waar hij verzekerd is (voor basis en aanvullende verzekering.) Vanuit de referentieprocessen wordt er vanuit gegaan dat de COV uitgevoerd wordt op drie momenten: Bij inschrijving van een patiënt; Bij het plannen van een verrichting; Bij het uitvoeren van een verrichten. 9 Zie Architectuurontwerp e-declareren

15 Op deze momenten zal de zorgaanbieder een COV verzoek sturen via het portaal naar de zorgverzekeraar van de patiënt. De zorgaanbieder dient de bij hem bekende zorgverzekeraar van de patiënt in bericht op te nemen. In de uitzonderingsgevallen dat de zorgaanbieder niet weet wie de zorgverzekeraar van de patiënt zal het portaal zorg dragen voor het afleveren van het COV verzoek bij de juiste zorgverzekeraar (in wordt beschreven hoe het portaal dit doet) Ook als blijkt dat de zorgaanbieder het COVverzoek aan de verkeerde zorgverzekeraar heeft gericht (bijvoorbeeld omdat zijn informatie achterhaald is), zal het portaal alsnog de juiste zorgverzekeraar opzoeken. Het portaal zal het antwoord op het COV-verzoek retourneren aan de zorgaanbieder. Dit antwoord bevat: informatie of de patiënt wel of niet verzekerd is; bij welke zorgverzekeraar hij verzekerd is (basis en aanvullend); de NAW gegevens van de patiënt/verzekerde die bij de zorgverzekeraar bekend is. Als de zorgaanbieder in het COV-verzoek ook de verrichting heeft opgenomen, zal het COV-antwoord ook de volgende informatie bevatten: de zorgaanbieder kan deze verrichting declareren bij de zorgverzekeraar; de zorgaanbieder heeft betalingsgarantie voor deze verrichting; er is voor de verrichting een machtiging benodigd. Op basis van deze geretourneerde informatie kan een zorgaanbieder bepalen hoe hij de declaratie verder kan afhandelen en of hij eerst een machtiging aan moet vragen. Declaratieproces In dit proces kunnen zorgaanbieders verleende zorg declareren bij zorgverzekeraars. Zorgaanbieders weten na het uitvoeren van COV bij welke verzekeraar de patiënt verzekerd is. In het antwoordbericht op het COV-verzoek wordt namelijk duidelijk bij welke zorgverzekeraar gedeclareerd kan worden (en op verrichtingen niveau of er gedeclareerd kan worden). Retourinformatieproces Op elke declaratie volgt retourinformatie waarin duidelijk wordt of de declaratie geaccepteerd is of niet. Hierbij wordt het principe gehanteerd dat elke declaratie leidt tot een retourbericht met voldoende informatie om van elke declaratieregel te weten of deze geaccepteerd is of niet. Ook op een machtigingverzoek volgt retourinformatie. De retourinformatie wordt verstuurd aan de zorgaanbieder. Merk op dat machtigingen door patiënten worden aangevraagd. Zorgaanbieders kunnen die alleen namens de patiënt uitvoeren. Het kan daarom ook voorkomen dat een retourbericht bij de zorgaanbieder aankomt die niet door hem is aangevraagd (die dus niet volgt op een machtigingverzoek van de zorgaanbieder), maar door de patiënt zelf. Machtigingproces Voor sommige vormen van zorg is het nodig om eerst toestemming te krijgen van de zorgverzekeraar voordat deze (op kosten van de zorgverzekeraar) uitgevoerd mag worden (in het COV-antwoord is deze informatie op verrichtingenniveau opgenomen, zie boven). Hiervoor dient vooraf een machtiging aangevraagd te worden. Uit het antwoord op dit machtigingsverzoek blijkt of de handeling gedekt wordt of niet. Dit proces is ontworpen in het project 'referentieprocessen e-declareren'. Architectuurontwerp e-declareren - 13

16 3.3.2 Identificatie en authenticatie Voor beveiligd declaratieverkeer is één unieke identificatie van zorgaanbieder, één unieke identificatie van zorgverleners in het vierde domein en één unieke identificatie van zorgverzekeraar noodzakelijk. Dit unieke kenmerk wordt in de gehele keten toegepast. Ook wordt één unieke identificatie van patiënt/verzekerde 10 toegepast op basis van het burger service nummer (BSN). Voor de identificatie en authenticatie in het declaratieverkeer wordt gebruik gemaakt van vooraf aangewezen authentieke bronnen: Identificatie en authenticatie van de patiënt/verzekerde wordt gedaan door de zorgaanbieder en zorgverzekeraar. Communicatie over patiënt/verzekerde vindt plaats op basis van BSN; Identificatie en authenticatie van de zorgaanbieder wordt uitgevoerd met het UZIregister. Elke zorgaanbieder heeft een UZI-nummer en bijbehorend UZIcertificaat. Het UZI-nummer en certificaat is voor de authenticiteit en onweerlegbaarheid in de elektronische communicatie. Het AGB-nummer blijft bestaan voor administratieve toepassingen en declaratieverkeer 11 ; Identificatie en authenticatie van de zorgverzekeraar wordt uitgevoerd met het UZOVI-register. Elke zorgverzekeraar heeft reeds een UZOVI-nummer. Per wordt het register ook voorzien van certificaten zodat beveiligde communicatie mogelijk wordt; Identificatie en authenticatie van zorgverleners in het vierde domein wordt uitgevoerd met het VDZ-register. Elke zorgverlener in dit domein heeft een VDZnummer. Het is nog niet duidelijk hoe en wanneer het VDZ-register er zal zijn 12. Als per dit register er niet is, kan als tussenoplossing met de AGB-code in combinatie met een tijdelijk certificaat gewerkt worden; Identificatie en authenticatie van het portaal vindt plaats op basis van hetzelfde register waarmee (de componenten in) het Landelijk Schakelpunt (LSP) zich identificeren en authenticeren. Welk register dit zal zijn is nog niet duidelijk. In de berichtuitwisseling draagt de versturende partij zorg voor het opnemen van zijn identiteitsnummer in het bericht. Naast het controleren van de identiteit en authenticiteit van de versturende partij zal het portaal geen extra controles doen op de juistheid van het gebruikte identiteitsnummer in het bericht. Met de toepassing van UZI, UZOVI én VDZ is nagenoeg een volledige dekking mogelijk van alle partijen die communiceren in de declaratiecasus. Een klein deel van dit vierde domein bevat partijen, zorgverleners uit de aanvullende verzekeringen die niet vallen onder de BSN-wet in de Zorg, die geen gebruik moeten/mogen maken van het BSN. De verwachting is dat deze partijen via een AMvB als nog gebruik mogen maken van BSN mits ook zij zorg dragen voor de geëiste waarborgen. De toepassing van BSN leidt niet tot volledige dekking van patiënt/verzekerde waarover gedeclareerd kan worden. Bijvoorbeeld krijgen buitenlanders die hier tijdelijk verblijven 10 Voor en tijdens de introductie van het BSN zal nog gebruik gemaakt kunnen worden van een kleine set van identificerende kenmerken van een patiënt: de minimale dataset (MDS). Zie Zie het onderzoek Onderzoek AGB-register, spelregels relatie UZI-nummer en AGB-nummer, Vektis, 25 oktober Zie ook voetnoot 5 op pagina Architectuurontwerp e-declareren

17 geen BSN. De toekomstige ontwikkelingen rondom de Europese zorgpas gaat hierin mogelijk een rol spelen. Uitgangspunt voor deze architectuurbeschrijving is dat personen zonder BSN buiten de scope declaratiescasus vallen en dat deze door zorgaanbieders en zorgverzekeraars apart afgehandeld worden Tijdigheid van processen In het declaratieverkeer zal voor beveiligde communicatie interactie plaats vinden met de diverse registers (UZI, UZOVI, VDZ). Deze interactie dient snel te verlopen. Een vraag aan het register moet snel worden beantwoord. De controle op verzekeringsrecht is een proces waarbij op de COV-vraag snel antwoord vereist is. Het indienen van machtigingen en het ontvangen van een antwoord is een proces dat minder tijdskritisch is. Het indienen van declaraties en ontvangen van retourinformatie is een proces dat minder tijdskritisch is. Van belang is dat bij de bovengenoemde processen afspraken gemaakt worden over normen en richtlijnen van deze processen, zoals bijvoorbeeld de tijdigheid (performance). Hiervoor wordt een aanzet gegeven in het project 'referentieprocessen e- declareren' Beveiliging De mate van beveiliging hangt af van de informatie die uitgewisseld wordt. In het declaratieverkeer wordt zorginhoudelijke informatie over patiënten/verzekerden uitgewisseld. Uit declaraties en COV-verzoeken (op verrichtingniveau) kan informatie over de medische toestand van een persoon afgeleid worden; gecommuniceerd met het BSN-nummer van een persoon. Het is hiervoor noodzakelijk dat een infrastructuur gebruikt wordt die afdoende beveiligd is en waarborgen biedt voor de bescherming van persoonsgegevens en de privacy. Door de minister van VWS is vastgesteld dat het gebruik van het BSN in de zorg mogelijk is mits voldaan wordt aan bepaalde waarborgen 13. Deze waarborgen stellen eisen aan het minimaal benodigde beveiligingsniveau. De waarborgen zijn op hoofdlijnen: De aangesloten zorgpartijen moeten voldoen aan de eisen van een Goed Beheerd Zorgsysteem (GBZ). Deze eisen zijn beschreven in het AORTA architectuurontwerp en in meer detail in specificatie van de basisinfrastructuur in de zorg; Wat betreft het transport en de toegang tot gegevens geldt de vertrouwensketen als uitgangspunt, bestaande uit drie stappen: identificatie, authenticatie en autorisatie gebruik makend van authentieke registers. Dat betekent dat in alle processen van gegevensuitwisseling deze drie stappen 13 Zie de brief aan de Tweede-Kamer met kenmerk IBE/I Hierin wordt gerefereerd naar de notitie van het CBP aan de minister Waarborgen rond invoering BSN in de zorg van 22 november 2004 en de notitie van Werkgroep Sectorale Vertrouwensfunctie in de zorg aan het CBP Notitie inzake het gebruik van BSN in de zorg en beoogde waarborgen van 20 oktober 2004 Architectuurontwerp e-declareren - 15

18 moeten worden doorlopen. Hierbij wordt gebruik gemaakt van een Public Key Infrastructure (PKI) die voldoet aan de eisen van PKI Overheid; Toepassen van de basisinfrastructuur in de zorg, zoals beschreven in de AORTA documentatie (architectuurontwerp en specificatie). Goed Beheerd Zorgsysteem De basisinfrastructuur voor de zorg is ontworpen om een veelheid aan applicaties in de zorg te ondersteunen. Deze applicaties draaien op zorginformatiesystemen. Zorginformatiesystemen mogen alleen op de basisinfrastructuur van de zorg worden aangesloten indien wordt voldaan aan een aantal eisen. Een Goed Beheerd Zorgsysteem (GBZ) is een ICT-voorziening van een zorgpartij die voldoet aan deze eisen. De eisen zijn beschreven in zowel het AORTA architectuurontwerp alsmede de bijbehorende specificaties. Onderscheid wordt gemaakt in algemene eisen en eisen specifiek voor een toepassing zoals declaratiecasus. De algemene eisen zijn met name gebaseerd op bestaande normen zoals de Code voor informatiebeveiliging (ISO IEC 17799), de norm voor informatiebeveiliging in de zorg (NEN 7510) en het beveiligingsadvies van het CBP. Wat betreft de applicaties van zorgverzekeraars kan in aanvulling op deze algemene normen die ook op hen van toepassing zijn, nog de gedragscode voor zorgverzekeraars genoemd worden. Ook treffen zorgverzekeraars autorisatiemaatregelen. In het AORTA architectuurontwerp wordt onderscheid gemaakt in GBZ die continu online moeten zijn en GBZ en die dit niet hoeven te zijn. Voor zorgverzekeraars en het portaal geldt dat deze continu online moeten zijn 14. De GBZ van een zorgaanbieder hoeft voor e-declareren niet continu online te zijn. Specifieke eisen aan een GBZ voor declaratiecasus zijn: Het voldoen aan de (EI-)standaarden voor berichten in declaratieverkeer, zoals gedefinieerd in het project 'referentieprocessen e-declareren'; Het toepassen van de juiste versie van de codestelsels in de bovengenoemde berichten, zoals gedefinieerd in het project effectief codebeheer; Het halen van de performance-eisen (zie hiervoor het project 'referentieprocessen e-declareren' dat hiervoor een voorstel doet). Autorisatie De infrastructuur maakt gebruik van een public key infrastructure (PKI). Partijen die gebruik willen maken van deze infrastructuur om berichten te versturen naar het declaratieportaal zullen een geldig en actueel 15 certificaat moeten hebben van een van de onderstaande registers (zie ook 3.3.2) om zich te identificeren en authenticeren: Een zorgaanbieder zal een certificaat nodig hebben die uitgegeven wordt vanuit het UZI register; Een zorgverzekeraar heeft een certificaat benodigd die uitgegeven wordt vanuit UZOVI-register; Overige zorgverleners in het vierde domein hebben daarvoor een certificaat nodig die uitgegeven wordt vanuit het VDZ-register. 14 Als een zorgverzekeraar voor COV een andere partij als tussenschakel inzet, dan geldt deze beschikbaarheids eis voor de tussenschakel 15 Met actueel wordt bedoeld: niet verlopen. Certificatie zijn voorzien van een geldigheidsduur Architectuurontwerp e-declareren

19 Aan het gebruik van de infrastructuur zijn voorwaarden verbonden die beschreven zijn in de AORTA architectuur (bijvoorbeeld kunnen alleen GBZ en communiceren over de infrastructuur). In de declaratiecasus is er sprake van autorisatie om van de e-declarerenfunctionaliteit op het declaratieportaal gebruik te kunnen maken: Voor het uitvoeren van controle op verzekeringsrecht wordt in de infrastructuur en op het portaal geen autorisatiecontroles uitgevoerd. Dit betekent dat een zorgaanbieder die met een UZI-pas aangesloten is op de infrastructuur altijd COV kan uitvoeren. Er wordt voor de overige functionaliteit (declareren, retourinformatie, machtigingen) door het portaal wel autorisatiecontrole uitgevoerd. Vertrouwelijkheid In het kader van de declaratiecasus vindt opslag van (patiënt)gegevens plaats bij zowel zorgaanbieder als zorgverzekeraar. De verantwoordelijkheid voor de vertrouwelijkheid van deze gegevens ligt daarom bij beide partijen. Voor zover het portaal tijdelijk berichten vasthoudt totdat de ontvanger gereed is om deze te ontvangen, zullen deze berichten beveiligd worden. Integriteit en onweerlegbaarheid De zorgverzekeraar en zorgaanbieder zijn verantwoordelijk voor het correct opstellen van berichten die zij versturen. Dit betekent tevens dat zij verantwoordelijk zijn voor het toepassen van de afgesproken versies van standaarden en bijbehorende codestelsels 16. E-declaraties moeten geauthenticeerd zijn en traceerbaar zijn voor materiële controle. Dit betekent dat voor verantwoording van de declaratiehandelingen (wie heeft wanneer wat gedaan?) een loggingsfaciliteit (op het declaratieportaal) vereist is Eenduidige berichtspecificaties en codestelsels Momenteel wordt uitval mede veroorzaakt doordat verstuurde EI-berichten verschillend worden geïnterpreteerd. Om deze uitval te voorkomen worden twee acties ondernomen: In het project 'referentieprocessen e-declareren' wordt eenduidig gedefinieerd welke berichtstandaarden in het proces gebruikt worden; In het project effectief codebeheer worden de codestelsels verbeterd die toegepast worden in de berichten. Verder zal via verbeteringen in het beheerproces van standaarden en codestelsels in combinatie met certificering van informatiesystemen de kwaliteit van berichtverkeer verbeterd worden. Dit wordt uitgevoerd in het project effectief codebeheer. Daarnaast valt het gebruik van de juiste berichtspecificaties en codestelsels onder de eisen aan een GBZ voor declaratiecasus. Zie ook Voor informatie over codestelsels wordt voor alle partijen een centraal informatieportaal voorzien. Via dit portaal worden alle berichtstandaarden en codestelsels ontsloten (via verwijzingen naar de beherende organisatie). 16 De procedures voor invoering van nieuwe versies van standaarden en codestelsels worden opgesteld in het project 'effectief codebeheer' Architectuurontwerp e-declareren - 17

20 3.4 Organisatorische aspecten Voor het realiseren van de declaratiecasus is de samenwerking tussen verschillende partijen in de zorg noodzakelijk. Dit zijn de zorgaanbieders, tussenschakels, de zorgverzekeraars, de registerhouders, de portaalbeheerder, de softwareleveranciers en de beheerder van het LSP Zorgaanbieder In dit architectuurontwerp wordt met zorgaanbieders bedoeld alle partijen die in het UZIregister opgenomen worden/zijn. Het UZI-register is afgebakend tot die partijen die vanuit hun rol toegang hebben tot zorginhoudelijke gegevens van personen 17. Zie verder Zorgverzekeraar In dit architectuurontwerp wordt met zorgverzekeraars bedoeld alle partijen die in het UZOVI-register opgenomen worden/zijn 18. Zie ook voor een overzicht van partijen die in het UZOVI-register worden opgenomen Tussenschakels De tussenschakels zijn partijen die namens zorgaanbieders of zorgverzekeraars administratieve handelingen verrichten, bijvoorbeeld declaraties of COV. Deze partijen vallen onder het vierde domein dat hieronder behandeld wordt. Tussenschakels worden gezien als bewerkers in het kader van de Wet Bescherming Persoonsgegevens en Wet BSN in de zorg. Zij zullen daarom moeten voldoen aan de eisen die vanuit deze wetten gesteld worden aan bewerkers van zorginhoudelijke informatie en gebruiker van BSN Vierde domein partijen In een onderzoek naar het vierde domein definieert Vektis het vierde domein als: Tot het VDZ behoren alle partijen met patiëntgerelateerde communicatie in de zorgsector, al dan niet geaggregeerd, behalve de partijen die opgenomen zijn in het UZI-register en het UZOVI-register. Kijkend naar de partijen die dan deel uitmaken van het vierde domein kan de volgende onderverdeling gemaakt worden. Deze onderverdeling is gekozen in verband met de wijze waarop de partijen in een categorie gebruik zullen maken van een BSN nummer: Partijen met toegang tot zorginhoudelijke gegevens van anderen: tandheelkundige centra, laboratoria (huisartsen, enz.), klinisch genetische centra, weefselbanken, thuiszorgorganisaties, GHOR, overige artsen (niet in UZI), RIO s, ambulancevervoerders, abortusklinieken, RIAGG s; Partijen die het BSN alleen nodig hebben voor identificatie in communicaties, en die geen toegang tot zorginhoudelijke gegevens van anderen hebben: Leveranciers hulpmiddelen, bloedbanken, centrale posten ambulancediensten (CPA), taxivervoerders, genezers (niet-artsen), brancheorganisaties, NIVEL, Prismant, Vektis, Vecozo; 17 Zie Advies UZI-domein en UZI-nummer van CIBG 18 Zie het rapport van Vektis: UZOVI fase 1 Unieke Identificatie van Zorgverzekeraars, Keuze register, opzet en beheer Architectuurontwerp e-declareren

21 Partijen die als verlengde arm van UZI-partijen of UZOVI-partijen optreden: Clearinghouses, factoring bureaus. Deze partijen zullen worden opgenomen in het VDZ-register. Zie verder Een klein deel van dit vierde domein bevat partijen, zorgverleners uit de aanvullende verzekeringen die niet vallen onder de BSN-wet in de Zorg, die geen gebruik moeten/mogen maken van het BSN. De verwachting is dat deze partijen via een AMvB als nog gebruik mogen maken van BSN mits ook zij zorg dragen voor de geëiste waarborgen De Registerhouders Het UZI-register Voor de identificatie en authenticatie van zorgaanbieders is het Unieke Zorgverleners Identificatie register (UZI-register) ingericht. Hiervoor geeft het UZI-register aan zorgaanbieders een elektronische identiteit, waarmee zij zichzelf kunnen authenticeren, waarmee zij de vertrouwelijkheid in de communicatie kunnen borgen en waarmee zij een elektronische handtekening kunnen zetten. Deze elektronische identiteit wordt praktisch vormgegeven via een zogenaamde UZI-pas. Met behulp van een paslezer op de computer van de zorgaanbieder wordt de elektronische identiteit opgehaald 20 en kan deze vanaf de computer gebruikt worden in beveiligde communicatie. In het UZI-register worden die zorgverleners opgenomen die ook in het BIG-register of in het Kwaliteitsregister paramedici zijn opgenomen: BIG-register (ondergebracht bij het CIBG): apothekers, artsen (huisartsen en medisch specialisten), fysiotherapeuten, gezondheidszorgpsychologen, psychotherapeuten, tandartsen, verloskundigen en verpleegkundigen; Kwaliteitsregister paramedici (ondergebracht bij het CIBG): diëtisten, ergotherapeuten, logopedisten en foniatristen, mondhygiënisten, oefentherapeuten Mensendieck en César, radiologisch laboranten, orthoptisten, podotherapeuten, optometristen, huidtherapeuten. Verder worden in het UZI-register vele soorten instellingen opgenomen: ziekenhuizen, dialyse centra, audiologische centra, radiotherapeutische centra, zelfstandige behandelcentra, verpleeginrichtingen somatisch en psychogeriatrisch, enz. UZOVI UZOVI is de Unieke ZOrgVerzekeraarsIdentificatie. Deze identificatie is per januari 2004 opgenomen in het zogenaamde UZOVI-register dat bij Vektis is ondergebracht. Het register bevat: ziekenfondsen; particuliere ziektekostenverzekeraars; gevolmachtigde assurantietussenpersonen; zorgkantoren; labelorganisaties; nevenvestigingen. 19 Zie ook voetnoot 5 op pagina De verwachting is dat de UZI-pas pas uitgelezen kan worden door een computer als de zorgverlener een pincode heeft ingevoerd. Architectuurontwerp e-declareren - 19

22 Het UZOVI-register vervangt per 15 september 2005 de Zorgverzekeraarstabel (ZV-tabel) van Vektis. Dat betekent dat het ZV-nummer (Code Zorgverzekeraar) wordt vervangen door het UZOVI-nummer. Het register is ontwikkeld om eenduidig vast te stellen wie een zorgverzekeraar is. Dit register draagt, samen met het UZI-register voor zorgverleners en het BSN voor patiënten, bij aan de integriteit, authenticiteit en vertrouwelijkheid van elektronische communicatie. Het UZOVI-register wordt momenteel door Vektis beheerd. De mogelijkheid bestaat dat VWS (of een uitvoeringsinstantie van VWS) dit beheer over zal nemen. In dat geval kan het zijn dat bovengenoemde opsomming van UZOVI-partijen beperkter zal worden. De partijen die dan niet meer onder het UZOVI-register vallen worden dan mogelijk overgeheveld naar het vierde domein. Momenteel wordt gewerkt aan het uitbreiden van het UZOVI-register met certificaten, zodat zorgverzekeraars zich kunnen identificeren en authenticeren voor beveiligde communicatie. Per zal dit operationeel zijn. BSN/SBV-Z Iedereen die zich goed kan identificeren en die een relatie heeft met de Nederlandse overheid, krijgt een uniek persoonsnummer: het Burger Service Nummer (BSN). Daarmee wordt de dienstverlening door de overheid eenvoudiger, verdwijnen een aantal technische barrières bij de uitwisseling van persoonsgegevens tussen overheidsorganisaties en komt de eenmalige gegevensverstrekking een stap dichterbij. Ook kan de bestrijding van fraude doelmatiger plaatsvinden. Het Burger Service Nummer zal zijn gebaseerd op het bestaande sofi-nummer. Momenteel wordt gewerkt aan wetgeving die het mogelijk maakt om, onder voorwaarden, het BSN te gebruiken in de zorg. De BSN wordt uitgegeven vanuit de gemeentelijke administratie (GBA). Vanuit het ministerie van BZK zal voor het beheer van de BSN een overkoepelende beheervoorziening (OBV) inrichten. Voor elke sector waarin het BSN toegepast mag worden, zal door de verantwoordelijke minister een sectorale beheervoorziening (SBV) ingericht worden. Deze beheervoorziening zorgt voor de uitgifte van, intrekking van en controle op BSN. Toegang tot het SBV kan via het LSP verlopen. Ook kan het SBV direct (zonder tussenkomst van het LSP) benaderd worden. VDZ-register In is het vierde domein beschreven. Voor de unieke identificatie en ook de authenticatie van partij in het vierde domein wordt een register voorzien, het VDZregister. Dit register bestaat nog niet. Mogelijk dat dit register door Vektis beheerd zal worden. Momenteel bestaat het VDZ-register niet 21. Onduidelijk is wanneer dit register er zal zijn. Als per dit register er niet is, kan als tussenoplossing met de AGB-code in combinatie met een tijdelijk certificaat gewerkt worden. Hiervoor zal een tijdelijk register ingericht moeten worden. 21 Zie ook voetnoot 5 op pagina Architectuurontwerp e-declareren