Omnichannel MijnZaken Principes kaders en context
Inhoud
Dit hoofdstuk beschrijft de principes en kaders waaraan de architectuur en MijnZaken-implementaties moeten voldoen en schetst de context daarbij.
Principes[bewerken]
| MijnZaken-principe | 1. MijnZaken-informatie is aangepast op de behoefte van de ontvanger |
|---|---|
| Rationale | MijnZaken-informatie informeert de ontvanger zo goed mogelijk over de status van levering van een product of dienst. Dit vereist dat de getoonde informatie op de behoeften van die ontvanger is afgestemd. |
| Implicaties voor referentiearchitectuur MijnZaken | De referentiearchitectuur MijnZaken beschrijft het aanbieden van gegevens als MijnZaken-informatie voor verschillende doelgroepen. |
| Implicaties voor implementaties MijnZaken | Implementaties van MijnZaken worden zodanig ingericht dat inhoud, taalgebruik en presentatie van MijnZaken-informatie worden aangepast aan de ontvanger. Deze informatie is voor die ontvanger:
Dit betekent dat niet in alle gevallen dezelfde gegevens als MijnZaken-informatie worden aangeboden. Een burger zal bijvoorbeeld een ander(e) kennisniveau en informatiebehoefte hebben dan een klantenservicemedewerker van een overheidsorganisatie. |
| Bronprincipe(s) | Dit principe is afgeleid van:
|
| MijnZaken-principe | 2. MijnZaken-informatie kan via meerdere kanalen worden verkregen |
|---|---|
| Rationale | Niet iedere ontvanger wil op dezelfde manier MijnZaken-informatie ontvangen. MijnZaken-informatie kan daarom via meerdere kanalen worden aangeboden. |
| Implicaties voor referentiearchitectuur MijnZaken | De referentiearchitectuur MijnZaken beschrijft hoe MijnZaken-informatie kan worden aangeboden, ongeacht het kanaal dat daarvoor wordt gebruikt. |
| Implicaties voor implementaties MijnZaken | Implementaties van MijnZaken worden zodanig ingericht dat MijnZaken-informatie (op termijn) via meerdere kanalen kan worden aangeboden. |
| Bronprincipe(s) | Dit principe is afgeleid van: |
| MijnZaken-principe | 3. Voor het leveren van MijnZaken-informatie worden zo mogelijk bestaande componenten en standaarden (her)gebruikt |
|---|---|
| Rationale | De drempel om MijnZaken-informatie aan te bieden moet laag zijn. Daarom wordt gebruikgemaakt van componenten met helder gedefinieerde verantwoordelijkheden en reeds beschikbare open standaarden. MijnZaken kan zo ‘meegroeien’ met de ontwikkeling van standaarden en het beschikbaar komen van oplossingen van leveranciers die MijnZaken-informatie bijvoorbeeld via een nieuw kanaal beschikbaar maken. |
| Implicaties voor referentiearchitectuur MijnZaken | De referentiearchitectuur maakt waar mogelijk (her)gebruik van open standaarden die los installeerbare componenten verbinden. |
| Implicaties voor implementaties MijnZaken | Implementaties van MijnZaken gebruiken de in de referentiearchitectuur beschreven standaarden en componenten en maken bij de presentatie van MijnZaken-informatie gebruik van standaardoplossingen als NL Design System. |
| Bronprincipe(s) | Dit principe is afgeleid van:
|
| MijnZaken-principe | 4. MijnZaken-informatie komt uit de bron |
|---|---|
| Rationale | Het is belangrijk dat MijnZaken-informatie actueel en juist is. MijnZaken informatie wordt daarom (voor zover mogelijk) op aanvraag verstrekt en bij de bron verkregen. |
| Implicaties voor referentiearchitectuur MijnZaken | De referentiearchitectuur beschrijft interactiepatronen om op basis van notificaties over statusveranderingen gegevens die onderdeel (kunnen) zijn van MijnZaken-informatie vanuit de bijbehorende bronregistraties op te halen en aan de ontvanger aan te bieden. |
| Implicaties voor implementaties MijnZaken | Implementaties van MijnZaken volgen (voor zover mogelijk) de in de referentiearchitectuur beschreven interactiepatronen. |
| Bronprincipe(s) | Dit principe is afgeleid van:
|
| MijnZaken-principe | 5. MijnZaken-informatie wordt vertrouwelijk verwerkt |
|---|---|
| Rationale | MijnZaken-informatie omvat persoonsgegevens en mogelijk andere gevoelige data die bijvoorbeeld te maken hebben met de financiële situatie van de aanvrager. Deze gegevens worden vertrouwelijk, en in lijn met wet- en regelgeving behandeld. |
| Implicaties voor referentiearchitectuur MijnZaken | De referentiearchitectuur beschrijft hoe toegang tot gegevens wordt beperkt voor ontvangers die daartoe niet gerechtigd zijn, en licht toe hoe deze gegevens conform relevante wet- en regelgeving verwerkt moeten worden. |
| Implicaties voor implementaties MijnZaken | Implementaties van MijnZaken beperken de toegang tot MijnZaken-informatie, verwerken die volgens relevante wet- en regelgeving en bieden burgers inzage in het gebruik van MijnZaken-informatie door medewerkers van de gemeente. |
| Bronprincipe(s) | Dit principe is afgeleid van:
|
Wet- en regelgeving[bewerken]
| Nr. | Verplichting | Bron | Toelichting |
|---|---|---|---|
| 1 | Beperkt recht op inzage door burgers bij behandeling vertrouwelijke of gevoelige zaken. | Algemene Verordening Gegevensbescherming (AVG) en materie- wetgeving | Op basis van artikel 23 lid 1 onderdeel i van de AVG mag inzage door burgers in eigen persoonsgegevens geweigerd worden als die afbreuk zou doen aan ‘rechten en vrijheden van anderen’. Bovendien kennen verschillende ‘materiewetten’ (bijvoorbeeld artikel 7.3.11 lid 3 Jeugdwet, artikel 5.3.2 lid 4 Wmo 2015) bepalingen op basis waarvan inzage in gevoelige informatie door betrokkenen geweigerd kan worden. Dit betekent dat aan burgers geen statusinformatie verstrekt wordt over bijvoorbeeld een onderzoek naar fraude of een onderzoek naar aanleiding van een melding bij Veilig Thuis. |
| 2 | Medewerkers hebben alleen toegang tot informatie die nodig is om een burger of ondernemer te helpen | Algemene Verordening Gegevensbescherming (AVG) | Persoonsgegevens die worden verwerkt moeten toereikend en ter zake dienend zijn, en beperkt zijn tot wat noodzakelijk is voor de doeleinden. Daarbij gaat het om proportionaliteit en subsidiariteit, waardoor een minimum aan verwerking van persoonsgegevens wordt gerealiseerd (artikel 5, eerste lid, onder c, van de AVG). Er mogen niet meer gegevens dan nodig worden verwerkt en er moet goed worden bezien of het doel niet op een manier kan worden bereikt die minder inbreuk maakt op privacy. |
| 3 | Overheidsorganisaties moeten zich kunnen verantwoorden over verwerkte persoonsgegevens | Algemene Verordening Gegevensbescherming (AVG) | Overheidsorganisaties moeten kunnen aantonen dat een verwerking aan de belangrijkste beginselen van verwerking voldoet, zoals rechtmatigheid, transparantie, doelbinding en juistheid. Ook moet aangetoond kunnen worden dat de juiste technische en organisatorische maatregelen genomen zijn om de persoonsgegevens te beveiligen. |
| 4 | Overheidsinformatie is duurzaam toegankelijk en wordt (indien van toepassing) op het aangewezen moment vernietigd | Archiefwet | Overheidsorganisaties houden hun informatie (‘archiefbescheiden’) duurzaam toegankelijk, en/of die vernietigen die wanneer de bewaartermijn is verlopen. Dit is belangrijk omdat overheidsinformatie een rol speelt bij rechtsvinding en de (publieke) verantwoording door diezelfde overheid. Overheidsorganisaties moeten daarom aan burgers of derden verstrekte informatie archiveren, of die verstrekking op zodanige wijze vastleggen (loggen), dat onomstotelijk kan worden bewezen op welk moment aan wie welke gegevens geleverd zijn. |
| 5 | Verplicht aangewezen open standaarden worden gebruikt | Wet digitale overheid (nog niet in werking) | Overheidsorganisaties kunnen bij algemene maatregel van bestuur worden verplicht een open standaard toe te passen. Een standaard kan worden aangewezen als dat noodzakelijk en proportioneel is voor de werking, de veiligheid, de betrouwbaarheid, de duurzame toegankelijkheid of de doelmatigheid van het elektronische verkeer met of tussen overheidsorganisaties of als dat voortvloeit uit internationale verplichtingen. |
| 6 | Voor diensten een is een betrouwbaarheidsniveau vastgesteld | Wet digitale overheid (nog niet in werking) | Op basis van de (voorgestelde) Wet digitale overheid zullen overheidsorganisaties verplicht worden voor hun elektronische diensten waarvoor veilige toegang nodig is, het betrouwbaarheidsniveau substantieel of hoog te gebruiken. Bij het zullen dienstverleners zich moeten houden aan nader Uitvoeringsregelgeving zal kaders bieden voor het bepalen van het bij de dienstverlening passende betrouwbaarheidsniveau. |
| 7 | Goedgekeurde identificatie- en authenticatiemiddelen worden geaccepteerd | Wet digitale overheid (nog niet in werking) | Vanuit het belang van het faciliteren van burgers en bedrijven en het belang van een veilige en betrouwbare identificatie- en authenticatieketen, verplicht dit wetsvoorstel overheidsorganisaties om bij elektronische dienstverlening de toegelaten identificatiemiddelen, erkende middelen en de bij de Europese Commissie genotificeerde middelen te accepteren, voor zover die middelen minimaal het voor de af te nemen dienst vereiste betrouwbaarheidsniveau ondersteunen. |
| 8 | Indiener ontvangt ontvangstbevestiging na indienen | Wet modernisering elektronisch bestuurlijk verkeer | Wanneer een overheidsorganisatie via elektronische weg een formeel bericht ontvangt (zoals een aanvraag voor een product of dienst), verstuurt het een ontvangstbevestiging. Dit tenzij de verzender en het bestuursorgaan gebruikmaken van hetzelfde systeem van gegevensverwerking, en de verzender kan zien dat het bericht door de overheidsorganisatie ontvangen is. Bovendien hoeft geen ontvangstbevestiging te worden verzonden als de afzender geen elektronisch adres heeft opgegeven waarop hij te bereiken is. Het bestuursorgaan moet daar wel naar vragen in het formulier. |
| 9 | Inzage in ingevulde gegevens | Wet modernisering elektronisch bestuurlijk verkeer | De overheidsorganisatie maakt door de indiener ingevulde gegevens aan die indiener beschikbaar. Deze inzagemogelijkheid dient beveiligd te zijn op een manier die passend is bij de vertrouwelijkheid en gevoeligheid van de verstrekte gegevens. |
| 10 | Verantwoording bij verzending en ontvangst berichten | Wet modernisering elektronisch bestuurlijk verkeer | Indien overheidsorganisaties gebruik maken van een MijnOmgeving of ander systeem waarin de burger of ondernemer toegang heeft tot door de overheid verzonden berichten, moet de overheidsorganisatie kunnen aantonen dat via dit systeem beschikbaar gestelde informatie is verzonden en (eventueel) ontvangen. Dit is geen verplichting om alles te loggen. De overheidsorganisatie kan zelf bepalen met welke gegevens in de meeste gevallen aan een bewijsplicht kan worden voldaan en het loggen beperken tot die gegevens. |
| 11 | Correctiegelegenheid na onjuiste indiening | Wet modernisering elektronisch bestuurlijk verkeer | Na ontvangst van een niet via de aangegeven weg ingediend bericht kan worden volstaan met de mededeling dat het bericht onjuist is ingediend en het wijzen op de juiste manier van indienen. In drie gevallen volstaat zo’n mededeling echter niet:
|
| 12 | Toegankelijkheid websites en apps | Tijdelijk besluit digitale toegankelijkheid overheid en Wet digitale overheid (nog niet in werking) | Websites en mobiele apps van Nederlandse overheidsinstanties moeten voldoen aan de toegankelijkheidseisen volgens de Europese norm 301 549. Hierover moet verantwoording worden afgelegd in een toegankelijkheidsverklaring. Deze eisen gelden voor websites van overheidsorganisaties en mobiele applicaties. |
Bouwblokken digitale overheid[bewerken]
Mijn Overheid lopende zaken en federatief berichtenstelsel[bewerken]
Mijn Overheid Lopende Zaken dient hetzelfde doel als MijnZaken: gebruikers de voortgang van een aanvraag stap voor stap laten volgen. Maar de techniek verschilt sterk: Mijn Overheid Lopende Zaken werkt op basis van StUF-zaakberichten. Deze moeten op basis van het Digikoppeling ebMS-koppelvak aangeleverd worden. Hierbij is beveiliging met dubbelzijdig TLS en een PKIoverheid-certificaat noodzakelijk.
Omdat het berichtenverkeer van MijnOverheid, de BerichtenBox app, MijnGegevens app en het (formele) berichtenverkeer aan inwoners en ondernemers gaat veranderen, is het waarschijnlijk beter om vooruit te kijken en te bepalen hoe MijnZaken kan aansluiten bij ontwikkelingen rondom het Federatief Berichtenstelsel (FBS). Dat heeft tot doel om de digitale dienstverlening te verbeteren, het beheer goedkoper te maken en de toepassingen uit te bereiden.
Het generieke deel van het Federatief berichtenstelsel bestaat uit een aantal componenten, die hieronder zijn geïllustreerd.
Notificatieservice[bewerken]
In het kader van het FBS kunnen bestuursorganen notificatieopdrachten geven aan de centrale notificatieservice aangaande de publicatie van berichten. De notificatieservice verstuurt de notificatie(s) naar de geadresseerde en eventuele vertegenwoordigers conform de ingestelde kanalen en voorkeuren in de notificatieprofielen van de ontvangers van de notificatie. De centrale notificatieservice is een generiek component en wordt breder ingezet dan de taken voor het FBS.
Notificatieprofielen[bewerken]
De gebruikers beheren hun persoonlijke notificatievoorkeuren in het centrale notificatieprofiel. Hiervoor wordt de notificatieprofielservice ontsloten aan de interactielaag zodat de gebruikers kun profiel kunnen beheren. Het profiel kan vervolgens worden gebruikt door afnemende services waaronder de notificatieservice.
Notifcatieservices en gebeurtenisgedreven werken[bewerken]
Bij het aanvragen van een product en bij het behandelen van een productaanvraag bereikt het proces steeds een andere status. Een burger, bedrijf of instelling kan deze status zelf opvragen via verschillende kanalen.
Een ander patroon ontstaat als er een notificatie gestuurd wordt op basis van een gebeurtenis. Deze gebeurtenissen worden naar een centraal notificatierouteringscomponent gestuurd. Informatiesystemen kunnen zich abonneren op bepaalde gebeurtenissen. Op het moment dat er een gebeurtenis is opgetreden die relevant kan zijn voor een informatiesysteem, onderneemt dit informatiesysteem (op basis van regels) actie.
In het kader van MijnZaken-informatie kan een specifiek interactiecomponent geabonneerd zijn op gebeurtenissen die te maken hebben met een productaanvraagstatus of zaakstatus. Zodra een status van een zaak door een processysteem wordt gewijzigd, wordt de interactiecomponent daarvan op de hoogte gesteld. Het interactiecomponent kan op basis van die notificatie de gewenste gegevens ophalen en tonen aan de gebruiker.
Door de projectgroep Notificatieservices wordt gewerkt aan een ‘Nederlandse Notificatie Strategie’ . Bij de ontwikkeling hiervan zijn overheidsorganisaties uit de verschillende bestuurslagen betrokken. Verder wordt nadrukkelijk aansluiting gezocht bij wereldwijd gebruikte standaarden, zoals de CloudEvents specificatie. Naar verwachting leidt dit tot een API standaard die functioneel beschreven is en overheidsbreed toegepast kan worden.
Het toepassen van deze nieuwe standaard (in ontwikkeling) kan een meerwaarde bieden in de dienstverlening naar burgers, bedrijven en instellingen. Door opname van de referentiecomponent Notificatierouteringscomponent en bijhorende Notificaties API in de referentiearchitectuur MijnZaken is reeds rekening gehouden met deze nieuwe standaard.