Architectuurontwerp e-declareren

Architectuurontwerp e-declareren

Status

: Concept

Versie : 1.1

Ref Datum

: ADPD.007 : 15.02.2005

Postbus 262, 2260 AG Leidschendam Overgoo 11, 2266 JZ Leidschendam telefoon: (070) 317 34 50 e-mail: info@NIC TIZ.nl / www.NIC TIZ.nl

Inhoudsopgave 1.

Inleiding

1.1 1.2 1.3 1.4

2.

Uitgangspunten voor dit architectuurontwerp

3.

De businesslaag

3.1 3.2 3.3

6 7 7 8

9 10

Achtergrond declaratiecasus Globaal overzicht Procesaspecten

3.3.1 3.3.2 3.3.3 3.3.4 3.3.5

3.4

10 11 12

Welke processen Identificatie en authenticatie Tijdigheid van processen Beveiliging Eenduidige berichtspecificaties en codestelsels

12 14 15 15 17

Organisatorische aspecten

3.4.1 3.4.2 3.4.3 3.4.4 3.4.5 3.4.6 3.4.7 3.4.8

3.5 3.5.1 3.5.2 3.5.3

3.6

18

Zorgaanbieder Zorgverzekeraar Tussenschakels Vierde domein partijen De Registerhouders De basisinfrastructuur en het Landelijk Schakelpunt Het declaratieportaal Het informatieportaal voor codestelsels

18 18 18 18 19 21 21 22

Benodigde infrastructurele diensten

22

Beveiligde communicatie Het declaratieportaal Het informatieportaal voor codestelsels

22 22 23

Inrichtingsaspecten

3.6.1 3.6.2 3.6.3

3.7

4.

6

Doel en doelgroep Scope van dit architectuurontwerp Beschrijvingsmodel Opbouw

23

Geen gegevens vastleggen bij portaal Vinden van een zorgverzekeraar Gebruik AGB code

23 24 24

Eisen aan zorgsystemen

Informatielaag

4.1 4.2 4.3 4.4 4.4.1 4.4.2 4.4.3

Berichten Coderingsstelsels Identificatie, authenticatie en autorisatie Functionaliteit Functionaliteit van het declaratieportaal Functionaliteit van aangesloten systemen Functionaliteit van het informatieportaal voor codestelsels

Architectuurontwerp e-declareren Ref. ADPD.007

25

27 27 27 27 28 28 31 32

-1–

4.4.4 4.4.5 4.4.6 4.4.7

5.

De technische laag

5.1

5.2

6. 6.1 6.2 6.3 6.4 6.5 6.6 6.7

-2-

37 38

Netwerkniveau en transport Interoperabiliteit/berichtcommunicatie Infrastructurele toepassingen Toepassingen

38 38 39 39

Beveiliging, continuïteit en beheer

5.2.1 5.2.2 5.2.3 5.2.4

5.3

32 33 34 35

Invulling van het service model

5.1.1 5.1.2 5.1.3 5.1.4

7.

Infrastructuur Beveiliging Interactieprincipes declaratieverkeer Interactieprincipes informatieportaal codestelsels

40

Vertrouwelijkheid Identificeren en authenticeren Integriteit en onweerlegbaarheid Technische eisen PKI

40 40 40 40

Technische eisen aan aangesloten systemen

Migratieaspecten

40

42

Introductie BSN Introductie identificerend stelsel Autorisatie voor declaratieverkeer RINIS AGB en UZI HL7 als berichtstandaard Testfaciliteiten

Concurrentieneutrale architectuur

42 42 43 43 43 43 43

44


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 € 110 - € 135 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 zorg1. Om echter per 1-1-2006 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-standaarden2 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 www.nictiz.nl

2

EI-standaarden staat voor standaarden voor externe integratie.


-3–

Dit identificerend stelsel zal bestaan3 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.

-4-


Documenthistorie Versie 0.1 0.2 0.3 1.0 1.1

Datum 8 december 2004 8 december 2004 21 december 2004 19 januari 2005 15 februari 2005


Toelichting Eerste concept Verwerking commentaar projectteam Concept t.b.v. interne NICTIZ-toets Eerste versie t.b.v. besluitvorming Feedback van programmacommissie verwerkt

-5–

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 € 110 - € 135 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

-6-


architectuurontwerp. Daarom wordt van de lezer verwacht dat zij bekend is met, en beschikt over4 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 register5. 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 1-1-2006. 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 www.nictiz.nl 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


-7–

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 Informatie

Techniek 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 1-1-2006 tot implementatie te komen. Ook wordt beschreven welke maatregelen tijdelijk van aard zijn.

-8-


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 1.1.2005 beschikbaar voor zorgaanbieders; Het UZOVI-register met verstrekking van certificaten voor beveiligde communicatie is per 1.1.2006 beschikbaar; Het BSN-nummer is vanaf 1.1.2006 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 1.1.2006 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 Schakelpunt6 (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 2004.

6

Voorheen Shared Service Centre (SSC)


-9–

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 2003 - 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'

- 10 -


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 zorgaanbieders8 geautomatiseerd het bericht bij het portaal aan te leveren (onderwaterkoppeling voor applicatie-portaal communicatie).

8

Vaak afgekort met XIS


- 11 –

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 infrastructuur9 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 3.3.1 Welke processen De referentieprocessen worden in het programma declaratiecasus in detail uitgewerkt. Voor deze uitwerking wordt verwezen naar het project "referentieprocessen edeclareren". 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 www.nictiz.nl

- 12 -


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 3.6.2 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'.


- 13 –

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/verzekerde10 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 declaratieverkeer11; Identificatie en authenticatie van de zorgverzekeraar wordt uitgevoerd met het UZOVI-register. Elke zorgverzekeraar heeft reeds een UZOVI-nummer. Per 1-12006 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 zijn12. Als per 1-1-2006 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 6.1 11

Zie het onderzoek “Onderzoek AGB-register, spelregels relatie UZI-nummer en AGB-nummer”,

Vektis, 25 oktober 2004. 12

Zie ook voetnoot 5 op pagina 7.

- 14 -


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.

3.3.3 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 edeclareren'.

3.3.4 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 waarborgen13. 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-2538117. 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


- 15 –

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 zijn14. 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 actueel15 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

- 16 -


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 codestelsels16. 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.

3.3.5 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 3.3.4. 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'


- 17 –

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.

3.4.1 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 personen17. Zie verder 3.4.5.

3.4.2 Zorgverzekeraar In dit architectuurontwerp wordt met zorgverzekeraars bedoeld alle partijen die in het UZOVI-register opgenomen worden/zijn18. Zie ook 3.4.5 voor een overzicht van partijen die in het UZOVI-register worden opgenomen.

3.4.3 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.

3.4.4 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

- 18 -


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 3.4.5. 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 waarborgen19.

3.4.5 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 opgehaald20 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


20

De verwachting is dat de UZI-pas pas uitgelezen kan worden door een computer als de

zorgverlener een pincode heeft ingevoerd.


- 19 –

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 1-1-2006 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 3.4.4 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 niet21. Onduidelijk is wanneer dit register er zal zijn. Als per 1-1-2006 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


- 20 -


3.4.6 De basisinfrastructuur en het Landelijk Schakelpunt Voor de infrastructurele voorzieningen wordt de basisinfrastructuur toegepast zoals beschreven in het AORTA architectuurontwerp. In 2005 worden de componenten in deze AORTA architectuur gerealiseerd in een Landelijk Schakelpunt22 (LSP). Daar waar mogelijk zal de declaratiecasus gebruik maken van deze voorzieningen. Zorgaanbieders zullen op de basisinfrastructuur worden aangesloten via een zorg service provider (ZSP). Een ZSP is een netwerkleverancier die voldoet aan specifieke eisen, zoals vastgesteld door NICTIZ. Via deze ZSP kan een zorgaanbieder het portaal bereiken. Dit kan op verschillende manieren: Direct via de infrastructuur van de ZSP Via de ZSP naar het LSP en via het LSP naar het portaal Het portaal communiceert vanaf het portaal met de zorgverzekeraars. De methode die het portaal hanteert om een zorgverzekeraar te vinden is beschreven in 3.6.2. Hierbij wordt (voor COV) een 'broadcast'-mechanisme toegepast waarbij het portaal aan alle zorgverzekeraars vraagt of een patiënt bij hem verzekerd is. Op termijn kan overwogen worden om bij het zoeken van de zorgverzekeraar bij een patiënt de verwijsindex van het LSP te gebruiken. (Voor een realisatie per 1-1-2006 van e-declareren is dit niet haalbaar.)

3.4.7 Het declaratieportaal Het declaratieportaal is niet voorzien in bovengenoemde realisatie van de basisinfrastructuur en het LSP. De realisatie van het portaal is daarom apart gepland in het programma declaratiecasus in 2005. De functionaliteit van het declaratieportaal is uitgewerkt in hoofdstuk 4. Verder zal het project 'portaal' binnen het programma het portaal nader specificeren. Vanuit proces bezien zal het portaal de referentieprocessen moeten ondersteunen. Verder geldt dat er beheersprocessen van het portaal ingevuld moeten worden. Deze processen omvatten: • Aansluiten (en onderhoud van aansluitingen) van zorgaanbieder en alle zorgverzekeraars. Ook aansluitingen van tussenschakels die namens zorgaanbieders of zorgverzekeraars processen in de declaratiecasus uitvoeren; • Onderhouden routeringinformatie, waarbij routering via tussenschakels ondersteund wordt; • Onderhouden autorisatietabel en loggingsfaciliteit. Voor een deel van de processen die het portaal ondersteund is autorisatie benodigd. Uitgangspunt hierbij is dat het portaal concurrentieneutraal opgezet moet worden. Dit impliceert dat het portaal zal moeten voldoen aan: o Open standaarden zoals gespecificeerd in dit architectuurontwerp en het AORTA architectuurontwerp en specificaties; o Het eigendom van gegevens blijft bij de zorgaanbieder en zorgverzekeraar; o Alle zorgaanbieders kunnen bij het portaal aansluiten onder dezelfde voorwaarden. o Alle zorgverzekeraars kunnen bij het portaal aansluiten onder dezelfde voorwaarden. o Alle tussenschakels kunnen bij het portaal aansluiten onder dezelfde voorwaarden 22

Gepland is om ultimo 2005 deze voorzieningen gerealiseerd te hebben.


- 21 –

3.4.8 Het informatieportaal voor codestelsels Ook het informatieportaal voor het op één punt ontsluiten van alle berichtstandaarden en codestelsels is niet voorzien in de basisinfrastructuur en het LSP. De realisatie van dit portaal zal daarom apart gepland worden vanuit het project 'effectief codebeheer'.

3.5 Benodigde infrastructurele diensten Om volledige elektronische declaratieverkeer mogelijk te maken is een aantal infrastructurele diensten benodigd: Faciliteiten voor beveiligde communicatie; Een portaal waar alle berichten in het kader van e-declareren uitgewisseld kunnen worden; Een portaal waar informatie ontsloten wordt over codestelsels in declaratieberichtstandaarden; Zorgtoepassingen die aangesloten zijn op de beveiligde infrastructuur.

3.5.1 Beveiligde communicatie De communicerende partijen in de declaratiecasus zullen met elkaar communiceren via een portaal. Dit betekent dat het portaal en alle partijen netwerkvoorzieningen (bijvoorbeeld ADSL- of inbelverbinding) moeten hebben om elektronische berichten te kunnen uitwisselen. Deze uitwisseling kan plaats vinden over het publieke Internet of via zorg service providers die beveiligde communicatie in de zorg als dienst bieden aan zorgaanbieders. De uitwisseling van berichten moet goed beveiligd worden zodat alleen die personen declaratieberichten in kunnen zien die daartoe geautoriseerd zijn. Om dit mogelijk te maken wordt een PKI ingericht, zodat de berichten die over de netwerkvoorzieningen verstuurd worden versleuteld (op basis van SSL) zijn en alleen in te zien zijn door geautoriseerde personen. Om de PKI in te kunnen richten zijn authentieke bronnen (de registers) nodig die kunnen zorgen voor de correct identificatie en authenticatie van de communicerende partijen. Vanuit deze registers worden certificaten uitgegeven aan de verschillende partijen zodat beveiligde communicatie met een PKI mogelijk wordt.

3.5.2 Het declaratieportaal Het is zeer omslachtig als elke zorgaanbieder direct elektronisch gekoppeld moet worden aan alle zorgverzekeraars. Daarom is gekozen voor een centrale portaal. Zorgaanbieders communiceren, eventueel via een tussenschakel, met dit portaal en het portaal zorgt vervolgens dat berichten, eventueel via een tussenschakel, bij de zorgverzekeraar aankomen. Naast deze ‘intermediairfunctie’ bij berichtuitwisseling zal het portaal tevens mogelijk maken dat zorgaanbieders handmatig een bestand met declaratie- of machtigingberichten kan indienen bij het portaal via webtechnologie, bijvoorbeeld als het informatiesysteem van de zorgaanbieder (nog) niet aangepast is om elektronisch declaraties te kunnen indienen. Het portaal biedt statusinformatie over ingediende declaraties23. 23

De mate van detail van deze statusinformatie is nog onderwerp van onderzoek. Minimaal zal het

- 22 -


Ook kan een zorgaanbieder handmatig via het portaal een COV uitvoeren en de retourinformatie ophalen/bekijken. Het portaal maakt het tevens mogelijk dat een zorgaanbieder vanuit zijn eigen informatiesysteem (XIS) declaraties, COV-verzoeken en machtigingsverzoeken bij het portaal aanlevert. Vervolgens is het mogelijk dat een XIS via het portaal met behulp van een systeemkoppeling (onderwaterkoppeling) de retourinformatie verkrijgt.

3.5.3 Het informatieportaal voor codestelsels Momenteel is het voor een partij zeer lastig om overzicht en inzicht te krijgen in de berichtstandaarden en de daarbij toe te passen codestelsels. Er is sprake van verschillende beheerders voor verschillende berichtstandaarden en codestelsels. Om dit inzicht en overzicht beter mogelijk te maken, wordt een informatieportaal voorzien voor codestelsels. Dit portaal maakt het mogelijk om via één centraal punt alle berichtstandaarden en codestelsels te vinden die voor het declaratieverkeer nodig zijn. Het portaal maakt (waar mogelijk) gebruik van verwijzingen naar de beheerder van een standaard of codestelsel. Dit portaal zal gebruik maken van de architectuur e-declareren zoals beschreven in dit document.

3.6 Inrichtingsaspecten 3.6.1 Geen gegevens vastleggen bij portaal Bij het ontwerp van de architectuur voor e-declareren is er de ontwerpkeuze om gegevens van verzekerden wel of niet bij het portaal vast te leggen. Een COV-vraag kan dan door het portaal beantwoord worden. Ook kan voor het ontwerp gekozen worden om declaraties en machtigingen die het portaal ontvangt vast te houden op het portaal en bijvoorbeeld maar eens per dag door te sturen aan de zorgverzekeraar. Hierdoor worden de zorgverzekeraars ontlast. Nadeel is dat er een nieuwe gegevensverzameling bij de portaal ontstaat. Deze moet upto-date gehouden worden om te voorkomen dat het portaal verkeerde antwoorden geeft. Tevens zal hierdoor extra beveiliging- en privacyeisen gesteld moeten worden aan het portaal. In het AORTA architectuurontwerp is gekozen voor het principe dat gegevens opgehaald (en vastgelegd) worden bij de bron. Als we dit principe vertalen naar de declaratiecasus betekent dit dat het portaal geen gegevens vasthoudt, immers het portaal is geen bron. Daarnaast geldt dat zorgverzekeraars voor de functies van AORTA gaan voldoen aan de eisen van een GBZ. Hierdoor worden het voordeel voor de zorgverzekeraar om door het portaal ontlast te worden, grotendeels teniet gedaan. Daarom wordt voor de architectuur van de declaratiecasus gekozen dat het portaal geen berichten vastlegt. Alleen tijdelijk (met een maximumduur) worden ingediende declaraties en machtigingen en retourberichten vastgehouden worden op het portaal (postbusfunctie) totdat de zorgaanbieder/-verzekeraar ze ophaalt (postbusfunctie). Bij het verstrijken van de maximumperiode worden de berichten verwijderd en worden de versturende en ontvangende partij hierover geïnformeerd. portaal aangeven of een bestand in goede (technische) orde is ontvangen en of deze is aangeleverd bij een zorgverzekeraar


- 23 –

3.6.2 Vinden van een zorgverzekeraar Bij het controleren op verzekeringsrecht (COV) is niet met zekerheid bekend bij welke zorgverzekeraar een patiënt verzekerd is. De zorgaanbieder heeft wel vastgelegd bij inschrijving waar de patiënt verzekerd is, maar dit kan in de tijd veranderd zijn. Het portaal zal, als nodig, dit moeten kunnen uitzoeken. Er zijn hiervoor twee mogelijkheden: 1. Het portaal vraagt aan alle zorgverzekeraars of de patiënt bij hem verzekerd is; 2. Het portaal gebruikt een soort verwijsindex bij zodat bij elke patiënt de zorgverzekeraar gevonden kan worden. Hiervoor kan van de verwijsindex van het Landelijk Schakelpunt gebruik gemaakt worden. In 2006 is het Landelijk Schakelpunt niet zo ver dat zij een verwijsindex kan aanbieden om een zorgverzekeraar van een patiënt/verzekerde te kunnen vinden. Daarom wordt nu gekozen voor mogelijkheid 1. Op termijn kan bekeken worden of de verwijsindex deze functie alsnog kan bieden voor e-declareren. Om mogelijkheid 1 efficiënt te laten verlopen wordt van de zorgaanbieder verwacht om het UZOVI-nummer van de zorgverzekeraar van de patiënt – voor zover dit bij hem bekend is – in het COV-verzoek op te nemen. Het portaal kan dan eerst bij deze zorgverzekeraar het COV-verzoek indienen. Als blijkt dat deze verzekeraar toch niet (meer) de zorgverzekeraar van de patiënt is, kan alsnog het COV-verzoek naar de andere zorgverzekeraars gestuurd worden. Bij het indienen van declaraties plaatst de zorgaanbieder het UZOVI-nummer van de zorgverzekeraar in het bericht. Deze heeft de zorgaanbieder ontvangen vanuit het COV-verzoek daar vooraf is gegaan aan de handeling die gedeclareerd wordt. Het portaal stuurt de declaratie vervolgens naar deze zorgverzekeraar. Het kan in uitzonderingssituaties voorkomen dat tussen het moment van COV en het indienen van de declaratie de patiënt bij een andere zorgverzekeraar verzekerd is, bijvoorbeeld omdat een zorgverzekerde met terugwerkende kracht bij een andere zorgverzekeraar verzekerd is. Momenteel worden hiervoor door zorgverzekeraars onderling afspraken gemaakt. In dit architectuurontwerp (en bij de referentieprocessen) wordt er vanuit gegaan dat dit onderling geregeld wordt en dat de zorgaanbieder kan declareren bij de verzekeraar waar hij COV heeft uitgevoerd.

3.6.3 Gebruik AGB code AGB staat voor Algemeen Gegevens Beheer. Dit is een code die door verzekeraars is toegekend aan zorgaanbieders. Deze code wordt momenteel gebruikt als identificatie van de zorgaanbieder in de communicatie tussen zorgaanbieders en zorgverzekeraars. Met de introductie van de UZI-pas ontstaat er een nieuw nummer waarmee een zorgaanbieder wordt geïdentificeerd. Uit onderzoek van CIBG is gebleken dat de vervanging van AGB door UZI een stap te ver. Op basis van dit onderzoek is besloten om voorlopig beide nummers te gebruiken: “Introductie van het UZI-nummer voor authenticiteit en onweerlegbaarheid in de elektronische communicatie. AGB-nummer handhaven voor administratieve toepassingen en declaratieverkeer”. Zie ook het rapport van Vektis over AGB24. 24

Onderzoek AGB-register, spelregels relatie UZI-nummer en AGB-nummer, versie 4.0 definitief,

25 oktober 2004, Vektis

- 24 -


Dit betekent dat het UZI-nummer van een zorgaanbieder in de declaratiecasus gebruikt wordt op infrastructuurniveau, ofwel dat de identificatie en authenticatie van de zorgaanbieder op de infrastructuur via het UZI-register verloopt. Als deze identificatie en authenticatie geslaagd is, wordt in de berichten vervolgens de AGB-code gebruikt. Om de koppeling mogelijk te maken, worden twee maatregelen genomen: De AGB-code wordt op de UZI-pas (in het certificaat) opgenomen, zodat een kaartlezer de AGB-code kan ophalen; Het CIBG zal een koppeltabel bijhouden en beschikbaar stellen, zodat bij een UZInummer de actuele AGB-code opgehaald kan worden25. Voor detail wordt verwezen naar het rapport over de AGB van Vektis26. Om op termijn een migratie naar UZI-nummer mogelijk te maken, zal in de berichten naast de AGB-code ook het UZI-nummer opgenomen worden. Zie ook 6.5 over migratie AGB. Het portaal zal geen berichtinhoudelijk controles uitvoeren. Het portaal zal dan ook geen controle uitvoeren of er wel een juiste combinatie van AGB en UZI is gebruikt. Dit is de verantwoordelijkheid van de zorgaanbieder (en controle door zorgverzekeraar).

3.7 Eisen aan zorgsystemen Zorgsystemen die deel willen nemen aan het declaratieverkeer zullen aangesloten moeten worden op de basisinfrastructuur. Vanuit het AORTA architectuurontwerp worden eisen gesteld aan aangesloten zorgsystemen (GBZ’en). Voor de declaratiecasus wordt een referentieproces opgezet waarin ook de te hanteren berichtstandaarden worden vastgesteld. Een eis aan de zorgsystemen zal zijn dat zij moeten voldoen aan deze standaarden. Uit de probleemanalyse27 blijkt dat uitval ontstaat omdat de versturende en ontvangende partij niet altijd dezelfde (versie van) codetabellen gebruiken. Een eis aan de zorgsystemen zal worden dat zij de juiste (versie van) codestelsels gebruiken. (In het project effectief codebeheer worden de codestelsels verbeterd zodat ze eenduidig en kwalitatief zullen zijn)28. In de referentieprocessen wordt op meerdere momenten van zorgaanbieders verwacht dat zij een controle op verzekeringsrecht uitvoeren (zie 3.3.1). De vraag kan gesteld 25

Dit is nodig, omdat beide nummers andere beheerregels kennen. In de tijd kan een

zorgaanbieder verschillende AGB-codes toegekend krijgen, terwijl hij hetzelfde UZI-nummer behoudt. 26

Zie voetnoot 24. Met name tabel B.7-2 toont de koppeling UZI-AGB.

27

Het rapport is beschikbaar op www.nictiz.nl, onder de kop e-declareren / publicaties

28

Er is gekozen voor het principe dat het portaal geen inhoudelijke controles zal uitvoeren op de

berichten. Het portaal zal dan ook geen controles uitvoeren of de ontvangen berichten werken met de juiste versie van de codestelsels. Deze controles zullen daarom bij de ontvangers (zorgaanbieder of zorgverzekeraar) van de berichten uitgevoerd moeten worden.


- 25 –

worden of voor bewijsvoering (heeft de zorgaanbieder de COV uitgevoerd of niet) het nodig zal zijn om deze COV-verzoeken (en –antwoorden) vast te leggen (te loggen). Vervolgvraag is waar deze logging plaats moet vinden, bij de zorgaanbieder, zorgverzekeraar of een derde partij. In dit architectuurontwerp wordt er vanuit gegaan dat logging voor bewijsvoering bij de zorgaanbieder plaats vindt. (Deze keuze is gemaakt in de referentieprocessen).

- 26 -


4. Informatielaag 4.1 Berichten Om in 2005 operationeel te kunnen e-declareren zal gebruik gemaakt worden van de bestaande declaratieberichten (EI-standaarden) die beheerd worden door Vektis. Vanuit de probleemanalyse en de referentieprocessen en het effectief codebeheer kunnen aanpassingen op de berichten worden verwacht. Elektronische machtigingen zullen tot nieuwe berichten leiden. Vanuit de referentieprocessen wordt in kaart gebracht welke berichten in de processen gebruikt gaan worden (korte termijn) en eventueel benodigde wijzigingen op deze berichten. In samenwerking met Vektis zal als nodig aanpassingen hieraan worden doorgevoerd.

4.2 Coderingsstelsels Het project ‘effectief codebeheer’ werkt aan verbeteringen in de bestaande codestelsels. Uitgangspunt van dit project is dat de codestelsels eenduidig, ondubbelzinnig zijn. Een standaard of codestelsel moet op één plek beheerd en beschikbaar gesteld worden. In de berichtspecificaties voor de declaratiecasus zal van deze verbeterde codestelsels gebruik gemaakt gaan worden. Om te voorkomen dat zorgaanbieder, zorgverzekeraar en het declaratieportaal met verschillende versies van de codestelsels werken, zal in de berichten duidelijk gemaakt moeten worden van welke versie van de codestelsels gebruik gemaakt moet gaan worden. Communicerende partijen hebben daarmee de mogelijkheid om te controleren of zij gebruik maken van dezelfde versie. Er wordt een centraal informatieportaal voorzien waar partijen inzicht kunnen krijgen in alle berichtstandaarden en codestelsels voor het declaratieverkeer, zie 3.5.3.

4.3 Identificatie, authenticatie en autorisatie Voor de identificatie, authenticatie en autorisatie in het declaratieverkeer wordt gebruik gemaakt van authentieke bronregisters. De bronregisters waarvan de declaratiecasus gebruik maakt zijn: UZI voor zorgaanbieders UZOVI voor zorgverzekeraars BSN voor patiënt/verzekerde VDZ voor de partijen in de zorg die niet onder UZI of UZOVI vallen, zoals hulpmiddelen, vervoer, tussenschakels, etc. 29 De bronregisters UZI, UZOVI en VDZ worden gebruikt voor de identificatie en authenticatie in het berichtverkeer van zorgaanbieder, zorgverzekeraar zorgverleners in het vierde domein. Berichtinhoudelijk wordt gebruik gemaakt van AGB-codes (zie ook 3.6.3) voor identificatie van een zorgaanbieder. De beheervoorzieningen voor het BSN (SBV en OBV) worden gebruikt voor het vinden en controleren van een BSN van een patiënt/verzekerde bij inschrijving (en mogelijk bij 29



- 27 –

mutatie van de inschrijving)30. Bij alle communicatie over een patiënt/verzekerde verloopt identificatie van de patiënt/verzekerde via zijn BSN. Merk op dat tussenschakels vanuit hun bewerkers rol geen controle op BSN via het SBV mogen doen. Deze handeling zal (volgens de wet en regelgeving rondom BSN) door de zorgaanbieder en zorgverzekeraar zelf gedaan moeten worden. Zorgaanbieders en zorgverzekeraars zorgen voor identificatie en authenticatie van de patiënt/verzekerde in haar processen. Het BSN van de patiënt/verzekerde worden door de infrastructuur en het portaal niet extra gecontroleerd. Voor de identificatie van de zorgaanbieder zal voor de beveiligde communicatie via een PKI gebruik gemaakt worden van het UZI-register. In het bericht zal de AGB-code gehandhaafd blijven. De AGB-processen worden verbeterd in het project effectief codebeheer.

4.4 Functionaliteit 4.4.1 Functionaliteit van het declaratieportaal Het portaal biedt functionaliteit voor controle op verzekeringsrecht (COV), voor het indienen van declaraties en voor het bieden van retourinformatie (over declaraties) en voor het uitwisselen van machtigingen. Het portaal legt hierbij geen zorginhoudelijke gegevens vast. Zie ook 3.6.1. De gegevens die het portaal wel vastlegt zijn: Logging van uitgewisselde berichten, wie deze wanneer verstuurd heeft en aan wie (maar niet het bericht zelf); Tijdelijk vasthouden van een bericht op het portaal omdat de ontvanger tijdelijk geen berichten kan ontvangen (buffering/queuing); Statusinformatie over ingediende declaraties (ontvangen, geaccordeerd, etc.). Het portaal draagt verder zorg voor het afleveren van een verzoek bij de juiste zorgverzekeraar. Zie ook 3.6.2. In een plaatje ziet het portaal er functioneel als volgt uit:

30

In het kader van nummerpropogatie kan het gecontroleerde BSN ook bij een zorgverzekeraar

opgevraagd worden.

- 28 -


Het declaratieportaal

ZorgZorgaanbieder

ZorgZorgverzekeraar

aanbieder

aanbieder

Webbrowser

Website voor interactief (handmatig) uitvoeren processen

Berichteninterface

XIS

Declaraties

Ophalen retourinformatie

Indienen machtigingen

Statusinformatie

Autorisatiefunctie

Berichteninterface

COV

Informatiesysteem

Routeringsfunctie berichten

Identificatie en authenticatie (PKI)

In de volgende paragrafen wordt de functionaliteit van het portaal voor de verschillende processen nader uitgewerkt.

Uitvoeren controle op verzekeringsrecht (COV) De COV-functionaliteit omvat: Het zoeken naar een verzekerde op een specifieke peildatum; Het bekijken van verzekeringsgegevens van een verzekerde op die peildatum. De gegevens zijn: particulier of ziekenfonds; Het bekijken of de verzekering van de persoon wel of niet actief is op die peildatum. Als een zorgaanbieder in het COV-verzoek ook een verrichting heeft opgenomen, omvat de functionaliteit ook: Het bepalen of de zorgaanbieder de verrichting kan declareren bij de zorgverzekeraar; Het bepalen of de zorgaanbieder een betalingsgarantie heeft voor deze verrichting; Het bepalen of er voor deze verrichting een machtiging benodigd is. Voor de COV biedt het portaal de volgende methoden van indienen van verzoeken: Handmatig indienen van één COV-verzoek via een interactieve webinterface; Handmatig aanleveren van een batchbestand met COV-verzoeken met behulp van een interactieve webinterface; Online (onderwater) indienen van een of meerdere COV-verzoeken zodat een XIS het COV-verzoek elektronisch bij het portaal kan indienen (geen handmatige actie op het portaal, maar een systeemkoppeling). De zorgaanbieder dient het UZOVI-nummer (mits hij die weet) in het verzoek op te nemen (t.b.v. efficiënt zoeken). Het portaal draagt vervolgens zorg dat het verzoek bij de juiste zorgverzekeraar ingediend wordt. Het portaal draagt zorg voor een snel antwoord op een COV-verzoek. De tijdigheideisen van COV wordt in het project 'referentieprocessen e-declareren' nader uitgewerkt.

Indienen van declaraties en ontvangen van retourinformatie Het portaal biedt voor het indienen van declaraties en het ophalen van retourinformatie de volgende functionaliteit:


- 29 –

Indienen van declaraties. Hierbij dient de indiener na het opsturen van het bestand met declaraties eerst akkoord te geven op het portaal voordat het portaal de declaraties verstuurt naar de zorgverzekeraar(s). Uitgangspunt hierbij is dat een bestand declaraties bevat voor één zorgverzekeraar; Zoeken naar en bekijken van de status31 van de ingediende declaraties (op bestandsniveau); Ophalen van retourinformatie. 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.

Voor het indienen van declaraties biedt het portaal de volgende mogelijkheden: Batchgewijs via het aanleveren van een bestand met declaraties met behulp van een interactieve webinterface; Online (onderwater) zodat een XIS een bestand met declaraties elektronisch bij het portaal kan aanleveren (geen handmatige actie op het portaal, maar een systeemkoppeling). Het portaal zal een technische controle (integriteit, syntax) uitvoeren of het aangeleverde bestand correct is.

Het aanvragen van machtigingen en ontvangen van retourinformatie Voor het machtigingenproces is momenteel geen berichtstandaard gedefinieerd. In de referentieprocessen wordt er vanuit gegaan dat het portaal functies biedt voor: het indienen van een verzoek tot machtiging door zorgaanbieders namens een verzekerde; het ophalen van het antwoord op het machtigingsverzoek. Hierbij zal het portaal de volgende methoden ondersteunen voor het indienen van machtigingen: Handmatig indienen van één aanvraag via een interactieve webinterface; Online (onderwater) aanleveren van één aanvraag zodat een XIS de aanvraag elektronisch bij het portaal kan aanleveren (geen handmatige actie op het portaal, maar een systeemkoppeling); Handmatig inzien van het antwoord op de aanvraag via een interactieve webinterface; Online (onderwater) opvragen van het antwoord op een aanvraag zodat een XIS de aanvraag elektronisch bij het portaal kan ophalen (geen handmatige actie op het portaal, maar een systeemkoppeling).

31

Hoe ver (welk detail) deze statusinformatie gaat is nog onderwerp van onderzoek. Minimaal zal

het portaal kunnen aangeven of een declaratiebestand in goede orde is ontvangen en of deze is aangeleverd bij de zorgverzekeraar

- 30 -


4.4.2 Functionaliteit van aangesloten systemen Zorgaanbieders Voor aansluiting op de infrastructuur zijn functionele eisen gesteld in het AORTA architectuurontwerp en de bijbehorende specificaties. Voor de declaratiecasus zijn de volgende van belang: Uniek identificeren van een patiënt. Zorgaanbieders zijn verantwoordelijk voor het registeren van het correcte BSN bij een patiënt. Hiervoor zal de zorgaanbieder gebruik (kunnen) maken van de SBV (zie ook 3.4.5); Aanbieden van de identiteit (UZI en AGB) van de zorgaanbieder bij een aanvraag; Het combineren, reduceren en presenteren van het resultaat van de aanvraag. De zorgaanbieder zal verzoeken bij het portaal moeten kunnen indienen. Dit betekent dat de zorgaanbieder: Vanuit de XIS verzoeken bij het portaal kan indienen (geautomatiseerde ‘onderwater’ systeemkoppeling); Een bestand met verzoeken kan aanmaken om deze handmatig via de webinterface bij het portaal aan te bieden; Handmatig een enkel verzoek bij het portaal kan indienen via de interactieve webinterface. De specifieke beveiligingseisen voor een zorgaanbieder worden beschreven in 4.4.5.

Zorgverzekeraars Voor aansluiting op de infrastructuur zijn functionele eisen gesteld in het AORTA architectuurontwerp en de bijbehorende specificaties. Voor de declaratiecasus zijn de volgende van belang: Uniek identificeren van een patiënt/verzekerde. Zorgverzekeraars zijn verantwoordelijk voor het registeren van het correcte BSN bij een verzekerde. Hiervoor kan de zorgverzekeraar gebruik maken van het SBV; Aanbieden van de identiteit van de zorgverzekeraar bij een antwoord; Het combineren, reduceren en presenteren van het resultaat van de aanvraag. Alle zorgverzekeraars sluiten zich aan bij het portaal. Dit betekent dat de zorgverzekeraar de volgende functionaliteit moet bieden die vanuit het portaal kan worden gebruikt: Verwerken machtigingsverzoeken; Direct uitvoeren van een COV-verzoek (dit kan uitbesteed worden aan een tussenschakel); Verwerken declaraties en verschaffen retourinformatie. Hiervoor dient een zorgverzekeraar voor COV, voor machtigingen en voor declaraties zowel batch als online bevraging te ondersteunen De specifieke beveiligingseisen voor een zorgverzekeraar worden beschreven in 4.4.5.

Tussenschakels Voor aansluiting op de infrastructuur zijn functionele eisen gesteld in het AORTA architectuurontwerp en de bijbehorende specificaties. Voor de declaratiecasus zijn de volgende van belang:


- 31 –

Uniek identificeren van een patiënt. Zorgaanbieders zijn verantwoordelijk voor het registeren van het correcte BSN bij een patiënt. Hiervoor kan de zorgaanbieder gebruik maken van het SBV. De tussenschakel zal ook het BSN gebruiken, namens een zorgaanbieder, maar zal er vanuit gaan dat de zorgaanbieder identificatie van de patiënt heeft gedaan. Een tussenschakel zal (en mag dit ook niet volgens BSN-wetgeving) geen gebruik maken van het SBV; Aanbieden van de identiteit van de tussenschakel bij een aanvraag en de identiteit van de partij namens wie zij deze aanvraag uitvoeren; Het combineren, reduceren en presenteren van het resultaat van de aanvraag.

De tussenschakels zullen, als bewerker, tevens moeten voldoen aan de eisen die gesteld worden aan de processen die zij uitvoert namens een zorgaanbieder of zorgverzekeraar, zoals hierboven beschreven in 4.4.2. De communicatie tussen zorgaanbieder en tussenschakel valt buiten de scope van dit document. Zie de uitgangspunten in hoofdstuk 2. Wel geldt dat deze communicatie zal moeten voldoen aan de eisen en waarborgen die gesteld worden vanuit weten regelgeving (Wet Bescherming Persoonsgegevens, Wet BSN in de Zorg) De specifieke beveiligingseisen voor een tussenschakel worden beschreven in 4.4.5.

Vierde domein partijen Voor zorgaanbieders in het vierde domein geldt hetzelfde als hierboven is beschreven onder de kop ‘zorgaanbieders’ Voor de tussenschakels en ander partijen die optreden namens een zorgaanbieder of zorgverzekeraar geldt hetzelfde als hierboven is beschreven onder de kop ‘tussenschakels’

4.4.3 Functionaliteit van het informatieportaal voor codestelsels Vanuit het project 'effectief codebeheer' is een centraal informatieportaal voorzien voor informatie over berichtstandaarden en bijbehorende codestelsels. Dit portaal voorziet in twee functies: Een informerende functie. Via het portaal worden alle berichtstandaarden en bijbehorende codestelsels voor declaratiecasus ontsloten. Hierbij wordt vanaf dit centrale punt verwezen naar de (website van de) beheerder van de standaard/codestelsel; 32 Een routerende functie. Voor AGB en mogelijk voor CLIQ wordt ter ondersteuning van de beheerprocessen een aanvraagfunctie op het portaal voor zien voor AGB-nummers en CLIQ-codes. Deze aanvraag wordt doorgegeven aan de beheerder van AGB of CLIQ die de verder afhandeling doet.

4.4.4 Infrastructuur De infrastructuur zal de volgende functionaliteit bieden: Zorgen voor overdracht van berichten tussen zorgverleners, vierde domein partijen, het portaal en de zorgverzekeraars; Zorgen voor beveiligde verbindingen waarover de berichten uitgewisseld kunnen worden;

32

Codetabel voor hulpmiddelen

- 32 -


Zorgen voor toegang tot de registers in het identificerend stelsel, namelijk SBV (BSN), UZI, UZOVI en VDZ; Zorgen voor logging van identificatie en authenticatie.

De specifieke beveiligingseisen voor de infrastructuur worden beschreven in 4.4.5.

4.4.5 Beveiliging Infrastructuur De hieronder beschreven functionele beveiligingseisen zijn overgenomen uit het AORTA architectuurontwerp en specifiek gemaakt voor de declaratiecasus: PKI voor de beveiligde communicatie tussen alle partijen op basis van PKI Overheid; Authenticeren van zorgsystemen, zorgverlener (UZI en VDZ), zorgverzekeraar (UZOVI en VDZ) en het portaal (nog niet bepaald register). Aangesloten zorgsystemen mogen er vanuit gaan dat bij binnenkomende berichten de identiteit en authenticiteit van de versturende partij is geverifieerd; Vaststellen van de privileges die behoren bij de rol van de communicerende partij; Logging van alle transacties zodat de rechtmatigheid achteraf kan worden gecontroleerd en transacties onweerlegbaar worden vastgelegd.

Aangesloten systemen De functionele beveiligingseisen aan aangesloten systemen zijn dezelfde als die geformuleerd zijn in het AORTA architectuurontwerp.

Het declaratieportaal De functionele beveiligingseisen die betrekking hebben op aangesloten systemen (zie hierboven) zijn ook voor het portaal van toepassing. Daarnaast geldt: Het portaal stelt alleen die gegevens ter beschikking aan een verzoeker waarvoor die verzoeker geautoriseerd is. Dit betekent dat: o Een zorgaanbieder kan alleen de informatie zien die voor hem van toepassing is o Een tussenschakel alleen de informatie kan zien voor zorgaanbieders die de tussenschakel hebben geautoriseerd. Het portaal zal technische controle uitvoeren op ontvangen berichten (integriteit, syntax).

Het informatieportaal voor codestelsels Dit portaal stelt informatie over berichtstandaarden en codestelsels aan iedereen ter beschikking. Voor het indienen van aanvragen zal identificatie, authenticatie en autorisatie plaats vinden van de aanvrager.

PKI De functionele beveiligingseisen aan de PKI voor de declaratiecasus zijn dezelfde als die geformuleerd zijn in het AORTA architectuurontwerp.

Registers voor identificatie en authenticatie De communiceren met de registers voor identificatie en authenticatie (UZI, UZOVI, VDZ en ook BSN/SBV) kan via het LSP verlopen zoals nader beschreven in het AORTA


- 33 –

architectuurontwerp. Het is daarnaast ook mogelijk voor zorgaanbieders, tussenschakels en zorgverzekeraars om direct de registers te raadplegen. In het kader van de nummerpropagatie kunnen zorgaanbieders in plaats van het SBV ook gebruik maken van zorgverzekeraars voor het opvragen van gecontroleerde BSNnummers.

4.4.6 Interactieprincipes declaratieverkeer De volgende figuur laat zien hoe de communicatie plaats vindt tussen de verschillende partijen die bij de declaratiecasus betrokken zijn. Toegang tot registers (evt. via LSP)

Zorgaanbieder

tussenschakel: door zorgaanbieder uitbestede processen

Declaratieportaa l

tussenschakel: door zorgaanbieder uitbestede processen

Zorgverzekeraar

De figuur laat zien dat zorgaanbieders met zorgverzekeraars via het portaal communiceren. Ook kunnen er tussenschakels in deze communicatie betrokken zijn. Voor de authenticatie wordt gebruik gemaakt van authentieke registers. Deze communicatie kan via het LSP verlopen.

Communicatiepatroon tussen zorgaanbieder en portaal Een zorgaanbieder kan op het portaal een verzoek doen voor controle op verzekeringsrecht. Dit verzoek moet direct worden beantwoord door het portaal (zie onder voor nadere uitwerking). Voor het indienen van declaraties, het ophalen van retourinformatie en het indienen van machtigingen zal het portaal niet direct een antwoord hoeven geven. De zorgaanbieder biedt de berichten hiervoor bij het portaal aan en het portaal neemt deze in ontvangst. Hierna wordt de communicatie met de zorgaanbieder afgesloten. De machtigingen en declaraties worden vervolgens door het portaal aangeleverd bij de zorgverzekeraars. Het ophalen van de retourinformatie werkt volgens het postbusmechanisme. Zorgverzekeraars bieden de retourinformatie bij het portaal aan. Het portaal legt deze in de postbus van de zorgaanbieder vast. De zorgaanbieder gaat op eigen initiatief op het portaal de retourinformatie ophalen. Alternatief voor dit 'pull'-mechanisme is een 'push'mechanisme waarbij het portaal actief de zorgaanbieder (of zijn tussenschakel) informeert dat retourinformatie beschikbaar is. Dit vindt plaats via webservices. Dit alternatief is optioneel. Zorgaanbieders die van deze mogelijkheid gebruik willen maken zullen continu online moeten zijn.

- 34 -


Communicatiepatroon tussen portaal en zorgverzekeraars Een zorgaanbieder weet niet in alle gevallen bij wie een patiënt verzekerd is. Ook kan zijn informatie achterhaald zijn. Bij het verzoek voor controle op verzekeringsrecht zal de zorgaanbieder de bij hem bekende zorgverzekeraar in het bericht aangeven. Het portaal zal eerst bij die zorgverzekeraar de COV uitvoeren. Mocht blijken dat deze zorgverzekeraar toch niet de zorgverzekeraar van de patiënt is, worden alle andere zorgverzekeraars het COV-verzoek toegestuurd. Het communicatiepatroon hiervan is die van ‘broadcast’, ofwel dat het portaal aan elke zorgverzekeraar zal vragen voor wie een bericht van een patiënt bedoeld is. Het portaal krijgt van elke zorgverzekeraar een antwoord (wel/niet verzekerd en basisverzekering of aanvullende verzekering). Maximaal twee zorgverzekeraars geven het antwoord 'wel' terug (een voor basis- en een voor aanvullende verzekering). In het antwoord naar de zorgaanbieder zal het portaal de UZOVI-nummesr van deze zorgverzekeraars opnemen. Voor machtigingverzoeken en ingediende declaraties geldt dat de zorgverzekeraar deze op eigen initiatief bij het portaal ophaalt. Ook hier geldt een postbusmechanisme. Als de declaraties door de zorgverzekeraar verwerkt zijn, zal de zorgverzekeraar de retourinformatie bij het portaal aanleveren. Het portaal bewaart deze in de postbus van de zorgaanbieder.

Communicatiepatroon tussen portaal en tussenschakels Als een zorgaanbieder of een zorgverzekeraar processen hebben uitbesteed aan tussenschakels, dan zullen deze tussenschakels communiceren namens de zorgverzekeraar of zorgaanbieder. Voor beveiligde communicatie zullen deze tussenschakels een eigen identiteit krijgen (UZI- of VDZ-register). In de berichten zal duidelijk gemaakt worden dat de tussenschakel namens een andere partij berichten verstuurt. Het portaal zal kennis moeten hebben om bij het vinden van de zorgverzekeraar of zorgaanbieder eventueel de tussenschakel te gebruiken. Momenteel wordt onderzocht of de tussenschakel tussen portaal en zorgverzekeraar op de hierboven beschreven wijze in de architectuur een plek moet krijgen. Een alternatief is het plaatsen van de tussenschakel ‘achter’ de zorgverzekeraar. Als de zorgverzekeraar voor bepaalde berichten de afhandeling heeft uitbesteed aan een tussenschakel, dan zal de zorgverzekeraar zelf het bericht aan die partij moeten doorsturen. Dit voorkomt complex beheer bij het portaal voor de routering van berichten.

4.4.7 Interactieprincipes informatieportaal codestelsels Een partij die informatie zoekt over codestelsels en berichtstandaarden voor declaratieverkeer kan bij dit portaal terecht. Op een plek wordt het overzicht gegeven van alle berichtstandaarden en codestelsels. Via verwijzingen wordt de lezer naar de beheerder van de standaard of codestelsel doorverwezen. Partijen die een aanvraag willen doen voor een AGB-code en/of CLIQ (codes voor hulpmiddelen) kunnen na identificatie en authenticatie bij het portaal een verzoek invullen via een formulier. Het portaal zorgt ervoor dat dit formulier gerouteerd wordt naar de juiste beheerder die de afhandeling verder doet.


- 35 –

Toegang tot registers (evt. via LSP)

Zorgaanbieder en/of zorgverzekeraar

- 36 -

codestelselportaal

Beheerder standaard en/of codestelsel


5. De technische laag In dit hoofdstuk wordt aangesloten bij het service model voor de technische laag zoals beschreven in het AORTA architectuurontwerp:

In hetzelfde architectuurontwerp wordt een uitwerking van het service model voor de koppelvlakken beschreven (in paragraaf 7.3). Kijkend naar de declaratiecasus zal deze anders worden: Er komt een declaratieportaal waarlangs alle declaratieberichten zullen gaan; Niet alle voorzieningen zijn voor e-declareren benodigd. De verwijsindex- en autorisatiemodule bijvoorbeeld zijn niet benodigd voor e-declareren in de architectuur die in dit document is beschreven. Hierdoor ontstaat het volgende (aangepaste) model: Gebruiker A

Centrale voorzieningen

Gebruiker B

Portalen: declaratieportaal en codestelsels codestelselsportaal -portaal App

Voorzieningen SSC: Logging, I&A en toegang tot registers

App

Berichten

Transport

Merk op dat dit plaatje niet aangeeft waar de portalen, de logging en de identificatie & authenticatie (I&A) functionaliteit belegd wordt. Waar mogelijk wordt gebruik gemaakt van het Landelijk Schakelpunt. Logging op infrastuctuurniveau (zie 3.3.4 onder de kop


- 37 –

'Integriteit en onweerlegbaarheid') en I&A (ook voor toegang tot authentieke registers) worden bij dit LSP belegd. Logging op applicatieniveau bij de zorgaanbieder. Het LSP heeft geen voorzieningen voor een portaal. Dit zal apart belegd worden.

5.1 Invulling van het service model In deze paragraaf wordt de invulling van de verschillende componenten in het service model beschreven.

5.1.1 Netwerkniveau en transport Op netwerkniveau wordt volledig aangesloten bij de AORTA architectuur. Dat betekent dat de communicatie zal verlopen op basis van Internet-protocollen (TCP/IP en/of UDP/IP). Ten behoeve van beveiligde verbindingen wordt SSL v3.0 of TSL v1.0 gebruikt (zie verder 5.2 voor beveiligingsprincipes). De certificaten die hierbij worden toegepast dienen te voldoen aan X.509 versie 3. De basisinfrastructuur staat het toepassen van een VPN prima toe, maar ook beveiligde en versleutelde verbindingen (SSL) over het publieke internet. In het AORTA architectuurontwerp zijn de scenario’s hiervan nader uitgewerkt. Zie paragraaf 7.5 Beveiliging, continuïteit en beheer van het AORTA architectuurontwerp.

5.1.2 Interoperabiliteit/berichtcommunicatie Ten behoeve van de interoperabiliteit is het noodzakelijk een standaard te kiezen voor syntax, semantiek en uitwisselmechanisme van de berichten voor het declaratieverkeer. Het uiteindelijke doel is om op dit punt aan te sluiten bij de principes van het AORTA architectuurontwerp, namelijk HL7 berichten via webservices technologie (zie paragraaf 7.4.2 uit het AORTA architectuurontwerp). Op korte termijn (1-1-2006) is deze stap niet haalbaar. Er wordt daarom uitgegaan van de huidige EI-standaarden van Vektis. Deze standaarden zullen voor de declaratiecasus aangepast worden (in het project referentieprocessen zullen de noodzakelijke wijzigingen in kaart worden gebracht en in het project effectief codebeheer zal de kwaliteit en eenduidigheid van de codestelsels die gebruikt moeten worden in de berichten verbeterd worden). De zorgaanbieder communiceert met het portaal op twee mogelijke manieren: handmatig via een webinterface (HTML over HTTPS). Hierbij kunnen batchbestanden via een HTTPS-UPLOAD worden aangeleverd; geautomatiseerd (onderwater). Hierbij zal de XIS gebruik maken van SOAP over HTTPS om een enkel bericht aan te leveren. Voor batchbestanden gebruikt de XIS SOAP en DIME33 over HTTPS. De DIME standaard wordt gebruikt om een bestand dat niet volgens XML is opgemaakt op te kunnen nemen in een SOAP bericht. De zorgverzekeraar communiceert met het portaal via SOAP over HTTPS. Bij het uitwisselen van batchbestanden wordt de DIME standaard gebruikt. 33

Direct Internet Message Encapsulation (DIME) is beschreven in H. Nielsen, H. Sanders, E.

Christensen, "Direct Internet Message Encapsulation (DIME)", INTERNET DRAFT http://www.ietf.org/internet-drafts/draft-nielsen-dime-01.txt

- 38 -


Voor de controle op verzekeringsrecht zal een direct antwoord nodig zijn. De zorgaanbieder zal via SOAP over HTTPS een COV-verzoek aanleveren aan het portaal. Het portaal zal deze aanbieden bij de zorgverzekeraars via een SOAP bericht over HTTPS. In het SOAP bericht zal het COV-verzoek (opgemaakt volgens de Vektis EI-standaarden) opgenomen worden.

5.1.3 Infrastructurele toepassingen Het declaratieportaal Het declaratieportaal is een webapplicatie. Deze biedt een webinterface voor gebruikers die via een webbrowser berichten willen uitwisselen. Daarnaast biedt de webapplicatie een applicatie-applicatie interface zodat XIS'en geautomatiseerd berichten bij het portaal kunnen aanleveren. Verder biedt het portaal een postbusfunctie voor het ophalen van berichten. Het portaal voldoet aan de eisen van een GBZ. Het portaal neemt deel in de PKI voor beveiligde communicatie en krijgt een identiteit (vanuit het UZI-register)

Het informatieportaal voor codestelsels Dit portaal is een website. Via deze website worden alle standaarden en codestelsels binnen de declaratiecasus op een plek beschreven. Waar mogelijk wordt verwezen naar de website van de beheerder van de standaard of codestelsel via hyperlinks. De aanvraagfunctie van het portaal is beschikbaar op het portaal. Via een webformulier wordt de aanvraag ingevoerd. Het portaal verstuurt het formulier naar de juiste beheerder die de aanvraag verder afhandelt. Voor het gebruik van deze functie moet de gebruiker geautoriseerd worden.

Authentieke registers via het LSP Voor beveiligde communicatie wordt gebruik gemaakt van een PKI. De registers die gebruikt worden voor identificatie en authenticatie, UZI, UZOVI, VDZ en SBV (BSN) zullen toegankelijk moeten zijn voor alle communicerende partijen in de declaratiecasus. De toegang tot deze registers kan via het LSP verlopen.

5.1.4 Toepassingen De XIS vanwaar uit gedeclareerd wordt moet berichten kunnen versturen volgens de hierboven beschreven standaarden. Deze berichten moeten verstuurd worden over een (beveiligde) PKI. De XIS moet mogelijk maken om aan een PKI deel te nemen. Dit betekent bijvoorbeeld dat de XIS met het certificaat van de gebruiker om moet kunnen gaan (bijvoorbeeld dat de XIS deze kan lezen van een UZI-pas met behulp van een kaartlezer). Aan de kant van de zorgverzekeraar geldt eigenlijk hetzelfde. De toepassingen zullen moeten communiceren volgens bovengenoemde standaarden. Ook deze toepassingen moeten kunnen communiceren over een PKI (met een identiteit vanuit het UZOVIregister).


- 39 –

De zorgverzekeraar zal bovendien mogelijk moeten maken van online een COV-verzoek direct wordt beantwoord. Dit impliceert hoge beschikbaarheideisen (die zijn de eisen aan een GBZ die online moet zijn, zoals beschreven in het AORTA architectuurontwerp).

5.2 Beveiliging, continuïteit en beheer 5.2.1 Vertrouwelijkheid In het AORTA architectuurontwerp wordt vertrouwelijkheid van de gegevens gegarandeerd door middel van beveiligde communicatie. De informatie-uitwisseling vindt plaats door een beveiligde ‘tunnel’. Deze tunnel wordt opgezet door middel van een PKI, zoals reeds eerder beschreven. Daarnaast kan ook additioneel gebruik gemaakt worden van VPN technologie.

5.2.2 Identificeren en authenticeren In een PKI wordt gebruik gemaakt van certificaten voor de identificatie en authenticatie van een communicerende partij. (Dit certificaat wordt tevens gebruikt voor de versleuteling van de communicatie). Identificeren en authenticeren van systemen en zorgverleners en zorgverzekeraars vindt plaats op basis van certificaten die worden uitgegeven met behulp van een Public Key Infrastructuur (PKI). Voor een sluitende authenticatie is vereist dat tevens wordt vastgesteld dat degene die een certificaat overlegt, in het bezit is van de bijbehorende private key. Authenticatie op basis van SSL/TLS, dat is gebaseerd op een challengeresponse mechanisme, voldoet aan deze vereisten. Aangezien het SSL/TLS protocol een bewezen technologie is die nog steeds voldoet, wordt de uitwerking van de authenticatiemethode hierop gebaseerd.

5.2.3 Integriteit en onweerlegbaarheid Hierbij wordt aangesloten bij de keuzen die in het AORTA architectuurontwerp zijn genomen: “De uiteindelijke doelstelling voor het garanderen van de integriteit van een bericht en het realiseren van onweerlegbaarheid dat dit bericht door een bepaald persoon is verzonden is het gebruik van de elektronische handtekening. Vooralsnog zullen veel applicaties deze vorm van beveiliging niet kunnen ondersteunen. De Zekerheidsstructuur zal derhalve de integriteit van berichten in eerste instantie garanderen door gebruik te maken van de functionaliteit van SSL/TLS en TCP. Onweerlegbaarheid van aanvragen zal worden gegarandeerd door een adequate authenticatie van de zorgverleners en een sluitend loggingsmechanisme voor alle informatieaanvragen en transacties die via de basisinfrastructuur plaatsvinden.”

5.2.4 Technische eisen PKI Hiervoor wordt verwezen naar de eisen die verwoord zijn in het AORTA architectuurontwerp, paragraaf 7.5.5

5.3 Technische eisen aan aangesloten systemen De aangesloten systemen zullen moeten voldoen aan vier eisen: Er dient connectiviteit te zijn om te kunnen communiceren met behulp van TCPUDP/IP; De systemen dienen te kunnen communiceren in een PKI. Dat betekent

- 40 -


Opzetten beveiligde verbindingen op basis van certificaten Het lokaal beheer van uitgereikte certificaten Controle identiteit en authenticiteit bij beveiligde communicatie via het LSP bij de aangewezen registers UZI, UZOVI, VDZ en SBV (BSN) Voor berichtuitwisseling met het portaal dient communicatie mogelijk te zijn via HTTP en HTTPS over de TCP/IP verbinding. Hierbij wordt bij systeemkoppelingen SOAP over HTTPS toegepast; Voor aangesloten systemen geldt verder de eisen van een GBZ zoals verwoord in het AORTA architectuurontwerp en nader gespecificeerd in 3.3.4. o o o


- 41 –

6. Migratieaspecten De in dit document beschreven architectuur gaat er vanuit dat de declaratiecasus operationeel is per 1-1-2006. Daarom zijn op verschillende punten keuzen gemaakt om deze datum te kunnen halen. Deze punten worden in dit hoofdstuk beschreven.

6.1 Introductie BSN Voor de communicatie over patiënten/verzekerden wordt gekozen voor het BSN als identificerend gegeven. Dit betekent voor de declaratiecasus dat het BSN (en dit is technisch hetzelfde nummer als het sofi-nummer) opgenomen moet worden in de administraties van de zorgaanbieders. Het BSN mag per 1-1-2006 gebruikt worden. In 2005 is dit niet mogelijk. Ook het sofinummer mag in 2005 slechts beperkt gebruikt worden in pilot-omgevingen. Dit betekent dat pas per 1-1-2006 de administraties van zorgaanbieders en zorgverzekeraars voorzien kunnen worden met BSN-nummers. Aangezien de introductie van het BSN – bij met name de zorgaanbieders – enige tijd zal kosten, wordt een overgangsituatie voorzien in het begin van 2006 waarbij naast het BSN de minimale dataset (MDS) mogelijk blijft. Een mogelijke oplossing waar aan gedacht wordt voor het vullen van de administraties van zorgaanbieders met het BSN is dat in het retourbericht van een controle op verzekeringsrecht het BSN van de patiënt/verzekerde is opgenomen. De administraties van de zorgaanbieders kunnen dan het BSN vastleggen en gebruiken in toekomstige communicatie over die patiënt/verzekerde. Deze oplossing voor de introductie van het BSN wordt door de zorgaanbieders als een haalbaar traject gezien. De zorgverzekeraars met ziekenfondsverzekerden zijn reeds voorzien van sofi-nummer in hun administraties. Migratie naar BSN is voor hen eenvoudig. Alleen zorgverzekeraars die alleen particuliere verzekeringen doen, zullen hun administratie met behulp van het SBV moeten aanvullen met het BSN-nummer.

6.2 Introductie identificerend stelsel Het UZI-register is per 1-1-2005 operationeel geworden. Dit register kan dus gebruikt worden voor e-declareren. Volgens de planning is per 1-1-2006 het SBV in de zorg operationeel. De huidige plannen voor het UZOVI-register in het identificerend stelsel laat zien dat per 1-1-2006 het UZOVI-register met certificaten voor PKI gereed zullen zijn. Als het UZOVI register niet tijdig klaar is, zal een tussenoplossing gekozen moeten worden. Gedacht kan worden om op basis van het AGB-register in combinatie met certificaten van een bestaande marktpartij, een tijdelijk register op te zetten Voor de inrichting van het VDZ-register is nog geen duidelijkheid. Besluitvorming dient hierover nog plaats te vinden. Als dit register voor 1-1-2006 niet gereed is, kan tevens overwogen worden om het hierboven genoemde tijdelijke register in te zetten. Dit tijdelijke register zal moeten voldoen aan de eisen/waarborgen die vanuit de BSN-wet wordt gesteld zodat communicatie met BSN door partijen in dit register mogelijk wordt. Tevens zal toegang tot dit register mogelijk moeten zijn voor alle partijen die met VDZpartijen moeten communiceren.

- 42 -


6.3 Autorisatie voor declaratieverkeer Momenteel wordt functionaliteit op het portaal voorzien voor het autoriseren van zorgaanbieders voor het indienen van declaraties, het indienen van machtigingen en het ophalen van retourinformatie. (De COV mag iedereen uitvoeren die door de basisinfrastructuur geïdentificeerd en geauthenticeerd is via UZI). Het LSP bevat impliciet functionaliteit voor het autoriseren van communicerende partijen. Namelijk, een partij is geautoriseerd om gebruik te maken van de communicatiefaciliteiten als hij zich kan identificeren en authenticeren. Dit kan hij doen met behulp van zijn certificaat die hem uitgereikt is vanuit een authentiek register. Als dit certificaat geldig is bevonden en niet verlopen is, is de persoon geautoriseerd om berichten over de PKI te versturen.

6.4 RINIS Zorgverzekeraars zijn in hun backoffice aangesloten op RINIS. Dit is een infrastructuur waarmee zorgverzekeraars zijn gekoppeld zijn aan het GBA, UWV, Justitie en de belastingdienst. Op dit moment zijn de ontwikkelingen vanuit RINIS buiten de scope van de declaratiecasus en worden nu niet meegenomen in het architectuurontwerp. Mogelijk dat op termijn dit wel zal gebeuren.

6.5 AGB en UZI Met de introductie van het UZI-nummer zijn er twee equivalente nummers. De doelstelling is om op termijn te migreren naar het UZI-stelsel. Deze migratie is niet haalbaar voor 1-1-2006. Daarom is gekozen voor de declaratiecasus om beide nummers te hanteren. Het UZI-nummer wordt gehanteerd voor de identificatie en authenticatie voor beveiligde communicatie. Het AGB-nummer wordt in het bericht toegepast als identificatie van de verzekerde in het bericht voor administratieve afhandeling.

6.6 HL7 als berichtstandaard In de zorg bestaat in toenemende mate interesse voor het gebruik van HL7 als berichtstandaard. Ook het AORTA architectuurontwerp gaat uit van het op XML gebaseerde HL7 versie 3. De declaratiecasus zal daar op termijn bij aansluiten. Echter is het niet haalbaar om per 1-1-2006 reeds op HL7 over te gaan. Daarom wordt voor de declaratiecasus gebruik gemaakt van bestaande EI-standaarden en wordt in kaart gebracht welke wijzigingen daarop gedaan moeten worden om het referentieproces te kunnen invoeren. In 2005 kan mogelijk een eerste stap gemaakt worden met elektronisch declareren op basis van HL7 versie 3.

6.7 Testfaciliteiten Nu steeds meer processen elektronisch via berichtenverkeer afgehandeld kunnen worden, is het steeds belangrijker voor een XIS en voor een informatiesysteem van een zorgverzekeraar om te kunnen testen of hun implementatie van de berichtuitwisseling correct functioneert. In het kader van implementatie van de declaratiecasus kan overwogen worden om testfaciliteiten op te zetten bij het portaal voor deze testen. Dit kan onderdeel worden van het certificeringproces voor aangesloten systemen.


- 43 –

7. Concurrentieneutrale architectuur In de architectuurbeschrijving voor e-declareren is gestreefd naar een concurrentie neutrale architectuur. De volgende maatregelen zijn getroffen in de architectuur om deze concurrentie neutrale architectuur te bereiken: Voor de infrastructuur wordt uitgegaan van het AORTA architectuurontwerp voor de zorg. Dit architectuurontwerp en bijbehorende specificaties zorgen voor een generieke infrastructuur in de zorg waar e-declareren van gebruik gaat maken. Voor identificatie en authenticatie van communicerende partijen worden authentieke registers ingezet. Dit zijn UZI voor zorgaanbieders, UZOVI voor zorgverzekeraars en het VDZ-register voor overige partijen. Hierdoor is de toegang tot de infrastructuur voor e-declareren belegd bij authentieke registers die zijn opgezet op basis van de eisen vanuit PKI Overheid. Voor de identificatie van een patiënt/verzekerde wordt het BSN ingezet. Hierdoor wordt een generiek toegankelijk nummer (deze is zelfs niet zorgspecifiek) beheerd vanuit het BSN-stelsel (GBA bij gemeenten) toegepast en niet een specifiek nummer van een marktpartij. In de architectuur worden open standaarden en open codestelsels toegepast. Deze open standaarden en bijbehorende codestelsels zijn voor iedereen toegankelijk onder dezelfde voorwaarden. Op de korte termijn worden bestaande EI-standaarden ingezet die voornamelijk beheerd worden door Vektis. Op termijn wordt overgegaan op het op XML gebaseerde HL7 versie 3 waardoor aangesloten wordt bij internationale open standaarden De interfaces (koppelpunt tussen applicaties) worden gestandaardiseerd op basis van de open standaarden SOAP en XML en internetstandaarden (HTTP en TCP/IP). De architectuur gaat er vanuit dat gegevens beheerd worden bij de bron. Dit impliceert dat het eigendom van gegevens ook bij de bron blijft. Een marktpartij die deelneemt aan e-declareren kan hierdoor geen eigendom verwerven over gegevens die uitgewisseld worden. Buiten de scope van architectuur vallen bestuurlijke afspraken. Een belangrijke afspraak is dat zorgaanbieders, zorgverzekeraars en tussenschakels kunnen deelnemen aan e-declareren onder dezelfde voorwaarden. Andere afspraak die noodzakelijk is betreft het eigendom van de autorisatiegegevens die het portaal zal beheren. Dit zijn de autorisaties om bijvoorbeeld een declaratie bij het portaal in te kunnen dienen of retourinformatie op te halen. De autorisatiefunctie die nu in het portaal is voorzien kan op termijn ook bij het LSP ondergebracht worden. De routeringsfunctie die nu in het portaal is voorzien kan op termijn door de het LSP uitgevoerd worden. Vanuit efficiëntievoordelen kan daarbij de verwijsindex34 ingezet worden om snel de zorgverzekeraar bij een patiënt te kunnen vinden.

34

Met name via de financiële paragraaf in de verwijsindex.

- 44 -


Architectuurontwerp e-declareren

Recommend Documents