Koppelprofiel stuf-nps
Inhoud
Werking
Alle gegevens uit de gemeentelijke basisregistraties zijn ondergebracht in één centrale, landelijke database: GBA-V. GBA-V staat voor GBA Verstrekkingsvoorziening en is de centrale component in het BRP-stelsel. Deze bevat alle persoonslijsten die in de Basisregistratie Personen (BRP) zijn ingeschreven.
Het gebruik van authentieke persoonsgegevens is een belangrijke voorwaarde om goed zaakgericht te kunnen werken. Om ervoor te zorgen dat er betrouwbare (authentieke) persoonsgegevens in Zaaksysteem terecht komen wil je dus aansluiten op de GBA-V. Echter mag het Zaaksysteem niet rechtstreek aansluiten op de GBA-V, omdat wij geen overheidsorgaan zijn. De gemeenten en andere overheidsorganisaties mogen dit wel.
Op dit moment gebruiken veel gemeenten één of meerdere datadistributiesystemen voor het uitwisselen van data tussen applicaties. Denk hierbij aan systemen als Key2Datadistributie (Centric) of Neuron ESB (Vicrea). Zo’n systeem ontvangt mutaties, beoordeelt ze en zorgt ervoor dat de afnemende applicaties over deze mutaties beschikken. Vaak voert een dergelijk systeem ook bewerkingen uit op de data.
Volgens de wet persoongegevens mogen alleen personen geïmporteerd en gevolgd worden door een applicatie als er doelbinding is met deze persoon. In geval van het zaaksysteem; de persoon wil een zaak aanvragen of heeft een lopende zaak.
Wat is StUF-BG?
StUF Basis Gegegevens (STUF-BG) is een berichtenstandaard voor de uitwisseling van basis- en kerngegevens binnen en tussen gemeenten en samenwerkende overheidsorganisaties. Het is gebaseerd op het Standaard Uitwisselings Formaat (StUF) voor het uitwisselen van gegevens die zijn beschreven in het Referentiemodel Stelsel Gemeentelijke Basisgegevens c.q. in het Gemeentelijk Functioneel Ontwerp (GFO). StUF-BG bevat generieke berichten voor de uitwisseling van gegevens over bijvoorbeeld personen, bedrijven en gebouwen.
(bron: gemmaonline)
StUF-BG NPS
NPS staat voor 'natuurlijke personen'. Dit is één van de basisgegevens die je kunt uitwisselen via StUF-BG. Dit is ook de enige variant die Zaaksysteem ondersteund. Bedrijven en adressen worden via een andere koppelvlak geïmporteerd in het Zaaksysteem.
Hoe werkt StUF-BG NPS in het zaaksysteem?
In dit onderdeel wordt een deze koppeling werkt in het zaaksysteem. Per scenario beschrijven we het proces.
Een persoon logt in met DigiD, en zit niet in het zaaksysteem
Een persoon logt in via DigiD, dat gekoppeld is aan het zaaksysteem. DigiD geeft alleen het BSN nummer van de persoon door. Op basis van dit BSN nummer stellen wij een vraagbericht aan de makelaar. Als het een geldig vraagbericht is geeft de makelaar een antwoord terug met daarin de gegevens van de persoon (in sommige gevallen via de GBA-V). De gegevens van de persoon worden gepresenteerd in het formulier van de burger, en kan zijn/haar zaak afronden. Het zaaksysteem heeft nu de gegevens, maar dit betekent niet dat het zaaksysteem de actuele gegevens blijft ontvangen voor deze persoon. Daarvoor is een sleuteluitwisseling (of anders gezegd; het plaatsen van een afnemerindicatie/het volgen van een persoon) vereist.
Sleuteluitwisseling
Op de achtergrond verstuurt het zaaksysteem een toevoegingsbericht naar de makelaar, waarmee we zeggen: Het zaaksysteem wil deze persoon volgen. In dit bericht versturen geven wij een sleutel mee (a:sleutelOntvangend="") zodat de makelaar deze kan opslaan en weet dat het zaaksysteem deze persoon wil volgen.
Als vervolgactie op het bericht stuurt de makelaar ons een wijzigingsbericht, met daarin alle actuele gegevens van de persoon, én de sleutel van de makelaar (a:sleutelVerzendend=""). Deze sleutel slaat het zaaksysteem op, zodat mutatieberichten vanuit de makelaar het juiste contact in het zaaksysteem bijwerken.
Een persoon logt in met DigiD, en zit wel in het zaaksysteem
Een persoon logt in via DigiD, dat gekoppeld is aan het zaaksysteem. DigiD geeft alleen het BSN nummer van de persoon door. Op basis van dit BSN nummer controleren wij of de persoon al in het zaaksysteem zit. Zo ja, presenteren we de gegevens van de persoon uit het zaaksysteem. Zo niet, stellen we een vraagbericht (zie proces 1).
Een medewerker zoekt een persoon op, en zit niet in het zaaksysteem
Het bevragen en importeren van een persoon werkt hetzelfde als een bevraging via DigiD. Het enige verschil is dat een medewerker op meer gegevens kan zoeken:
- BSN nummer
- BSN nummer i.c.m. geboortedatum
- Verblijfsadres
Een medewerker zoekt een persoon op, en zit wel in het zaaksysteem
Indien een persoon al in het zaaksysteem zit kan een medewerker de persoon vinden via de algemene zoekbalk, of via het veld zoekveld bij het registreren van een zaak.
Multi-tenant (meerdere aansluiting)
Het is mogelijk om meer dan één koppelprofiel van dit type actief te hebben, zodat er gekoppeld kan worden met meer dan één makelaar (meerdere gemeenten). Met één koppelprofiel krijgt de behandelaar bij het zoeken van een persoon een checkbox voor het wel/niet zoeken in het BRP. Met meer dan één koppelprofiel krijgt de behandelaar een selectielijst met de opties 'Intern' en de geselecteerde gemeenten.
Authentieke personen
Wanneer een persoon wordt geïmporteerd via de makelaar wordt deze persoon altijd als "authentiek" gemarkeerd. Dit betekent dat de gegevens van de persoon niet handmatig gewijzigd kunnen worden, maar dat dit enkel kan via een mutatiebericht uit de makelaar. Authentieke personen worden aangeduid met een icoon van een 'slotje' in het contactdossier. Handmatig aangemaakt personen worden aangeduid met een icoon van een 'database'.
Implementatie
Deze koppeling wordt in de meeste gevallen tijdens de implementatiefase gerealiseerd. Een consultant van zaaksysteem zal dit begeleidingen. Voorafgaand ontvangt de organisatie de voorbereidingsdocumentatie voor deze koppeling.
Beheren
Na in de implementatie dient de koppeling beheert te worden door een functioneel beheerder en een gegevensbeheerder. De volgende beheertaken komen hierbij kijken:
| Taak | Toelichting |
|---|---|
| Controleren transacties | Het is van belang dat het transactieoverzicht wordt gecontroleerd op fouten en daar, indien nodig, actie op wordt ondernomen. |
| Beheren gegevensmagazijn | Personen mogen niet tot in lengte van dagen gevold worden zonder reden. Dit beleid verschilt per organisatie. In het gegevensmagazijn kun je bepalen welke personen gevolgd worden, en welke niet. |
Uitleg velden koppelvlak
| Titel | Omschrijving |
|---|---|
| Aanbieder van de servicebus | Selecteer hier de makelaar/servicebus die de organisatie gebruikt |
| Type koppeling | In de meeste gevallen wordt er gekozen voor de hybride variant. Hierbij kun je vraagberichten stellen, en ontvang je mutatiebericht voor personen die worden gevolgd. |
| Gemeente code | Selecteer een gemeente |
| Naam op zoekformulier | Dit label wordt zichtbaar in het zoekformulier voor de behandelaar |
| Client-certificaat + key | Hier dient het gecombineerde certificaat en key geupload te worden, waarmee Zaaksysteem communicatie beveiligt. Dit bestand kan alleen door Zaaksysteem geupload worden in verband met het beveiligingsbeleid. Het publieke deel van dit certificaat dient vertrouwd te zijn in de makelaar. |
| Certificaat (CA certificaten) | Upload hier het publieke deel van het client-certificaat van de makelaar. |
| Public key (Makelaar) | StUF certificaat |
| Naam verzender | Vul hier de naam in die door Zaaksysteem gebruikt moet worden om de ontvanger en verzender van StUF berichten te identificeren. (bijvoorbeeld ZSNL) |
| Naam ontvanger | Vul hier de naam in die door de makelaar gebruikt wordt om de ontvanger en verzender van StUF berichten te identificeren. (bijvoorbeeld DDS) |
| GBA-V Ontvanger | Vul hier de naam in die door de makelaar verwacht wordt wanneer er vraagberichten (GBA-V) verstuurd worden door Zaaksysteem. (bijvoorbeeld DDS) |
| Naam ontvanger afnemer | Vul hier de naam in die door de makelaar verwacht wordt wanneer er berichten verstuurd worden met betrekking tot afnemersindicatie (bijvoorbeeld: CMODIS) |
| Vraagberichten toestaan | Geef hier aan of het gebruik van integrale zoekvragen via de makelaar is toegestaan in het gebruik van Zaaksysteem. Wanneer deze uitstaat is de optie ook niet zichtbaar voor de behandelaar. |
| Makelaar endpoint (SYNC) | Om te communiceren met een makelaar moet de StUF koppeling geconfigureerd zijn met een endpoint om berichten te kunnen uitwisselen met de makelaar. Plaats hier het end-point dat het zaaksysteem moet gebruiken om vraagberichten te stellen. |
| Makelaar endpoint (ASYNC) | Om te communiceren met een makelaar moet de StUF koppeling geconfigureerd zijn met een endpoint om berichten te kunnen uitwisselen met de makelaar. Plaats hier het end-point dat het zaaksysteem moet gebruiken om afnemerindicaties te plaatsen en te verwijderen. |
| PinkRoccade endpoint integrale BRP-bevraging | Let op: Enkel voor Pink |
| Vraagberichten naar GBA-V toestaan | Wanneer zaaksysteem.nl is gekoppeld met een makelaar voor verkeer naar de makelaar toe, en zoeken via de GBA-V gewenst is |
| Vraagberichten alleen toestaan voor 'BRP extern bevrager'-rol | Wanneer aangevinkt is het extern zoeken enkel nog beschikbaar voor medewerkers met de systeemrol 'BRP Externe bevrager' |
| Vraagberichten alleen toestaan via webformulier | Voorkom zoeken in de makelaar door medewerkers en zoek enkel burgers geauthenticeerd via DigiD |
| Laat zaaksysteem een makelaar simuleren | Activeert de spoofmodus |
Veelgestelde vragen
Dit dit hoofdstuk tref je een overzicht van de veelgestelde vragen rondom de werking van dit koppelvlak.
Zodra een persoon inlogt via DigiD en nog niet in het zaaksysteem is stellen wij een vraag aan de makelaar. Als de makelaar niet reageert, te laat reageert, of een leeg antwoord terugstuurd, kan het zaaksysteem geen actuele gegevens presenteren aan de burger. De burger dient via een formulier nu zijn gegevens in te vullen. Deze persoon wordt aangemaakt als niet-authentiek, maar heeft wel als bron 'DigiD'.
