Eindrapportage 'De Witte Kaart'

Eindrapportage 'De Witte Kaart' Het ontsluiten van gegevens over zorginstellingen met behulp van het stelsel van basisregistraties

Eindrapportage ‘De Witte Kaart’

1

Versiebeheer & Accordering 1. Revisiehistorie document Versie 01 02 03 04

Datum November 2012 December 2012 Januari 2013 Januari 2013

Status Concept Concept Concept Definitief

Wijziging Zie document Managementsamenvatting Toevoeging Hoofdstuk 5

Opgesteld/gewijzigd door Sandra Thomassen Nicole Damen Sandra Thomassen Ype Schat

2. Goedkeuring Dit projectplan wordt goedgekeurd door de opdrachtgever


2

Inhoudsopgave Voorwoord ......................................................................................................................................... 5 Managementsamenvatting.......................................................................................6 Hoofdstuk 1. Inleiding en achtergrond project ......................................................7 1.1 Aanleiding “De Witte Kaart” ........................................................................... 7 1.2 Leeswijzer ..................................................................................................... 7 1.3 Accordering document................................................................................... 7 Hoofdstuk 2. Achtergrond projectopdracht & inrichting project .........................8 2.1 Uitdaging .................................................................................................. 8 2.2 Doelstelling project ................................................................................... 8 2.3 Vooraf gedefinieerde resultaten................................................................ 8 2.4 Acceptatiecriteria ...................................................................................... 8 2.5 Afbakening................................................................................................ 8 2.6 Randvoorwaarden PSB ............................................................................ 9 2.7 Budget ...................................................................................................... 9 2.8 Relatie met andere projecten / applicaties................................................ 9 Hoofdstuk 3. Projectresultaten..............................................................................10 3.1 Fase 1: Definitiefase ............................................................................... 10 3.1.1 Inleiding ........................................................................................... 10 3.1.2 Definitie van “De Witte Kaart” .......................................................... 10 3.1.3 Wensen en eisen gebruikers ........................................................... 10 3.1.4 Bronbestanden...................................................................................... 13 3.2 Fase 2: Gebruik bronnen en koppelen regio Arnhem ............................. 14 3.2.1 Inleiding ........................................................................................... 14 3.2.2 Aanpak ............................................................................................ 14 3.2.3 Resultaten ....................................................................................... 15 3.2.4 Lessons Learned fase 2........................................................................ 17 3.3 Fase 3: Realisatie Witte Kaart Gallery Nederland................................... 17 3.3.1 Inleiding ........................................................................................... 17 3.3.2 Aanpak landelijke database ontwikkelen ......................................... 17 3.3.3 Viewers............................................................................................ 18 3.3.4 Lessons Learned fase 3 .................................................................. 19 Hoofdstuk 4. Conclusie en aanbevelingen...........................................................20 4.1 Bijdrage stelsel van basisregistraties aan ‘De Witte Kaart’ ..................... 20 4.2 Succesfactoren ....................................................................................... 21 4.3 Baten voor deelnemende partijen ........................................................... 22 4.3.1 Baten voor de OOV sector alias de afnemer ................................... 22 4.3.2 Baten voor het stelsel van basisregistraties..................................... 23 Hoofdstuk 5. Het vervolg .......................................................................................25 5.1 Vooruitblik op architectuur en beveiliging .................................................... 25 5.1.1 Keuzemogelijkheden architectuur.................................................... 25 5.1.2 Wijzigingenbeheer ........................................................................... 25 Eindrapportage ‘De Witte Kaart’

3

5.1.3 Ontsluiting........................................................................................ 25 5.1.4 Datamodel ....................................................................................... 25 5.1.5 Wijze van koppelen bronbestanden................................................. 26 5.1.6 Beveiliging ....................................................................................... 26 5.1.7 Architectuurprincipes ....................................................................... 27 5.1.8 Relaties met andere projecten c.q. systemen.................................. 27 5.2 Mogelijke vervolgstappen ............................................................................ 27 5.2.1. Overdracht GHOR Nederland .............................................................. 28 - Bijlagen - ...............................................................................................................29 Bijlage 1............................................................................................................. 29 Bijlage 2............................................................................................................. 30 Bijlage 3............................................................................................................. 31


4

Voorwoord Ruim anderhalve jaar geleden zijn voor het eerst gesprekken gevoerd tussen i-NUP en Veiligheids- en Gezondheidsregio Gelderland-Midden. Het doel was het verkennen van een goede casuïstiek voor het gebruik van het stelsel van basisregistraties. Nu eind 2012, een jaar later na de start van het project De Witte Kaart, zijn wij klaar met het beproeven van het stelsel van basisregistraties. En met succes. Het bij elkaar brengen van enerzijds de vraag (OOV sector) en aanbod (stelsel van basisregistraties) bleek een dynamisch avontuur te worden. Als veiligheidsregio hebben we niet eerst de kwaliteit van het stelsel bekeken, maar hebben we het ‘gewoon’ gedaan. De projectleiders zijn in de basisregistraties op zoek gegaan naar informatie over zorginstellingen, soms met en soms zonder succes. Vervolgens zijn al die gegevens aan elkaar gekoppeld en ontstond er langzaam een gevulde Witte Kaart. Gewoon doen bleek nog helemaal zo slecht nog niet. Onze innovatieve inzichten zijn uiteindelijk in december 2012 beloond met een prachtig resultaat in de finale van de Don Berghuijs Award 2012. Geen eerste plek, maar niettemin zijn wij er trots op dat we dat podium gehaald hebben. Het was een kers op de taart voor dit project. Uiteindelijk moet je uitdagende zoektochten ook beëindigen en dat doen we door middel van dit eindrapport. In dit rapport nemen wij u mee langs de zoektocht die is afgelegd, geven wij aan welke basisregistraties ons inziens toekomstvast en zeker zijn en welke vervolgstappen nog genomen moet worden. De belangrijkste les voor ons is dat ‘gewoon doen’ loont. Het levert mooie en concrete resultaten die bruikbaar zijn voor de hele sector. Ype Schat, Directeur Publieke Gezondheid Veiligheids- en Gezondheidsregio Gelderland-Midden


5

Managementsamenvatting Het project De Witte Kaart heeft plaatsgevonden tussen 1 januari en 31 december 2012. In het project stond centraal het gebruik van de basisregistraties bij het identificeren van zorginstellingen in heel Nederland voor de sector openbare orde en veiligheid. Het klinkt misschien vreemd, maar tot dusver is er geen goede registratie waarin we zorginstellingen kunnen terug vinden. Waarom hebben we deze gegevens nodig? Cliënten in een verpleeg- of verzorgingshuis, gehandicapten of patiënten in ziekenhuizen zijn niet zelfredzaam. Zij hebben de hulpverleningsdiensten hard nodig bij incidenten, maar dan moeten die hulpverleningsdiensten wel weten waar deze mensen verblijven. Vanuit het project De Witte Kaart is de vraag gesteld aan het stelsel van basisregistraties of het stelsel in staat is om zorginstellingen in Nederland identificeerbaar te maken. Hierbij gaat het om een naam van de organisatie, straat, huisnummer, postcode, plaats en X,Y coördinaat. In de zoektocht naar deze vraag zijn de volgende basisregistraties gebruikt voor onderzoek: Nieuwe Handelsregister (NHR), Basisadministratie Adressen en Gebouwen (BAG), LISA, Waardering Onroerende Zaken. Daarnaast hebben we in het onderzoek de kernregistraties GHOR4all en Populator meegenomen. Een moeilijke factor in dit project was dat geen van deze registraties 100% betrouwbaar was. Met behulp van lokale kennis is bekeken welk bestand de beste kwaliteit leverde. Uit die vergelijking is gebleken dat het NHR bestand in combinatie met de BAG een goede basis vormt om zorginstellingen te identificeren en te ontsluiten in allerlei applicaties voor de sector openbare orde en veiligheid. Hierbij moet opgemerkt worden dat het NHR bestand nu nog niet compleet is, doordat zorginstellingen veelal alleen zijn ingeschreven met hun hoofdlocatie. Bij borging en implementatie van de projectresultaten zal daar dan ook uitgebreid aandacht voor moeten komen. Een tweede optie voor verankeren van goede en betrouwbare data is het inrichten van een sectorale registratie bij het ministerie van Volksgezondheid, Welzijn en Sport. De basis voor die registratie komt nog steeds uit het NHR en de BAG waarmee het principe data halen bij de bron overeind blijft. Voordeel van deze optie is dat de sectorale registratie het NHR al heeft gefilterd op zorginstellingen. Naast het identificeren van zorginstellingen had dit project ook als doel om informatie over het object te geven. In de kernregistratie GHOR4all registreren GHOR regio’s capaciteitsgegevens en voorbereiding op incidenten door zorginstellingen. Dit betreft informatie die niet in de basisregistraties voorkomen. Deze informatie is noodzakelijk voor de GHOR om tijdens incidenten zo adequaat mogelijk op te treden. Door middel van de unieke BAG coördinaten kunnen gegevens uit de landelijke basisregistraties gekoppeld worden met informatie uit GHOR4all. Op die manier ontstaat er database die voor alle partijen binnen de veiligheidsregio bruikbaar is. Eenmalige opslag, meervoudig gebruik. Rampenbestrijders kunnen denken in grote termen als gifwolken maar ook klein als risico-objecten. Daarbij is het van belang dat er goede en betrouwbare informatie is over die objecten. De combinatie van het NHR met de BAG en verrijkt door GHOR4all zal hierbij een belangrijke bijdrage kunnen leveren. Om over te gaan tot verankering zijn er nog wel wat stappen nodig. De ruwe data is niet zomaar op te nemen en zal daarom nog wel aan dienst aangeboden moet worden. Denk hierbij aan de inrichting van een sectoraal knooppunt die een dergelijke dienst kan aanbieden en de informatie zo beschikbaar kan stellen voor meerdere applicaties. Zorg daarbij voor dat het voor de afnemer niet te ingewikkeld wordt. Hoewel basisregistraties toegankelijk zijn blijkt dat in praktijk niet altijd zo te zijn. Zorg ervoor dat dit relatief eenvoudige werkprocessen niet onnodig verstoord. Daarnaast zal aan zijde van de OOV sector in belangrijke mate samenwerking en vraagarticulatie moeten plaatsvinden om niet als individuele dienst dezelfde vraag te stellen, maar gezamenlijk belangen te verankeren tot goede resultaten. Al met al kunnen wij concluderen dat de basisregistraties voldoende basis bieden om belangrijke informatie voor de sector openbare orde en veiligheid uit te genereren. Borging en implementatie van de resultaten van De Witte Kaart vinden wellicht plaats in vervolg projecten, voor nu sluiten wij dit project af.


6

Hoofdstuk 1. Inleiding en achtergrond project 1.1 Aanleiding “De Witte Kaart” Begin 2011 kwam er nieuw elan vanuit het Programmaraad Stelsel van Basisregistraties (PSB) voor het gebruik van basisregistraties in de ketens. Want daar, in de keten, moet het gebeuren. In het jaarplan 2011 van de PSB waren een aantal doelen gedefinieerd om de ketenbenadering te realiseren: • het gebruik van basisregistraties in de uitvoering te bevorderen; • perspectief te bieden op versnelling van de implementatie en; • beter zichtbaar te maken waar de baten van een werkend stelsel zich voordoen. Op de agenda van VGGM stond al langer de wil om zorginstellingen in kaart te brengen met behulp van de basisregistraties. Actuele, betrouwbare informatie over zorginstellingen is soms letterlijk van levensbelang in crisissituaties. Veel mensen zijn zelfredzaam, maar dat geldt niet voor bewoners van verpleeg- en verzorgingshuizen, of patiënten in een ziekenhuis. Juist als het dáár mis gaat moet je snel volledige informatie hebben om hen te helpen. Die informatie kan ontsloten worden met behulp van basisregistraties. Zodoende wilde de VGGM graag haar steentje bijdragen om het nieuwe elan vanuit de PSB te helpen versterken en verzilveren. In de beantwoording van de vraag “is het mogelijk om de binnen de overheid beschikbare databases te koppelen en te ontsluiten met gegevens over zorginstellingen?” komt de VGGM (als vraagzijde) en de PSB (als aanbodzijde) samen. Uniek is dat dit project begint bij de vraagzijde.

1.2 Leeswijzer In dit rapport vindt u informatie over de achtergrond en inrichting van project de Witte Kaart (hoofdstuk 2). De projectresultaten en de bevindingen van de verschillende fasen die doorlopen zijn (hoofdstuk 3). En tot slot de conclusie en aanbevelingen (hoofdstuk 4). In het laatste hoofdstuk (5) blikken we vooruit op de toekomst.

1.3 Accordering document De opdrachtgever van het project is de heer Ype Schat, directeur GHOR van Veiligheids en Gezondheidsregio Gelderland-Midden (VGGM). Hij heeft ter ondersteuning van zijn rol als opdrachtgever een stuurgroep voor dit project ingericht. De stuurgroep stelt het PID en de (tussen)resultaten vast.


7

Hoofdstuk 2. Achtergrond projectopdracht & inrichting project Met dit project werd beoogd een werkende Proof of Concept (PoC) op te leveren waarin informatie over zorginstellingen worden ontsloten. Kort gezegd, de PoC moet laten zien dat de witte kaart kan werken door gegevens uit de basisregistraties te combineren met authentieke gegevens en die beschikbaar te stellen in de GIS-omgeving van de OOV-sector. In een PoC wordt een werkende innovatieve toepassing beproefd en geëvalueerd.

2.1

Uitdaging

Het project De Witte Kaart had als uitdaging om: 1. gegevens uit de basisregistraties, de BAG (Basisadministratie Adressen en Gebouwen) en het Nieuw Handelsregister (NHR), te koppelen, 2. deze te verrijken met sectorale kernregistraties, GHOR4all, 3. en vervolgens te ontsluiten binnen een GIS omgeving.

2.2

Doelstelling project

Het project had drie doelen: 1. Laten zien dat door het slim koppelen van basisregistraties er een daadwerkelijke invulling gegeven kan worden aan de ‘witte kaart’ voor het LCMS 2.0; 2. Inzicht geven in welke factoren dit proces positief en negatief beïnvloeden; 3. Inzicht geven in welke baten die voor de deelnemende ketenpartijen oplevert bij implementatie.

2.3

Vooraf gedefinieerde resultaten

Het project had de volgende gedefinieerde resultaten: 1. Het inventariseren van bestaande registraties over zorginstellingen en deze te ontsluiten; 2. Het inrichten van generieke services; 3. Het bieden van functionaliteiten door in het I-Bridge de generieke services te ontsluiten; 4. Het bieden van functionaliteiten om de ‘witte kaart’ binnen I-Bridge te kunnen raadplegen; 5. Het rapporteren over de gevolgde weg, de resultaten, kwaliteit en bruikbaarheid van de geleverde gegevens en de mogelijke baten in de keten; 6. Resultaten worden vastgesteld door de stuurgroep van het project.

2.4

Acceptatiecriteria

Het project kan als succesvol worden beschouwd wanneer: 1. Er is een werkende POC gerealiseerd en beproefd is; 2. De stuurgroep tevreden is over de eindrapportage die in dit ketenprojecten wordt opgeleverd; 3. De PSB tevreden is over de bovenstaande resultaten en de bijdrage van dit project aan de overige projecten.

2.5

Afbakening

Dit project zorgt voor een werkende PoC in de I-Bridge - omgeving. Het is niet verantwoordelijk voor verder implementatie of hergebruik in de OOV-sector of daarbuiten. De Proof of Concept omgeving zal als demo-omgeving operationeel worden gemaakt. Out of scope is:  Implementatie in het LCMS  Implementatie van brondata in GHOR4all  Beheer van de data of service


8

2.6

Randvoorwaarden PSB

Er zijn aan dit project geen bijzondere randvoorwaarden gesteld. Dit project houdt zich aan alle relevante bestaande afspraken, zoals NORA, goed financieel beheer, pro-activiteit, openheid en afspraken die zijn gemaakt met/kaders van het Programma i-NUP.

2.7

Budget

Het budget is € 100.000,- gefinancierd door de PSB. VGGM levert een contrafinanciering door inzet van medewerkers.

2.8

Relatie met andere projecten / applicaties

De uitwerking van dit project heeft grote baten voor vele andere projecten/applicaties die op dit moment landelijk in werking zijn. Hieronder vindt u een lijst van deze projecten/applicaties: - Project Netcentrisch Werken - I-Bridge - (Project) Digitale Bereikbaarheidskaart - GHOR4all - Groepsrisicoberekening, ministerie van Infrastructuur en Milieu - Project Wet Cliëntenzorg, VWS - Maatschappelijk vastgoed, Kadaster Het project De Witte Kaart is onderdeel van het Programmaraad Stelsel van Basisregistraties – Stuurgroep Werkend Stelsel. Binnen deze stuurgroep worden nog twee projecten aangestuurd, “Slim heffen en innen met het stelsel” en “Woningcorporatie werkt met WOZ”. Verwachting is dat alle drie de projecten rond juli 2012 hun resultaten opleveren. Met de financierder (Programmaraad Stelsel van Basisregistraties) is afgesproken dan te rapporteren over de gevolgde weg, kwaliteit en bruikbaarheid van de geleverde gegevens en de baten voor de keten.


9

Hoofdstuk 3. Projectresultaten In de PID, vastgesteld op 30-03-2012, zijn een zestal werkpakketten gedefinieerd die allen uitgevoerd werden binnen de kaders van dit project. Uiteindelijk zijn deze werkpakketten samengevoegd in drie fasen: 1. Definitiefase 2. Gebruik bronnen en koppelen regio Arnhem 3. Landelijk bestand zorginstellingen In dit hoofdstuk wordt per fase beschreven wat de gevolgde weg is geweest, welke knelpunten daarbij aan bod zijn gekomen en wat het resultaat van de betreffende fase is.

3.1

Fase 1: Definitiefase

3.1.1 Inleiding De Witte Kaart is gestart met ‘de definitiefase’. Tijdens deze fase zijn: 1. de informatiebehoeften van de gebruikers gedefinieerd 2. de functionele en technische eisen voor het gebruik van ‘de kaart’ gedefinieerd 3. en alle mogelijke bronnen in kaart gebracht, .

3.1.2 Definitie van “De Witte Kaart” De Witte Kaart heeft als doel om informatie uit de zorgsector (de zogenaamde ‘witte’ sector) samen te stellen uit verschillende bronbestanden en beschikbaar te maken bij de verschillende fasen van incidentbestrijding. Op de Witte Kaart komen uiteenlopende typen zorginstellingen te staan, met daarbij administratieve gegevens over bijvoorbeeld het soort zorg dat op die plaats wordt verleend, en het type en aantal patiënten. De Witte Kaart is een digitale kaart die binnen verschillende softwareapplicaties te raadplegen is. Daarmee wordt een brede set van data over zorginstellingen, overige zorgleveranciers en zorgbehoevende ook breed ontsloten. De Witte Kaart is bruikbaar voor alle fasen van de rampenbestrijding door de hulpverleningsdiensten, GGD en andere belanghebbenden.

3.1.3 Wensen en eisen gebruikers Informatie van de Witte Kaart is van belang voor de werkprocessen van verschillende organisaties. Elk werkproces heeft verschillende wensen ten aanzien van de inhoud van gebruikte informatie, de functies die men op de informatie kan toepassen en verschillende eisen met betrekking tot de beschikbaarheid van die informatie. Bijvoorbeeld voor acute processen als incidentbestrijding is een ononderbroken beschikbaarheid van de informatie cruciaal, omdat immers niet van tevoren bekend is wanneer een beroep op de informatie gedaan zal worden. Voor andere toepassingen is een beschikbaarheid tijdens kantooruren soms al voldoende. De Witte Kaart voegt bestaande informatie uit diverse bronnen samen. Het is wenselijk dat daarvoor geen nieuwe semantiek, afkortingen, symbologie en dergelijke opgesteld worden, maar dat gebruik gemaakt wordt van wat al is. Daarom is voor het bepalen van de wensen en eisen ten aanzien van de informatie voornamelijk de set van eisen gebruikt die er al was voor de regionale registratie GHOR4all. Data requirements Voor de gebruikers binnen de GHOR moeten ten minste de onderstaande typen zorginstelling in de Witte Kaart worden onderscheiden zie tabel 1. Tabel 1 Typen zorginstelling voor op de Witte Kaart

Type Verpleeg- en verzorgingshuizen Ziekenhuizen Revalidatiecentra Gehandicaptenzorg Geestelijke Gezondheidszorg


10

Apothekers Huisartsen Huisartsenposten Thuiszorg Verloskundigen Verslavingszorg Jeugdzorg In onderstaande tabel (tabel 2) staat een overzicht van de requirements ten aanzien van de informatiebehoeften. Deze requirements zijn geprioriteerd met behulp van de MoSCoW-methode. Hieronder worden de vier prioriteiten uit deze methode kort toegelicht. M - must: deze eis is niet onderhandelbaar en moet in het eindresultaat terugkomen, als aan deze eis niet wordt voldaan is het eindproduct niet bruikbaar; S - should: deze eis is nadrukkelijk gewenst, maar zonder is het product wel bruikbaar; C - could: deze eis zal alleen aan bod komen als er tijd genoeg is; W - Would: deze eis zal in dit project nog niet aan bod komen, eventueel wel in een vervolgproject wel. Met behulp van deze methodiek zijn de ‘musts’ bepaald voor het vervolg van het project. Tabel 2 Prioritering eisen met betrekking tot data

Nr 1 2 3 4 5 6 7

Requirement BAG verblijfsobjecten als basis voor de zorgobjecten Symbologie gebaseerd op bestaande afspraken Gebruik van open data formaten Gebruik van semantische standaarden en coderingen Inzicht in kwaliteit van de gegevens Ten minste de typen instellingen uit tabel 1 Waar beschikbaar aanvullende informatie uit tabel 2

Toelichting BAG is basisregistratie, gebruik is verplicht voor pandgeometrie Gebruik van bestaande classificaties Gebruik van bestaande symbolenset(s) Volgens NORA

MoSCoW Must

Bv SBI coderingen

Must

Bv waarschijnlijkheid of actualiteit van het gegeven

Could

Should Must

Must Should

Functionele Requirements De beschreven gegevens moeten zowel geografisch als administratief ontsloten worden. De geografische ontsluiting kan via GIS software zoals ArcMap of in een nieuw te bouwen ‘Witte Kaart webviewer’. In de applicatie moeten de gegevens uit de database als één kaart (‘de Witte Kaart’) gepresenteerd worden. Er moeten namelijk ruimtelijke analyses gemaakt kunnen worden, zodat vragen als: “welke zorginstellingen liggen binnen 750 meter van de plaats van het incident” beantwoord kunnen worden. Daarnaast dient de kaart geraadpleegd te kunnen worden voor administratieve informatie. Er moet aanvullende informatie per zorgobject opgevraagd kunnen worden, zoals het aantal patiënten dat niet mobiel dan wel zelfredzaam is. Binnen de geografische ontsluiting is kortom behoefte aan de mogelijkheid om  objecten te visualiseren;  objectinformatie op te vragen voor individuele objecten;  topologische en thematische selecties te maken van objecten;  objecten te zoeken op bijvoorbeeld naam. In onderstaande tabel (tabel 3) staat per gewenste functionaliteit de prioriteit. De Witte Kaart is een dataset dus bevat niet zelf deze functionaliteit, maar moet onderstaande functionaliteit wel mogelijk maken. Wederom is voor het bepalen van prioriteiten de MoSCOW methodiek toegepast. Tabel 3 Functionele eisen

Nr

Requirement


Toelichting

MoSCoW

11

Nr 1a

Requirement Visualiseren type zorg met symbool

1b 2 3 4

Visualiseren type zorg met symbool Topologische selectie Informatie opvragen Thematische selecties

5

Zoekfunctie

6 7

Inzicht kwaliteit Terugkoppeling naar GHOR4all

8

Terugkoppeling naar KvK

9

Terugkoppeling naar Kadaster

Toelichting Deze verschillende typen zijn in ieder geval te symboliseren:  Verpleegtehuizen & Verzorgingstehuizen  Ziekenhuizen  Revalidatiecentra  Gehandicaptenzorg  Geestelijke Gezondheidszorg  Apotheek  Huisartsen  Huisartsenposten  Thuiszorg  Verloskundigen  Verslavingszorg  Jeugdzorg  Penitentiaire inrichtingen Overige typen zorg symboliseren per type

MoSCoW Must

  

Must Must Would

Nabijheidsrelaties Informatie over object Vb: Symboliseer instellingen zonder eigen vervoer  Type instelling  Naam instelling  Opvragen indicator datakwaliteit  Geografische gegevens uit GHOR4all updaten met Witte Kaart gegevens Wettelijke verplichting, niet per se geautomatiseerd1 Wettelijke verplichting, niet per se geautomatiseerd

Could

Could Could Could Must Must

Niet Functionele Requirements Niet functionele requirements zijn eisen die gebruikers stellen aan de omgeving van de Witte Kaart. Daaronder valt bijvoorbeeld de beschikbaarheid van de Witte Kaart. Bij het opstellen van de nietfunctionele eisen is uitgegaan van de warme fase, omdat deze de hoogste eisen zal stellen aan onder meer de beschikbaarheid. Een overzicht van de niet-functionele eisen is gegeven in tabel 4 hieronder. Tabel 4 Niet-functionele eisen

nr 1

Requirement Quality of Service

2 3 4 5

Usability (Look and feel) Koppelbaar met andere systemen Beheer en onderhoud Privacy en Security

6

Juridisch

Toelichting QoS – Uptime 99% QoS – Responsetijd <3 sec QoS – Performance 20 concurrent Uniformiteit met LCMS Gebruik van open standaarden

MoSCoW Must Must Must Should Should

Update-frequentie passend bij bronbestanden Toegangsbeheer Afscherming van gevoelige gegevens P.m.

Should Must Must Must

Juridische aspecten van de Witte Kaart zijn nog niet geïnventariseerd, maar het juridisch kader heeft een hoge prioriteit bij de uiteindelijke implementatie, evenals privacy en beveiliging.

1

Terugkoppeling van gevonden onjuistheden in basisregistraties is een verplichting en daarom hier opgenomen als een must.


12

3.1.4 Bronbestanden Voor het ontwikkelen van de Witte Kaart Arnhem kwamen zes databestanden in aanmerking, te weten: NHR, BAG, LISA, WOZ-bestand, Populator en GHOR4all . 1. De Kamer van Koophandel heeft het Nieuwe Handelsregister (NHR) bestand geleverd. In het NHR wordt alle bedrijven, rechtspersonen en organisaties geregistreerd die deelnemen aan het economische verkeer. Het bestand is niet BAG-conform geleverd. De KvK merkte op dat er daardoor nog een afwijking in kan zitten, bijvoorbeeld de veldlengtes, of er kan soms nog een vreemd leesteken inzitten. Afwijkingen kwamen inderdaad voor. Er werd aangegeven dat in een later stadium het technisch mogelijk zou zijn om de NHR BAG-compliant uit te leveren, waarin ook bovengenoemde afwijkingen niet meer zullen voorkomen2. Idealiter zou een NHR-bestand met BAG-id toegepast worden om te voorkomen dat door afwijkingen het koppelen op adres niet 100% lukt. Naast het adres bevatte het NHR-bestand een omschrijving van zowel hoofd- als ook twee nevenactiviteiten. 2. De Basisregistraties Adressen en Gebouwen (BAG) bevat gemeentelijke basisgegevens van alle adressen en gebouwen in een gemeente. In de BAG is per verblijfsobject een gebruiksdoel geregistreerd (‘bouwkundig gebruiksdoel conform Bouwbesluit’). De BAG kent in totaal 11 gebruiksdoelen3, waaronder ‘gezondheidszorgfunctie’. We verwachtten dat deze categorie voor de Witte Kaart niet fijnmazig genoeg is omdat er geen nadere onderverdeling in bijvoorbeeld verzorgingshuizen of verpleeghuizen vastgelegd is. Daarnaast zijn de gebruiksdoelen voornamelijk vastgelegd op basis van de vergunning in plaats van hoe de feitelijke situatie is. De BAG kan echter wel gebruikt worden voor een uniforme adressering. 3. LISA is een databestand met gegevens over alle vestigingen in Nederland waar betaald werk wordt verricht. Er is gebruik gemaakt van een proefbestand van LISA dat betrekking heeft op SBI versie 2008 sectie Q. Dit is de sectie die overeenkomt met SBI-code 864 (gezondheidszorg), 87 (Verpleging, verzorging en begeleiding met overnachting), 88 (maatschappelijke dienstverlening zonder overnachting). Het LISA-bestand van Arnhem is beschikbaar gesteld door I&O-research. 4. In het kader van Wet Waardering Onroerende Zaken (wet WOZ) houden gemeente een registratie bij over onroerende zaken waarin ook de bouwkundige bestemming is omgenomen. Het WOZ-bestand is verkregen via DataLand. DataLand is een intergemeentelijk samenwerkingsverband op het gebied van vastgoedinformatie. 21 gemeenten zijn niet aangesloten, wat betekent dat de data die verzameld worden niet landsdekkend zijn. Gegevens over gebouwde objecten worden door DataLand beschikbaar gesteld. Zo ook gegevens over de WOZ-registratie. Deze registratie bevat informatie over de bouwkundige bestemming van een gebouw die gebruikt wordt voor een correcte bepaling van de waarde. De bouwbestemmingen zijn niet één-op-één te vergelijken met de SBI-coderingen, maar kunnen mogelijk wel adressen toevoegen die in de andere bestanden niet zijn meegenomen. 5. De Populator is een service die het mogelijk maakt om inzicht te krijgen waar hoeveel mensen (zogenaamde ‘verzorgden’) zich bevinden. Dit bestand is ontwikkeld door Bridgis en bevat informatie over zorginstellingen en ziekenhuizen. Bron is een bestand van VWS van 2009, dus de verwachting was dat de actualiteit en volledigheid niet helemaal op orde is. Voor onze analyse hebben we een databestand met adressen ontvangen, dus zonder naam of omschrijving. Bijna de helft (49%) van deze adressen heeft geen postcode. Voordat we de adressen kunnen geocoderen, is het noodzakelijk de postcodes toe te voegen. 6. Vanuit de GHOR4all hebben we een extract ontvangen met 118 records voor de totale regio Gelderland-Midden, waarvan 20 in Arnhem. Dit zijn voornamelijk verpleeg- en verzorgingsinstellingen (n=16), gehandicaptenzorg (n=3) en revalidatiecentrum (n=1). Of een potentieel bronbestand relevant is voor de Witte Kaart hangt af van verschillende eigenschappen van het bestand. Allereerst is natuurlijk de inhoud van het bestand van belang, maar ook de herkomst is van belang. Het bestand moet bijvoorbeeld niet alleen de benodigde informatie bevatten, het moet ook voor langere tijd beschikbaar zijn met een constante kwaliteit en prijs.

2

Dit bestand is in augustus 2012 geleverd Sportfunctie, onderwijsfunctie, winkelfunctie, overige gebruiksfunctie, woonfunctie, bijeenkomstfunctie, celfunctie, gezondheidsfunctie, industriefunctie, kantoorfunctie, logiesfunctie

3

4

http://www.cbs.nl/NR/rdonlyres/BEB2ADAE-3A2E-4929-8DFF-

3EC4C872684D/0/sbi2008versie2012incl6eniveautoelichting.pdf


13

Men kan een bestand selecteren op inhoud naar aanleiding van:  Hoeveelheid informatie –hoeveel relevante informatie bevat het bestand?  Detailniveau –hoeveel detail heeft de informatie?  Volledigheid – zijn de gegevens compleet?  Juistheid – kloppen de gegevens?  Koppelbaarheid –in welke mate zijn de gegevens te koppelen aan andere gegevenssets? Het laatste item, koppelbaarheid, is nog verder uit te splitsen in koppelbaarheid aan een locatie en koppelbaarheid of vergelijkbaarheid van de zorgactiviteit met andere gegevens. Voor koppelbaarheid aan een locatie is een uniforme locatieaanduiding nodig. Een voorbeeld van een uniforme locatieaanduiding is de adresaanduiding in de BAG. In Nederland wordt gebruik gemaakt van SBI coderingen om bedrijfsactiviteiten mee aan te duiden. SBI staat voor Standaard Bedrijfs Indeling, en is een afgeleide van de Europese NACE codering. De SBI geeft ook voor de zorgsector een tamelijk gedetailleerde indeling in verschillende zorgactiviteiten.5 Op basis van de hierboven geschetste selectiecriteria zijn er vijf bestanden geselecteerd als potentieel bronbestand voor de Witte Kaart: BAG, GHOR4all, LISA, NHR en WOZ.6

3.2

Fase 2: Gebruik bronnen en koppelen regio Arnhem

3.2.1 Inleiding Na de definitiestudie is een eerste aanzet gemaakt tot het ontwikkelen van de Witte Kaart op een kleine schaal: de gemeente Arnhem. Het doel van deze fase was om de gebruikte bronbestanden te beoordelen op hun geschiktheid voor de Witte Kaart. De gemeente Arnhem is gekozen als proefgemeente vanwege de lokale kennis die aanwezig is bij VGGM. In deze paragraaf de aanpak beschreven om te komen tot een ‘Witte Kaart Arnhem’. Vervolgens wordt beschreven welke stappen zijn genomen om een shapefile te ontwikkelen met zorginstellingen in Arnhem. Tenslotte wordt het definitieve oordeel gegeven over de bronbestanden, met andere woorden, welke bestanden een goede basis bieden voor de Witte Kaart.

3.2.2 Aanpak Vanwege de verwachting dat geen van de databestanden compleet is, is besloten een Witte Kaart voor Arnhem op te bouwen uit verschillende lagen (de verschillende bronbestanden). We zijn hierbij als volgt te werk gegaan: A. Databestanden voorbereiden 1. GHOR omzetten van WGS84 naar RD 2. In Populator-tabel ontbrekende postcodes toevoegen aan de hand van het ACN-bestand7 3. Van alle aangeleverde datasets zijn tabellen gemaakt met PHT (postcode, huisnummer, toevoeging), waardoor de adressen zijn te geocoderen. B. Dataselecties (zorg en Arnhem) maken 4. Selectie relevante SBI-codes uit NHR en LISA en relevante omschrijvingen uit het WOZbestand (BAG, Populator en GHOR4all zijn al geselecteerd op zorg). 5. Voor NHR relevante SBI-codes nevenactiviteit 1 en 2 toevoegen. 6. Van GHOR, NHR en WOZ-bestand alleen de adressen in Arnhem selecteren. Voor NHR betekent dit specifiek dat ‘woonplaats VA’ (vestigingsadres) is toegepast, in plaats van ‘woonplaats CA’ (contactadres). LISA, Populator en BAG waren al selecties voor Arnhem. C. Projecteren 7. X en Y-coördinaten aan adressen toevoegen (geocoderen).

5 6 7

Zie bijlage 1 voor SIB coderingen ‘Zorg’ Zie bijlage 2 voor overzicht van eigenschap per attribuut ACN is het bestand ‘Adrescoördinaten Nederland’, een digitaal bestand op basis van ieder bekend TNT Post-adres, voorzien

van een x- en y-coördinaat, gemeten in het Rijksdriehoekstelsel.


14

8. Voor elk bestand (totaal 6) een nieuw bestand met PHT en XY coördinaat vanuit het totale bestand. 9. Elk bestand projecteren in GIS en koppelen aan pictogram (zie tabellen 4 en 5 voor de sleutel tussen WOZ, SBI en pictogrammen). D. Resultaat onderzoeken 10. Visueel aan de hand van de Witte Kaart Arnhem (losse kaartlagen beoordelen in ArgGis). 11. De adressentabellen van de verschillende bestanden doornemen (aanvullende adressen ten opzichte van NHR).

3.2.3 Resultaten Allereerst hebben we gekeken naar het aantal adressen met zorginstellingen per bestand in Arnhem geregistreerd. Dit is te lezen in tabel 5. Hierin hebben we eveneens aangegeven van hoeveel adressen het mogelijk is geweest om deze te voorzien van een X- en Y-coördinaat. Tabel 5: Aantal adressen met zorg in Arnhem, per bestand, en aantal daarvan met XY-coördinaat Aantal na selectie Aantal zorg in Percentage van bestand met XY zorg in Arnhem Arnhem met XY BAG 296 296 100% NHR (totaal)

219 210 7

192 183 7

88% 87% 100%

2

2

100%

WOZ

44

44

100%

LISA

273

229

84%

Populator

116

83

72%

GHOR4all

20

20

100%



Hoofdactiviteit



Neven1 (uniek tov hoofd)



Neven2 (uniek tov voorgaande)

Wat valt op naar aanleiding van Tabel 5:  De BAG bevat van de zes bestanden de meeste adressen. Om te controleren welke zorgcategorieën de BAG bevat, hebben we de BAG en de NHR gecombineerd. In totaal zijn 207 adressen gekoppeld en voorzien van een hoofdactiviteit aan te koppelen. Het BAGbestand bevat adressen met zorggerelateerde activiteiten die niet alle relevant zijn voor de Witte Kaart (bijv. personeelsverenigingen van zorgverleners). Daarom is het aan te raden om het NHR-bestand als basis te gebruiken voor de Witte Kaart.  Van zowel het NHR als het LISA bestand, lukt het - door afwijkingen in adresnotatie - niet om alle adressen te geocoderen, maar respectievelijk 87% en 84%. Zodra de NHR een BAG-id zal toevoegen (eind 2012 is de verwachting), zal dit percentage richting 100 gaan. Ook zijn niet alle adressen in het LISA-bestand te geocoderen. Dit komt eveneens door ‘ongeldige’ adresnotaties (bijvoorbeeld 19+21+23 of 10-16), of adressen die niet voorkomen in het ACNbestand (zoals onzelfstandige woonruimten).  Nevenactiviteiten in de NHR voegen slechts 9 unieke adressen toevoegen ten opzichte van de hoofdactiviteiten.  LISA bevat relatief veel adressen (met het oog op het aantal SBI-categorieën dat is meegenomen.  Het percentage adressen van de Populator dat gegeocodeerd kan worden is relatief laag: 72%.  Het GHOR4all bestand bevat relatief weinig adressen. Kaartbeeld Wanneer je de verschillende adressen combineert en deze op de kaart ontsluit ontstaat figuur 1. Duidelijk is dat er zowel overlap als grote verschillen zijn tussen wat de diverse bronbestanden als


15

‘zorg’ classificeren. In deze kaart zijn de KvK gegevens niet opgenomen, bij de analyse van de verschillende databases is deze wel meegenomen.

Figuur 1 Uitsnede uit resultaat van test koppeling bronbestanden Witte Kaart

Wat aan figuur 1 vooral opvalt is:  Koppelvlak is niet uniform; adressen zijn niet uniform genoteerd in de verschillende bestanden.  Meerdere activiteiten op 1 plaats; op 1 adres kunnen meerdere – niet gerelateerd – activiteiten geregistreerd staan.  SBI-code onjuist; een SBI code kan onjuist geregistreerd staan.  SBI-code niet dekkend; een SBI code kan juist zijn maar dekt niet alle activiteiten.  Gegevens ontbreken; meerdere locaties komen maar in één van de bestanden voor.  Door vele databestanden te koppelen komt er nog geen compleet overzicht, dit figuur heeft aanleiding gegeven om over te gaan tot het kiezen van 2 of 3 basisregistraties. Het doel van de Witte Kaart is het bevorderen van het gebruik van basisregistraties. Omdat de zorgcategorie van de BAG te weinig specifiek is, hebben we ervoor gekozen om het NHR te vergelijken met de overige bestanden. De resultaten staan in tabel 6. Tabel 6: Vergelijkingen tussen de bestanden (uitgaande van hoofdcategorie NHR) Niet in NHR, wel in Wel in NHR niet in Beide bestanden BAG 260 156 38 WOZ 28 169 23 LISA (totaal) 153 102 119 86102 0 0 1 86925 1 0 0 86103 3 0 0 86104 0 6 3 8720* (20)* (0)* (0)* 8621 15 31 88 86911 3 6 6 88101 96 2 2 8710 1 2 0 87302 6 7 8 Populator 67 162 18 GHOR4all 20 187 0 * opm: hoofdcategorie in LISA, in NHR is ondercategorie gevuld, dus niet goed te vergelijken

De BAG bevat een aanzienlijke hoeveelheid adressen die niet in de NHR voorkomen. Dit komt omdat de BAG ook zorgcategorieën bevat die niet van belang zijn voor de Witte Kaart. Het WOZ-bestand voegt weinig adressen toe, evenals Populator. De LISA voegde in onvoldoende mate toe om op te nemen in het standaard gebruik voor De Witte Kaart. Om te bepalen of het WOZ, LISA en Populator bestand bruikbare toevoegingen doen ten opzichte van het NHR-bestand, zijn de aanvullende adressen doorgenomen door VGGM. Op basis van ervaringskennis is gecontroleerd of de aanvullende adressen (WOZ, LISA) bruikbaar waren voor de Witte Kaart. Alleen voor het GHOR-bestand bleek dit het geval.


16

3.2.4 Lessons Learned fase 2 Uit de testresultaten blijkt dat de BAG geschikt is om, via aangepaste adresnotaties van de overige databestanden, de diverse bestanden aan een adres of pand te koppelen. De GHOR4all gegevens bieden de meeste extra attributen, maar zijn niet compleet. Waar de NHR gegevens nu nog te weinig vestiging-gegevens toont kan LISA deze tijdelijk invullen. SBI codes blijken niet voldoende om de diverse zorginstellingen te onderscheiden, aanvullende classificaties zijn gelukkig beschikbaar. De keuze voor welke bronbestanden uiteindelijk gebruikt zullen worden kan ook een tijdelijke zijn, in afwachting van ontwikkelingen van de verschillende bronbestanden. Uit de koppeling van het NHR en het LISA bestand blijkt dat de huidige datakwaliteit nog te wensen over laat. Naar verwachting zal de kwaliteit van de registratie van vestigingen in het NHR nog enorm verbeteren. Door het aanwijzen van de NHR als basisregistratie en daarnaast mogelijk ook gestuurd door de Witte Kaart, omdat nu zichtbaar is welke informatie ontbreekt of onjuist is. Dit laatste geldt ook voor het GHOR4all bestand. Doordat nu duidelijk is welke gegevens wel en welke gegevens niet in het bestand opgenomen zijn, kan dit een impuls geven aan het alsnog invoeren van de ontbrekende gegevens. In de GHOR4all database zijn zorgverleners onderverdeeld met een andere systematiek dan de SBI codering. In bijlage 1 is een overzicht opgenomen van de type zorgverleners zoals die gebruikt wordt binnen de GHOR4all, met het huidige aantal registraties per type op landelijk niveau. Per veiligheidsregio verschilt de hoeveelheid instellingen die geregistreerd staan, voor de ene veiligheidsregio staan alleen de ziekenhuizen en verpleeg- en verzorgingsinstellingen opgenomen, voor andere regio’s is het beeld meer compleet. De beschikbare brongegevens beschikken niet elk over hetzelfde koppelvlak. Koppelen van gegevens op basis van een uniek identificatienummer is te prefereren boven een koppeling op basis van bijvoorbeeld adresgegevens. Bij adresgegevens is er sprake van verschillende manieren van registratie en interpretatie. Als koppeling alleen mogelijk is op basis van adresgegevens moet de notatie van de adresgegevens eerst gestandaardiseerd worden. Als gegevens BAG-compliant zijn dan is de notatie van de adresgegevens (in theorie) reeds gestandaardiseerd. Diverse bronbestanden zullen naar verwachting op korte termijn BAG compliant zijn. De BAG lijkt daarmee een geschikte dataset om te fungeren als koppeling tussen de overige bronbestanden. Conclusie: Het NHR bestand vormt de basis voor de Witte Kaart. Het GHOR4all bestand biedt bruikbare toevoegingen en bevat als enige bestand aanvullende informatie over de zorgvoorzieningen. De BAG lijkt geschikt om te fungeren als koppeling tussen de verschillende bronbestanden.

3.3

Fase 3: Realisatie Witte Kaart Gallery Nederland

3.3.1 Inleiding In de laatste fase heeft het project zich gericht op de realisatie van ‘de kaart’. Hiervoor is er een landelijk bestand ontwikkeld van NHR, BAG en GHOR4all: de database van De Witte Kaart. Voornemens was om deze kaart te ontwikkelen en de ‘I-Bridge omgeving’ te plaatsen, maar veranderde ontwikkelingen in het werkveld van landelijk crisismanagement systeem (en daarmee IBridge) is er besloten om dit niet te doen. Er is daarom gekeken naar een omgeving die voor iedereen toegankelijk is en makkelijk te benaderen. Om die reden is er gekozen om De Witte Kaart te ontwikkelen binnen ArcGis online.

3.3.2 Aanpak landelijke database ontwikkelen In fase twee is bepaald welke databestanden leidend zijn voor de verdere PoC. In fase drie is vanuit die datasets een landelijk bestand gemaakt. Dit heeft de volgende stappen opgeleverd: 1. Geocoderen van data (zowel NHR bestand als GHOR4all) 2. BAG-id’s toevoegen aan deze bestanden 3. Koppelen van GHOR4all aan NHR bestand middels de BAG- id’s 4. Pictogrammen toekennen aan de sectoren


17

Toelichting van de stappen 1. Geocoderen De aangeleverde data was gedeeltelijk gecodeerd, maar op verschillende manieren. Omdat een koppeling tussen de twee datasets gelegd moest worden, was het belangrijk de twee datasets op dezelfde manier te geocoderen. Er is voor gekozen dit via de BAG te doen, omdat op deze manier er gebruikt gemaakt van de basisregistratie. Het resultaat was een ESRI File Geodatabase met twee gecodeerde datasets. Van de NHR is ruim 98% gecodeerd, van GHOR4all ongeveer 90%. 2. BAG-id’s toevoegen De NHR en GHOR4all hebben geen gemeenschappelijk attribuut waarop ze te koppelen zijn. De enige manier om te koppelen is dus via de locatie, ofwel geografisch ofwel via een adres. Er is voor gekozen om de bestanden te koppelen op BAG-id via het adres. Hiervoor moesten de beide datasets dus verrijkt worden met een BAG-id. Er zijn verschillende BAG-ids, er is gekozen voor het gebouw-id, want dat zijn de gebouwen/panden die ook op de kaart te zien zijn. Na geocoderen en toevoegen BAG-id’s hebben van GHOR4all 6115 van de 7125 records een BAG-id (86%). Van NHR is dat 18028 van de 18393 (98%). 3. Koppelen GHOR4all aan NHR bestand middels de BAG-id’s Nadat beide aan beide datasets een BAG-ids is toegevoegd konden ze op die basis gekoppeld worden. Idealiter zou er een genormaliseerd datamodel gemaakt worden om de bestanden te koppelen, maar om praktische redenen (kost teveel tijd aan zowel data- als applicatie-kant) is er voor gekozen de data ‘plat te slaan’. Dat wil zeggen dat van alles één grote tabel is gemaakt met alle data. Het resultaat van deze stap is een tabel met 21083 records, waarvan er 5582 een koppeling zijn tussen NHR en GHOR4all. De NHR-records die met meerdere GHOR4all records konden worden gekoppeld zijn gedupliceerd, vandaar dat er meer records in deze tabel zitten dan in de losse NHR tabel. Omdat alle velden van NHR en GHOR4all zijn toegevoegd bevat de tabel 153 kolommen. Er is een kaartlaag gemaakt om de resultaten van het koppelen te visualiseren. 4. Pictogrammen toekennen aan de sectoren Om de data te kunnen visualiseren op de kaart is aan de wittekaart-tabel een attribuut ‘pictogram’ toegevoegd. Dit is gebaseerd op basis van de SBI-codering van het NHR. Alle records bleken een bruikbare SBI-code te hebben, maar van één code ('ambulancediensten en centrale posten') bestond geen pictogram. De pictogrammen zelf zijn aangeleverd in de vorm van images, maar omdat deze er slecht uitzagen in de viewers is een truetype font gebruikt. Dit gaf een iets beter resultaat. De huidige pictogrammen zijn echter niet zo geschikt voor in de kaart, omdat ze teveel op elkaar lijken en de symbolen te gedetailleerd zijn.

3.3.3 Viewers Om de data te visualiseren zijn een aantal viewers gemaakt. Hierbij is zoveel als mogelijk gebruik gemaakt van de standaardfunctionaliteit in ArcGIS Online. Omdat niet alles mogelijk is via ArcGis Online is ook een Javascript viewer gemaakt met behulp van de ArcGis Javascript API. De volgende services zijn aangemaakt met ArcGis Server:  Wittekaart – op basis van de wittekaart tabel  Wittekaart_terugmeldservice – featureservice om terugmelden mogelijk te maken  Wittekaart_geocode – laat de resultaten van de geocodeeractie zien  Wittekaart_koppelstatus – laat de resultaten van de datakoppeling zien Er is één viewer gemaakt met de ESRI Javascript API, die een aantal functionaliteiten bevat die niet met ArcGIS Online gerealiseerd konden worden, namelijk:  Bufferselectie  Polygoonselectie  Filteren op categorie  Tonen in tabel


18

Viewer voor terugmeldfaciliteit Eén van de wensen voor deze POC was om te kijken naar een terugmeldservice voor de NHR-data. Om dit mogelijk te maken is een applicatie gemaakt binnen ArcGIS Online (met standaard template) waarmee gebruikers punten kunnen toevoegen en attributen kunnen invullen om ontbrekende informatie te melden. Dagelijks wordt een e-mail verstuurd met de nieuwe meldingen, deze kunnen na het project aangeboden worden aan de KvK. Hieronder vindt u een overzicht van de verschillende viewers:

3.3.4 Lessons Learned fase 3 

     

NHR gekoppeld met BAG-id’s aanleveren. Om te voorkomen dat data steeds opnieuw gegeocodeerd moet worden, is het essentieel dat NHR de bijbehorende BAG-id’s levert. Dan is via de BAG ook de locatie bekend. De BAG levert echter niet de locatie waar de voordeur is gelegen. NHR en Ghor4all zijn niet direct koppelbaar, hiervoor zijn nu een aantal foutgevoelige stappen nodig (geocoderen, toevoegen BAG-id’s, koppelen), waardoor mogelijk data verloren gaat. GHOR4all bevat erg veel lege velden en bevat nog lang niet alle zorggerelateerde instellingen. Veel problemen met veldnamen GHOR4all, te lange of dubbele veldnamen. Er is behoefte aan een relationeel datamodel. Bij koppelen van NHR met GHOR4all gaan GHOR4all-records verloren (zo’n 20%), dit komt voornamelijk doordat ze geen BAG-id konden krijgen, maar voor een deel ook omdat de locatie niet in NHR aanwezig was. Categorieën (t.a.v. type zorg) in GHOR4all komen niet overeen met SBI-coderingen in NHR. Standaardisatie en afstemming voor toekomstige koppelingen is zeer gewenst. Excel is geen handig formaat om te verwerken (problemen met veldnamen, datatypes, etc.).


19

Hoofdstuk 4. Conclusie en aanbevelingen De Witte Kaart een jaar later, tijd voor het opmaken van de balans: heeft het stelsel van basisregistraties daadwerkelijk bijgedragen aan een invulling van de Witte Kaart, zijn er factoren die dit proces positief of negatief beïnvloeden, oftewel de succesfactoren en welke baten hebben de deelnemende partijen dan wel bronhouders van de verschillende databestanden? Deze vragen worden beantwoord in dit hoofdstuk.

4.1

Bijdrage stelsel van basisregistraties aan ‘De Witte Kaart’

In dit project stond het gebruik van basisregistraties centraal voor de sector van openbare orde en veiligheid en in het bijzonder de geneeskundige hulpverlening. In die sector worden allerlei verschillende registraties bijgehouden voor het in kaart brengen van zorginstellingen. Aan de andere kant wordt ook door de overheid geïnvesteerd in het op orde brengen van het stelsel van basisregistraties. In dit project is vraag en aanbod bij elkaar gebracht. Vanuit het project De Witte Kaart is de vraag gesteld aan het stelsel van basisregistraties of het stelsel in staat is om zorginstellingen in Nederland identificeerbaar te maken. Hierbij gaat het om een naam van de organisatie, straat, huisnummer, postcode, plaats en X,Y coördinaat. In de zoektocht naar deze vraag zijn de volgende basisregistraties gebruikt voor onderzoek:  Nieuwe Handelsregister; in het handelsregister zijn alle bedrijven, rechtspersonen en organisaties ingeschreven die deelnemen aan het economische verkeer.  Basisadministratie Adressen en Gebouwen: de BAG is een gemeentelijke registratie waarin alle gebouwen en adressen in zijn vastgelegd.  LISA: dit is een databestand met gegevens over alle vestigingen in Nederland waar betaald werk wordt verricht. De kerngegevens per vestiging hebben een ruimtelijk component (adresgegevens) en sociaal-economisch component (werkgelegenheid en economische activiteit).  Waardering Onroerende Zaken: waardering van de gemeente over onroerende zaken t.b.v. belastingheffing. Daarnaast zegt de WOZ iets over de bouwkundige bestemming. Daarnaast zijn er twee kernregistraties gebruikt ter onderzoek en aanvulling en op de basisregistraties:  GHOR4all: applicatie die GHOR regio’s inzetten om capaciteitsgegevens en voorbereiding op incidenten van zorginstellingen vast te leggen  Populator: service die het mogelijk maakt om inzicht te krijgen waar hoeveel mensen (zogenaamde ‘verzorgden’) zich bevinden. Basis voor De Witte Kaart Een moeilijke factor in het project is dat niet één databestand 100% betrouwbaar is. Er dient ook aanspraak gemaakt te worden op lokale kennis om te bekijken welk databestand kwalitatief de beste gegevens levert. Er is in dit project dan ook veel tijd gestoken in het afpellen van de afzonderlijke basis- en kernregistraties om ze met elkaar te kunnen vergelijken en waar nodig aan te vullen met lokale kennis. Uit de vergelijking van de verschillende databestanden is gebleken dat het NHR-bestand, al dan niet BAG compliant, een goede basis vormt om zorginstellingen in kaart te brengen. De SBI codering die het NHR hanteert geeft een scheiding in de type zorg die aangeboden wordt. Dit vraagt echter wel afstemming met de sector OOV/GHOR, omdat niet één op één de vergelijking gemaakt kan worden met typen zorginstellingen die de sector hanteert in haar kernregistratie (GHOR4all). Verder merken we op dat in het NHR-bestand veel zorginstellingen enkel zijn ingeschreven op hun hoofdlocatie. maar dat daarmee niet alle sublocaties geregistreerd zijn. Juist die sublocaties (vestigingen) zijn voor de OOV sector ook interessant om te kennen. Daarnaast is het noodzaak dat het NHR-bestand BAG compliant wordt opgeleverd, zodat ook het ‘kaart-gedeelte’ op een adequate wijze wordt ingevuld. De geneeskundige kolom heeft juist behoefte aan zowel administratieve als geografische informatie over een object. Bovendien geeft de ‘BAG-id’


20

een basis om informatie over een object aan elkaar te koppelen. Dit is ook van belang als gegevens uit sectorale registraties (bijv.: GHOR4all) gekoppeld moet worden. We concluderen dat een betrouwbaar Handelsregister en de koppeling met BAG een goed uitgangspunt vormt om zorginstellingen te identificeren en te ontsluiten in allerlei applicaties. ‘Het sommetje’ ziet er dan als volg uit:

(NHR + BAG) + sectorale gegevens (bijv. GHOR4all) = “De Witte Kaart” De Witte Kaart is echter geen op zich zelf staande applicatie. De Witte Kaart wordt nu gepresenteerd in de GIS-applicatie ArcGisOnline, maar de onderliggende database kan ook voor andere applicaties worden gebruikt.. Voor de toekomst is het noodzaak dat de data van De Witte Kaart verankert wordt in de verschillende applicaties die in de veiligheidsregio’s gebruikt worden. Een andere optie voor het verankeren van data uit het NHR is een sectorale registratie inrichten bij het ministerie van VWS. Vervolgens kan de OOV sector aansluiten op deze sectorale registratie en gebruik maken van die data. Voorwaarde voor een dergelijk registratie is dat deze is aangesloten op het NHR, zodat het principe ‘data halen bij de bron’ overeind blijft. Voordeel van een sectorale registratie is dat deze als doel heeft om zorginstellingen c.q. –aanbieders te filteren uit het NHR en daar een compleet overzicht van te maken. De registratie zal wel als een server aangeboden moeten worden aan de gebruikers, zodat deze zelf keuzes kan maken welke zorginstellingen wel of niet in haar applicaties worden opgenomen. De som wordt dan anders:

Sectorale registratie (VWS, landelijk) + sectorale gegevens (bijv. GHOR4all) = Witte Kaart OOV sector Gemeentelijke Basisadministratie In de PoC is de basisregistratie GBA buiten beschouwing gelaten, maar door meerdere partijen is opgemerkt dat dit een interessante aanvullende bron kan zijn voor De Witte Kaart. In de GBA worden inwoners geregistreerd op hun naam, geboortedatum, etc. en ook het adres. Juist dat laatste is interessant om te weten. Door in de GBA na te gaan hoeveel personen er op X adres geregistreerd staan, kan nagegaan worden hoeveel personen in een bepaald object verblijven. De privacy komt hierdoor niet in gevaar omdat men in de OOV sector niet wilt weten wie er verblijven maar slechts hoeveel personen er verblijven. Het is dan ook aan te raden om bij de implementatie van De Witte Kaart deze optie zeer serieus te onderzoeken.

4.2

Succesfactoren

Een van de doelstelling van het project was het in kaart brengen van succesfactoren. Het grote succes van dit project was het samenbrengen van vraag en aanbod. In dit project werden bestaande posities en belangen opzij gezet en werd er gewerkt aan de inhoud. Dat heeft geleid tot een mooi en praktisch resultaat. Juist de praktische insteek van alle partijen heeft daar een enorme bijdrage aan geleverd en kan om die reden beschouwd worden als een belangrijke succesfactor. De ervaring in het samenwerken heeft wederzijds veel opgeleverd. Het heeft enerzijds de vraagzijde laten inzien welke


21

mogelijk- en onmogelijkheden er zijn binnen het stelsel van basisregistraties en anderzijds heeft het de aanbodzijde laten inzien waar gebruikers naar op zoek zijn. Voor alle partijen komen er verbeterpunten uit die nuttig en noodzakelijk zijn voor implementatie in de toekomst.

4.3

Baten voor deelnemende partijen

In dit project stond het bij elkaar brengen van vraag en aanbod voorop. De vraag vanuit de OOV sector was lever ons gegevens over zorginstellingen vanuit de basisregistraties. Samenwerking tussen de verschillende partijen is een belangrijk element geweest in het tot stand brengen van een werkende PoC. De ervaringen over de aanpak en het resultaat zijn positief. Niet eerder is ‘het stelsel’ zo direct bevraagt vanuit een bepaalde sector. Door goodwill van alle partijen is in een relatief korte tijd veel werk verzet; het vergelijken van databestanden, het koppelen van bestanden en de bouw van kaarten waarin gegevens getoond kunnen worden.

4.3.1 Baten voor de OOV sector alias de afnemer De informatie die nodig is bij rampenbestrijding is veelomvattend. Het gaat niet alleen op repressie maar ook om preventie en de afhandeling van gevolgen van incidenten. Rampenbestrijders denken groot in termen van gifwolken, overstromingsgebieden maar ook klein zoals risico-objecten. Daarbij is het van belang dat er zowel geografische informatie beschikbaar is als administratieve informatie. Voor de OOV sector in het algemeen en de geneeskundige hulpverlening in het bijzonder kan gesteld worden dat het gebruik van basisregistratie van absolute meerwaarde is. Zeker het gebruik van het NHR bestand, gecombineerd met de BAG, bevat veel data over objecten die bruikbaar zijn voor de veiligheidsregio. Vooral de combinatie tussen geografische en administratieve data levert een belangrijke meerwaarde bij rampenbestrijding. Nu is alleen onderzoek gedaan naar gegevens over zorginstellingen, maar het concept van De Witte Kaart is ook van toepassing op andere sectoren zoals scholen of kinderdagverblijven, kortom meer van hetzelfde. Het verbreden van de scope zal ook het succes doen verbreden. Zo zullen er steeds meer partijen (binnen en buiten de veiligheidsregio) zijn die de basisregistraties gaan gebruiken. Om deze baten te verankeren voor de veiligheidsregio zijn er nog wel wat stappen nodig. Gegevens uit de basisregistratie is ruwe data die niet één op één op te nemen is in applicaties van de OOV sector. De wens is dat ook om hiervoor een ‘sectoraal knooppunt’ te ontwikkelen. Dit knooppunt moet data uit de basisregistraties samenbrengen en als een dienst aanbieden aan de OOV sector. Vervolgens kan deze dienst in allerlei applicaties gebruikt worden binnen het domein, zoals GHOR4all, Crisismanagementsysteem of Digitale Bereikbaarheidskaart. Veronderstelt wordt dat aanpassingen in de applicaties om die data binnen te halen een verantwoordelijkheid van de afnemer zijn. Afspraken over semantiek, maar ook beheer en kosten zijn daarbij van belang. Wij raden aan dat GHOR Nederland de belangen behartigd van de 25 GHOR regio’s en deze ontwikkelingen blijft bewaken en aansluiten daar waar noodzakelijk (zie 5.2.1 voor overdracht GHOR Nederland). Ter visualisering hiervan zie het onderstaande figuur.


22

“Maak het de afnemer makkelijker” Alle basisregistraties horen toegankelijk en openbaar te zijn, maar ik de praktijk blijkt dat soms tegen te vallen. Zo hebben wij ervaren dat de afname van het NHR bestand een ingewikkelde casus betreft. Tot drie keer toe hebben wij de PSB (het escalatieniveau) moeten benaderen om de gewenste databestanden te bemachtigen. Het is als afnemer lastig in te schatten waar dit probleem ligt, maar feit blijft dat het voor de afnemer nu niet mogelijk is deze basisregistratie makkelijk in huis te krijgen. Daarnaast is meerdere malen gecommuniceerd dat het NHR bestand per februari 2012 BAG compliant zou zijn, maar ook dit bleek in de praktijk niet te kloppen. Om voor de POC toch iets werkends te krijgen hebben wij aan het NHR bestand zelf BAG-id’s gekoppeld. Dit zijn relatief ‘kleine’ zaken die toch lastig zijn voor de gebruiker. Het zorgt voor stagnatie in werkprocessen en doet afbreuk aan het vertrouwen in het stelsel als foutieve toezeggingen worden gedaan. “Vraagarticulatie” Een belangrijke les voor dit project is dat het stellen van een vraag aan ‘het stelsel’ een goed startpunt is. Het stelsel van basisregistraties is enorm aanbod gedreven, maar richt zich veel minder op welke vraag er leeft bij afnemers. Nu is er door dit project een hele specifieke vraag gesteld, maar voor de toekomst is het aan de sector OOV om die vraagarticulatie zelf in te richten. Daarnaast moet er één aanspreekpunt vanuit het stelsel komen zodat communicatie tussen het stelsel en de sector OOV makkelijker en sneller verloopt.

4.3.2 Baten voor het stelsel van basisregistraties Het stelsel van basisregistraties is ingewikkeld voor buitenstaanders, dat was het ook voor ons als veiligheidsregio. De verdieping heeft ons geleerd dat het veel kan leveren, maar dat er nog wel gewerkt moet worden aan de kwaliteit van de data en aan faciliteiten rondom de basisregistraties. Alhoewel nu wordt gesuggereerd dat Digilevering en Digimelding geregeld zijn, blijkt het in de praktijk toch nog niet te werken. De absolute baat die het stelsel van basisregistraties heeft, is het gebruik ervan. Wanneer eindgebruikers het stelsel gaan gebruiken en foutieve gegevens snel kunnen terugmelden, zullen de basisregistraties snel een kwaliteitsslag kunnen maken. Met deze PoC is er een tijdelijke oplossing gecreëerd door in één kaart nieuwe gegevens te kunnen toevoegen, maar dit is niet geheel de wenselijke situatie. Het liefst moet de eindgebruiker kunnen redigeren op bestaande gegevens in de Witte Kaart en deze van daar uit terugmelden. Eén van de belangrijke conclusies van deze PoC is de onvolledigheid van het NHR-bestand. Zorginstellingen zijn nu (vaak) ingeschreven op hun hoofdlocatie. Alle sublocaties, daar waar dus echt de zorg verleent wordt, staan niet in het NHR vermeld. De Kamer van Koophandel zou zorginstellingen meer aan kunnen sporen zich alsnog volledig in te schrijven. Daarmee kan het NHR een goed en volledig bestand worden en van toepassing zijn voor vele afnemers. Niet alleen voor de OOV sector zoals in dit geval, maar ook voor bijvoorbeeld het register LISA dat de werkgelegenheid registreert. Wij hebben begrepen dat Kamer van Koophandel bezig is met VWS om te zorgen dat


23

ontbrekende vestigingen in de zorg uiteindelijk zullen worden opgenomen in NHR. Daar waar de baten twee kanten op gaan is het ook aan te bevelen dat de OOV sector, en GHOR in het bijzonder, zorginstellingen aansporen om zich volledig en juist in te schrijven bij de Kamer van Koophandel zodat gegevens eenmalig worden opgeslagen, maar meervoudig worden gebruikt. Dat scheelt de betreffende zorginstelling ook werk, omdat zij dan minder bevraagd zullen worden door verschillende organisaties. De zorginstelling zou idealiter zijn wijzigingen alleen richting NHR hoeven door te geven van waaruit alle andere registraties weer worden bijgewerkt. Gebleken is dat de activiteiten en SBI-codes in het NHR goed aansluiten bij de fijnmazige behoefte van de Witte Kaart. Een andere conclusie is dat de BAG als middel heeft gefungeerd om verschillende bronnen aan elkaar te koppelen. Essentieel hierbij is dat het NHR ook de bijbehorende BAG-id’s gaat leveren. De gebruiksfuncties in de BAG zijn niet fijnmazig genoeg voor de eisen die vanuit de Witte Kaart zijn gesteld. Het bevat alleen de gezondheidszorgfunctie en niet een nadere onderverdeling in bijvoorbeeld verpleeghuizen of verzorgingshuizen. Laatste observatie is dat de BAG weliswaar coördinaten bevat maar niet de coördinaten waar de ingang van het pand is te vinden. Zolang de BAG deze gegevens niet bevat zullen deze gegevens zelf geregistreerd moeten blijven worden. Ten aanzien van de WOZ zijn de volgende ervaringen opgedaan:  De WOZ levert ten opzichte van NHR nauwelijks nieuwe objecten op.  De gebruiksfuncties in de WOZ sluiten onvoldoende aan op de behoefte van de Witte Kaart.


24

Hoofdstuk 5. Het vervolg Na een jaar hard werken, mooie resultaten en veel kennis rijker is het goed om te balans op te maken. Waar staan we en wat biedt de toekomst ons? Het project De Witte Kaart heeft ervoor gezorgd dat we veel kennis hebben opgedaan rondom het gebruik van het stelsel van basisregistraties voor de sector openbare orde en veiligheid. De volgende stap is het benutten van die baten, we kennen nu immers de mogelijkheden.

5.1 Vooruitblik op architectuur en beveiliging Over de architectuur, het beheer en de beveiliging van de Witte Kaart zijn nog geen besluiten genomen. Toch wordt hieronder alvast een vooruitblik op de architectuur gegeven, om aan te geven welke overwegingen er spelen rond de keuzes die hier gemaakt kunnen worden.

5.1.1 Keuzemogelijkheden architectuur Bij het bepalen van de meest passende architectuur, beheer en beveiliging moeten eerst enkele keuzes gemaakt worden over bijvoorbeeld het gewenste en verwachtte gebruik van de Witte Kaart. Hieronder staan de belangrijkste onderwerpen waarover een beslissing genomen moet worden beschreven, met de implicaties van de verschillende opties.

5.1.2 Wijzigingenbeheer Omdat de Witte Kaart een geassembleerde kaart is, is het ongewenst op de Witte Kaart zelf wijzigingen en aanvullingen aan te brengen. Die zullen bij een update van een of meer van de bronbestanden immers weer overschreven worden, tenzij er een (fout-gevoelige) procedure opgesteld wordt om wijzigingen bij nieuwe versies te behouden. Wijzigingen en aanvullingen moeten zoveel mogelijk bij de bronbestanden plaatsvinden. Omdat veel van de bronbestanden basisregistraties zijn is dat veelal zelfs een wettelijke verplichting: de zogenaamde terugmeldingsplicht. Voor de GHOR4allgegevens zijn de veiligheidsregios’ indirect zelf bronhouder, en daarmee verantwoordelijk voor inhoud en compleetheid van dit bestand. Het is om beide redenen verstandiger om wijzigingen niet op de Witte Kaart zelf maar op haar bronbestanden door te voeren.

5.1.3 Ontsluiting De Witte Kaart kan op verschillende manieren ontsloten worden: als webservice of als statisch bestand. Web services kunnen zowel via een nieuw te bouwen Witte Kaart-viewer als in een bestaand GIS systeem zoals ArcGIS. Het voordeel van webservices is de actualiteit: de webservice levert automatisch de meest recente versie van de Witte Kaart. Een Witte Kaart Viewer zorgt ervoor dat ook gebruikers zonder ervaring met GIS systemen op een laagdrempelige manier de gegevens van de Witte Kaart kunnen bekijken. Het nadeel van een webservice is de afhankelijkheid van een verbinding met het internet en de server waar de webservice op draait. Is een internetverbinding niet altijd beschikbaar, of is de vereiste beschikbaarheid zeer hoog, dan kan gebruik gemaakt worden van een bulk uitlevering: de gehele dataset wordt dan lokaal opgeslagen voor gebruik in een lokaal geinstalleerd GIS. Nadeel hiervan is dat er mogelijk gewerkt wordt met verouderde gegevens als er niet regelmatig de laatste versie opgevraagd wordt. Ook is de lokale manier van werken met de Witte Kaart niet laag-drempelig genoeg voor een groot deel van de beoogde gebruikers. Daarom wordt aangeraden om de Witte Kaart in ieder geval als webservice in combinatie met een Witte Kaart – viewer aan te bieden, en daarnaast eventueel ook downloadbaar te maken voor gebruik off-line.

5.1.4 Datamodel Bij de inrichting van de database moet zoveel mogelijk rekening worden gehouden met bestaande informatiemodellen (zoals van de BAG, NHR en GHOR4all). Er kan gebruik worden gemaakt van database schema’s om bepaalde typen data logisch te scheiden. Dit maakt de database overzichtelijker en makkelijker te beheren. Het datamodel wordt overgedragen aan GHOR Nederland die dit mogelijk kan gebruiken voor de herinrichting van GHOR4all. Het datamodel dat gebaseerd is op gebruik van NHR, BAG, GHOR4all en WOZ gegevens als bronbestanden is opgenomen in bijlage 3.


25

Onafhankelijk van de brongegevens moet de koppeling van deze gegevens tot een Witte Kaart reproduceerbaar zijn. Niet alleen de huidige kwaliteit (van met name het NHR) maar ook de verwachtte kwaliteit van de gegevens in de toekomst moet bij de selectie van bronbestanden meegenomen worden.

5.1.5 Wijze van koppelen bronbestanden De databronnen die ten grondslag liggen aan de Witte Kaart zijn verspreid over verschillende organisaties. Deze organisaties zijn verantwoordelijk voor beheer en ontsluiting van de brondata van de Witte Kaart. De Witte Kaart wordt geassembleerd uit de bronbestanden. De Witte Kaart moet een vergelijkbare actualiteit hebben als de bronbestanden. Vanwege de hoge eisen ten aanzien van response tijd en uptime is koppelen van bronbestanden “on the fly” geen optie. Daarom zal de koppeling van de diverse bronbestanden met een vastgestelde frequentie plaatsvinden. Het resultaat van de koppeling zal centraal opgeslagen worden, en van daaruit ontsloten. Dit proces zal grotendeels geautomatiseerd plaatsvinden, met enkele handmatige controles. Het koppelen van bronbestanden kan op verschillende manier plaatsvinden. Er kan gebruik gemaakt worden van het hele bestand of slechts een selectie van alle wijzigingen ten opzichte van de vorige levering. Daarnaast kan een bronbestand zelf een wijziging doorgeven zodra deze plaatsvindt (Push) of wachten totdat gevraagd wordt om een levering van gegevens (Pull). Voor elk van de bronbestanden moet een keuze gemaakt worden in de drie mogelijkheden (zie tabel 13) die in combinatie vervolgens ontstaan. Bij het maken van de keuze moet gekeken worden naar de technische mogelijkheden van het bronbestand (staat het in een omgeving die “push” kan uitvoeren), de updatefrequentie van het bronbestand en de verwerking van de gegevens tot een nieuwe versie van de nieuwe kaart. Tabel 7 Combinaties van Push en Pull en selecties op database

Databasebewerking Selectie (wijzigingen) Gehele database

Push x Geen zinvolle combinatie

Pull x x

Bij de koppeling van de bronbestanden vind een validatie plaats door middel van ETL processen. Pas na een geslaagde validatie wordt een Witte Kaart object opgeslagen. In dit ETL proces kan ook een terugkoppeling naar de beheerders van de bronbestanden plaatsvinden. Voor de basisregistraties is een dergelijke terugkoppeling verplicht. Voor de overige bronbestanden hangt dit af van afspraken die met de betreffende bronhouder gemaakt zijn.

5.1.6 Beveiliging Eerst moet het beleid ten aanzien van de beveiliging van de Witte Kaart vastgesteld worden. Dit beleid is gebonden aan de wettelijke kaders bijvoorbeeld op het gebied van privacy. Deze wettelijke kaders bepalen welke gegevens men mag bewaren, hoe men de toegang tot deze gegevens moet beveiligen, en in welke gevallen met de gegevens mag verstrekken aan derden. Nadat de wensen van de Witte Kaart getoetst zijn aan het wettelijk kader kan de technische implementatie van de benodigde beveiliging uitgewerkt worden. Een belangrijke vraag met betrekking tot beveiliging is: “Wie mag wat zien, op welk moment en waar”. Er kunnen verschillende groepen gebruikers gedefinieerd worden met elk een eigen beveiligingsinstellingen. De technische implementatie van de beveiliging kan dan door een webservice security laag worden afgehandeld. Door deze security laag kan worden afgedwongen dat alleen bepaalde geautoriseerde gebruikers toegang hebben tot bepaalde webservices. Webservice security kan op verschillende niveaus worden gerealiseerd: • Service niveau (hele service is wel/niet toegankelijk) • Layer niveau (specifieke kaartla(a)g(en) binnen een service) • Ruimtelijk (alleen een bepaald gebied of bepaalde objecten beschikbaar) • Tijd (alleen binnen bepaalde tijden is de service beschikbaar)


26

5.1.7 Architectuurprincipes De Nederlandse Overheid Referentie Architectuur (NORA) bevat principes, beschrijvingen, modellen en standaarden voor het ontwerp en de inrichting van de elektronische overheid. Het is een instrument dat door overheidsorganisaties kan worden benut in de verbetering van de dienstverlening aan burgers en bedrijven. Binnen NORA zijn diverse principes opgesteld, ook met betrekking tot het gebruik van geo-informatie binnen de overheid. Een NORA principe dat relevant is voor de Witte Kaart is “eenmalige inwinning en meervoudig gebruik”. Dit principe houdt in dat (geo)-informatie slechts eenmaal wordt ingewonnen, en vervolgens voor verschillende doeleinden toegepast kan worden. Voor basisregistraties geldt zelfs een verplichting om bestaande registraties te gebruiken in plaats van gegevens zelf opnieuw in te winnen. Daarnaast is er de plicht om onjuistheden in basisregistraties terug te melden. Deze verplichtingen komen de beschikbaarheid en kwaliteit van gegevens ten goede.

5.1.8 Relaties met andere projecten c.q. systemen Bij het opstellen van de architectuur moet rekening gehouden worden met omliggende architecturen. Daarvoor is geïnventariseerd welke projecten en systemen mogelijk een samenhang hebben met de Witte Kaart. Onderstaand overzicht geeft de projecten en systemen weer die mogelijk een relatie hebben met de ontwikkelen Witte Kaart. Tabel 8 Relaties met andere systemen Nr Project/systeem Organisatie 1 Doorontwikkeling GHOR Nederland, Orange Hill GHOR4all

2

LCMS

Netcentrisch Werken

3

GOED

VGGM

4

Digitale Bereikbaarheids Kaart (DBK)

NVBR

5

Risicokaart

IPO + Provincies

6

Kies beter.nl

Ministerie VWS

7

Kadaster

8

Maatschappelijk Vastgoed Zorgkaart Nederland

9 10

SoCard Bibliotheek.nl

11

Mee NL

Uitgeverij, diverse zorgverzekeraars Digitale Sociale Kaart G!DS gegevens over o.a. zorginstellingen Digitale Sociale kaart in gebruik bij ca 80 gemeenten

Toelichting GHOR4all bevat informatie over zorginstellingen. Momenteel wordt een nieuwe versie van GHOR4all ontwikkeld. De oude versie is niet zo gebruiksvriendelijk Landelijk Crisis Management Systeem (LCMS 1.4). Het LCMS bevat een veelheid aan geo-informatie, Witte Kaart zou een aanvulling zijn. Hierin registreert men informatie over zorginstellingen binnen de veiligheidsregio VGGM. De Witte Kaart is de opvolger van GOED Initiatief voor de realisatie van digitale bereikbaarheidskaarten gebaseerd op o.a. BAG objecten. Nog niet landsdekkend, veelal per veiligheidsregio georganiseerd. Systeem van provincies waarin informatie over kwetsbare objecten en risicoveroorzakers wordt geregistreerd (obv vergunningen). Kwetsbare objecten zijn o.a. zorginstellingen, daardoor overlap met Witte Kaart. Vestigingen van verschillende typen zorgverleners, aangevuld met specialismen en kwaliteitsgegevens. Uit diverse bronnen, met name van beroeps- en brancheorganisaties. Registratie in ontwikkeling bij Kadaster. Bevat informatie over o.a. zorginstellingen Commercieel Niet toekomstbestendig Niet toekomstbestendig Niet toekomstbestendig

5.2 Mogelijke vervolgstappen De intentie is om een start te maken met het herijken van de applicatie GHOR4all. Deze applicatie moet in ieder geval zo snel mogelijk BAG compliant worden opgeleverd, zodat alle zorginstellingen hierin geregistreerd op een kaart gezet kunnen worden. Dat betekent dat de applicatie nog wel aan een flink aantal eisen zal moeten voldoen voordat dit mogelijk is. Het gebruik van het NHR is een tweede stap. Deze database blijkt namelijk nog niet volledig te zijn (daar waar het gaat om registratie van vestigingen), daar waar GHOR4all waarschijnlijk meer vestigingslocaties in beeld heeft. Met de Kamer van Koophandel zullen daarom afspraken gemaakt


27

moeten worden over of het NHR bestand gebruikt kan worden (inclusief BAG-id’s) en op welke wijze terugmelden zal gaan en hoe aanvullende/nieuwe gegevens verwerkt gaan worden.

5.2.1. Overdracht GHOR Nederland GHOR Gelderland Midden zal de resultaten van het project De Witte Kaart overdragen aan GHOR Nederland. Bovendien zijn er gesprekken gaande met landelijk project netcentrisch werken om GHOR4all op te nemen in de landelijke proxyserver. Hierdoor kunnen gegevens die nu beschikbaar zijn snel ontsloten worden in het Landelijk Crisismanagement Systeem. Dit zou vast een mooie stap zijn om gegevens over zorginstellingen, tot zover bekend, landelijk te ontsluiten. Daarnaast moet bekeken worden op welke structurele wijze gegevens uit de basisregistraties aangeleverd worden aan de sector. Mogelijk kan dit via een sectoraal knooppunt zodat de gehele veiligheidsregio deze gegevens kan gebruiken. Verkennende gesprekken worden hierover gehouden tussen de programmaraad informatievoorziening van de Nederlandse Vereniging Brandweer en Rampenbestrijding (NVBR) en GHOR Nederland en Stuurgroep Werkend Stelsel/Maatschappelijke Baten. Inmiddels is ook een notitie geschreven waaronder gepleit wordt voor een businesscase om een sectoraal knooppunt te organiseren. GHOR Nederland zal deze ontwikkeling oplettend in de gaten moeten houden en moeten blijven aandringen op implementatie van de basisregistraties. Parallel loopt het traject van het ministerie van Volksgezondheid, Welzijn en Sport die met gelijksoortige ontwikkeling bezig zijn. GHOR Nederland moet daar vooral gesprekspartners aan tafel worden om te bepalen wat de gebruikers willen. Voorop staat dat uitrol van de Witte Kaart alleen landelijk kan en moet. Regionale oplossingen zijn niet wenselijk en lossen het gezamenlijke probleem ook niet op. De handen moeten inéén!


28

- Bijlagen Bijlage 1 Sectornaam GHOR4all met bijbehorende SBi codering + aantal

Sectornaam GHOR4all

SBI code

Aantal organisaties

Algemeen maatschappelijk werk Apothekers Brandweer Bureau GHOR Gehandicaptenzorg Gemeenten Gezinsvervangende en categorale woonvormen GGD GGz Hospices Huisartsen Huisartsenkringen Huisartsenposten Instanties die hulpmiddelen verstrekken Jeugdzorg Kraamzorg MKA Mondzorg NRK (Nederlandse Rode Kruis) Penitentiaire inrichtingen Politie RAV Revalidatiecentrum Slachtofferhulp Thuiszorgorganisaties Traumacentrum Verloskundigenzorg Verpleeg- en verzorgingsinstellingen Ziekenhuizen

87.90.2, 88.99.2 47.73 onbekend onbekend 87.20, 87.30 n.v.t. onbekend onbekend 86.10.4, 86222 onbekend 86.21 86.21 86.21 32.50.2 ,47.74.2 87.90.1, 88.99.1 onbekend onbekend onbekend onbekend 84323 onbekend onbekend 86.10.31 onbekend 88.10.1 onbekend 86.91.1 87.30.2, 87.20, 87.30.1 86.10

134 432 4 8 704 81 211 27 337 25 1510 6 54 33 86 32 2 334 5 8 6 12 23 9 249 3 185 1872 160


29

Bijlage 2 Dataset BAG

Bronhouder Kadaster

NHR

KvK

GHOR4all

GHOR/Orange Hill

LISA

Stichting LISA

WOZ administratie

Gemeenten (Dataland ovekoepelend)

8

Attributen (* = mogelijk koppelvlak)  Pand-id *  Straat  Toevoeging *  Huisletter *  Postcode *  X,Y coordinaat  Verblijfsobject-id *  Oppervlakte  gebruiksdoel  KvK nr*  Vestigings nr  adres correspondentie 8  adres vestiging *  SBI- hoofdcode(s)  SBI- nevencode(s)  ID (intern koppelvlak)  Naam  Subnaam  doelgroep  Noodnet telnr  Sectornaam  Straatnaam  Huisnummer *  Huisnummertoevoeging *  Postcode *  Per type verschillende extra informatie over bv aantal patiënten: deze is zeer relevant!  LISA-nr  Naam vestiging  Straatnaam  Huisnr*  Toevoeging*  Postcode*  Telefoon nr  Mobiel telefoon nr  KvK nr *  SBI code (4-5 posities)  OmscNHRijving  Werkgelegenheidsgegevens  Straatnaam  Huisnr*  Toevoeging*  Postcode*  Bouwkundige bestemming  Bouwkundige bestemming volgens DUWOZ

Opmerking Geometrie van verblijfsobjecten als punt, van panden als polygoon; landelijke basisregistratie

Landelijke basisregistratie; vestigingen 2012 BAG compliant

Nog onbekend wanneer BAG compliant.

Naar verwachting in 2013 BAG compliant

Dataland heeft niet 100% dekking, enkele gemeenten ontbreken; samengesteld uit individuele Gemeentelijke Basisregistraties

Vestigingen zijn momenteel slechts beperkt aanwezig in het NHR, hier wordt aan gewerkt maar dit is een punt van aandacht.


30

Bijlage 3


31


32

Eindrapportage 'De Witte Kaart'

Recommend Documents