Eindrapportage 'De Witte Kaart'



Vergelijkbare documenten
BRIDGIS EN DE BAG Opgesteld door Bridgis Geoservices BV Datum Mei 2013

Intelligent Bridge (i-bridge) & witte kaart

Ervaringen met de BAG

Basisregistraties Adressen en Gebouwen. De BAG: niet omdat het moet, maar omdat we er wijzer van worden!

Functioneel ontwerp. Omgevingsloket online. Koppeling met BAG

BAG Beheerauditrapportage

Handleiding voor implementatie WEBSERVICE GEOCODEREN

Bijlage 1. Overzicht van de basisvoorziening in het NUP: afspraken en gevolgen voor de gemeente

Technisch Rapport. BAG Extract in i-bridge2.0. Versie 1.0. Datum 9 December 2010

Brandweer Hollands Midden. Achtergrond In het kader van inowit wordt hiermee door BHM een innovatievoorstel ingediend en als projectplan uitgewerkt.

BAG. Anke Wolters 20 mei Microdata Regio en Ruimte

Processen en juridische aspecten LV WOZ

De complete oplossing voor uw kadastrale informatievoorziening.

Business case Digikoppeling

PRESENTATIE WOZ KAART

Microdata-middag. Kenmerken woning gebruik registers. Gelske van Daalen 1 november 2018

Release datum: 11 juni 2012

Het stelsel werkt, ook voor de WOZ

BGT migratie Maastricht BGT contactdagen 30 oktober 2014, Tilburg

WOZ-BAG vergelijking. Gemeente: Steenstad. Gemeentecode: 1234 Aantal inwoners: Oppervlakte (km 2 ): 175,96. Dongeradeel

DRAAIBOEK AANSLUITEN DOOR GEMEENTEN OP DE LV WOZ. VERSIE d.d

Toegang tot kwalitatief goede gemeentelijke informatie

Basisregistraties: het aanbod, de uitdagingen. successen met het gebruik. Eén digitale overheid: betere service. Vicrea 22 mei 2014.

Wat kan linked data betekenen voor de Basisregistratie Grootschalige Topografie?

Hierbij stuur ik u de antwoorden op de vragen van het lid Smaling (SP) over de website ruimtelijkeplannen.nl (ingezonden 29 januari 2015).

Inschrijving RBB-AWARD 2018

BAG plug-in. Versie 14.01

Stappenplan en voorbeeld afbakening studentencomplexen

Centrum voor Beleidsstatistiek en Microdata Services. Documentatierapport X- en Y-coördinaten van een verblijfsobject (VSLCOORDTAB)

Aanvraag huisnummer (nummeraanduiding)

Basisregistraties Adressen en Gebouwen (BAG) voor afnemers

Canonieke Data Modellering op basis van ArchiMate. Canonieke Data Modellering op basis van Archimate Bert Dingemans

Verantwoordingsrapportage. Beheer en Bestuur Basisregistratie Adressen en Gebouwen. Gemeente ZZ-ICTU-7. Datum

Projectplan. Kernregistratie Medewerkers en inowit

0.1 LVBAG Bevragen Productbeschrijving. versie 1.0. Datum. 10 augustus Document versie. 1.0 ConceptICT Services Keten RZDirectie IT

Plan van Aanpak beschikbaar stellen broncode Basisregistratie Personen (BRP)

Ligt uw uitdaging in het aansluiten op de voorzieningen en de distributie van basisgegevens?

Rapport metadata Voor de gebruikersvoorwaarden zie aan deze informatie kunnen geen rechten worden ontleend. Metadata RCE MIP Objecten

CIVISION OPERATIONELE OVERZICHTEN

Vergelijking verwerkingsregister AVG

Functionaliteit: lvwoz-processor 1. In deze versie worden de opentunnel.extra eigenschappen van berichten correct geretourneerd naar OpenTunnel.

Documentatierapport Coördinaten van de vierkanten van 100x100 en 500x500 meter waarin een verblijfsobject valt niet gecoördineerd (VSLVIERKANTTAB)

1. Aanlevering databestanden CQI Farmacie 2016

Voorblad Inhoudsopgave Inhoud

Checklist testen Lopende zaken MijnOverheid. Versie 1.1

In deze appendix wordt bekeken wat er moet gebeuren voordat

AFSPRAKEN StUF StUF bg OVERZICHT. Datum: 23 september 2017

Maximale inwonerstevredenheid. Overheid 360º. Daniël Prins (VeloA) Maarten van der Hoek (Exxellence)

Samenvatting NOTITIE. : Ellen Debats & Arjan KLoosterboer. : Leden van de expertgroep informatiemodellen

Methodebeschrijving Landelijke Monitor Leegstand

BGT/IMGEO gisib voorbeeld weg. BGT/IMGEO gisib?

Woningtypering. Verschillende woningtypes We onderscheiden verschillende woningtypes, namelijk:

Microdataservices. Documentatierapport Coördinaten van de vierkanten van 100x100 en 500x500 meter waarin een verblijfsobject valt (VSLVIERKANTTAB)

Handboek ZooEasy Online Wachtlijst

Microdataservices. Documentatierapport X- en Y-coördinaten van een verblijfsobject (VSLCOORDTAB)

Datum 20 maart 2017 Onderwerp

gravita PSUR-C conversie en import van relaties in PSU Relatiebeheer Algemeen

De BAG in gebruik. Resultaten Gebruikersonderzoek Janette Storm (Kadaster) Martijn Odijk (Ministerie BZK) Prodentfabriek - Amersfoort

Technisch Ontwerp W e b s i t e W O S I

Chris Veenstra, DataLand

Chris Veenstra, DataLand

Woningvoorraad naar gemeente, wijk, buurt en PC5, Kim van Zoonen en Wouter van Andel

Annex bij het methoderapport

B en W-nummer ; besluit d.d Onderwerp Inspectie BAG-beheer oktober 2014

Beheeradvies BasisRegistratie (BRS)

MijnOmgeving. Geo-informatie dvoor X de ogen van de klant

Overzicht veelgenoemde stelselthema's en STIP-onderwerpen

Stap 5. Koppel vervolgens de Stages aan de AIOS op het blad AIOS Stageplaats (figuur 5). Nu kunnen de Stage specifieke afspraken aangemaakt worden.

Qlik Sense Healthcare. Document 16052

Belangrijkste uitdagingen voor landelijke versnelling van verwijzen

Documenten en zaken op de kaart. Roadmap. Documenten en zaken op de kaart

Gebruik georegistraties binnen de Politie. Wat is het en wat kunnen wij ermee

KLIC API voor afwijkende situatie Pilot

Herinspectierapportage Wet basisregistraties adressen en gebouwen

Kernregistratie Openbare Ruimte Overheid & ICT, Utrecht

Aanlevering geografische gegevens

WOZ-waardes Woningvoorraad naar Eigendom en Regio 2015 en 2017

Verantwoordingsrapportage

PROJECT PLAN VOOR DE IMPLEMENTATIE VAN EEN STANDAARD SITE VOOR DE VERENIGING O3D

Workshop 6: aan de slag met leuke dingen in Atlas

Functioneel ontwerp. Omgevingsloket online. Koppeling met GBA

BGT migratie Spijkenisse

Centraal Bureau voor de Statistiek Statistics Netherlands

AFO 142 Titel Aanwinsten Geschiedenis

Handboek ZooEasy Online Uitslagen

Betere besluitvorming bij crisis en ramp door betere informatiepositie

Verantwoordingsrapportage

Rotterdamse TerugMeld Faciliteit

Verantwoordingsrapportage

Raadsvoorstel 2013 Rockanje, 1 oktober 2013 Nr /74225

Les 15 : updaten van gegevens in de database (deel2).

Project methodiek. Auxilium BV Oude Delft CD Delft. T: F: E:

Financieringsverstrekkersportaal. Aansluitdocument

Plan van Aanpak Pilot

Kwaliteitssysteem datamanagement. Meetbaar Beter

GEO-informatie bij Politie. Locatieserver 2.0

PVE ICT SOCIALE WIJKTEAMS. Inleiding

Juliana van Stolberglaan CA Den Haag Postbus AC Den Haag [Handleiding Generieke interface Energielabels.

Inspectierapportage Wet basisregistraties adressen en gebouwen

De terugmeldingsverplichting. Datum 22 mei 2014

Transcriptie:

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 Datum Status Wijziging Opgesteld/gewijzigd door 01 November 2012 Concept - Sandra Thomassen 02 December 2012 Concept Zie document Nicole Damen 03 Januari 2013 Concept Managementsamenvatting Sandra Thomassen 04 Januari 2013 Definitief Toevoeging Hoofdstuk 5 Ype Schat 2. Goedkeuring Dit projectplan wordt goedgekeurd door de opdrachtgever Eindrapportage De Witte Kaart 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 Eindrapportage De Witte Kaart 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 Eindrapportage De Witte Kaart 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. Eindrapportage De Witte Kaart 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. Eindrapportage De Witte Kaart 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 Eindrapportage De Witte Kaart 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. Eindrapportage De Witte Kaart 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 Eindrapportage De Witte Kaart 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 Requirement Toelichting MoSCoW 1 BAG verblijfsobjecten als basis BAG is basisregistratie, gebruik is verplicht Must voor de zorgobjecten voor pandgeometrie 2 Symbologie gebaseerd op Gebruik van bestaande classificaties Should bestaande afspraken Gebruik van bestaande symbolenset(s) 3 Gebruik van open data Volgens NORA Must formaten 4 Gebruik van semantische Bv SBI coderingen Must standaarden en coderingen 5 Inzicht in kwaliteit van de Bv waarschijnlijkheid of actualiteit van het Could gegevens gegeven 6 Ten minste de typen Must instellingen uit tabel 1 7 Waar beschikbaar aanvullende informatie uit tabel 2 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 Eindrapportage De Witte Kaart 11

Nr Requirement Toelichting MoSCoW 1a Visualiseren type zorg met Deze verschillende typen zijn in ieder geval te Must symbool symboliseren: Verpleegtehuizen & Verzorgingstehuizen Ziekenhuizen Revalidatiecentra Gehandicaptenzorg Geestelijke Gezondheidszorg Apotheek Huisartsen Huisartsenposten Thuiszorg Verloskundigen Verslavingszorg Jeugdzorg Penitentiaire inrichtingen 1b Visualiseren type zorg met Overige typen zorg symboliseren per type Could symbool 2 Topologische selectie Nabijheidsrelaties Must 3 Informatie opvragen Informatie over object Must 4 Thematische selecties Vb: Symboliseer instellingen zonder eigen Would vervoer 5 Zoekfunctie Type instelling Could Naam instelling 6 Inzicht kwaliteit Opvragen indicator datakwaliteit Could 7 Terugkoppeling naar GHOR4all Geografische gegevens uit GHOR4all Could updaten met Witte Kaart gegevens 8 Terugkoppeling naar KvK Wettelijke verplichting, niet per se Must geautomatiseerd 1 9 Terugkoppeling naar Kadaster Wettelijke verplichting, niet per se geautomatiseerd 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 Requirement Toelichting MoSCoW 1 Quality of Service QoS Uptime 99% QoS Responsetijd <3 sec QoS Performance 20 concurrent Must Must Must 2 Usability (Look and feel) Uniformiteit met LCMS Should 3 Koppelbaar met andere Gebruik van open standaarden Should systemen 4 Beheer en onderhoud Update-frequentie passend bij bronbestanden Should 5 Privacy en Security Toegangsbeheer Afscherming van gevoelige gegevens Must Must 6 Juridisch P.m. 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. Eindrapportage De Witte Kaart 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 voorkomen 2. 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 gebruiksdoelen 3, 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 86 4 (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 3 Sportfunctie, onderwijsfunctie, winkelfunctie, overige gebruiksfunctie, woonfunctie, bijeenkomstfunctie, celfunctie, gezondheidsfunctie, industriefunctie, kantoorfunctie, logiesfunctie 4 http://www.cbs.nl/nr/rdonlyres/beb2adae-3a2e-4929-8dff- 3EC4C872684D/0/sbi2008versie2012incl6eniveautoelichting.pdf Eindrapportage De Witte Kaart 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-bestand 7 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 Zie bijlage 1 voor SIB coderingen Zorg 6 Zie bijlage 2 voor overzicht van eigenschap per attribuut 7 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. Eindrapportage De Witte Kaart 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) Hoofdactiviteit Neven1 (uniek tov hoofd) Neven2 (uniek tov voorgaande) 219 210 7 2 192 183 7 2 88% 87% 100% 100% WOZ 44 44 100% LISA 273 229 84% Populator 116 83 72% GHOR4all 20 20 100% 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 Eindrapportage De Witte Kaart 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) 86102 86925 86103 86104 8720* 8621 86911 88101 8710 87302 153 0 1 3 0 (20)* 15 3 96 1 6 102 0 0 0 6 (0)* 31 6 2 2 7 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. 119 1 0 0 3 (0)* 88 6 2 0 8 Eindrapportage De Witte Kaart 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 I- Bridge) 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 Eindrapportage De Witte Kaart 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 Eindrapportage De Witte Kaart 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.). Eindrapportage De Witte Kaart 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 Eindrapportage De Witte Kaart 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 Eindrapportage De Witte Kaart 21