diff --git a/README.md b/README.md index fbe2938a01..b89c7aa732 100644 --- a/README.md +++ b/README.md @@ -1,235 +1,19 @@ --- layout: home -title: Jekyll Gitbook Theme +title: Samen onder Handbereik permalink: / +cover: https://samen-onder-handbereik.github.io/afsprakenstelsel/assets/handenblauwlogolong.png --- -Make Jelly site have a GitBook look! +Netwerksamenwerking onder de vingertoppen -## Demo +## Het Jeugd, Zorg en Veiligheid Afsprakenstelsel -Live demo on Github Pages: [https://sighingnow.github.io/jekyll-gitbook](https://sighingnow.github.io/jekyll-gitbook) +Deze site beschrijft het Jeugd Zorg en Veiligheid Afsprakenstelsel. In het jeugd-, zorg- en veiligheidsdomein is het doel om samenwerking moeiteloos en voor iedereen toegankelijk te maken. Anders samenwerken moet leiden tot meer vertrouwen, betere betrokkenheid van burgers, een evenwichtigere werkverdeling en effectievere oplossingen. -[![Jekyll Themes](https://img.shields.io/badge/featured%20on-JekyllThemes-red.svg)](https://jekyll-themes.com/jekyll-gitbook/) - -## Why Jekyll with GitBook - -GitBook is an amazing frontend style to present and organize contents (such as book chapters -and blogs) on Web. The typical to deploy GitBook at [Github Pages][1] -is building HTML files locally and then push to Github repository, usually to the `gh-pages` -branch. It's quite annoying to repeat such workload and make it hard for people do version -control via git for when there are generated HTML files to be staged in and out. - -This theme takes style definition out of generated GitBook site and provided the template -for Jekyll to rendering markdown documents to HTML, thus the whole site can be deployed -to [Github Pages][1] without generating and uploading HTML bundle every time when there are -changes to the original repo. - -## How to Get Started - -This theme can be used just as other [Jekyll themes][1] and support [remote theme][12], -see [the official guide][13] as well. - -You can introduce this jekyll theme into your own site by either - -- [Fork][3] this repository and add your markdown posts to the `_posts` folder. -- Use as a remote theme in your [`_config.yml`][14](just like what we do for this - site itself), - -```yaml -remote_theme: sighingnow/jekyll-gitbook -``` - -### Deploy Locally with Jekyll Serve - -This theme can be ran locally using Ruby and Gemfiles. - -[Testing your GitHub Pages site locally with Jekyll](https://docs.github.com/en/pages/setting-up-a-github-pages-site-with-jekyll/testing-your-github-pages-site-locally-with-jekyll) - GitHub - -## Full-text search - -The search functionality in jekyll-gitbook theme is powered by the [gitbook-plugin-search-pro][5] plugin and is enabled by default. - -[https://sighingnow.github.io/jekyll-gitbook/?q=generated](https://sighingnow.github.io/jekyll-gitbook/?q=generated) - -## Code highlight - -The code highlight style is configurable the following entry in `_config.yaml`: - -```yaml -syntax_highlighter_style: colorful -``` - -The default code highlight style is `colorful`, the full supported styles can be found from [the rouge repository][6]. Customized -style can be added to [./assets/gitbook/rouge/](./assets/gitbook/rouge/). - -## How to generate TOC - -The jekyll-gitbook theme leverages [jekyll-toc][4] to generate the *Contents* for the page. -The TOC feature is not enabled by default. To use the TOC feature, modify the TOC -configuration in `_config.yml`: - -```yaml -toc: - enabled: true - h_min: 1 - h_max: 3 -``` - -## Google Analytics, etc. - -The jekyll-gitboook theme supports embedding the [Google Analytics][7], [CNZZ][8] and [Application Insights][9] website analytical tools with the following -minimal configuration in `_config.yaml`: - -```yaml -tracker: - google_analytics: "" -``` - -Similarly, CNZZ can be added with the following configuration in `_config.yaml` - -```yaml -tracker: - cnzz: "" -``` - -Application Insights can be added with the following configuration in `_config.yaml` - -```yaml -tracker: - application_insights: "" -``` - -## Disqus comments - -[Disqus](https://disqus.com/) comments can be enabled by adding the following configuration in `_config.yaml`: - -```yaml -disqushandler: "" -``` - -## Jekyll collections - -Jekyll's [collections][15] is supported to organize the pages in a more fine-grained manner, e.g., - -```yaml -collections: - pages: - output: true - sort_by: date - permalink: /:collection/:year-:month-:day-:title:output_ext - others: - output: true - sort_by: date - permalink: /:collection/:year-:month-:day-:title:output_ext -``` - -An optional `ordered_collections` key can be added to `_config.yaml` to control the order of collections in the sidebar: - -```yaml -ordered_collections: - - posts - - pages - - others -``` - -If not specified, the order of collections would be decided by Jekyll. Note that the key `posts` is a special collection -that indicates the `_posts` pages of Jekyll. - -## Extra StyleSheet or Javascript elements - -You can add extra CSS or JavaScript references using configuration collections: - -- extra_css: for additional style sheets. If the url does not start by http, the path must be relative to the root of the site, without a starting `/`. -- extra_header_js: for additional scripts to be included in the `` tag, after the `extra_css` has been added. If the url does not start by http, the path must be relative to the root of the site, without a starting `/`. -- extra_footer_js: for additional scripts to be included at the end of the HTML document, just before the site tracking script. If the url does not start by http, the path must be relative to the root of the site, without a starting `/`. - -## Customizing font settings - -The fonts can be customized by modifying the `.book.font-family-0` and `.book.font-family-1` entry in [`./assets/gitbook/custom.css`][10], - -```css -.book.font-family-0 { - font-family: Georgia, serif; -} -.book.font-family-1 { - font-family: "Helvetica Neue", Helvetica, Arial, sans-serif; -} -``` - -## Tips, Warnings and Dangers blocks - -The jekyll-gitbook theme supports customized kramdown attributes (`{: .block-tip }`, `{: .block-warning }`, -`{: .block-danger }`) like that displayed in [the discord.js website][11]. The marker can be used like - -```markdown -> ##### TIP -> -> This guide is last tested with @napi-rs/canvas^0.1.20, so make sure you have -> this or a similar version after installation. -{: .block-tip } -``` - -Rendered page can be previewed from - -[https://sighingnow.github.io/jekyll-gitbook/jekyll/2022-06-30-tips_warnings_dangers.html](https://sighingnow.github.io/jekyll-gitbook/jekyll/2022-06-30-tips_warnings_dangers.html) - -## Cover image inside pages - -The jekyll-gitbook theme supports adding a cover image to a specific page by adding -a `cover` field to the page metadata: - -```diff - --- - title: Page with cover image - author: Tao He - date: 2022-05-24 - category: Jekyll - layout: post -+ cover: /assets/jekyll-gitbook/dinosaur.gif - --- -``` - -The effect can be previewed from - -[https://sighingnow.github.io/jekyll-gitbook/jekyll/2022-05-24-page_cover.html](https://sighingnow.github.io/jekyll-gitbook/jekyll/2022-05-24-page_cover.html) - -## Diagrams with mermaid.js - -This jekyll-theme supports [mermaid.js](https://mermaid.js.org/) to render diagrams -in markdown. - -To enable the mermaid support, you need to set `mermaid: true` in the front matter -of your post. - -```markdown ---- -mermaid: true ---- -``` - -The example can be previewed from - -[https://sighingnow.github.io/jekyll-gitbook/jekyll/2023-08-31-mermaid.html](https://sighingnow.github.io/jekyll-gitbook/jekyll/2023-08-31-mermaid.html) - -## License - -This work is open sourced under the Apache License, Version 2.0. - -Copyright 2019 Tao He. - -[1]: https://pages.github.com -[2]: https://pages.github.com/themes -[3]: https://github.com/sighingnow/jekyll-gitbook/fork -[4]: https://github.com/allejo/jekyll-toc -[5]: https://github.com/gitbook-plugins/gitbook-plugin-search-pro -[6]: https://github.com/rouge-ruby/rouge/tree/master/lib/rouge/themes -[7]: https://analytics.google.com/analytics/web/ -[8]: https://www.cnzz.com/ -[9]: https://docs.microsoft.com/en-us/azure/azure-monitor/app/app-insights-overview -[10]: https://github.com/sighingnow/jekyll-gitbook/blob/master/gitbook/custom.css -[11]: https://discordjs.guide/popular-topics/canvas.html#setting-up-napi-rs-canvas -[12]: https://rubygems.org/gems/jekyll-remote-theme -[13]: https://docs.github.com/en/pages/setting-up-a-github-pages-site-with-jekyll/adding-a-theme-to-your-github-pages-site-using-jekyll -[14]: https://github.com/sighingnow/jekyll-gitbook/blob/master/_config.yml -[15]: https://jekyllrb.com/docs/collections/ +We noemen dat: +‘Samen onder Handbereik: netwerk samenwerking onder de vingertoppen’. +Die Ambitie deelden we op in 3 doelen: +1. We zorgen voor praktische, betrouwbare en de-escalerende informatie waarmee de burger zelf inzicht kan krijgen in problemen en deze zelfstandig kan aanpakken om de zelfredzaamheid van burgers te vergroten. We noemen dit preventie voor de burger. +2. We zorgen ervoor dat burgers inzicht en invloed hebben op hun situatie, de status en betrokkenen in de samenwerking én op de hulp die wij bieden. Zo komen de burger en diens behoeften centraal te staan en houdt de burger de regie over diens leven of kan die terugpakken. We noemen dit transparantie voor de burger. +3. We zorgen dat burgers en professionals vanuit totaaloverzicht van de behoeften van het gezin kunnen onderzoeken, beslissen en handelen, zodat aan de echte oorzaken wordt gewerkt en in de juiste volgorde. Op basis van een gezamenlijk en integrale informatiepositie en taxatie/diagnose/analyse over het gezin te komen tot een gezamenlijk besluit en plan wat ook daadwerkelijk gecoördineerd wordt uitgevoerd door alle deelnemers. diff --git a/_config.yml b/_config.yml index f4c1c9c7a2..12d2bd6937 100644 --- a/_config.yml +++ b/_config.yml @@ -1,16 +1,16 @@ # Configurations -title: Jekyll Gitbook -longtitle: Jekyll Gitbook -author: HE Tao -email: sighingnow@gmail.com +title: Afsprakenstelsel +longtitle: Het Jeugd Zorg en Veiligheid Afsprakenstelsel +author: lg +email: 234217824+samen-onder-handbereik@users.noreply.github.com description: > - Build Jekyll site with the GitBook style. + Samen onder Handbereik - Netwerksamenwerking onder de vingertoppen. Het Jeugd Zorg en Veiligheid Afsprakenstelsel version: 1.0 gitbook_version: 3.2.3 -url: 'https://sighingnow.github.io' -baseurl: '/jekyll-gitbook' +url: 'https://samen-onder-handbereik.github.io' +baseurl: '/afsprakenstelsel' rss: RSS # bootstrap: use the remote theme for the site itself diff --git a/_others/about.md b/_others/about.md deleted file mode 100644 index b02e0f1612..0000000000 --- a/_others/about.md +++ /dev/null @@ -1,9 +0,0 @@ ---- -title: About others -author: Tao He -date: 2022-02-04 -category: Jekyll -layout: post ---- - -This is an about page for "others" in the collections. diff --git a/_others/begrippenkader.md b/_others/begrippenkader.md new file mode 100644 index 0000000000..89a0ccfe6a --- /dev/null +++ b/_others/begrippenkader.md @@ -0,0 +1,359 @@ +--- +title: Begrippenkader +author: lg +date: 2025-09-29 +category: Jekyll +layout: post +--- + +Gegevens ontstaan in de context van een bedrijfsproces. Om die als informatie te kunnen hergebruiken en begrijpen in de samenwerking moeten ze eenduidig en gestructureerd zijn. Uniforme begrippen zijn daarvoor onontbeerlijk. Dat gaat verder dan een woordenlijst: het gaat om de relaties tussen begrippen, op het niveau van professionals en in technische woordenboek. De gegevens moeten altijd gestructureerd zijn, d.w.z. goed gedefinieerd en getypeerd. + +We hanteert als uitgangspunt dat we concepten modelleren voor een informatiecontext. De andere contexten zijn onderdeel van het model. Voorbeelden van een informatiecontext zijn zorg, veiligheid, financieel. De informatiecontext vormt het kader waarvoor we de ontologie ontwikkelen. Dat zorgt ervoor dat we grenzen stellen aan wat we modelleren. Maar ook dat we modelleren wat bij elkaar hoort. Maar de grens goed bepalen is complex. We zullen daarin moeten leren en moeten kunnen veranderen. + +- Er moeten afspraken zijn over de betekenisloze aanduiding van deze objecten en wie die toekent. Bijvoorbeeld: unieke aanduidingen voor Gezin, Casus, Casusoverleg, Plan en Interventie. +- Gegevens in de keten moeten worden gestructureerd in de vorm van identificeerbare informatie-objecten die op verschillende manieren benaderd en gecombineerd kunnen worden. Dit vereist ook een identificatie- en nummerstelsel. +- Data en begrippen moeten “machineleesbaar” zijn. + +![Alt text]({{ site.baseurl }}/assets/metronew1.png) + +Semantisch model +------------- + +> ##### Consultatie +{: .block-warning } + +In een keten met veel verschillende partijen en diverse samenwerkfuncties is een gemeenschappelijke taal belangrijk. Er kunnen hier verschillende benaderingen worden gevolgd: +1. De aanbieder bepaalt het model van de eigen aanleveringen en voorziet deze van context en betekenis. Alle afnemers vertalen het model van de aanbieder naar het eigen model en zorgen daarbij dat ze de betekenis en context goed doorgronden. Dit model is ongeschikt voor deze keten gelet het type organisaties, het aantal daarvan en verschillen daartussen. In een andere context kan dit model overigens zeer geschikt zijn. +2. Er wordt onderscheid gemaakt in verschillende domeinen binnen de keten. Elk domein volgt het eigen semantisch model en biedt vanuit daar aan en in lijn daarmee. Alle afnemers vertalen het model van de aanbieder naar het eigen model en zorgen daarbij dat ze de betekenis en context goed doorgronden. Dit model kent dezelfde nadelen als voorgaande model in de geldende context, zij het in een minder zware vorm. +3. Alle partijen volgen het keten Informatiemodel en passen dat toe in keten-API’s en in het keten event datamodel. Deze benadering past goed bij ketens met veel verschillende partijen en in situaties waar nog veel API’s ontwikkelt moeten worden. + +Binnen het Jeugd, Zorg en Veiligheiddomein wordt het Metamodel voor Informatiemodellering (MIM) gehanteerd en beheerd als kader voor het opstellen van informatiemodellen. Het MIM bevat duidelijke afspraken over het vastleggen van gegevensspecificaties en biedt tegelijkertijd ruimte aan de verschillende niveaus van modellering. + +Voor de begrippen, conceptuele informatiemodellen, logische gegevensmodellen en technische uitwisselmodellen ontwikkelen we een gegevensarchitectuur jeugd, zorg en veiligheid. Waarbij aansluiting is gezocht met het gemeenschappelijk gegevensmodel (GGM) van de VNG (voor het gemeentedomein/BZK) door wijzigingsvoorstellen in te dienen voor ontbrekende concepten zoals gezin/huishouden, zorgmelding, ketenpartner/professional en casusoverleg. Zo groeit een gezamenlijk modellenkader voor het sociaal domein. Ook verkennen we de mapping met de informatiemodellen/Zibbs vanuit Nictiz (voor het zorgdomein/VWS). + + + +Begrippen +------------- + +> ##### Consultatie +{: .block-warning } + + +### Adres + +| voorkeursterm | definitie | heeft bron | alternatieve term | toelichting | +| --- | --- | --- | --- | --- | +| Adres | Adres is een fysieke of administratieve locatie waar een persoon of organisatie gevestigd is of waar communicatie kan worden ontvangen. | O.a. W3C Address definitie, Stelselcatalogus | | | + +### Advies + +| voorkeursterm | definitie | heeft bron | alternatieve term | toelichting | +| --- | --- | --- | --- | --- | +| Advies | Een Advies is de combinatie en samenvatting van een Analyse en aanbeveling met onderbouwing als input voor een te nemen Beslissing | | | | + +### Besluit + +| voorkeursterm | definitie | heeft bron | alternatieve term | toelichting | +| --- | --- | --- | --- | --- | +| Besluit | Een na overweging of beraadslaging vastgestelde beslissing van een overheidsorgaan voor een individueel of concreet geval. | Gemma bedrijfsobject | Beschikking, Beslissing | Een Beslissing is een formele keuze voor wat er moet gebeuren, inclusief voorwaarden, wijze van uitvoering, genomen door een bevoegde rol/beslissende instantie op een bepaald tijdstip, van kracht vanaf een bepaald moment | + +### Bestand + +| voorkeursterm | definitie | heeft bron | alternatieve term | toelichting | +| --- | --- | --- | --- | --- | +| Bestand | Een Bestand is de fysiek vorm waarin een document, bewijs, afbeelding, verwijzing, bestand of geluidsfragment digitaal is opgeslagen. | | | | + +### Casusoverleg + +| voorkeursterm | definitie | heeft bron | alternatieve term | toelichting | +| --- | --- | --- | --- | --- | +| Casusoverleg | Een Casusoverleg is een periodiek beraad waarbij meerdere bij de Casus betrokken ketenpartners in een Samenwerking samenwerken: tot Integrale Analyse, Beslissing (bijv. wie wordt CasusRegisseur) en contouren van een Integraal Plan komen. | | | | + +### Check op Bekendheid + +| voorkeursterm | definitie | heeft bron | alternatieve term | toelichting | +| --- | --- | --- | --- | --- | +| Check op Bekendheid | Een Check op Bekendheid is het beantwoorden van de vraag door een instantie, veelal op verzoek, of ze haar taak heeft verricht c.q. diensten heeft verleend aan de in het verzoek benoemde persoon | | | | + +### Clientondersteuner + +| voorkeursterm | definitie | heeft bron | alternatieve term | toelichting | +| --- | --- | --- | --- | --- | +| Clientondersteuner | Een Clientondersteuner is een persoon met met informatie, advies, algemene ondersteuning en (zorg)bemiddelingop het gebied van maatschappelijke ondersteuning, preventieve zorg, zorg, jeugdhulp, onderwijs, welzijn, wonen, werk en inkomen die bijdraagt aan het versterken van de zelfredzaamheid en participatie en het verkrijgen van een zo integraal mogelijke dienstverlening | WMO, WLZ | | | + +### Contact + +| voorkeursterm | definitie | heeft bron | alternatieve term | toelichting | +| --- | --- | --- | --- | --- | +| Contact | Een contact is een interactie tussen een burger en medewerker/organisatie in het kader van een zaak. Dit kunnen bezoeken of niet fysieke interacties zijn.Het betreft historische en toekomstige contacten. | Nictiz Zib | Klantcontact | | + +### Dienst + +| voorkeursterm | definitie | heeft bron | alternatieve term | toelichting | +| --- | --- | --- | --- | --- | +| Dienst | Middel om services/maatregelen in te vullen, Het uitvoeren van werkzaamheden met een continu of periodiek karakter om waarde te realiseren voor een afnemer. | Gemma bedrijfsobject | Voorziening | | + +### Document + +| voorkeursterm | definitie | heeft bron | alternatieve term | toelichting | +| --- | --- | --- | --- | --- | +| Document | Geheel van gegevens met een eigen identiteit ongeacht zijn vorm, met de bijbehorende metadata ontvangen of opgemaakt door een natuurlijke en/of rechtspersoon bij de uitvoering van taken, zijnde een ENKELVOUDIG DOCUMENT of een SAMENGESTELD DOCUMENT. | Model Kern RGBZ | | | + +### Doel + +| voorkeursterm | definitie | heeft bron | alternatieve term | toelichting | +| --- | --- | --- | --- | --- | +| Doel | Een doel is een op korte of middelllange termijn nagestreefde, beoogde situatie of resultaat | Gemma bedrijfsobject | | | + +### Dossier + +| voorkeursterm | definitie | heeft bron | alternatieve term | toelichting | +| --- | --- | --- | --- | --- | +| Dossier | Een Dossier is een bundeling van papieren en digitale informatieprodukten en gegevens die gaan over een Persoon of Gezin en een Casus. | Gemma Bedrijfsobject | | | + +### Eigen bijdrage + +| voorkeursterm | definitie | heeft bron | alternatieve term | toelichting | +| --- | --- | --- | --- | --- | +| Eigen bijdrage | Een eigen bijdrage is de financiele of anderszins waarde die de burger moet toevoegen in de samenwerking | Gemma bedrijfsobject | Tegenprestatie | | + +### Familiale Relatie + +| voorkeursterm | definitie | heeft bron | alternatieve term | toelichting | +| --- | --- | --- | --- | --- | +| Familiale Relatie | Een relatie is een aanduiding van een familierechtelijke betrekking of een sociale betrekking tussen personen | Artikel 1:179 BW | gezagsrelatie, | | + +### Gemachtigde + +| voorkeursterm | definitie | heeft bron | alternatieve term | toelichting | +| --- | --- | --- | --- | --- | +| Gemachtigde | Een gemachtigde is een Natuurlijk Persoon of een Niet Natuurlijk Persoon die als vertegenwoordiger of als bijstand van een burger optreedt. | AWB artikel 8:24 | | | + +### Huishouden + +| voorkeursterm | definitie | heeft bron | alternatieve term | toelichting | +| --- | --- | --- | --- | --- | +| Huishouden | Persoon of groep personen die een huishouden voert waarbij sprake is van een onderlinge verbondenheid en continuiteit in de samenstelling ervan, die binnen een woning duurzaam gebruik maakt van dezelfde voorzieningen. | Gemma bedrijfsobject, Nictiz Zib | Gezin, Gezinssituatie | Traditioneel is een gezin gedefinieerd als een leefverband van een of meer volwassenen die verantwoordelijkheid dragen voor de verzorging en de opvoeding van een of meer kinderen. Tegenwoordig wordt de term breder gebruikt voor alle samenlevingsvormen die een herkenbare sociale eenheid vormen, met al dan niet verwante personen die duurzame en affectieve banden hebben en elkaar onderling steun en verzorging verlenen. | + +### Incident + +| voorkeursterm | definitie | heeft bron | alternatieve term | toelichting | +| --- | --- | --- | --- | --- | +| Incident | Een Incident is een onverwachte verstorende of gevaar opleverende gedraging of gebeurtenis | | | | + +### Informering + +| voorkeursterm | definitie | heeft bron | alternatieve term | toelichting | +| --- | --- | --- | --- | --- | +| Informering | Het informeren van de burger in het gedwongen kader | Gemma bedrijfsobject | | | + +### Instrument + +| voorkeursterm | definitie | heeft bron | alternatieve term | toelichting | +| --- | --- | --- | --- | --- | +| Instrument | Een Instrument is een meetmethodiek, vaak aangereikt vanuit de wetenschap, waarmee zinvol een bepaalde analyse en conclusie kunnen worden bereikt, vaak door te categoriseren, te kwantificeren. | | | Een geordend systeem of vragenlijst waarbij aan elf domeinen van het dagelijks leven (zoals inkomen en dagbesteding; zie figuur) een waarde voor zelfredzaamheid wordt toegekend. Bijv. Zelfredzaamheidmatrix | + +### Interventie + +| voorkeursterm | definitie | heeft bron | alternatieve term | toelichting | +| --- | --- | --- | --- | --- | +| Interventie | Een Interventie is een actie om een zorgelijke situatie af te wenden door een Medewerker van een Instantie gericht op een bepaald Resultaat of Doel | Gemma bedrijfsobject | Crisisinterventie, | | + +### Klacht + +| voorkeursterm | definitie | heeft bron | alternatieve term | toelichting | +| --- | --- | --- | --- | --- | +| Klacht | Een Klacht is een formele melding van ontevredenheid t.a.v. de gedraging van of dienstverlening aan een Persoon door een Medewerker of Instantie | Algemene wet bestuursrecht hoofdstuk 9. | | | + +### Leefgebied + +| voorkeursterm | definitie | heeft bron | alternatieve term | toelichting | +| --- | --- | --- | --- | --- | +| Leefgebied | Een Leefgebied is een deelgebied van het Sociaal Domein, een maatschappelijk veld waarop Personen problematiek kunnen ervaren zoals wonen, financien, inburgering, participatie, onderwijs, werk | Gemma bedrijfsobject, | Domein, Subdomein, Sector, Taakveld | Het is ook de verzameling van werkzaamheden, gericht op de productie van bepaalde goederen en diensten. Het gaat hierbij niet alleen om activiteiten van het bedrijfsleven, maar ook om activiteiten van niet op winst gerichte instellingen en de overheid. Kennisgebied of activiteit gekarakteriseerd door een verzameling van concepten, begrippen en/of waarden | + +### Levering + +| voorkeursterm | definitie | heeft bron | alternatieve term | toelichting | +| --- | --- | --- | --- | --- | +| Levering | Levering van ondersteuning of zorg | Gemma bedrijfsobject | | | + +### Medewerker + +| voorkeursterm | definitie | heeft bron | alternatieve term | toelichting | +| --- | --- | --- | --- | --- | +| Medewerker | Een Medewerker is diegene die krachtens een arbeidsovereenkomst naar Nederlands recht werkzaam is bij een Organisatie, die bevoegd is handelingen uit te voeren op het gebied van haar functie | Ambtenarenwet 2017, Gemma bedrijfsobject, Nictiz Zib | Professional, Zorgverlener (Zib) | | + +### Melding + +| voorkeursterm | definitie | heeft bron | alternatieve term | toelichting | +| --- | --- | --- | --- | --- | +| Melding | Een melding is een officiele verstrekking van informatie waarin zorgen worden geuit over de veiligheid, gezondheid of ontwikkeling met betrekking tot een burger of gezin | | Zorgmelding | Deze melding kan worden gedaan door professionals, zoals leraren, huisartsen of politie, maar ook door burgers of familieleden. Een zorgmelding bevat signalen of concrete aanwijzingen van mogelijke risico’s, zoals mishandeling, verwaarlozing, huiselijk geweld, of een onveilige thuissituatie. Het doel van een zorgmelding is om de situatie te laten beoordelen en, indien nodig, passende hulp of bescherming te organiseren om het welzijn van het kind of de jongere te waarborgen. | + +### Natuurlijk persoon + +| voorkeursterm | definitie | heeft bron | alternatieve term | toelichting | +| --- | --- | --- | --- | --- | +| Natuurlijk persoon | Een Natuurlijk persoon is ingeschreven persoon of ander natuurlijk persoon, een mens van vlees en bloed, die drager kan zijn van rechten en plichten en rechtshandelingen kan verrichten en gebruik kan maken van producten en diensten | Artikel32 BW (Boek 3), Gemma Bedrijfsobject, Nictiz Zib | Burger, Ingeschreven Persoon, Client, Patient | | + +### Onderzoek + +| voorkeursterm | definitie | heeft bron | alternatieve term | toelichting | +| --- | --- | --- | --- | --- | +| Onderzoek | Een onderzoek is de activiteit met als doel om tot een Taxatie of Analyse van een situatie te komen. | | | | + +### Opdracht + +| voorkeursterm | definitie | heeft bron | alternatieve term | toelichting | +| --- | --- | --- | --- | --- | +| Opdracht | Een Opdracht is het expliciete verzoek aan een Instantie of Persoon in een rol (bijv. Casusregisseur) om een Beslissing uit te voeren, vaak op basis van een Plan. | | | | + +### Organisatie + +| voorkeursterm | definitie | heeft bron | alternatieve term | toelichting | +| --- | --- | --- | --- | --- | +| Organisatie | Een Organisatie is een instelling of instantie die werkzaamheden uitvoert op het gebied van het sociaal domein of aanpalende domeinen. | Gemma bedrijfsobject, Nictiz Zib | Instantie, Zorgaanbieder (Zib) | | + +### Organisatorische eenheid + +| voorkeursterm | definitie | heeft bron | alternatieve term | toelichting | +| --- | --- | --- | --- | --- | +| Organisatorische eenheid | Het deel van een functioneel afgebakend onderdeel binnen de organisatie dat haar activiteiten uitvoert binnen een VESTIGING VAN ZAAKBEHANDELENDE ORGANISATIE en die verantwoordelijk is voor de behandeling van zaken.. | Model Kern RGBZ, Nictiz Zib | Team, Zorgteam | | + +### Plan + +| voorkeursterm | definitie | heeft bron | alternatieve term | toelichting | +| --- | --- | --- | --- | --- | +| Plan | Een plan is een schriftelijk document waarin de zorg- of ondersteuningsbehoefte van een burger wordt vastgelegd, inclusief de afspraken over de zorgverlening | WMO, WLZ, Gemma bedrijfsobject | Zorgplan, Ondersteuningsplan | | + +### Product + +| voorkeursterm | definitie | heeft bron | alternatieve term | toelichting | +| --- | --- | --- | --- | --- | +| Product | Het resultaat van een proces dat in het economisch verkeer een waarde bezit. | Gemma Bedrijfsobject | | | + +### Profiel + +| voorkeursterm | definitie | heeft bron | alternatieve term | toelichting | +| --- | --- | --- | --- | --- | +| Profiel | Combinatie van kenmerken die samen de sociale en economische omstandigheden van een individu bepalen. | Gemma bedrijfsobject, Nictiz Zib | Leefsituatie, Patienten context, bijv. taalvaardigheid, middelengebruik, woonsituatie, nationaliteit, etc. | | + +### Regeling + +| voorkeursterm | definitie | heeft bron | alternatieve term | toelichting | +| --- | --- | --- | --- | --- | +| Regeling | De regeling is het wettelijk kader als de juridische context of het handelingskader als afgesproken en geformaliseerde handeling waar binnen een zaak wordt besproken of een interventie wordt uitgevoerd. | Gemma bedrijfsobject | Wettelijk kader, handelingskader | Verzamelnaam voor AMvB’s, Ministeriële regelingen, lokale verordeningen, convenanten, etc. De regeling is de meest concrete uitleg van de wet. | + +### Regio + +| voorkeursterm | definitie | heeft bron | alternatieve term | toelichting | +| --- | --- | --- | --- | --- | +| Regio | Een Regio is een bepaald gebied in de geografische indeling van Nederland, vaak als fysieke grenzen van een Samenwerking. | Gemma bedrijfsobject | Buurt, Wijk, Provincie | | + +### Resultaat + +| voorkeursterm | definitie | heeft bron | alternatieve term | toelichting | +| --- | --- | --- | --- | --- | +| Resultaat | De uitkomst van iets, bijvoorbeeld een berekening of een onderzoek. een gevolg. | Gemma bedrijfsobject | | | + +### Rol + +| voorkeursterm | definitie | heeft bron | alternatieve term | toelichting | +| --- | --- | --- | --- | --- | +| Rol | Een samenhangende set van taken, bevoegdheden en verantwoordelijkheden | Gemma bedrijfsobject | Functie | Een functie kan worden gedefinieerd als het samenstel van feitelijk opgedragen taken en werkzaamheden, formeler dus | + +### Samenwerking + +| voorkeursterm | definitie | heeft bron | alternatieve term | toelichting | +| --- | --- | --- | --- | --- | +| Samenwerking | Een Samenwerking is een afspraak/convenant en werkwijze/ketenproces tussen een groep Instanties, gericht op een bepaald Resultaat/Doel op zowel regionaal en casusniveau, bijv. in de vorm van een casusoverleg en casusregie. | | | | + +### Score + +| voorkeursterm | definitie | heeft bron | alternatieve term | toelichting | +| --- | --- | --- | --- | --- | +| Score | Een Score is de samenvattende, kwantitatieve conclusie van het gebruik van een wetenschappelijk Instrument voor een Persoon op een bepaald moment aan de hand van vragen/criteria op verschillende aspecten (bijvoorbeeld leefgebieden) en een schaal met eventueel een weging. | Gemma bedrijfsobject | | | + +### Sociale Groep + +| voorkeursterm | definitie | heeft bron | alternatieve term | toelichting | +| --- | --- | --- | --- | --- | +| Sociale Groep | Een sociale groep is een verzameling van twee of meer individuen die met elkaar interacteren, gemeenschappelijke waarden, normen of doelen delen, en een gevoel van saamhorigheid of identiteit hebben. S | Gemma bedrijfsobject | Jeugdgroep | Sociale groepen kunnen variëren in omvang en structuur, van kleine, informele groepen zoals een gezin of vriendengroep tot grote, formele organisaties zoals verenigingen of professionele netwerken. Het lidmaatschap van een sociale groep beïnvloedt vaak het gedrag en de sociale interacties van de leden en speelt een belangrijke rol in de vorming van persoonlijke en sociale identiteiten. | + +### Sociale Relatie + +| voorkeursterm | definitie | heeft bron | alternatieve term | toelichting | +| --- | --- | --- | --- | --- | +| Sociale Relatie | Een sociale relatie is een duurzame en wederzijdse verbinding tussen twee of meer individuen, gebaseerd op interactie, communicatie en sociale normen. | | | Sociale relaties kunnen verschillende vormen aannemen, zoals persoonlijke (bijvoorbeeld vriendschappen of familiebanden), professionele (zoals collega’s of werkgever-werknemer) of maatschappelijke relaties (bijvoorbeeld tussen buren of leden van een gemeenschap). Ze worden gekenmerkt door wederzijdse verwachtingen en beïnvloeden vaak het gedrag, de gevoelens en de sociale positie van de betrokken personen. Sociale relaties spelen een cruciale rol in het opbouwen van sociale netwerken en het functioneren van samenlevingen. | + +### Status + +| voorkeursterm | definitie | heeft bron | alternatieve term | toelichting | +| --- | --- | --- | --- | --- | +| Status | Een aanduiding van de stand van zaken | Gemma bedrijfsobject | | | + +### Taak + +| voorkeursterm | definitie | heeft bron | alternatieve term | toelichting | +| --- | --- | --- | --- | --- | +| Taak | Een samenhangende set activiteiten | Gemma bedrijfsobject | | | + +### Taxatie + +| voorkeursterm | definitie | heeft bron | alternatieve term | toelichting | +| --- | --- | --- | --- | --- | +| Taxatie | Een Taxatie is het resultaat van de toepassing van een (taxatie) instrument, om de ernst van de situatie van een persoon (qua risico’s op verslechtering) systematisch in kaart te brengen, met als doel mogelijke/benodigde Interventies te bepalen. | | | | + +### Traject + +| voorkeursterm | definitie | heeft bron | alternatieve term | toelichting | +| --- | --- | --- | --- | --- | +| Traject | Samenstel van achtereenvolgens uit te voeren en onderling samenhangende zaken of van opeenvolgende stadia in een PDCA cyclus, voorgesteld als een route die via opeenvolgende bestemmingen naar de eindbestemming voert. | Gemma bedrijfsobject | | | + +### Triage + +| voorkeursterm | definitie | heeft bron | alternatieve term | toelichting | +| --- | --- | --- | --- | --- | +| Triage | Een Triage is de toepassing van een (selectie en screenings)Instrument, om de ernst van de situatie van een Persoon (qua problematiek, risico's, kansen) systematisch in kaart te brengen, met als doel het kunnen beoordelen, wegen en besluiten of en welke prioriteit en vervolg de situatie krijgt. | | | | + +### Uitnodiging + +| voorkeursterm | definitie | heeft bron | alternatieve term | toelichting | +| --- | --- | --- | --- | --- | +| Uitnodiging | Een Uitnodiging is een uitnodiging aan een Persoon of Instantie om deel te nemen aan een Casusoverleg. Het beschrijft wanneer en waar het overleg is, wat er besproken wordt en welk resultaat het overleg nastreeft. Ze is al dan niet formeel. | Gemma bedrijfsobject | Oproep | | + +### Verklarende Analyse + +| voorkeursterm | definitie | heeft bron | alternatieve term | toelichting | +| --- | --- | --- | --- | --- | +| Verklarende Analyse | Een Verklarende Analyse is het resultaat van een onderzoek, vaak middels een (analyse) Instrument naar de oorzaak van problemen van een persoon met als doel mogeljke/benodigde Interventies te bepalen. | | | | + +### Verrijking + +| voorkeursterm | definitie | heeft bron | alternatieve term | toelichting | +| --- | --- | --- | --- | --- | +| Verrijking | Een Verrijking is het beschikbaar maken van een (nieuwe) verzameling informatie over een persoon, veelal op verzoek, voor triage, taxatie en analyse doeleinden | | | | + +### Verzoek + +| voorkeursterm | definitie | heeft bron | alternatieve term | toelichting | +| --- | --- | --- | --- | --- | +| Verzoek | Een Verzoek is een vraag aan het bevoegd gezag om een speficieke product of dienst te leveren. | AWB artikel 9:28 | | | + +### Zaak + +| voorkeursterm | definitie | heeft bron | alternatieve term | toelichting | +| --- | --- | --- | --- | --- | +| Zaak | Een samenhangende hoeveelheid werk met een welgedefinieerde aanleiding en een welgedefinieerd eindresultaat, waarvan kwaliteit en doorlooptijd bewaakt moeten worden. | Model Kern RGBZ | | | + +### Zienswijze + +| voorkeursterm | definitie | heeft bron | alternatieve term | toelichting | +| --- | --- | --- | --- | --- | +| Zienswijze | Een Zienswijze is input, feedback of een verklaring van een Persoon m.b.t. diens situatie of als reactie op processtappen, besluiten of produkten van Medewerkers van Instanties | Algemene wet bestuursrecht hoofdstuk 3. | | | + +### Zorgelijke situatie + +| voorkeursterm | definitie | heeft bron | alternatieve term | toelichting | +| --- | --- | --- | --- | --- | +| Zorgelijke situatie | Een zorgelijke situatie is een omstandigheid waarin de veiligheid, gezondheid of ontwikkeling van burger en diens gezin in het geding is. | Gemma bedrijfsobject | | | diff --git a/_others/license.md b/_others/license.md new file mode 100644 index 0000000000..dc5723daa0 --- /dev/null +++ b/_others/license.md @@ -0,0 +1,11 @@ +--- +title: License +author: lg +date: 2025-09-29 +category: Jekyll +layout: post +--- + +Dit werk (document /website), samen onder handbereik - afsprakenstelsel, valt onder de volgende licentie: Creative Commons 4.0 Internationaal licentie (CC BY 4.0). Zie [Creative Commons 4.0][1]. + +[1]: https://creativecommons.org/licenses/by/4.0/legalcode diff --git a/_others/versie.md b/_others/versie.md new file mode 100644 index 0000000000..ef3a60efdf --- /dev/null +++ b/_others/versie.md @@ -0,0 +1,15 @@ +--- +title: Versie +author: lg +date: 2025-10-27 +category: Jekyll +layout: post +--- + +Huidige versie: 0.1.0 + +| Versie | Datum | Omschrijving | +| --- | --- | --- | +| 0.1.0 | 06-10-2025 | Initiële versie gepresenteerd op JZV architectuuroverleg 6 oktober 2025 | +| | | | +| | | | diff --git a/_pages/about.md b/_pages/about.md deleted file mode 100644 index 1c621d403e..0000000000 --- a/_pages/about.md +++ /dev/null @@ -1,9 +0,0 @@ ---- -title: About -author: Tao He -date: 2022-02-04 -category: Jekyll -layout: post ---- - -This is an about page. diff --git a/_pages/contact.md b/_pages/contact.md index a67b8efa73..39e3cd726b 100644 --- a/_pages/contact.md +++ b/_pages/contact.md @@ -1,9 +1,62 @@ --- title: Contact -author: Tao He -date: 2022-02-05 +author: lg +date: 2025-09-30 category: Jekyll layout: post --- -This is an contact page. +Contactgegevens: volgen + +Test1 + + ```python + from google.colab import drive + drive.mount('/content/drive') + ``` + +
▶ Click to show answerCorrect Answer: A
+ +Test1a + + ```python + from google.colab import drive + drive.mount('/content/drive') + ``` + +
▶ PlantUML +@startuml +skinparam monochrome true +skinparam defaultTextAlignment center + +actor "Client" as Client +rectangle "Autorisatieserver" as AuthServer +rectangle "Policy Administration Point\n(PAP)" as PAP +rectangle "Policy Retrieval Point\n(PRP)" as PRP +rectangle "Policy Decision Point\n(PDP)" as PDP +rectangle "Policy Information Point\n(PIP)" as PIP + +rectangle "Policy Enforcement Point\n(PEP)" as PEP +database "Data Toegangspunt\n(Resource-Server)" as DataAccess + +Client -up-> AuthServer : "Tokenaanvraag" +AuthServer -down-> Client : "JWT Access-token" + +Client -right-> PEP : "Toegangsverzoek\n(REST/GraphQL + JWT)" +PEP -left-> Client : "Gevraagde data" + +PEP -right-> DataAccess: "Geautoriseerde data-aanvraag" +DataAccess -left-> PEP : "Gevraagde data" + +PEP -down-> PDP : "Toegangsverzoek" +PDP -up-> PEP : "Toegangsbesluit" + +PDP -right-> PIP : "Contextinformatie opvragen" +PIP -left-> PDP : "Contextinformatie retourneren" + +PDP -down-> PRP : "Beleidsregels ophalen" +PRP -up-> PDP : "Beleidsregels retourneren" + +PAP -up-> PRP: "Beleidsregels beheren" +@enduml +
\ No newline at end of file diff --git a/_pages/design/draft.md b/_pages/design/draft.md index 141e942a35..24368421b0 100644 --- a/_pages/design/draft.md +++ b/_pages/design/draft.md @@ -1,9 +1,100 @@ --- -title: Design Draft -author: Tao He -date: 2022-02-06 +title: Credits +author: lg +date: 2025-09-30 category: Jekyll layout: post --- This is an draft page. + +Test1a + + ```python + from google.colab import drive + drive.mount('/content/drive') + ``` + +Test1b +
▶ Click to show answerCorrect Answer: A
+ + + +Test2 +
+ +
+ + +Test3 +>### tl;dr +>blabla. +{: .block-tip } + +Test4 +>Consider the following data search and collection services: +>* RKGs such as [ORKG](https://orkg.org) or [OpenAIRE Graph](https://graph.openaire.eu) +>* [Papers With Code](https://paperswithcode.com) +>* [Google Dataset Search](https://datasetsearch.research.google.com) +>* [Kaggle](https://www.kaggle.com/datasets) +>* [Hugging Face Datasets](https://huggingface.co/docs/datasets/index) +>* [Awesome Public Datasets](https://github.com/awesomedata/awesome-public-datasets) +>* [Data.world](https://data.world/search?context=community&entryTypeLabel=dataset&type=resources) +>* [ELG](https://live.european-language-grid.eu) +>* Additional useful data collection services are available under *Services Lifecycle* on the [NFDI4DS](https://www.nfdi4datascience.de/services/all/) webpage. + + +PlantUML +Algemeen: +@startuml +skinparam monochrome true +skinparam defaultTextAlignment center + +actor "Client" as Client +rectangle "Autorisatieserver" as AuthServer +rectangle "Policy Administration Point\n(PAP)" as PAP +rectangle "Policy Retrieval Point\n(PRP)" as PRP +rectangle "Policy Decision Point\n(PDP)" as PDP +rectangle "Policy Information Point\n(PIP)" as PIP + +rectangle "Policy Enforcement Point\n(PEP)" as PEP +database "Data Toegangspunt\n(Resource-Server)" as DataAccess + +Client -up-> AuthServer : "Tokenaanvraag" +AuthServer -down-> Client : "JWT Access-token" + +Client -right-> PEP : "Toegangsverzoek\n(REST/GraphQL + JWT)" +PEP -left-> Client : "Gevraagde data" + +PEP -right-> DataAccess: "Geautoriseerde data-aanvraag" +DataAccess -left-> PEP : "Gevraagde data" + +PEP -down-> PDP : "Toegangsverzoek" +PDP -up-> PEP : "Toegangsbesluit" + +PDP -right-> PIP : "Contextinformatie opvragen" +PIP -left-> PDP : "Contextinformatie retourneren" + +PDP -down-> PRP : "Beleidsregels ophalen" +PRP -up-> PDP : "Beleidsregels retourneren" + +PAP -up-> PRP: "Beleidsregels beheren" +@enduml + +Autoriseren: +@startuml +skinparam monochrome true +skinparam defaultTextAlignment center + +actor Client as "Deelnemer (Client)" +participant "Autorisatieserver" as AuthzServer + +Client -> AuthzServer: **1. Aanvragen van autorisatie**\n(scope, authenticatiemiddel) +AuthzServer -> AuthzServer: **2. Valideer authenticatiemiddel** +AuthzServer -> AuthzServer: **3. Beoordeel scope**\n(beleidsregels) +AuthzServer -> AuthzServer: **4. Controleer audience** +AuthzServer --> Client: **5. Genereer en retourneer**\n(access token) +Client <-[#red]-X AuthzServer: **6. Foutmeldingen**\n(400/403/500) +@enduml diff --git a/_posts/2019-04-27-why.md b/_posts/2019-04-27-why.md deleted file mode 100644 index 81af6b7b61..0000000000 --- a/_posts/2019-04-27-why.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: Why Jekyll with GitBook -author: Tao He -date: 2019-04-27 -category: Jekyll -layout: post ---- - -GitBook is an amazing frontend style to present and organize contents (such as book chapters -and blogs) on Web. The typical to deploy GitBook at [Github Pages][1] -is building HTML files locally and then push to Github repository, usually to the `gh-pages` -branch. However, it's quite annoying to repeat such workload and make it hard for people do -version control via git for when there are generated HTML files to be staged in and out. - -This theme takes style definition out of generated GitBook site and provided the template -for Jekyll to rendering markdown documents to HTML, thus the whole site can be deployed -to [Github Pages][1] without generating and uploading HTML bundle every time when there are -changes to the original repository. - -[1]: https://pages.github.com \ No newline at end of file diff --git a/_posts/2019-04-28-howto.md b/_posts/2019-04-28-howto.md deleted file mode 100644 index d1e9750fb1..0000000000 --- a/_posts/2019-04-28-howto.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: How to Get Started -author: Tao He -date: 2019-04-28 -category: Jekyll -layout: post ---- - -The jekyll-gitbook theme can be used just as other [Jekyll themes][3] and -support [remote theme][2] on [Github Pages][1], see [the official guide][4] -as well. - -You can introduce this jekyll theme into your own site by either - -- [Fork][5] this repository and add your markdown posts to the `_posts` folder, then - push to your own Github repository. -- Use as a remote theme in your [`_config.yml`][6](just like what we do for this - site itself), - -```yaml -# Configurations -title: Jekyll Gitbook -longtitle: Jekyll Gitbook - -remote_theme: sighingnow/jekyll-gitbook -``` - -> ##### TIP -> -> No need to push generated HTML bundle. -{: .block-tip } - -[1]: https://pages.github.com -[2]: https://github.com/sighingnow/jekyll-gitbook/fork -[3]: https://pages.github.com/themes -[4]: https://docs.github.com/en/pages/setting-up-a-github-pages-site-with-jekyll/adding-a-theme-to-your-github-pages-site-using-jekyll -[5]: https://github.com/sighingnow/jekyll-gitbook/fork -[6]: https://github.com/sighingnow/jekyll-gitbook/blob/master/_config.yml diff --git a/_posts/2019-04-29-license.md b/_posts/2019-04-29-license.md deleted file mode 100644 index 793e52a6ee..0000000000 --- a/_posts/2019-04-29-license.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -title: License -author: Tao He -date: 2019-04-29 -category: Jekyll -layout: post ---- - -This work is open sourced under the Apache License, Version 2.0, using the -same license as the original [GitBook](https://github.com/GitbookIO/gitbook) repository. - -Copyright 2019 Tao He. diff --git a/_posts/2021-08-10-toc.md b/_posts/2021-08-10-toc.md deleted file mode 100644 index 6ad1f81967..0000000000 --- a/_posts/2021-08-10-toc.md +++ /dev/null @@ -1,176 +0,0 @@ ---- -title: How to Generate TOC -author: Tao He -date: 2021-08-10 -category: Jekyll -layout: post ---- - -The jekyll-gitbook theme leverages [jekyll-toc][1] to generate the *Contents* for the page. -The TOC feature is not enabled by default. To use the TOC feature, modify the TOC -configuration in `_config.yml`: - -```yaml -toc: - enabled: true -``` - -Why this repo -------------- - -long contents ..... - -1. a -2. b -3. c -4. d - -### Sub title 1 - -### Sub title 2 - -### Sub title 3 - -Why this repo -------------- - -long contents ..... - -+ 1 -+ 2 -+ 3 -+ 4 - -Why this repo -------------- - -long contents ..... - -1. e -2. f -3. g -4. h - -Why this repo -------------- - -+ 5 -+ 6 -+ 7 -+ 8 - -Why this repo -------------- - -long contents ..... - -1. a -2. b -3. c -4. d - -Why this repo -------------- - -long contents ..... - -+ 1 -+ 2 -+ 3 -+ 4 - -Why this repo -------------- - -long contents ..... - -1. e -2. f -3. g -4. h - -Why this repo -------------- - -+ 5 -+ 6 -+ 7 -+ 8 - -Why this repo -------------- - -long contents ..... - -1. a -2. b -3. c -4. d - -Why this repo -------------- - -long contents ..... - -+ 1 -+ 2 -+ 3 -+ 4 - -Why this repo -------------- - -long contents ..... - -1. e -2. f -3. g -4. h - -Why this repo -------------- - -+ 5 -+ 6 -+ 7 -+ 8 - -Why this repo -------------- - -long contents ..... - -1. a -2. b -3. c -4. d - -Why this repo -------------- - -long contents ..... - -+ 1 -+ 2 -+ 3 -+ 4 - -Why this repo -------------- - -long contents ..... - -1. e -2. f -3. g -4. h - -Why this repo -------------- - -+ 5 -+ 6 -+ 7 -+ 8 - -[1]: https://github.com/allejo/jekyll-toc diff --git a/_posts/2022-05-24-page_cover.md b/_posts/2022-05-24-page_cover.md deleted file mode 100644 index 44a57e2fbe..0000000000 --- a/_posts/2022-05-24-page_cover.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: Page with cover image -author: Tao He -date: 2022-05-24 -category: Jekyll -layout: post -cover: https://sighingnow.github.io/jekyll-gitbook/assets/dinosaur.gif ---- - -The jekyll-gitbook theme supports adding a cover image to a specific page by adding -a `cover` field to the page metadata: - -```diff - --- - title: Page with cover image - author: Tao He - date: 2022-05-24 - category: Jekyll - layout: post -+ cover: /assets/jekyll-gitbook/dinosaur.gif - --- -``` diff --git a/_posts/2022-06-26-wide_tables.md b/_posts/2022-06-26-wide_tables.md deleted file mode 100644 index 9693b161ea..0000000000 --- a/_posts/2022-06-26-wide_tables.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: Wide tables -author: Tao He -date: 2022-06-26 -category: Jekyll -layout: post ---- - -A wide tables needs to be wrapped into a `div` with class `table-wrapper` -to make sure it displayed as expected on mobile devices. For example, - -```markdown -
- -|title1|title2|title3|title4|title5|title6|title7|title8| -|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:| -|1|2|3|4|5|6|7|8| -|1|2|3|4|5|6|7|8| -|1|2|3|4|5|6|7|8| -|1|2|3|4|5|6|7|8| - -
-``` - -Will be rendered as - -
- -|title1|title2|title3|title4|title5|title6|title7|title8| -|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:| -|1|2|3|4|5|6|7|8| -|1|2|3|4|5|6|7|8| -|1|2|3|4|5|6|7|8| -|1|2|3|4|5|6|7|8| - -
diff --git a/_posts/2022-06-30-tips_warnings_dangers.md b/_posts/2022-06-30-tips_warnings_dangers.md deleted file mode 100644 index 0dfb55d1f6..0000000000 --- a/_posts/2022-06-30-tips_warnings_dangers.md +++ /dev/null @@ -1,67 +0,0 @@ ---- -title: Tips, Warnings, and Dangers -author: Tao He -date: 2022-06-30 -category: Jekyll -layout: post ---- - -This jekyll-theme supports tips, warnings, and dangers blocks and the style is referred -from [the discord.js website][1]. - -You could have the following [markdown attributes (supported by kramdown)][2]: - -### Tips - -Using a `{: .block-tip}` attribute: - -```markdown -> ##### TIP -> -> This guide is last tested with @napi-rs/canvas^0.1.20, so make sure you have -> this or a similar version after installation. -{: .block-tip } -``` - -> ##### TIP -> -> This guide is last tested with @napi-rs/canvas^0.1.20, so make sure you have -> this or a similar version after installation. -{: .block-tip } - -### Warnings - -Using a `{: .block-warning}` attribute: - -```markdown -> ##### WARNING -> -> Be sure that you're familiar with things like async/await and object destructuring -> before continuing, as we'll be making use of features like these. -{: .block-warning } -``` - -> ##### WARNING -> -> Be sure that you're familiar with things like async/await and object destructuring -> before continuing, as we'll be making use of features like these. -{: .block-warning } - -### Dangers - -Using a `{: .block-danger}` attribute: - -```markdown -> ##### DANGER -> -> You cannot delete an ephemeral message. -{: .block-danger } -``` - -> ##### DANGER -> -> You cannot delete an ephemeral message. -{: .block-danger } - -[1]: https://discordjs.guide/popular-topics/canvas.html#setting-up-napi-rs-canvas -[2]: https://kramdown.gettalong.org/quickref.html#block-attributes diff --git a/_posts/2023-08-31-mermaid.md b/_posts/2023-08-31-mermaid.md deleted file mode 100644 index 5aec3057a3..0000000000 --- a/_posts/2023-08-31-mermaid.md +++ /dev/null @@ -1,73 +0,0 @@ ---- -title: Diagrams with mermaid.js -author: Tao He -date: 2023-08-31 -category: Jekyll -layout: post -mermaid: true ---- - -This jekyll-theme supports [mermaid.js](https://mermaid.js.org/) to render diagrams -in markdown. - -To enable the mermaid support, you need to set `mermaid: true` in the front matter -of your post. - -```markdown ---- -title: Diagrams with mermaid.js -date: 2023-08-31 -layout: post -mermaid: true ---- -``` - -Then you can use mermaid syntax in your markdown: - -``` -graph TD; - A-->B; - A-->C; - B-->D; - C-->D; -``` - -```mermaid -graph TD; - A-->B; - A-->C; - B-->D; - C-->D; -``` - -Or, even some complex examples: - -``` -sequenceDiagram - participant Alice - participant Bob - Alice->>John: Hello John, how are you? - loop Healthcheck - John->>John: Fight against hypochondria - end - Note right of John: Rational thoughts
prevail! - John-->>Alice: Great! - John->>Bob: How about you? - Bob-->>John: Jolly good! -``` - -```mermaid -sequenceDiagram - participant Alice - participant Bob - Alice->>John: Hello John, how are you? - loop Healthcheck - John->>John: Fight against hypochondria - end - Note right of John: Rational thoughts
prevail! - John-->>Alice: Great! - John->>Bob: How about you? - Bob-->>John: Jolly good! -``` - -Refer to the [mermaid.js website](https://mermaid.js.org/intro/) for more examples. diff --git a/_posts/2023-10-14-math-latex.md b/_posts/2023-10-14-math-latex.md deleted file mode 100644 index 36a9cd353c..0000000000 --- a/_posts/2023-10-14-math-latex.md +++ /dev/null @@ -1,47 +0,0 @@ ---- -title: MathJax and LaTeX -author: Tao He -date: 2023-10-14 -category: Jekyll -layout: post -mermaid: true ---- - -This jekyll-theme supports [MathJax](https://www.mathjax.org/) to render $\LaTeX$ -and mathematics expressions. - -> ##### TIP -> -> Currently, Kramdown uses double dollar sign delimiters for inline and display math: -> [https://kramdown.gettalong.org/syntax.html#math-blocks](https://kramdown.gettalong.org/syntax.html#math-blocks). -{: .block-tip } - -e.g., - -```markdown -The well known Pythagorean theorem $x^2 + y^2 = z^2$ was -proved to be invalid for other exponents. -Meaning the next equation has no integer solutions: - -$$ x^n + y^n = z^n $$ -``` - -The well known Pythagorean theorem $x^2 + y^2 = z^2$ was -proved to be invalid for other exponents. -Meaning the next equation has no integer solutions: - -$$ x^n + y^n = z^n $$ - -Another example with more complex markups: - -```markdown -When $a \ne 0$, there are two solutions to $ax^2 + bx + c = 0$ and they are - -$$x = {-b \pm \sqrt{b^2-4ac} \over 2a}.$$ -``` - -When $a \ne 0$, there are two solutions to $ax^2 + bx + c = 0$ and they are - -$$x = {-b \pm \sqrt{b^2-4ac} \over 2a}.$$ - -Refer to the [MathJax website](https://docs.mathjax.org/en/latest/index.html) for more examples. diff --git a/_posts/2023-12-12-footnotes.md b/_posts/2023-12-12-footnotes.md deleted file mode 100644 index eae423aff8..0000000000 --- a/_posts/2023-12-12-footnotes.md +++ /dev/null @@ -1,125 +0,0 @@ ---- -title: Using Footnotes -author: Tao He -date: 2023-12-12 -category: Jekyll -layout: post -mermaid: true ---- - -This jekyll-theme supports [MathJax](https://www.mathjax.org/) to render footnotes -in markdown. - -e.g., - -```markdown -The well known Pythagorean theorem $x^2 + y^2 = z^2$ was -proved to be invalid for other exponents[^1]. -Meaning the next equation has no integer solutions: - -$$ x^n + y^n = z^n $$ -``` - -The well known Pythagorean theorem $x^2 + y^2 = z^2$ was -proved to be invalid for other exponents[^1]. -Meaning the next equation has no integer solutions: - -$$ x^n + y^n = z^n $$ - -Long contents -------------- - -long contents ..... - -1. a -2. b -3. c -4. d - -### Sub title 1 - -### Sub title 2 - -### Sub title 3 - -Long contents -------------- - -long contents ..... - -1. a -2. b -3. c -4. d - -### Sub title 1 - -### Sub title 2 - -### Sub title 3 - -Long contents -------------- - -long contents ..... - -1. a -2. b -3. c -4. d - -### Sub title 1 - -### Sub title 2 - -### Sub title 3 - -Long contents -------------- - -long contents ..... - -1. a -2. b -3. c -4. d - -### Sub title 1 - -### Sub title 2 - -### Sub title 3 - -Long contents -------------- - -long contents ..... - -1. a -2. b -3. c -4. d - -### Sub title 1 - -### Sub title 2 - -### Sub title 3 - -Long contents -------------- - -long contents ..... - -1. a -2. b -3. c -4. d - -### Sub title 1 - -### Sub title 2 - -### Sub title 3 - -[^1]: [https://en.wikipedia.org/wiki/Fermat%27s_Last_Theorem](https://en.wikipedia.org/wiki/Fermat%27s_Last_Theorem) diff --git a/_posts/2025-09-22-leeswijzer.md b/_posts/2025-09-22-leeswijzer.md new file mode 100644 index 0000000000..9ba8b3c7a3 --- /dev/null +++ b/_posts/2025-09-22-leeswijzer.md @@ -0,0 +1,23 @@ +--- +title: Leeswijzer +author: lg +date: 2025-09-29 +category: Jekyll +layout: post +--- + +Het afsprakenstelsel is zo opgezet dat elke doelgroep eenvoudig kan navigeren naar relevante informatie. De informatie in het stelsel kan een bepaalde status, zie onderstaande tabel. + +| **Status** | **Omschrijving** | +| ----------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Concept | De betreffende tekst (hoofdstuk of paragraaf) is concept. Er wordt nog over gesproken en de tekst kan nog aanzienlijk wijzigen. | +| Consultatie | De betreffende tekst (hoofdstuk of paragraaf) is reeds besproken en afgestemd, maar nog niet definitief. Er zijn nog wijzigingen mogelijk, deze zullen in de regel niet substantieel van aard zijn. | +| Definitief | De betreffende tekst (hoofdstuk of paragraaf) is vastgesteld en daarmee definitief. De tekst kan alleen nog aangepast worden na besluit tot wijziging. | + +In onderdeel **De werking van het stelsel** wordt achtergrond en doel geschetst. + +Binnen **Onderdeel Principes en standaarden** worden richtinggevende uitspraken gedaan (principes) die de inrichting en ontwikkeling van het jeugd, zorg en veiligheidsstelsel sturen. De genoemde standaarden zijn de standaarden die minimaal toegepast worden in het stelsel. + +Vervolgens zijn is in de onderdelen **Samenwerkfuncties** en **Samenwerkpatronen** een functionele verdieping te vinden. In het onderdeel **Techniek** wordt ingegaan op de ICT technische aspecten binnen het stelsel. Het onderdeel **Stelselvoorzieningen** beschrijft de centrale voorzieningen binnen het federatieve stelsel. + +In onderdeel **Afspraken** zijn alle afspraken te vinden die van het stelsel maken wat het is, een afsprakenstelsel. Verder kent het stelsel een **Begrippenkader**, waarin de gemeenschappelijke taal van het stelsel is gedefinieerd. \ No newline at end of file diff --git a/_posts/2025-09-23-intro.md b/_posts/2025-09-23-intro.md new file mode 100644 index 0000000000..f437a4e48b --- /dev/null +++ b/_posts/2025-09-23-intro.md @@ -0,0 +1,118 @@ +--- +title: Introductie +author: lg +date: 2025-09-23 +category: Jekyll +layout: post +--- + +> ##### Definitief +{: .block-tip } + +Waarom een afsprakenstelsel +------------- + +Samen onder Handbereik is ontstaan vanwege de ervaren knelpunten in de huidige, verkokerde werkwijze binnen het sociaal domein, waar professionals en burgers beperkt overzicht en regie hebben. De ambitie van Samen onder Handbereik is een toekomstbestendige, transparante en effectieve samenwerking, met de burger en ketenpartners digitaal ondersteund binnen één netwerk. + +Traditioneel wordt er gewerkt volgens een estafettemodel waarbij informatie bilateraal tussen twee ketenpartners wordt uitgewisseld als volledige datasets, in vaste volgordes. Dit model leidt tot gesloten informatieketens waarbij gegevens worden gekopieerd, hergebruikt en niet bij de bron geraadpleegd. Daardoor ontstaat een grote afhankelijkheid tussen berichten en weinig flexibiliteit om het proces aan te passen aan de dynamische realiteit van de werkvloer. + +Waarom is dit een probleem? +- Professionals hebben onvoldoende integraal inzicht in de actuele situatie, omdat informatie versnipperd is en via kopieën wordt gedeeld. +- Dit leidt tot hoge administratieve lasten doordat meerdere keren dezelfde gegevens moeten worden aangeleverd. +- Er is sprake van vertraging en inefficiëntie in samenwerking doordat processen streng opeenvolgend verlopen en afhankelijk zijn van de voortgang bij andere partijen. +- Burgers hebben geen transparantie, regie of inzicht in hun eigen dossiers en het samenwerkingsproces en worden daardoor onvoldoende betrokken. +- Door misinterpretatie van privacywetgeving zoals de AVG zijn er terughoudendheden ontstaan ten aanzien van noodzakelijke gegevensdeling, met als gevolg dat relevante signalen niet tijdig gedeeld worden. +- De bestaande systemen en werkwijzen sluiten onvoldoende aan op de behoeften van zowel professionals als burgers aan overzicht, regie en preventieve ondersteuning. +- De samenwerking verloopt vaak reactief, met onvoldoende digitale ondersteuning, wat leidt tot verkokering en het ontbreken van netwerkverband in de samenwerking. +- Het estafettemodel is technisch en procesmatig verouderd en sluit niet aan bij de dynamische praktijk en netwerkstructuren van de huidige samenwerking. +- Beperkte digitale ondersteuning en verkokering in processen belemmeren snelle en effectieve samenwerking. + +Traditionele samenwerking is grotendeels bilateraal, statisch en niet gericht op gezamenlijke regie, wat de effectiviteit beperkt. + +Samen onder Handbereik biedt een oplossing door een gebeurtenisgestuurd netwerkmodel en digitale infrastructuur, waarin gegevens bij de bron blijven, samenwerking in integrale netwerken plaatsvindt en burgers meer regie krijgen over hun gegevens. Dit maakt samenwerking flexibeler, transparanter, efficiënter en sluit beter aan op de praktijk van professionals en burgers. + +Wat levert het afsprakenstelsel op +------------- + +Samen onder Handbereik oplevert, biedt de volgende voordelen en meerwaarde: +- Maakt uniforme, transparante en betrouwbare samenwerking tussen ketenpartners mogelijk binnen het sociaal domein. +- Bevordert werken op basis van gemeenschappelijke principes, standaarden en afspraken, wat interoperabiliteit vergroot en versnippering minimaliseert. +- Creëert een gelijk speelveld voor leveranciers en ketenpartners door gebruik van open, overheid brede en internationale standaarden; dit vereenvoudigt samenwerking, verlaagt kosten en vergroot toekomstbestendigheid. +- Faciliteert gestandaardiseerde informatie-uitwisseling via afspraken over berichtformaten, uitwisseling, toegangsverlening, identificatie, authenticatie en autorisatie. +- Biedt zekerheid dat gegevens veilig, zorgvuldig en doelgericht gedeeld worden binnen privacywet- en regelgeving. +- Ondersteunt het netwerkmodel van Samen onder Handbereik, waardoor informatie gebeurtenisgestuurd gedeeld wordt en ketenpartners flexibel kunnen reageren. +- Zorgt voor gezamenlijke regie over hulpverleningstrajecten door transparantie in rollen, taken, bevoegdheden en processen. +- Maakt het mogelijk burgers beter te betrekken en regie te geven door afspraken over transparantie, inzage en participatie. + +Kortom: Samen onder Handbereik levert een uniform en toekomstbestendig afsprakenstelsel waarin professionals en burgers veilig, efficiënt en betrokken kunnen samenwerken, ondersteund door moderne architectuur en erkende standaarden. + +Wat is de kern van het afspraken stelsel +------------- + +De kern van het afsprakenstelsel van Samen onder Handbereik is het creëren van een gezamenlijke, federatieve structuur waarin meerdere ketenpartners - uit jeugdhulp, zorg en veiligheid - op een uniforme, veilige en betrouwbare wijze informatie kunnen uitwisselen en samenwerken. Belangrijke elementen zijn: +- Uniforme afspraken over gegevensdefinities en berichtvormen, zodat gegevens betekenisvol, eenduidig en herbruikbaar zijn in verschillende contexten en systemen. +- Een gedeelde governance, waarin beslissingen worden genomen door een breed gedragen netwerk van betrokken partijen met duidelijke samenwerkingsafspraken en procesafspraken. +- Gestructureerde rollen en verantwoordelijkheden, inclusief het aanwijzen van regisseurs en afspraken over gegevensbeheer, privacy en beveiliging. +- Gebruik van open en landelijke standaarden voor interoperabiliteit, beveiliging, authenticatie, autorisatie en gegevensuitwisseling (zoals APIs, CloudEvents, ebMS). +- Een event-driven netwerkmodel, waarbij informatie realtime en contextueel wordt gedeeld aan alle relevante partners zonder de rigiditeit van het klassieke estafette model. +- Veilige en gecontroleerde toegang tot gegevens, waarbij rol-, doel- en contextafhankelijke toegangsrechten worden gehanteerd, ondersteund door moderne autorisatieprincipes. +- Participatie van burgers door transparantie, inzage en mogelijkheid tot actieve betrokkenheid in het samenwerkingsproces. + +Dit samenstel van afspraken zorgt voor een toekomstbestendig, flexibel en schaalbaar kader waarmee ketenpartners effectief en conform wet- en regelgeving kunnen samenwerken en informatie digitaal uitwisselen binnen het sociaal domein. + +Hoe werkt het stelsel +------------- + +Het stelsel van Samen onder Handbereik werkt volgens een modern event-driven netwerkmodel, waarbij ketenpartners op een gedecentraliseerde wijze informatie uitwisselen en samenwerken in (quasi) real-time. Belangrijke kenmerken van het functioneren zijn: +- Gebeurtenissen (events): In plaats van volledige berichten worden veranderingen of gebeurtenissen vastgelegd en gedeeld. Dit maakt het mogelijk dat alleen relevante veranderingen worden verzonden, wat de hoeveelheid communicatie en vertragingen reduceert. +- Event hub en event stores: Een centrale voorziening registreert en beheert de gebeurtenissen in een onveranderlijke en chronologische wijze. Deze voorziening vormt een index waar ketenpartners actuele gebeurtenissen kunnen opzoeken en volgen. +- Decentralisatie en autonomie: Ketenpartners zijn verantwoordelijk voor het melden van relevante gebeurtenissen, het aanbieden van gegevens via APIs en het hanteren van autorisatie en authenticatie binnen eigen grenzen. +- Drijvend door drie patronen: + - Aanvragen en leveren van diensten: Ketendistributie van opdrachten en antwoorden via afgesproken APIs. + - Melden en ophalen van gebeurtenissen: Ketenpartners melden hun acties als gebeurtenissen, anderen kunnen deze ophalen en hun processen hierop afstemmen. + - Inzien en delen van gegevens: Momenteel beschikbare gegevens kunnen via API’s gestructureerd en beveiligd worden ingezien. +- Autorisatie en authenticatie: Toegang tot gegevens en diensten wordt strikt geregeld via digitale identificatie, autorisatie en logging. Hierbij worden rollen en doelbinding in acht genomen zodat gegevens veilig en privacy-vriendelijk gedeeld worden. +- Gedragsregels en coordinatie: Regisseurs en samenwerkingsverbanden zorgen voor opgaven, afspraken en sturing binnen het netwerk, inclusief regie over de samenwerking en verantwoordelijkheden. +- Koppeling aan lokale systemen: De samenwerking wordt in de eigen werkprocessen van ketenpartners ondersteund, waarbij digitale functies en gebeurtenissen naadloos in eigen systemen worden geïntegreerd. + +Het stelsel werkt als een gedecentraliseerd, event-gedreven samenwerkingsnetwerk waarin actuele gebeurtenissen centraal worden opgeslagen en ontsloten, en ketenpartners flexibel, veilig en transparant op deze gegevens kunnen reageren. + +Wat betekent het stelsel in de praktijk +------------- + +> ##### Concept +{: .block-danger } + +Hier komen beschrijvingen van casussen door proffesionals over de huidige situatie en werkwijze en hoe deze zou het kunnen zijn. + +Hoe verhoudt het stelsel zich tot andere stelsels +------------- + +Het Samen onder Handbereik afsprakenstelsel sluit waar mogelijk aan op en hergebruikt waar mogelijk bestaande overheidsbrede en zorgspecifieke stelsels en stelselvoorzieningen. Samen onder Handbereik positioneert zich als een verbindend sociaal domeinstelsel dat functioneel, organisatorisch en technisch integreert met bestaande overheid - en zorgstelsels en landelijk beschikbare voorzieningen, om zo samenwerking en gegevensuitwisseling breed en flexibel mogelijk te maken in het jeugd-, zorg- en veiligheidsdomein. + +Ontwikkelingen +------------- + +Voor het jeugd, zorg en veiligheidsdomein zijn de volgende maatschappelijke ontwikkelingen van belang. + +### Maatschappelijke ontwikkelingen + +| Burger en mensgericht | Er lijkt een einde te komen aan de verzakelijking van het openbaar bestuur en het belang van het individu in relatie tot de overheid komt meer voorop te staan. De focus verschuift van “over de burger” naar “met de burger”: wie wonen in ons land en wat hebben ze nodig? | +| Preventie | Verschuiving van wachten tot de situatie ernstig genoeg is voor hulp naar ondersteunen bij het zelf verhelpen van de situatie, vroegsignalering en preventief werken. | +| Systemisch | De verkokering lijkt te verminderen. Er is een beweging om de hokjes en potjes, de organisatiegrenzen en het eigen budget te overstijgen. We lijken van specifieke single issue / produkt interventies naar praktische ondersteuning en gecoördineerde interventies te gaan. Van reductionistisch single issue naar systemische / integrale analyse van de situatie. Van individu naar gezinssysteem. | +| Digitalisering | Er is grote invloed van digitalisering, sociaal media en verwachtingen van gebruik van Apps op de mobiele telefoon. Er zijn hoge verwachtingen van digitale dienstverlening, ook door de overheid en voor overheidsdienstverlening en van de digitale vaardigheden. Ontevredenheid hierover wordt makkelijk en breed gedeeld. | +| Rechtsbescherming en rechtstatelijkheid | Er ligt een toenemende nadruk op transparantie, zorgvuldigheid en bewijsvoering en privacy en participatie en toegang tot effectieve rechtsmiddelen. Zie o.a. het advies van de adviescommissie rechtsbescherming en rechtsstatelijkheid. | +| Tweedeling, Doenvermogen en Digitaal vermogen | Er lijkt een tweedeling in de maatschappij te ontstaan en die lijkt ook toe te nemen. Van hen die kunnen meekomen, de benodigde vaardigheden en netwerk en financiele middelen hebben en degene die de vaardigheden, het netwerk en de financiele middelen niet hebben. De laatste doelgroep groeit en factoren als stress verhinderen dat de vaardigheden, middelen, het netwerk wat er wel is goed wordt gebruikt om weer aan de goede kant te komen. Ten aanzien van wonen, inkomen lijkt er sprake te worden van een grote mismatch en groeiende onzekerheid. | +| Afname sociaal netwerk | De mate waarin burgers steun hebben aan hun eigen sociaal netwerk neemt af: het aantal alleengaanden neemt toe. Mensen raken in een sociaal isolement. Wat noodzaak geeft tot meer professionele en ook bemoeizorg. | +| Demografie en arbeidsmarkt | De Nederlandse bevolking vergrijst. Het aantal werkenden en vrijwilligers neemt af. Dat geeft druk op de ondersteuning die kan worden geboden in het sociaal domein. | + +### Politiek bestuurlijke ontwikkelingen + +De beleidskaders uit het verleden t.a.v. Jeugd, Zorg en Veiligheid zijn verwoord in de volgende programma’s en agenda’s. + +| Landelijke agenda zorg en Veiligheid: Perspectief 2025 [8] | In 2025 is in iedere regio een persoons- en systeemgerichte aanpak actief voor inwoners met opeenstapeling van persoonlijke problemen met een zorg en veiligheidscomponent. Focus ligt op versterking van de regionale regie (1) én het aanreiken van de handvatten voor professionals om goed te kunnen samenwerken en tijdig op- en af te schalen (2). Landelijk zijn de noodzakelijke randvoorwaarden op orde waarbij het principe leidend is dat we het iedere dag een beetje eenvoudiger willen organiseren in de samenwerking. Deze insteek sluit aan op de position papers van de politie en de VNG, de ambities van Reclassering Nederland, het vergezicht vanuit Zorgverzekeraars Nederland op de GGZ en het waardenetwerk Zorg en Veiligheid van de Nederlandse ggz. | +| Toekomstscenario kind en gezinsbescherming [9] | Over vijf tot tien jaar staan om kinderen en volwassenen (0 – 100), gezinnen en huishoudens heen het lokaal (wijk)team dat hulp verleent. Er is voor een gezin of huishouden één vast gezicht binnen het lokaal (wijk)team dat indien nodig samen optrekt met een professional uit een op te richten regionale veiligheidsteam. Het regionaal veiligheidsteam heeft aanvullende expertise en bevoegdheden op gebied van veiligheidsvraagstukken in gezinnen en huishoudens Professionals worden gefaciliteerd om samen te werken en een lerende omgeving te vormen. Dicht bij deze professionals en gezinnen staat een netwerk van specialisten met kennis van kinderen, volwassenen en specifieke uitingsvormen van geweld. | +| Hervormingsagenda Jeugd [10] | De Hervormingsagenda Jeugd bevat een groot pakket afspraken om de jeugdzorg te verbeteren en financieel houdbaar te krijgen. Gemeenten en het rijk gaan structureel investeren in de landelijke kwaliteit en effectiviteit van jeugdhulp. Ook komt er een aanpassing van de Jeugdwet, waardoor duidelijker wordt waarvoor kinderen en ouders hulp kunnen krijgen. | +| Programma Leefbaarheid en Veiligheid, Preventie met Gezag [11] | Dit programma zet In wijken en buurten in op jongeren die betrokken zijn bij of zich aangetrokken voelen tot drugshandel, uitbuiting, geweld en andere vormen van criminaliteit. Als partners versterken we onze aanpak: van vroegsignalering en preventie tot begeleiding en begrenzing om te voorkomen dat jongeren (verder) in de criminaliteit belanden en in het begeleiden van een goede re-integratie in de maatschappij. | +| Stelselherziening justitiële jeugd, vrijheidsbeneming op maat | In dit programma staat maatwerk voor jongeren voorop, gericht op recidivevermindering en dat de jongere zijn/haar leven goed kan voortzetten. Gewerkt wordt met nieuwe vorm van vrijheidsbeneming door kleinschalige voorzieningen (KVJJs) met zeer intensieve samenwerking van alle ketenpartners rondom de jongere en het gezin. Alsook een doelgroepen aanpak met differentiaties in zorg en beveiliging in JJI’s. Dit vraagt ook vernieuwing op het gebied van screening, onderzoek, behandeling en netwerksamenwerking. | +| Programma OmniChannel VNG, i4SociaalDomein | In het gemeentelijk en sociaal domein wordt gewerkt aan burgerinteractie en ketenintegratie. Gemeenten, landelijke overheden en belangenorganisaties onder regie van VNG Realisatie en met financiële steun van het ministerie van Binnenlandse Zaken en Koninkrijksrelaties hebben een praktische omnichannel aanpak ontwikkeld. | diff --git a/_posts/2025-09-24-werking.md b/_posts/2025-09-24-werking.md new file mode 100644 index 0000000000..ed843171dc --- /dev/null +++ b/_posts/2025-09-24-werking.md @@ -0,0 +1,168 @@ +--- +title: De werking van het stelsel +author: lg +date: 2025-09-24 +category: Jekyll +layout: post +--- + +> ##### Definitief +{: .block-tip } + +Samenwerkingsproces +------------- + +Samen onder Handbereik kent het proces van Verbinding aangaan, Samen onderzoeken, Samen Beslissen, Doen wat werkt en Samen leren. De samenwerking is een cyclus, wat wil zeggen dat het proces meerdere keren doorlopen kan worden, zie het vergelijk met de PDCA-cyclus. Dit noemen we het Proces van Samenwerken in de keten. + +1. **Verbinding aangaan** is het inzien en verwerken van informatie over betrokkenen en de context van de situatie beschikbaar bij partners +2. **Samen onderzoeken** is het analyseren van de situatie, onderbouwd onderzoeken en het formuleren en adviseren over mogelijke oplossingen +3. **Samen Beslissen** is het uitwisselen en afwegen van perspectieven, scope & doelbepaling, aanpak kiezen en onder wiens regie en op basis van welke uitgangspunten en afspraken +4. **Doen wat werkt** is het onder regie samen uitvoeren van een plan voor deze situatie, niet doen wat niet werkt en oogsten en monitoren van de resultaten +5. **Samen leren** is het monitoren en evalueren van de kwaliteit/resultaat van de samenwerking op casus overstijgend niveau en op basis daarvan samen verbeteren + +Onderstaande figuur geeft een overzicht van het ketenproces. + +![Alt text]({{ site.baseurl }}/assets/processamenwerkingcyclus.png) + +Samenwerkfuncties +------------- + +Aan het **Samenwerkingsproces** wordt in hun samenhang invulling gegeven met **Samenwerkfuncties**. Deze samenwerkfuncties kunnen worden gezien als keten diensten die onderling in het netwerk aan elkaar worden verleend. + +![Alt text]({{ site.baseurl }}/assets/samenwerkfuncties1.png) + +Er zijn in het Samenwerkproces 15 samenwerkfuncties gedefinieerd: + +1. Allereerst de functie **Uitwisselen Melding** waarmee een professional de betrokkenen in een samenwerkingsverband kan informeren over een mogelijk nieuwe casus. Hiermee wordt het verzamelen, combineren en verrijken van de beschikbare informatie opgestart en start de samenwerking. +2. De functie **Vaststellen Identiteit en Relatie(s)** waarmee de gezinssamenstelling en het sociale netwerk kan worden opgebouwd. +3. De functie **Bepalen Bekendheid en Verrijking** waarmee onderzocht wordt bij welke ketenpartners een burger al bekend is of welke ketenpartners bij de melding betrokken moeten worden. De functie verzamelt ook de informatie die gedeeld mag worden in de keten. +4. De functie **Werken aan Preventie** waarmee burgers in hun kracht worden gezet +5. De functie **Uitvoeren Triage en Taxatie** ondersteunt bij het selecteren en prioriteren, het bepalen van een risicoprofiel, het bepalen van doelbindingen en de te betrekken ketenpartners en hulpaanbod. +6. De functie **Opstellen Analyse & Advies** die systematisch onderzoek naar oorzaken ondersteunt en helpt bij het maken van een onderbouwde rapportage. +7. De functie **Inzien en Deelnemen door de Burger** als burger voorziening. +8. De functie **Overleggen over de Casus** voor het organiseren, voorbereiden en vastleggen van een casusoverleg. +9. De functie **Uitwisselen Uitkomst Overleg** zorgt voor het aan betrokken partijen bekendmaken van de aangewezen casusregisseur, aanpak, afspraken en besluiten. +10. De functie **Opstellen en Regisseren Plan** ondersteunt de casusregisseur, burger of professional bij het maken, uitzetten en managen van een plan van aanpak. +11. De functie **Uitvoeren Actie**. Hiermee meldt een partij of professional aan de keten dat een actie wordt en is uitgevoerd en wat het resultaat is. +12. De functie **Nazorg en Afsluiten Casus** ondersteunt het monitoren van de casus en het zorgvuldig sluiten van het dossier en uiteindelijk voor vernietiging of archivering van het dossier. + +Om de digitale samenwerking in te kunnen richten, te evalueren en te verbeteren zijn tenslotte nog 3 samenwerkfuncties nodig. + +13. Met de functie **Uitwisselen beschikbare diensten** kunnen partijen aangeven welke diensten met welke capaciteit beschikbaar zijn. Met die informatie zijn we beter in staat om uitvoerbare besluiten te nemen en plannen te maken. +14. Met de functie **Inrichten en bijsturen samenwerking** kunnen de partijen en de te gebruiken functies worden gekozen van een samenwerkingsverband en zo worden ingesteld dat we voldoen aan privacyregels en andere wettelijke voorschriften. +15. Met de functie **Monitoring kwaliteit en effectiviteit** wordt het verloop van de samenwerking vastgelegd en kunnen de resultaten en kwaliteit van de samenwerking gemeten worden. + + +Samenwerkpatronen +------------- + +In de samenwerking zijn er drie patronen te onderkennen, ook in technische zin, welke alle gebruikt worden om in vulling te geven aan de Samenwerkfuncties en daarmee het Samenwerkproces. Het betreft: + +a.  **Opdracht** geven of verzoeken om een opdracht uit te voeren +b.  **Inzage** bieden in informatie +c.  **Gebeurtenissen** uitwisselen + +**Opdracht** is doorgaans een asynchroon patroon. Er wordt een opdracht verstrekt of verzoek gedaan een bepaalde opdracht uit te voeren. De uitvoering vergt doorgaans enige tijd. Denk aan opdrachten zoals het handelen naar aanleiding van een melding, of het informatie verzamelen naar aanleiding van een opdracht of verzoek. + +**Inzage** daarentegen is een synchroon patroon. Er wordt een inzageverzoek gedaan en indien dit verzoek wordt gehonoreerd wordt de inzage direct gegeven (bij de bron). + +**Gebeurtenissen**, of wel events, worden gemeld en ontvangen. Gebeurtenissen kunnen leiden tot een actie. + +Grondslagen en juridisch kader +------------- + +### Grondslagen + +| **Wetgeving** | **Korte toelichting** | +| --------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Europees Verdrag tot Bescherming van de Rechten van de Mens | Verdrag, in navolging van de Universele Verklaring van de Rechten van de mens van de VN, waarop het Europees Hof voor de Rechten van de Mens toeziet qua naleving, met directe werking in Nederland. Omvat o.a. het recht op vrijheid en veiligheid, recht op bescherming van de privésfeer. | +| Internationaal Verdrag voor de Rechten van het Kind | Kinderrechtenverdrag dat Nederland heeft geratificeerd. Het omvat o.a. voorrang voor het belang van het kind, recht op privacy, een thuis, band met ouders, groots mogelijke geneeskundige verzorging, roereikende levensstandaard, e.d. | +| Jeugdwet 2015 | De Jeugdwet regelt de jeugdzorg, de jeugdbescherming en de jeugdreclassering. Ze is in 2015 van kracht geworden en geeft gemeenten de verantwoordelijkheid erover. | +| WAMS (alsmede WPG, AVG, WGS, WGPGA, e.d.) | De Wet aanpak Meervoudige Problematiek in het Sociaal Domein zal de juridische grondslag voor het verzamelen, verwerken en delen van persoonsgegevens domein overstijgend gaan geven. Ze was beoogd per 1 januari 2024 een aanvulling op de reeds bestaande wetgeving en andere komende wetgeving rond gegevensbescherming te zijn. | +| EU Data wetten, waaronder Data Act, Data Governance Act, AI Act, EHDS (Health Data Space) Act | De EU werkt aan haar data wetten met als doel om versnippering te voorkomen, vertrouwen te verbeteren, grondrechten en waarden van de EU te laten respecteren en vendor lock-ins te voorkomen. De Data Governance Act gaat over toegang tot overheidsdata. Dit doet de EU voornamelijk via verordeningen. Dit zijn wetten die rechtstreeks werken, en niet nog door de lidstaten verwerkt te hoeven worden in nationale wetgeving. Geborgd wordt dat gegevens onmiddellijk, gratis en makkelijk beschikbaar zijn. | +| Wmebv | De Wet Modernisering Elektronisch Bestuurlijk Verkeer geeft burgers het recht om officiele berichten digitaal aan overheidsorganisaties te sturen: aanvragen, meldingen, besluiten, klanten, zienswijzen, bezwaar en beroep. Dat maakt ook dat burgers kunnen aangeven alles zo veel mogelijk digitaal te willen doen. Dat vraagt dat digitale kanalen worden ingericht, digitale ontvangstbevestiging en notificaties worden verstuurd en inzicht wordt geboden in de voortgang van de afhandeling, inclusief bewijzen. Ook verplicht het instanties tot ondersteuning bij dienstverlening aan digitaal minder vaardige inwoners, de zorgplicht. Deze wet gaat vermoedelijk 1-1-2025 in. | +| WDO | De Wet Digitale Overheid (WDO) is een kaderwet die de basis legt voor verdere digitalisering, waaronder regulering van de digitale overheid en in het bijzonder generieke voorzieningen in een gemeenschappelijke digitale infrastructuur. In de eerste tranche richt het zich op betrouwbaar inloggen en zekerheid over iemand identiteit. | + +### Juridische kaders + +| **Wetgeving** | **Korte toelichting** | +| --------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Europees Verdrag tot Bescherming van de Rechten van de Mens | Verdrag, in navolging van de Universele Verklaring van de Rechten van de mens van de VN, waarop het Europees Hof voor de Rechten van de Mens toeziet qua naleving, met directe werking in Nederland. Omvat o.a. het recht op vrijheid en veiligheid, recht op bescherming van de privésfeer. | +| Internationaal Verdrag voor de Rechten van het Kind | Kinderrechtenverdrag dat Nederland heeft geratificeerd. Het omvat o.a. voorrang voor het belang van het kind, recht op privacy, een thuis, band met ouders, groots mogelijke geneeskundige verzorging, roereikende levensstandaard, e.d. | +| Jeugdwet 2015 | De Jeugdwet regelt de jeugdzorg, de jeugdbescherming en de jeugdreclassering. Ze is in 2015 van kracht geworden en geeft gemeenten de verantwoordelijkheid erover. | +| WAMS (alsmede WPG, AVG, WGS, WGPGA, e.d.) | De Wet aanpak Meervoudige Problematiek in het Sociaal Domein zal de juridische grondslag voor het verzamelen, verwerken en delen van persoonsgegevens domein overstijgend gaan geven. Ze was beoogd per 1 januari 2024 een aanvulling op de reeds bestaande wetgeving en andere komende wetgeving rond gegevensbescherming te zijn. | +| EU Data wetten, waaronder Data Act, Data Governance Act, AI Act, EHDS (Health Data Space) Act | De EU werkt aan haar data wetten met als doel om versnippering te voorkomen, vertrouwen te verbeteren, grondrechten en waarden van de EU te laten respecteren en vendor lock-ins te voorkomen. De Data Governance Act gaat over toegang tot overheidsdata. Dit doet de EU voornamelijk via verordeningen. Dit zijn wetten die rechtstreeks werken, en niet nog door de lidstaten verwerkt te hoeven worden in nationale wetgeving. Geborgd wordt dat gegevens onmiddellijk, gratis en makkelijk beschikbaar zijn. | +| Wmebv | De Wet Modernisering Elektronisch Bestuurlijk Verkeer geeft burgers het recht om officiele berichten digitaal aan overheidsorganisaties te sturen: aanvragen, meldingen, besluiten, klanten, zienswijzen, bezwaar en beroep. Dat maakt ook dat burgers kunnen aangeven alles zo veel mogelijk digitaal te willen doen. Dat vraagt dat digitale kanalen worden ingericht, digitale ontvangstbevestiging en notificaties worden verstuurd en inzicht wordt geboden in de voortgang van de afhandeling, inclusief bewijzen. Ook verplicht het instanties tot ondersteuning bij dienstverlening aan digitaal minder vaardige inwoners, de zorgplicht. Deze wet gaat vermoedelijk 1-1-2025 in. | +| WDO | De Wet Digitale Overheid (WDO) is een kaderwet die de basis legt voor verdere digitalisering, waaronder regulering van de digitale overheid en in het bijzonder generieke voorzieningen in een gemeenschappelijke digitale infrastructuur. In de eerste tranche richt het zich op betrouwbaar inloggen en zekerheid over iemand identiteit. | + +Governance +------------- + +> ##### Concept +{: .block-danger } + +In het Afsprakenstelsel worden drie verschillende roltypen onderscheiden. Deze roltypen zijn: + +Besturingsrollen: de rollen en verantwoordelijkheden voor de besturing van het Afsprakenstelsel, hiermee wordt de governance geborgd. + +Organisatorische en proces rollen: de rollen en verantwoordelijkheden voor het organiseren van de samenwerking binnen het Jeugd, Zorg en Veiligheidsdomein, hiermee wordt het proces geborgd. + +Systeemrollen: de rollen en verantwoordelijkheden voor de technische realisatie van gegevensuitwisseling binnen het Afsprakenstelsel, hiermee wordt de techniek geborgd. + +### Besturingsrollen + +> ##### Concept +{: .block-danger } + +De besturing sluit aan op NEN7522:2021, de Nederlandse norm voor het ontwikkelen en beheren van standaarden en stelsels van standaarden. Het Afsprakenstelsel is in de terminologie van NEN7522 een stelsel van standaarden. Voor meer informatie, zie NEN7522:2021. + +| Rol | Toelichting | Invulling | +| --- | --- | --- | +| Stelselhouder | Eindverantwoordelijk voor het ontwikkelen en beheren van het stelsel. De houder stelt de scope en het doel van het stelsel vast evenals de principes en de uitgangspunten die worden gehanteerd bij ontwikkeling en beheer. | Invulling rol nog te bepalen | +| Stelselfinancier | Verantwoordelijk voor de financiering van de ontwikkeling en het beheer van het stelsel. | Invulling rol nog te bepalen | +| Stelselautorisator | Keurt een stelselstandaard (waaronder normen en technische afspraken) goed. | Invulling rol nog te bepalen | +| Stelsel Functioneel beheerder | Verantwoordelijk dat het proces van ontwikkelen en beheren verloopt volgens de gemaakte afspraken. Hiertoe behoort ook het beheer en toezicht op het vertrouwen en de kwaliteit van het ecosysteem. | Invulling rol nog te bepalen | +| Stelsel Technisch beheerder | Verantwoordelijk voor het technisch beheren van individuele standaarden of stelsels van standaarden. | Eindverantwoordelijk ntb, Per onderdeel ntb | +| Stelsel-distributeur | Verantwoordelijk voor het distribueren van informatie over de ontwikkeling en het beheer van het informatiestelsel. | Invulling rol nog te bepalen | +| Stelsel-expert | Brengt specifieke noodzakelijke kennis in. | Invulling rol nog te bepalen | +| Stelselgebruiker en Stelseleindgebruiker | Gebruikers en eindgebruikers maken gebruik van het stelsel en brengen de voor de besturing benodigde domeinkennis in. | Invulling rol nog te bepalen | +| Auditor | De rol van auditor is een aanvulling op de bovenstaande rollen: deze rol zorgt voor het kwalificeren en certificeren van (software)producten, zowel voor data, applicaties als infrastructuur. | Invulling rol nog te bepalen | + + +### Organisatorische en proces rollen + +> ##### Concept +{: .block-danger } + +Deze paragraaf beschrijft op organisatorisch niveau de rollen benodigd voor het uitvoeren van het samenwerkproces. + +| Rol | Toelichting | +| --- | --- | +| Burger | Dit betreft de betrokkene(n) in het gezin, de familie: zij blijven op de hoogte van wat er gebeurd en oefenen daar invloed op uit door input voor het onderzoek en input voor het plan te maken of feedback te geven. | +| Melder | De rol van een medewerker van een meldende of deelnemende organisatie die de casus aanbrengt voor behandeling in de vorm van een aanmelding | +| Deelnemer | De rol van een medewerker van een deelnemende organisatie aan het samenwerkingsverband die o.a.-     informatie beschikbaar stelt-     onderzoek doen-     advies uitbrengt t.b.v. beschikking / beslissing-     deelneemt in het overleg bij kiezen regisseur, adviseren, besluitvorming, samenstellen plan, etc.-     toegewezen acties in het plan van aanpak uitvoert | +| Procesregisseur | De rol van een medewerker van een Deelnemer of van een medewerker specifiek in dienst van het samenwerkingsverband die de intake en triage uitvoert en die het samenwerkingsverband organiseert en faciliteert, m.n. de bedrijfsvoeringskant:-     uitvoeren intake handelingen-     organiseren/uitvoeren van de triage-     organiseren van het overleg-     bewaken van de voortgangOok is deze rol verantwoordelijk voor de inrichting van de samenwerking, convenant en doelbindingen en het op casus overstijgend niveau bijsturen van de samenwerking | +| Casusregisseur | De rol van een medewerker van een deelnemende organisatie aan het casusoverleg die is belast met de taken:-     meestal gekozen uit de organisatie waar het zwaartepunt ligt van de zorgverlening aan het subject-     belast met het gieten van de besluiten / beschikking/ het verslag in een plan c.q. concrete interventies-     belast met toezicht op naleving van afspraken in het plan van aanpakEen flink deel van de acties in het plan ligt op diens bordje, alsmede de overall effectiviteit van het plan.Het is dus vooral een inhoudelijke rol:-     overleggen met de betrokken burgers-     zelf uitvoeren van acties-     monitoren of de doelen wordt gehaaldbijsturen van andere deelnemers op het leveren van hun bijdrage | + +### Technische rollen + +> ##### Concept +{: .block-danger } + +Deze paragraaf beschrijft de systeemrollen die relevant zijn voor het Afsprakenstelsel. + +| Rol | Toelichting | Invulling | +| --- | --- | --- | +| Bronhouder | Deelnemer die data en bijvoorbeeld inzage services aanbiedt. | Invulling rol nog te bepalen | +| Afnemer | Een deelnemer die data en services afneemt van een bronhouder. | Invulling rol nog te bepalen | +| Vertrouwensleverancier | Levert (samen met andere vertrouwensdienstverleners) een infrastructuur voor publieke sleutels en beheert een registratie van publieke sleutels. | Invulling rol nog te bepalen | +| Ledenadministrator | Op basis van registraties of kenmerken kunnen deelnemers worden herkend en op basis hiervan kunnen bepaalde rechten worden ontleend. | Invulling rol nog te bepalen | +| Bevoegde uitgever van verklaringen | Een erkenning dat de uitgever bevoegd is voor het uitgeven van verklaringen. Deze verklaringen betreffen bijvoorbeeld een identiteitskenmerk of een toegangsbewijs. | Invulling rol nog te bepalen | +| Stelselbeheerder | Beheer van het stelsel en kent technische rollen toe. | Invulling rol nog te bepalen | +| Ketenvoorzieningbeheerder | Verantwoordelijk voor het beheren, actueel houden en beschikbaar stellen van ketenvoorzieningen | Invulling rol nog te bepalen | +| Verzekeraar betrouwbaarheid | Maakt inzichtelijk welke attesten mogen worden uitgegeven door welke deelnemers. | Invulling rol nog te bepalen | + + + + + diff --git a/_posts/2025-09-25-principes.md b/_posts/2025-09-25-principes.md new file mode 100644 index 0000000000..af79f1f612 --- /dev/null +++ b/_posts/2025-09-25-principes.md @@ -0,0 +1,222 @@ +--- +title: Principes en standaarden +author: lg +date: 2025-09-29 +category: Jekyll +layout: post +--- + +> ##### Definitief +{: .block-tip } + +We zijn niet de enige die de beweging naar het netwerkmodel maken. Op verschillende plaatsen binnen de Nederlandse overheid zie je die technologie beweging van berichtenverkeer naar APIs en gebeurtenissen technologie. In de gemeentewereld onder de Common Ground vlak. In de zorgwereld. We willen in het netwerk optimaal gebruik maken van overheidsbrede afspraken, standaarden en voorzieningen. + +Daarom zijn de NORA (Nederlandse Overheid Referentie Architectuur), de Architectuur Digitale Overheid 2030 en de MIDO (Meerjaren Infrastructuur Digitale Overheid) Domeinarchitecturen van toepassing. De principes daarin herhalen we niet, die zijn te vinden in: +- NORA principes +- MIDO Domeinarchitectuur toegang (identificatie, authenticatie, machtigen en vertegenwoordigen) +- MIDO Domeinarchitectuur gegevensuitwisseling 2.0, vastgesteld 5 februari 2025 +- MIDO Interactiearchitectuur (hoewel die nog meer van toepassing is op de Solution Intent m.b.t. Burgerportaal). +- Federatief datastelsel +- We verwijzen graag naar de veranderfactoren, beleid, wet- en regelgeving, ontwikkelingen, knelpunten en principes die in die referentie en domein architecturen worden benoemd en herhalen ze hier niet. + +In dit hoofdstuk werken we vooral aanvullende thema’s en principes uit. Thema’s en principes wat specifieker voor domein Jeugd, Zorg en Veiligheid. + + +Thema's +------------- + +Maatschappelijke, juridische en digitale overheidskaders waarbinnen de oplossing welke het afsprakenkader biedt moet passen zijn samen te vatten in 4 kernthema’s: + +1. **Zelfredzaamheid ondersteund**: Hier komen de ontwikkelingen mensgerichtheid, doenvermogen, digitalisering, arbeidsmarkt en de inzet van Hervormingsagenda Jeugd/Toekomstscenario bij elkaar. Het voorkomt veel leed door problematiek in een vroeg stadium te (helpen) verhelpen. En met digitale preventieve oplossingen kan de beperkt beschikbare professionele aandacht worden gereserveerd voor waar ze echt nodig is. +2. **Transparantie voor de burger**: Hier komen de ontwikkelingen rechtsbescherming, rechtsstatelijkheid, digitaal doenvermogen, omnichannel, digibeter, de EU datawetten en de Wembv bij elkaar. Door inzicht in het proces voor de betrokkenen, transparant en accountable, met de mogelijkheden om te participeren (zienswijze en bezwaar inbrengen) en met de zorgplicht voor minder digitaal vaardigen krijgt de burger een centrale rol. +3. **Integraal Samenwerken**: Hier komen de ontwikkelingen Systemisch, Digitalisering, Arbeidsmarkt, Interbestuurlijke datastrategie, moderne koppelvlakken en de landelijke agenda zorg en veiligheid bij elkaar. Focus is op het gezin(ssysteem), het samenbrengen van de relevante partners, komen tot een gedeeld beeld, een gedeeld plan en  duidelijke regie**.** +4. **Informatie gedreven**: Hier komende ontwikkelingen Datagedreven, Privacy, Federatief Datastelsel, Common/Public Ground, I-Strategie en Moderne Architectuur bij elkaar. Ketenpartners bieden functionaliteit en gegevens aan elkaar met gegevensbescherming en verantwoording in het hart. + +Voor elk thema zijn principes met hun implicaties uitgewerkt. + +Principes +------------- + +### Zelfredzaamheid ondersteund +We ondersteunen de zelfredzaamheid concreet, de-escalerend en specifiek. Dweilen met de kraan open is niet gewenst, we moeten erger voorkomen. Bij voorkeur bereikt de burger de gedwongen/justitiële kaders niet. Daarom ondersteunen we vanuit de overheid de burger met gekwalificeerde, onafhankelijke, niet-commerciële ondersteuning. Vooral door leerbare en inzicht gevende uniforme kennis beschikbaar te maken over problematiek en concrete oplossingen op een betrouwbare plek. Aangevuld met regionale kennis en laagdrempelige hulp van professionals. + +Voor dit thema vonden we geen principes bij NORA, GEMMA, MIDO of FDS om her te gebruiken. + +De specifieke principes voor dit thema, met in achtneming dat gedwongen justitiële kaders nog niet zijn bereikt, zijn daarom: + +| B11 | Concrete hulp | +| --- | --- | +| Statement | Anoniem en via zelfbediening is praktisch advies beschikbaar. Dus concreet antwoord op vragen, vragenlijsten voor zelfanalyse, stappenplan, tips en tricks, handvatten, overzichten en ervaringsverhalen. Bewezen effectief. Met taal die aansluit. | +| Implicaties | - We stellen zoveel mogelijk informatie ter beschikking en maken onze diensten zodanig, dat de burger zelfredzaam kan zijn in het regelen van eigen zaken, ook met de overheid. | + +| B12 | De-escalerend | +| --- | --- | +| Statement | De inhoud van de hulp is gericht op verminderen van de problematiek en voorkomen van het verergeren van de situatie. Het stuurt niet richting professionals, het bevordert het benutten van het eigen netwerk om problemen op te lossen en geeft objectieve input om zelf mee aan de slag te gaan. | +| Implicaties | - We richten ons ook op preventie en normalisering, door de burger | + +| B13 | Personaliseerbaar | +| --- | --- | +| Statement | De burger kan kiezen de hulp toe te snijden op de situatie. Door antwoord op vragen of kiezen van opties. Zo kan de begeleiding specifieker worden gemaakt en nog concretere vervolg stappen, aanpak instrumenten of thema’s worden aangeboden. | +| Implicaties | - De burger krijgt actieve controle over het hulptraject. - Door zelf keuzes te maken of vragen te beantwoorden, wordt de hulp afgestemd op persoonlijke behoeften en omstandigheden. | + +| B14 | Regie bij de Burger | +| --- | --- | +| Statement | De burger bepaalt zelf of er professionele ondersteuning nodig is en wat met een hulpverlener wordt gedeeld of wat met andere hulpverleners wordt gedeeld. Ze worden desgewenst ondersteund in de werkstroom naar hulpverleners.Zo kunnen burgers met groeiende problemen desgewenst vroeg in beeld komen. | +| Implicaties | - De burger heeft zeggenschap over het al dan niet inschakelen van professionele hulp. - De burger bepaalt zelf welke informatie gedeeld wordt en met wie, wat privacy en autonomie versterkt. | + +### Transparantie voor de burger + +We werken nauw en transparant samen met de burger en zijn/haar gezin. Transparantie is voor de jeugd, zorg en veiligheid een belangrijk thema. Doel is om de burger en zijn/haar gezinssysteem meer inzicht te geven in hun gegevens en de status van hun zaken, aansluitend bij hun perspectief en vanuit één ingang. Zodat de burger zelf de regie kan (terug)pakken en zijn bijdrage in de samenwerking kan leveren. + +Basisprincipes voor dit thema zijn afkomstig van 3 bronnen: de NORA, de Gemma, de MIDO en het FDS. + +Voor de NORA hanteren we principes: +- NAP01 Verplaats je in de gebruiker +- NAP02 Geef inzicht in de afhandeling van de dienst +- NAP03 Lever een kanaal onafhankelijk resultaat + +Voor de GEMMA hanteren we principes: +- GAP18 Bied regie op gegevens +- GAP 19 Zorg voor digitale inclusie +- GAP 20 Zorg voor digitale weerbaarheid + +Voor de MIDO domein architectuur Interactie hanteren we principes: +- BD-01: één overheidsbeleving +- BD-03: Samenhangende communicatie +- BD-04: Inzicht in gegevens over jezelf +- BD-08: Keuzevrijheid in kanalen en kanaalonafhankelijke, consistente dienstverlening +- BD-09 Herkenbare en uniform gestructureerde overheidswebsites en -apps + +We hanteren 4 eigen aanvullende principes: + +| B21 | Inzichtelijk | +| --- | --- | +| Statement | De burger kan de eigen persoonsinformatie en procesinformatie inzien. Inzoemen en een perspectief kiezen (bijv. vanuit gezinslid, ketenpartner, processtap of tijdslijn) is mogelijk voor meer inzicht. De informatie is sorteerbaar, doorzoekbaar, filterbaar.  Met de mogelijkheid voor een verzoek om correctie, verwijdering. | +| Implicaties | - Inzage is op uniforme wijze ingericht over alle betrokken ketenpartners heen en vanuit het perspectief van de gezinsleden, gebruiksvriendelijk en dienstverlenend. - Er is één duidelijk en vindbaar toegangspunt voor informatie dat niet om kennis van de organisatorische of procesmatige inrichting vraagt. - Inzichtelijk is ook wie (welke professional) welke gegevens heeft gebruikt. - Inzichtelijk is wie (organisatie en professional) welke gegevens hebben ingevoerd en gewijzigd. - Ook de historische stand van zaken is inzichtelijk. - Een gezinslid kan een verzoeken tot wijziging van gegevens doen, die bij de juiste organisatie en professional wordt beschikbaar gesteld. - Er moet een alternatieve mogelijkheid worden geboden aan gezinsleden die niet in staat zijn dit op digitale manier in te inzien of te verzoeken. | + +| B22 | Integraal op/vanuit 1 plek | +| --- | --- | +| Statement | De burger kan op of vanuit 1 landelijke plek het gehele dossier inzien. De burger kan op 1 plek zijn voorkeuren aangeven welke en via welk kanaal informatie actief wordt beschikbaar gesteld. De burger kan op één plaats inzien wie waarvoor zijn gegevens heeft gebruikt en dat beinvloeden.Regie op gegevens hanteert als vertrekpunt dat mensen inzage moeten hebben in hun persoonlijke gegevens en het gebruik daarvan door derden, dat zij de mogelijkheid moeten hebben om gegevens te corrigeren of verwijderen en -niet in de laatste plaats- dat zij gegevens moeten kunnen (her)gebruiken, zowel binnen de overheid als daarbuiten. Hierdoor verbetert de transparantie, neemt de kwaliteit van gegevens toe en wordt de positie van de burger versterkt. | +| Implicaties | - Als burger wordt ik actief digitaal op de hoogte gesteld van wat er van mij wordt verwacht. - Als burger heb ik invloed op met wie en wanneer mijn gegevens gedeeld worden. | + +| B23 | Perspectief van Burger/Gezin | +| --- | --- | +| Statement | Het perspectief van de burger en zijn/haar gezinssysteem staan centraal. We testen continu met burgers wat wel en niet werkt. Dat betekent ook dat de actuele stand van zaken en de specifieke context van de burger wordt gebruikt. En dat de burger keuze mogelijkheden moet krijgen. Bovendien wordt rekening gehouden met de persoonlijke verschillen in mogelijkheden, omstandigheden en culturen. | +| Implicaties | - We verminderen het voor de burger onoverzichtelijke mijnenveld van mijn omgevingen | + +| B24 | Participatief | +| --- | --- | +| Statement | De burger kan ook actief bijdragen aan analyse, overleg, besluitvorming en plan. De burger wordt actief gevraagd die bijdrage te leveren. | +| Implicaties | - Als burger word ik actief digitaal op de hoogte gesteld van wat er van mij wordt verwacht. - Als burger heb ik invloed op met wie en wanneer mijn gegevens gedeeld worden. | + +### Integraal samenwerken + +In het domein van jeugd, zorg en veiligheid werken veel professionals die elk hun eigen taken uitvoeren voor het gezin. Die taken zijn vaak (bewust of onbewust) afhankelijk van taken of informatie van andere professionals. Daarom is het van belang dat een professional niet alleen zicht heeft op wat in de interne bedrijfsvoering van de organisatie waar die werkt bekend is. Maar dat er ook zicht is op informatie en over taken die door professionals van andere organisaties worden gedaan. Die informatie over de samenwerking moet gedeeld worden, zodat organisaties in staat worden gesteld ze ook onder de vingertoppen van hun professional te brengen . We werken vanuit eigen taak(systeem) en verantwoordelijkheid in een gezamenlijk proces en sturingskader. Er is een flexibel inzetbaar samenwerkproces met ondersteuning voor daarin benodigde vaardigheden / bouwstenen. Focus is op het gezin(ssysteem), het samenbrengen van de relevante partners, komen tot een gedeeld beeld, een gedeeld plan en  duidelijke regie**.** + +Basisprincipes voor dit thema zijn afkomstig van 1 bron: de NORA. Van de GEMMA, de MIDO en het FDS zijn geen principes geoogst. + +Voor de NORA hanteren we principes: +- NAP07. Bouw diensten modulair op: ontwerp losse ontkoppelde diensten +- NAP15. Maak diensten schaalbaar +- NAP17. Stuur cyclisch op kwaliteit + +Specifieke principes voor dit thema rond samenwerken: + +| B31 | Gezamenlijk proces | +| --- | --- | +| Statement | De deelnemers in een samenwerkingsverband werken conform een lerend samenwerkingsproces met vaste samenwerkrollen. Daarover maken we gezamenlijk afspraken, in een federatief stelsel. Met 12 vaardigheden voor verrijken, analyseren, beslissen en uitvoeren. Gericht op het regisseren van de juiste interventie door de juiste partner op het juiste moment. | +| Implicaties | - Samenwerken aan delen van analyses en plan moet mogelijk zijn- Ook voor vervanging c.q. delen van de verantwoordelijkheid moet een oplossing/afspraken worden geïntroduceerd- Aan een (deel)plan moet door meerdere professionals tegelijk kunnen worden gewerkt. Ook de betrokken burger moet daaraan logischerwijs kunnen meewerken.- Partijen zullen daarvoor functionaliteit in hun eigen processen en bedrijfsvoeringssystemen opnemen, zodat het als vanzelf sprekend kan worden gedeeld én opgehaald- Een verstoring van het delen kan grote impact hebben bij andere ketenpartners. Het is dus zaak in het ontwerp van het beschikbaar stellen en delen robuuste oplossingen te maken, die rekening houdt met andere ketenpartners. | + +| B32 | Eigen taak(systeem) | +| --- | --- | +| Statement | Samenwerken is niet afgescheiden, naast het gewone werk noch gebeurt het (alleen) in ketenportalen. Samenwerken is ingebed in de eigen taak en dus ook in het eigen taaksysteem. Daarin wordt men opmerkzaam gemaakt op nieuwe relevante informatie en kan deze informatie ook in het taaksysteem inzien. | +| Implicaties | - In verzoeken om informatie en de digitale uitwisseling moet voldoende gespecificeerd zijn over de rol en functie van de betrokkene, de wettelijke taak, de doelbinding en de informatiebehoefte voor de professional om te beoordelen of tot verstrekking wordt overgegaan.- Verzoeken tot samenwerking en inzage/verstrekking van informatie kunnen worden geweigerd. Dat kan zowel geautomatiseerd collectief (bijv. voor een bepaald type verzoek van een bepaalde organisatie) of individueel door een professional | + +| B33 | Eigen verantwoordelijkheid | +| --- | --- | +| Statement | Ondanks de samenwerking is er steeds een aanwijsbare verantwoordelijke/dienstverlener.En maakt een professional een eigen afweging vanuit eigen cultuur, werkwijze en kader. Dat geldt ook voor de procesregisseur of casusregisseur, die de coördinatie van het samenwerkproces of de uitvoering van het plan ter hand neemt. | +| Implicaties | - In verzoeken om informatie en de digitale uitwisseling moet voldoende gespecificeerd zijn over de rol en functie van de betrokkene, de wettelijke taak, de doelbinding en de informatiebehoefte voor de professional om te beoordelen of tot verstrekking wordt overgegaan.- Verzoeken tot samenwerking en inzage/verstrekking van informatie kunnen worden geweigerd. Dat kan zowel geautomatiseerd collectief (bijv. voor een bepaald type verzoek van een bepaalde organisatie) of individueel door een professional- De meest geschikte ketenpartner wordt casusregisseur. Deze moet snel worden bepaald en zichtbaar zijn voor alle betrokkenen | + +| B34 | Gezamenlijk sturingskader | +| --- | --- | +| Statement | Ketenpartners meten en sturen de samenwerking bij. Gericht op de gewenste output, kwaliteit en maatschappelijk effect, met een relatie naar de doelenboom. We doen dit zowel voor operationeel gebruik als voor beleidsvorming, leren en verantwoording. Het is niet voldoende om alleen operationele, casus gerelateerde informatie te delen. Samenwerken betekent ook dat evaluaties, tactische informatie en stuurinformatie wordt gedeeld. Om te leren is het belangrijk het effect te meten. | +| Implicaties | - In verzoeken om informatie en de digitale uitwisseling moet voldoende gespecificeerd zijn over de rol en functie van de betrokkene, de wettelijke taak, de doelbinding en de informatiebehoefte voor de professional om te beoordelen of tot verstrekking wordt overgegaan.- Verzoeken tot samenwerking en inzage/verstrekking van informatie kunnen worden geweigerd. Dat kan zowel geautomatiseerd collectief (bijv. voor een bepaald type verzoek van een bepaalde organisatie) of individueel door een professional- Voor het verzamelen van data en monitoren van de samenwerking is behoefte aan een standaard- Op verschillende niveaus kunnen gegevens bevraagd worden c.q. informatieproducten geleverd worden- Evalueren onderdeel en cyclisch verbeteren maakt onderdeel uit van het proces- Behoefte aan een monitor om de resultaten inzichtelijk te maken | + + +### Informatie gedreven + +We maken als ketenpartners informatie by design betekenisvol, duurzaam en privaat voor de samenwerking beschikbaar. Na de digitalisering van bestaande (papier)stromen tussen 2 partijen maken we de volgende sprong. Er ontstaat een virtueel samenwerkplatform van informatiediensten. Daarin is helder wie verantwoordelijk is voor welke informatie en wat de betekenis van de gegevens is. Daarbij is gegevensbescherming in het platform “by design” ingebed en werken we op basis van overheid brede afspraken. + +Vanuit het perspectief van een ketenpartner verschuift het paradigma van keteninformatievoorziening hiermee van het verplicht aansluiten op ketenvoorzieningen naar het verzamelen en aanbieden van functionaliteit en gegevens aan elkaar met gegevensbescherming en verantwoording in het hart. Dat versterkt de samenwerking. + +Hierop hanteren we geen eigen principes, maar hanteren we de principes van 4 bronnen: de NORA, de GEMMA, de MIDO en het FDS. + +Voor de NORA/GEMMA hanteren we principes: +- NAP/GAP08 Standaardiseer waar mogelijk: reduceer varieteit en kosten, zorg voor een betere interoperabiliteit. +- NAP/GAP10 Neem gegevens als fundament: de kwaliteit, toegankelijkheid en zorgvuldig beheer van ontstaan tot vernieuwing van gegevens zijn het fundament voor waardevolle diensten. +- NAP/GAP11 Pas doelbinding toe +- NAP/GAP12 Informeer bij de bron + +De MIDO Domeinarchitectuur Gegevensuitwisseling (paragraaf 4.2). Met name: +- Principes m.b.t. het beheren van metagegevens (3.1 – 3.6) +- Principes m.b.t. bescherming van persoonsgegevens, logging en beveiliging (1.7, 1.8) +- Principes m.b.t. kwaliteit en geschikheid voor gebruik (1.1, 1.3, 1.4, 4.1, 4.2) +- Principes m.b.t. toepassing van (open) standaarden (1.2) + +En als derde bron de principes van toepassing van het Federatief Datastelsel. Met name: + +- Data blijft bij de bron, de bronhouder is soeverein, heeft zeggenschap en autoriseert de toegang tot data +- Zorgvuldige omgang met beveiliging en privacy +- Toepassing van afspraken boven standaarden en voorzieningen +- Decentraal wat kan, centraal wat moet +- Toepassing van een vertrouwensraamwerk +- Hoogwaardige data: waarborgen van datakwaliteit en/met metadata + + +> ##### Consultatie +{: .block-warning } + +We hanteren de volgende drie eigen aanvullende principes: + +| B35 | Binnen het gezamenlijke proces spreken we een zelfde taal | +| --- | --- | +| Statement | Er is één gemeenschappelijk semantisch, schematisch en syntactisch model nodig om binnen het gezamenlijke proces en binnen het domein efficiënt en effectjes informatie uit te kunnen wisselen. Populair gezegd spreken we, binnen het samenwerkverband, dezelfde taal. | +| Implicaties | - Elke organisatie moet kunnen omgaan met het gemeenschappelijk semantisch, schematisch en syntactisch model, zowel als ontvanger van informatie als aanbieder. - Er zullen doorgaans vertalingen nodig zijn naar eigen interne wereld met een eigen semantisch, schematisch en syntactisch model. | + +| B36 | De informatiebehoeftige is verantwoordelijk voor informatie inwinning | +| --- | --- | +| Statement | Organisaties met een informatiebehoefte zijn verantwoordelijk voor het ophalen van die informatie. Organisaties die informatie beheren zijn verantwoordelijk voor het ontsluiten van die informatie voor bevragingen en voor het actief kenbaar maken van beschikbaarheid ervan, bijvoorbeeld via gebeurtenissen, catalogi of registers. In de praktijk wordt deze verantwoordelijkheid vaak onterecht bij informatieaanbieders gelegd door hen te verplichten informatie actief te brengen. Brengen kan en moet soms plaatsvinden, maar het mag niet structureel als primaire verplichting worden opgelegd aan de informatiehouder. | +| Implicaties | - Niet de organisatie die informatie heeft wordt verantwoordelijk gemaakt voor aanlevering bij de ontvanger, maar de verantwoordelijkheid voor inwinning ligt bij de ontvanger. In het estafette model wordt deze verantwoordelijkheid vaak (oneigenlijk) verplaatst naar de leverende organisatie en moet deze informatie gaan brengen. - De ontvanger moet de informatie gaan halen, zie ook de aansluiting bij het ‘halen bij de bron’ gedachtengoed. | + +| B37 | De ontvanger vertaald naar het eigen domein | +| --- | --- | +| Statement | De aanbieders van informatie bieden deze aan conform het keteninformatiemodel. Als vertalingen nodig zijn naar het domein van de ontvanger, doet de ontvanger van de informatie dit zelf en wordt deze taak niet verplaatst naar de aanbieder of naar een ketenvoorziening en daarmee niet naar een shared service organisatie. | +| Implicaties | - Vertalingen t.b.v. het domein van de afnemer van de informatie worden niet verlegt naar de aanbieder van de informatie.- Afnemers zullen waar nodig zelf vertalingen (translaties) moeten uitvoeren. - Vertalingen kunnen niet worden verlegd naar  ketenvoorziening / shared service organisaties. Dergelijke vertalingen zijn uniek waardoor het centraal invullen daarvan onlogisch en onwenselijk is. Mogelijke uitzonderingen zijn vertalingen voor een domein met verschillende organisaties daarbinnen zonder eigen shared service voorzieningen (mogelijke explain). | + +| B38 | Single pane of glass | +| --- | --- | +| Statement | Zoals de burger informatie op één plek kan vinden (zie betreffende principe), beschikt de professional ook over één plek waar de benodigde informatie is te vinden of kan worden ingewonnen, namelijk binnen de taakapplicatie van de betreffende partij. | +| Implicaties | - De taakapplicaties moeten de informatie kunnen tonen en opvraag kunnen maken. - Daar waar nu verschillende tool en portals beschikbaar gemaakt worden is een consolidatie nodig. - Er moet gebruik gemaakt worden van functies, services en koppelvlakken van het stelsel zodat een flexibel, aanpasbaar  loosely coupled landschap ontstaat en geen monolithische functionaliteit binnen de taakapplicaties | + +| B39 | Scheiding data en processen(common ground) | +| --- | --- | +| Statement | Data en processen zijn gescheiden zowel in het gezamenlijke domein als binnen de achterliggende ICT infrastructuren, daar bevindt zich immers de te ontsluiten data. | +| Implicaties | Scheiding van data en processen leidt tot een efficiënter, veiliger en flexibeler ICT-landschap, maar vraagt ook om nieuwe technische, organisatorische en juridische aanpakken. | + +Standaarden +------------- + +Relevant voor afsprakenstelsel zijn de volgende standaarden (in wording) en afspraken over internationale standaarden in de Nederlandse context (zoals bijvoorbeeld - NL GOV profile for CloudEvents): +- OAuth en NL GOV Assurance profile for OAuth 2.0 (NLGov OAuth) +- OIDC en NL GOV Assurance Profile for OIDC (NLGov OpenID connect) +- SCIM +- CloudEvents en NL GOV profile for CloudEvents +- Digikoppeling Koppelvlakstandaard REST-API +- NL GOV API Design Rules (NLGov ADR) +- OpenAPI Specification (OAS) +- FSC: Federated Service Connectivity +- FTV: Federatieve Toegangsverlening +- TLS (standaard voor het versleutelen van de connectie waar de API’s gebruik van maken) + +Deze lijst is niet limitatief en zal in de tijd nog worden aangevuld. + diff --git a/_posts/2025-09-26-samenwerkfuncties.md b/_posts/2025-09-26-samenwerkfuncties.md new file mode 100644 index 0000000000..324b4215a8 --- /dev/null +++ b/_posts/2025-09-26-samenwerkfuncties.md @@ -0,0 +1,152 @@ +--- +title: Samenwerkfuncties +author: lg +date: 2025-09-29 +category: Jekyll +layout: post +--- + +> ##### Definitief +{: .block-tip } + +De samenwerkingsfuncties zoals genoemd in onderdeel Werking zijn navolgend uitgewerkt. + +Uitwisselen Melding +------------- + +| | Omschrijving | +| --- | --- | +| Omschrijving | Het vermogen om berichten met zorgen van professionals en burgers over een burger of gezin te kunnen opstellen, verzenden en ontvangen.Na ontvangst van een bericht wordt de correctheid en compleetheid beoordeeld op basis van vastgelegde criteria zodat het naadloos aansluit op het volgende proces. Dat levert een uitkomst melding op, het resultaat van die beoordeling (o.a. de status).Het doel van de melding is dat een samenwerking rond een gezin op gang wordt gebracht, opdat tijdig passende hulp en zorg kan worden geboden. | +| Huidige voorbeelden | VT Melding, Niet Acuut Melding, ZVH Melding, Comensha Melding. En de bijbehorende VT Terugmelding, ZVH Terugmelding | +| Huidige oplossingen | De gegeven voorbeelden zijn per domein, per regio, per samenwerkingsverband heel specifiek opgezet. Inhoudelijk heel verschillend en Technologisch ook. | +| Gebruikersverhaal | Als verzoeker van een melding wil ik eenvoudig en uniform mijn zorgen m.b.t. een burger / gezin bij de juiste instantie/partner kunnen aangeven. Over de uitkomst van de melding wil ik worden geïnformeerd.Als dienstverlener van een melding wil ik een melding makkelijk en uniform in behandeling kunnen nemen, kunnen doorzetten naar of ontvangen van andere meldpuntenAls deelnemer in een samenwerkingsverband en als burger wil ik graag op de hoogte worden gebracht van nieuwe meldingen/uitkomst meldingen en die, binnen wettelijke kaders en met in achtneming van veiligheid van de burgers en gezinsleden, in kunnen zien | +| Zakelijke rechtvaardiging | O.a. Politie meldt bij zorgen rond personen aan diverse organisaties (VT, ZVH, Niet Acuut, Comensha, etc.). De werkwijze, regels, beschikbaar te stellen informatie en wijze van terugreageren verschillen per regio, per organisatie, doelgroep, en/of problematiek. Door uniformering tot een generieke landelijke melding en uitkomst melding met automatische routering en intuïtieve vraagstelling neemt de training af, is de afhandeling en terugkoppeling efficiënt, wordt de kwaliteit hoog, zijn medewerkers in andere regio’s inzetbaar en kunnen meldpunten makkelijk onderling uitwisselen. | + +Uitwisselen Vaststellen Identiteit & Relaties +------------- + +| | Omschrijving | +| --- | --- | +| Omschrijving | Het vermogen om een duidelijk beeld te creëren van het netwerk aan betrokken burgers en hun relaties (bijv. gezinssysteem), als ook andere formele (gezag, voogdij) en informele (groepen, sociale) relaties.Hierbij kan bijv. gebruik gemaakt worden van basisregister personen, basisvoorziening vreemdelingen, de gezag-, voogdij en vertegenwoordigingsresultaten, DigiD en DigiV (digid vreemdeling) en resultaten uit fluïde netwerken.Het doel is te zorgen dat ketenpartners een duidelijk beeld krijgen van het netwerk van de relevante personen, de gezinssamenstelling en het gezag of de voogdij. Maar ook dat burgers zich kunnen identificeren voor toegang tot het burgerportaal en als wettelijk vertegenwoordigers valide toegang tot informatie over hun kinderen kunnen krijgen. | +| Gebruikersverhaal | Als verzoeker wil ik eenvoudig, uniform en snel kunnen bepalen wie een burger is en wat de (familie/groeps)relaties van de burger zijn. M.n. wil ik ook kunnen vaststellen wie zeggenschap heeft over de opvoeding en verzorging van een Jeugdige en belangrijke beslissingen over en met de Jeugdige mag nemen.Als burger wil ik me graag kunnen identificeren om toegang te krijgen tot mijn casus en die van mijn gezinsleden (binnen de wettelijke mogelijkheden) | +| Zakelijke rechtvaardiging | O.a. Politie en KMAR (maar ook VT, RvdK, GI), hebben behoefte aan inzicht welke jeugdigen (broertjes, zusjes) nog meer onderdeel uitmaken van het gezin en wie gezag of voogdij, de zorgverantwoordelijkheid, over de personen heeft. Vaststelling is nu omslachtig en tijdrovend omdat de vastlegging (o.a. bij de rechtspraak) en de afleidingsregels complex zijn. Op tijd kritische momenten (o.a. bij uitreis, bij gezondheid en veiligheidsissues) is snelle vaststelling echter cruciaal.Er kan kwalitatief een grote slag worden gemaakt en kwantitatief kan een enorme afname van administratieve last worden bereikt | + +Bepalen Bekendheid & Verrijking +------------- + +| | Omschrijving | +| --- | --- | +| Omschrijving | Het vermogen om de informatie over een burger of gezin te verrijken. Dit start bij een uitvraag bij ketenpartners of een burger bij hen bekend is of niet. Een ketenpartner beantwoord zo’n uitvraag met de uitslag of de burger bij hen “bekend” is.Als de uitslag positief is, kunnen die ketenpartners om aanvullende informatie worden verzocht, die nodig is voor haar wettelijke taken. Dit leidt al dan niet tot het verstrekken van zulke feiten/informatie, uiteraard binnen de kaders van wettelijke rol/doelbinding.Doel is actuele en betrouwbare informatie te verzamelen die reeds bij ketenpartners aanwezig is | +| Gebruikersverhaal | Als regisseur voor een melding wil ik als verzoeker eenvoudig en snel kunnen vaststellen of een samenwerkingspartner bekend is met een burger of gezinEn als dat zo is bij een partner contextafhankelijk (bijv. wettelijke taak, betrokkenheid bij gezin/burger, rol in het samenwerkingsverband, doelbinding) op een aantal concrete vragen inzicht kunnen verkrijgen in de situatie die betreffende partner kent en relevant kan zijn voor de casus. | +| Zakelijke rechtvaardiging | Veilig Thuis ontvangt jaarlijks grofweg 120.000 meldingen, waarvoor bekendheid en casusinformatie bij ketenpartners (o.a. politie, RvdK, Gis, wijkteams) moet worden verzameld. Dat gebeurt lokaal heel verschillend, is arbeidsintensief voor VT en alle ketenpartners, is foutgevoelig en privacy gevoelig en tijdige beschikbaarheid is een probleem.Er kan kwalitatief een grote slag worden gemaakt en kwantitatief kan een enorme afname van administratieve last worden bereikt (schatting 10.000 uur). | + +Werken aan Preventie +------------- + +| Aanmelding | Omschrijving | +| --- | --- | +| Omschrijving | Het vermogen om burgers inzicht en kennis te geven om zelfstandig de situatie te de-escaleren en preventief te verhelpen. De geboden aanpak dient effectief en zelfstandig, vrijwillig uit te voeren te zijn.Doel is gezinnen en professionals de middelen te geven om problematiek vroegtijdig, in eigen regie en/of met laagdrempelige en lokale hulp in het sociaal domein te onderzoeken en te bepalen wat te doen. Om zo kostbare en eventueel gedwongen hulp te voorkomen.Voorbeeld is de landelijke content en digitale psycho-educatie m.b.t. relatieproblemen, die lokaal door gemeente en zorgverleners wordt aangeboden. | +| Gebruikersverhaal | Als burger met problemen wil ik inzicht krijgen in en leren toepassen van bewezen, goed werkende oplossingsrichtingen voor mijn situatie opdat ik in eigen regie/selfservice of via beperkt professioneel contact mijn problemen kan verminderen of oplossen | +| Zakelijke rechtvaardiging | Veel burgers met relatie-, opvoed-, geestelijke-, verslavings-, financiele of veiligheidsproblemen krijgen (zoekend op internet) niet direct en goed werkende inzichten/oplossingen. Dat resulteert in een toenemend beroep op professionele zorg en hulp.Met goed gevonden en werkende zelfdiagnose, zelfhulp, neemt de professionele zorgbehoefte af en kan problematiek mogelijk worden verminderd of in een vroegtijdig stadium opgelost zonder of met minder professionele hulp. | + +Uitvoeren Triage & Taxatie +------------- + +| | Omschrijving | +| --- | --- | +| Omschrijving | Het vermogen om een wetenschappelijke onderbouwde inschatting te maken.  Met de uitkomst kan worden bepaald of opvolging nodig is en met welke prioriteit, duur, intensiteit of inhoud van de aanpak. De inschatting wordt opgebouwd door het in kaart brengen wat bepalende beschermend- en/of risicofactoren binnen de diverse leefgebieden van de burger zijn. Op basis daarvan kunnen personen en gezinnen worden toegeleid naar een passend inhoudelijk hulpaanbod.Doel is ketenbreed betrouwbaar en volledig inzicht en goede inschatting (op herhaling, escalatie, veiligheid, e.d.) te hebben van de situatie. | +| Gebruikersverhaal | Als professional wil ik, zelf of deels op basis van antwoorden/ casusinformatie of resultaten van ketenpartners, een gestructureerde en wetenschappelijk gevalideerde vragenlijst / instrument (op meerdere leefgebieden) completeren, scoren en rapporteren opdat ik de juiste routering en interventies kan helpen onderbouwen om de levensloop en de ontwikkeling van de betrokkene(n) in de goede richting te beïnvloeden. | +| Zakelijke rechtvaardiging | Deze bouwsteen beoogd betrokkene(n) te screenen en indien nodig toe te leiden naar andere samenwerkingsverbanden (bijv. voor zorg) en erkende (gedrags)interventies opdat eerder en effectiever kan worden ingegrepen en kostbare herhaling of ingrepen later kunnen worden voorkomen. Bovendien beoogd de bouwsteen het delen van kennis/analyses uit instrumenten tussen ketenpartners/professionals, zodat burgers niet steeds weer op hetzelfde worden bevraagd en informatie kan worden hergebruikt of daarop wordt voortgebouwd. Eenduidigheid in begrip (t.a.v. score instrument, leefgebied, uitkomst, interventie) helpt de samenwerking verder.Samenvattend is het efficiënter voor professionals in hergebruik van informatie, maakt het dat de burger minder vaak het(zelfde) verhaal hoeft te doen én zijn doorverwijzigingen/interventies effectiever. | + +Opstellen Analyse & Advies +------------- + +| | Omschrijving | +| --- | --- | +| Omschrijving | Het vermogen om systematisch en gestructureerd (integraal en systeemgericht) te achterhalen welke factoren van invloed zijn op het ontstaan/voortbestaan van vraag of situatie. Het vermogen om door middel van een gedegen en goed onderbouwde rapportage de betrokkenen een advies op maat te bieden, die richting geeft aan wat het belangrijkst en meest urgent is om op te pakken en waarom, en middels welk hulpaanbod.Doel is een zorgvuldige en integrale, verklarende analyse, vanuit verschillende denkkaders, te krijgen. Je graaft dieper naar de oorzaken van problemen.De analyse en het advies zijn input voor het gezamenlijke totaalbeeld en het Besluitvormen als volgende stap. | +| Gebruikersverhaal | Als professional wil ik (samen met gezin en andere professionals) de kern en de samenhang blootleggen van de problemen/hulpvraag van een jongere, gezin of betrokkene, de factoren die een rol spelen, de aanknopingspunten die er positief uitspringen, opdat ik/we deze analyse met bijbehorend advies kunnen beschikbaar stellen in de samenwerking voor overleg en besluitvorming. | +| Zakelijke rechtvaardiging | Verschillende organisaties gebruiken verschillende methodieken, protocollen, handelingskaders, begrippen, visies en instrumenten.Om met elkaar integraal en systeemgericht te kunnen werken is het van belang de verscheidenheid aan hulpmiddelen te verkleinen en in samenhang te kunnen brengen. Met als uiteindelijk doel dat er zorgvuldige (zo veel mogelijk op feiten gebaseerde) analyses uitgevoerd worden zodat onderbouwde (al dan niet gezamenlijke) adviezen tot effectief overleg en besluitvorming en uiteindelijk tot passende hulp leidt. | + +Inzien en Deelnemen door de Burger +------------- + +| Aanmelding | Omschrijving | +| --- | --- | +| Omschrijving | Het vermogen van de burger om transparant inzicht te hebben op. En om zo deel te kunnen nemen aan de samenwerking.Eerste doel is de burger inzicht te geven welke instanties en medewerkers betrokken zijn, wat ze doen qua proces en product, wat ze onderling uitwisselen aan persoonsgegevens.Vervolgens krijgt de burger de mogelijkheid zijn privacy rechten (inzage, wijziging/correctie, verwijdering, klacht) in persoonsgegevens te kunnen uitoefenen.Verder is het van belang dat burgers kunnen participeren in overleg, in het opstellen van plannen en het uitvoeren van acties tot resultaten. Additioneel ook inzicht in gemaakte bilaterale afspraken, gespreksverslagen, e.d. En feedback en akkoord geven.Denk hierbij o.a. aan een digitaal Burgerportaal. Nader bepaald moet worden wat haalbaar en werkzaam/baar is. Verschil in vrijwillig en gedwongen kader. En de invloed van professionals op wat inzichtelijk is. | +| Gebruikersverhaal | Als burger wil ik inzicht in wat de instanties en professionals in mijn casus aan het doen zijn en onderling uitwisselenAls burger wil ik mijn wettelijke rechten (op correctie, verwijdering, etc.) kunnen uitoefenenAls burger wil ik kunnen participeren in casusanalyse, casusoverleg en bij het maken en uitvoeren van plannenAls professional wil ik een logisch en veilig kanaal waarover ik informatie met burgers en hun gezinssysteem kan delen en verzoeken aan ze kan doen | +| Zakelijke rechtvaardiging | Momenteel is het overzicht voor de burger beperkt, vaak wisselen professionals uit door samenwerking van gezicht tot gezicht, op papier, via e-mail of via eerste versie van mijnomgevingen. Dat maakt samenwerken omslachtig en arbeidsintensief. Ook leidt dit tot veel burger-contact, door een burger op zoek naar overzicht en inzicht en een professional op zoek naar informatie.Door ontwikkeling van een integraler burgerportaal, waar alle stappen, besluiten en informatie overzichtelijk beschikbaar zijn kan veel tijd worden gewonnen en onduidelijkheid worden voorkomen. | + +Overleggen over de Casus +------------- + +| | Omschrijving | +| --- | --- | +| Omschrijving | Vermogen om de samenwerking op te zetten en het casusoverleg te organiseren, zoals het bepalen van de deelnemers (waaronder de burger) de uitnodiging te verzenden, het bepalen van de informatie die ter inzage is met de voorwaarden die daarvoor gelden, het bepalen en verspreiden van relevante gespreksthema’s en type besluiten die genomen moeten worden.Doel is een zorgvuldige voorbereiding en uitvoering van een multidisciplinair overleg zodat adequate besluitvorming en ‘warme’ overdracht van casus- of zaakinformatie plaatsvindt vanuit een gedeeld beeld. | +| Gebruikersverhaal | Als professional wil ik efficiënt een casusoverleg met betrokken partijen opzetten inclusief het delen van informatie en uitwisselen van denkbeelden en adviezen opdat interventies en effectieve hulp in korte tijd tot stand komen | +| Zakelijke rechtvaardiging | Als politie en VT kost het veel doorlooptijd om een casusoverleg met specifieke ketenpartners op te zetten inclusief het delen van informatie. Bij de politie is de behoefte al “ter plaatse”/motorkapoverleg met betrokkenen, ook bij VT is de behoefte op korte termijn (binnen uren).Als overleg en informatie delen efficiënt kan worden gedaan worden ongewenste geitenpaadjes voorkomen, komen kwalitatief betere besluiten tot stand en kunnen incidenten eerder worden bezworen. | + +Uitwisselen Uitkomst Overleg +------------- + +| | Omschrijving | +| --- | --- | +| Omschrijving | Vermogen de gedeelde beelden en gemaakte keuzes en afspraken vast te leggen. Afspraken worden gemaakt over de uitvoering, besloten wordt wie de casusregisseur wordt, welke aanpak wordt gehanteerd en of een casus terug komt en hoe wordt besloten tot afschaling. Deze resultaten van het overleg worden vastgelegd en gedeeld.Doel is het communiceren van de gemaakte afspraken en besluiten opdat het overleg tot actie wordt omgezet. | +| Gebruikersverhaal | Als professional wil ik het resultaat van (casus)overleg, in de vorm van de gemaakte afspraken, de besluiten, de casusregisseur, het verslag c.q. de onderbouwing kunnen inzien opdat ik mijn rol in de samenwerking kan waarmaken en de collega’s in mijn organisatie daarover kan informerenAls organisator van het overleg wil ik de uitkomst van het overleg publiceren als waarborg dat hetgeen is afgesproken ook bekend is bij de ketenpartners en de burger, erdoor in gang wordt gezet en ook bekend is bij collega’s van de aanwezigen.Als burger wil ik de uitkomst van het overleg inzien opdat ik op basis daarvan actie kan ondernemen | +| Zakelijke rechtvaardiging | Ketenorganisaties als politie en RvdK zijn met duizenden professionals/collega’s, waarvan één/enkele bij het casusoverleg aanwezig zijn. Zonder ondersteuning voor die ene om de concrete afspraken en besluiten naar die collega’s te brengen bestaat het risico dat de afspraken beperkt of niet tijdig worden geïmplementeerd, niet de juiste interventie op het juiste moment wordt uitgevoerd en de problematiek wordt vergroot of het incident zich blijf herhalen, met alle inspanning en kosten van dien. | + +Opstellen & Regisseren Plan +------------- + +| | Omschrijving | +| --- | --- | +| Omschrijving | Vermogen om als casusregisseur (in samenwerking met ketenpartners) een integraal plan te ontwikkelen en bij te stellen, waaronder doelen en interventies en met relevante ketenpartners en burgers te delen. Vervolgens het regisseren van de uitvoering van het plan door overzicht te houden op het totaal van de interventies en hun samenhang en eventuele stagnaties bij de uitvoering van het plan.Doel is het in actie zetten van onderdelen van het plan en nastreven van de doelen in samenhang. Bijsturen op nieuwe ontwikkelingen die bijstelling vragen of eventuele stagnaties in de uitvoering. | +| Gebruikersverhaal | Als (benoemd casus)regisseur wil ik gemaakte afspraken, besluiten, verslagen omzetten in concrete plannen met doelen, acties en gewenste resultaten  en kunnen delen opdat ik helder krijg wat ik ga doen, regie kan gaan voeren op acties en resultaten en mijn voornemens met ketenpartners en Burgers kan delen en zij de plannen desgewenst kunnen aanscherpen of reviewen.Als Burger wil ik inzicht krijgen in en op termijn meeschrijven/werken aan  het plan dat er wordt uitgevoerd, zodat ik gecommitteerd ben | +| Zakelijke rechtvaardiging | Als professional/regisseur is het maken van een plan al een onderdeel van mijn taak.Als ik dat plan, waaraan ook andere ketenpartners deelnemen met een deel van de acties, met die ketenpartners/professionals en met de Burger efficiënt zou kunnen delen, heb ik er veel minder administratie rompslomp aan en komt dat het resultaat ook nog ten goede. | + +Uitvoeren Actie +------------- + +| | Omschrijving | +| --- | --- | +| Omschrijving | Het vermogen om individuele taken, afspraken en interventies uit te zetten bij andere ketenpartners, die deze ontvangen en uitvoeren. En het Resultaat daarvan kunnen terugkoppelen, die door de casusregisseur worden ontvangen voor zijn regietaak.Doel is het overdragen van taken die door andere ketenpartners volgens afspraak worden uitgevoerd, met de daarvoor benodigde informatie | +| Gebruikersverhaal | Als (benoemd casus)regisseur wil ik acties kunnen uitzetten bij Ketenpartners/professionals opdat ze worden uitgevoerd en ik resultaten kan gaan zien bij de doelen in mijn planAls deelnemer wil ik inzage in afspraken, acties die ik moet doen opdat ik ze ga uitvoeren, resultaat boeken opdat we samen de doelen voor het gezin waarmaken | +| Zakelijke rechtvaardiging | Als politie is het van belang dat afspraken en acties, zowel reactieve als proactieve, concreet en praktisch beschikbaar komen, zodat ze aan de vele collega’s efficiënt beschikbaar kunnen worden gemaakt. Alleen zo komen afspraken/acties in een persoons-, gezins- en groepsgerichte aanpak die in de keten zijn afgesproken tot uitvoering en resultaat. Een andere wijze is onpraktisch en ineffectief/omslachtig. | + +Nazorg en Afsluiten Casus +------------- + +| | Omschrijving | +| --- | --- | +| Omschrijving | Het vermogen om in stappen de samenwerking af te bouwen. Eerst nog actief gelaten en bewaakt voor het geval er een terugval optreedt en een nieuwe samenwerking doorgestart moet worden.Het vermogen tot gezamenlijke archivering van de casus in de samenwerking. Het vermogen om te leren en analyseren op de casus(sen)Doel is nazorg verlenen en later zorgvuldig afsluiten en archiveren voor de bescherming van de persoonlijke levenssfeer van de betrokkenen.Maar ook stuurinformatie beschikbaar te maken voor beleidsontwikkeling en leren. | +| Gebruikersverhaal | Als regisseur of professional wil ik de casusvoortgang en effectiviteit kunnen monitoren opdat ik zo nodig een nieuwe ronde van onderzoeken, overleggen en regisseren kan ingaan om de situatie aan te pakkenAls regisseur of professional wil ik de casus stapsgewijs kunnen afronden en afhechten opdat de privacy van de burger wordt geborgd | +| Zakelijke rechtvaardiging | | + +Nazorg en Afsluiten Casus +------------- + +| | Omschrijving | +| --- | --- | +| Omschrijving | Het vermogen om het beschikbare en de geboden kwaliteit van het (gecontracteerd) hulpaanbod te beheren/te kunnen zien, inclusief eventuele wachttijden.Het doel is om bij besluitvorming en planvorming en gegeven de hulpvraag, de meest passende en beschikbare diensten te kunnen kiezen. | +| Gebruikersverhaal | Als verzoeker wil ik inzage in het beschikbare aanbod van (gecontracteerde) (hulp)aanbod, eventuele wachttijden opdat ik realistische keuzes en plannen kan maken, passend bij de hulpvraag.Als dienstverlener wil ik dat mijn (gecontracteerd) aanbod wordt meegenomen in de besluitvorming en planvorming.Als deelnemer in een samenwerkingsverband en als burger wil ik graag inzage in de beschikbaarheid, kwaliteit van diensten in relatie tot de/mijn hulpvraag. | +| Zakelijke rechtvaardiging | | + +Inrichten en Bijsturen Samenwerking +------------- + +| | Omschrijving | +| --- | --- | +| Omschrijving | Het vermogen om het samenwerkingsverband in te regelen, waaronder processtappen, gebruikte bouwstenen, betrokken instanties, professionals, rollen, functies, wettelijk kader, doelbinding, taken, informatiebehoeften, abonnementen.Naast inregelen is uiteraard herinrichten, door andere stappen, bouwstenen, instanties, etc. in te regelen mogelijk.Het doel is dat flexibel kan worden bijgestuurd in het functioneren van een samenwerkingsverband. | +| Gebruikersverhaal | Als verzoeker wil ik voor mijn samenwerkingsverband ons proces, gebruikte bouwstenen, betrokken instanties, rollen, functies, wettelijk taken, informatiebehoefte, wettelijke grondslagen beheren. Opdat ikAls deelnemer in een samenwerkingsverband en als burger wil ik graag inzage in de afspraken, betrokkenen en de werking van een samenwerkingsverband. | +| Zakelijke rechtvaardiging | | + +Inrichten en Bijsturen Samenwerking +------------- + +| | Omschrijving | +| --- | --- | +| Omschrijving | Het vermogen om de kwaliteit en de maatschappelijke effectiviteit van de samenwerking te kunnen overzien.Hierbij gaat het ook om de logging van gegevensverstrekkingen en toestemmingen. Met de juiste toepassing van pseudonimisering en anonimisering in de logging en monitoring.Doel is om input te verzamelen voor het bijsturen van de samenwerking en haar her in te richten. | +| Gebruikersverhaal | Als samenwerkingsverband wil ik graag inzage in de kwaliteit en effectiviteit van de samenwerking, opdat we de samenwerking kunnen bijsturen. | +| Zakelijke rechtvaardiging | | + + + diff --git a/_posts/2025-09-27-samenwerkpatronen.md b/_posts/2025-09-27-samenwerkpatronen.md new file mode 100644 index 0000000000..602e793645 --- /dev/null +++ b/_posts/2025-09-27-samenwerkpatronen.md @@ -0,0 +1,68 @@ +--- +title: Samenwerkpatronen +author: lg +date: 2025-09-29 +category: Jekyll +layout: post +--- + +> ##### Definitief +{: .block-tip } + +De samenwerkingsfuncties zoals genoemd in onderdeel Werking zijn navolgend uitgewerkt. + +Opdracht patroon +------------- + +Het gaat hier om het patroon van het aan elkaar geven van opdrachten of verzoeken om een opdracht uit te voeren (of dienst te verlenen). + +_Opmerking: Dit patroon wordt toegepast in estafettemodel, maar ook in het netwerkmodel. Binnen het netwerkmodel worden ook andere patronen toegepast, binnen het estafettemodel niet tot nauwelijks._ + +Bij het opdracht patroon geeft de ene ketenpartner de andere ketenpartner opdracht of verzoekt om een opdracht uit te voeren. De ketenpartner wacht op een antwoord, bijvoorbeeld dat opdracht is uitgevoerd of krijgt bijvoorbeeld het resultaat van de opdracht. Hier kan sprake zijn van diensten en dienstverlening. De modaliteiten hiervan (eisen aan de geleverde dienst, vorm van het antwoord, reactietermijn, ..) zullen vooraf zijn afgesproken en bijvoorbeeld zijn vastgelegd in een SLA (of soortgelijke afspraken).  + +Kenmerkend voor dit patroon is de vaak een asynchrone verwerking van het verzoek; met andere woorden: na het verzoek gaat er enige tijd overheen voordat de terugkoppeling volgt. + +_Voorbeeld: De opdracht kan zijn: “lever mij informatie over …”. Bij een informatiedienst moet deze informatie bijvoorbeeld eerst worden opgezocht en of verzameld. Kan de informatie direct worden opgevraagd, dan is er sprake van een synchrone verwerking en is het patroon Inzage van toepassing. Met dit patroon kan ook een asynchroon verzoek tot het wijzigen van informatie worden georganiseerd._ + +Kenmerken: asynchroon. + +Om deze patronen te implementeren moeten taak/procesapplicaties van ketenpartners worden uitgerust met applicatiefuncties voor iedere Samenwerkfunctie: + +- **Opdracht Aanvragen** \[Samenwerkfunctie\]: De applicatiefunctie "Aanvragen \[Samenwerkfunctie\]" ondersteunt de dienstaanvrager bij de afhandeling van een dienstaanvraag bij een ketenpartner. Dit omvat zowel het plaatsen van een dienstaanvraag bij een ketenpartner, als het in ontvangst nemen van het aangevraagde (informatie)product. +- **Opdracht Leveren** \[Samenwerkfunctie\]: De applicatiefunctie "Levering \[Samenwerkfunctie\]" ondersteunt de dienstleverancier bij de afhandeling van dienstaanvragen van de \[Dienst\]. Dit omvat zowel het in ontvangst nemen van een dienstaanvraag van een ketenpartner, als het leveren van het aangevraagde (informatie)product en de afhandeling van de statusovergangen van de Samenwerkfunctie. + +Inzage patroon +------------- + +Dit patroon wordt gebruikt om informatie in te zien (bij de bron). Op een inzageverzoek volgt direct (synchroon) het antwoord. + +Kenmerken: synchroon, niet toestand veranderend + +De te implementeren applicatiefuncties: + +- **Inzage Verzoek** \[Samenwerkfunctie\]: De ketenapplicatiefunctie "Inzage Verzoek \[Samenwerkfunctie\]" is de functie met behulp waarvan de daartoe geautoriseerde functionarissen van de eigen organisatie informatie via Samenwerkfunctie kan opvragen bij ketenpartners. +- **Inzage Leveren** \[Samenwerkfunctie\]: De ketenapplicatiefunctie "Inzage Leveren \[Samenwerkfunctie\]" is de informatie verstrekkende functie via de Samenwerkfunctie van de Ketenpartner die door de leverende Ketenpartner wordt ingericht. + +Gebeurtenis patroon +------------- + +Dit patroon betreft het melden van en zich informeren over gebeurtenissen die in de processen bij een specifieke ketenpartner hebben plaatsgevonden. Gebeurtenissen bevatten slechts enkele identificerende gegevens over de gebeurtenis. Het is aan de afnemer om zich regelmatig te informeren over nieuwe gebeurtenissen en te bepalen wat hij hiermee doet. Geeft de gebeurtenis aanleiding tot een informatiebehoefte, dan kan deze verkregen worden via patroon Inzage. + +In de IV is de term event driven bekend geworden, gebeurtenis gedrevenheid. Het idee achter gebeurtenis gedrevenheid is dat gegevens worden vastgelegd als een gebeurtenis en dat een proces wordt getriggerd door deze toestandsveranderingen. Een gebeurtenis beschrijft die toestandsverandering die gelogd (of geregistreerd) wordt. Betreffen doorgaans ruwe data of observaties. In deze zienswijze is een event een gestandaardiseerde manier waarop gegevens worden opgeslagen. + +Dat heet ook wel toestand gedrevenheid. Het is juist een relevante toestand die een proces activeert. Wanneer één afzonderlijke gebeurtenis die toestand beschrijft dan zijn toestand en gebeurtenis “in sync”. Vaak is het zo dat eerdere gebeurtenissen tezamen een relevante toestand beschrijven. Een verzameling aan gebeurtenissen leiden tot een bepaalde toestand waarop geacteerd moet worden. Zo leidt één specifieke gebeurtenis niet tot handelen (bijvoorbeeld 1 VT melding), maar een verzameling wel (bijvoorbeeld verschillende zorgmeldingen). De toestand die voldoende grondslag of reden biedt om over te gaan tot handelen is de toestand (en niet de afzonderlijke gebeurtenis). Dit impliceert overigens dat gebeurtenissen gepersisteerd moeten worden, als deze op deze manier ingezet worden. + +Een gebeurtenis is een specifieke, waarneembare actie of voorval dat plaatsvindt op een bepaald moment en dat invloed kan hebben op de toestand van een systeem, proces of entiteit. Een gebeurtenis kent de volgende eigenschappen: +- Tijdgebonden: Een gebeurtenis vindt plaats op een specifiek tijdstip of binnen een bepaalde tijdsperiode. +- Waarneembaar: Gebeurtenissen kunnen geregistreerd worden. Ze derhalve meetbaar of observeerbaar. +- Contextafhankelijk: Een gebeurtenis, net als alle gegevens, heeft in een bepaalde context betekenis. +- Afzonderlijk en onderscheidbaar: Gebeurtenissen staan los van andere gebeurtenissen en kunnen duidelijk worden geïdentificeerd. +- Niet doelgericht: Een gebeurtenis kent geen intentie. Een gebeurtenis beschrijft, zoveel mogelijk, de feitelijkheden. +- Toestandbeschrijvend: Een gebeurtenis beschrijft een event. +- Onwijzigbaar en niet verwijderbaar: Gebeurtenissen beschrijven feiten. Ze zijn daarom onwijzigbaar of verwijderbaar. Tenslotte is iets daadwerkelijk voorgevallen. +- Asynchroon: Events worden asynchroon gecommuniceerd. De afzender wacht niet op reactie. + +De volgende applicatiefuncties zijn relevant: + +- **Gebeurtenis Melden** \[Samenwerkfunctie\]: Voor iedere dienst die een ketenpartner levert, voorziet deze ketenpartner in een applicatiefunctie "Gebeurtenis melden \[Dienst\]". Deze applicatiefunctie meldt aan de centrale voorziening de voortgang van de afhandeling van een Dienstaanvraag. +- **Gebeurtenis Ontvangen** \[Samenwerkfunctie\]: Ketenpartners dienen geregeld te verifiëren of er interessant gebeurtenissen zijn. De ketenpartners kunnen deze gebeurtenissen gebruiken om gegevensverwerkende processen te activeren; bijvoorbeeld om de eigen informatiepositie bij te werken en hier vervolgens adequaat op te reageren. diff --git a/_posts/2025-09-28-architectuur.md b/_posts/2025-09-28-architectuur.md new file mode 100644 index 0000000000..8a163498f3 --- /dev/null +++ b/_posts/2025-09-28-architectuur.md @@ -0,0 +1,179 @@ +--- +title: Architectuur +author: lg +date: 2025-09-29 +category: Jekyll +layout: post +--- + +> ##### Concept +{: .block-danger } + +ICT architectuur heeft als doel richting te geven aan een oplossing binnen een bepaalde scope. De oplossing in deze context is het creëren van een gezamenlijke, federatieve structuur waarin meerdere ketenpartners - uit jeugdhulp, zorg en veiligheid - op een uniforme, veilige en betrouwbare wijze informatie kunnen uitwisselen en samenwerken. De scope is het Jeugd, Zorg en Veiligheidsdomein. In dit domein zijn vele organisaties vertegenwoordig, zie onderstaande figuur. + +![Alt text]({{ site.baseurl }}/assets/domein.png) + +Inhoudelijk bezien zijn er de organisaties welke informatie delen of ontvangen, en zijn er de stelselvoorzieningen welke door deze partijen gebruikt worden. Dit geeft twee belangrijke architectuur invalshoeken, die van de organisaties en die ten aanzien van het stelsel zelf en de stelselvoorzieningen. Zie onderstaande figuur. + +![Alt text]({{ site.baseurl }}/assets/conpro.png) + +De architectuur wordt belicht aan de hand van het NORA vijflaagsmodel. Bij architectuur keuzes moet vanwege wendbaarheid en aanpassingsvermogen altijd meegenomen worden welke afhankelijkheden nu en in de toekomst zullen bestaan. + +**Grondslagen** + +De Grondslagenlaag beschrijft met welke methoden en standaarden invulling gegeven kan worden aan wet- en regelgeving die relevant is voor het stelsel. (bron: NORA) + +**Organisatie** + +Deze laag bevat architectuurcomponenten die relevant zijn voor het maken van de architectuur waarin de organisatorische aspecten in balans worden gebracht met de afgesproken diensten. (bron: NORA) + +**Informatie** + +Deze laag bevat architectuurcomponenten die relevant zijn voor het maken van de architectuur waarin de aspecten van informatie (zoals begrippen en informatiemodellen) in balans worden gebracht met de afgesproken diensten. (bron: NORA) + +**Applicaties** + +De Applicatie laag beschrijft met welke methoden en standaarden invulling gegeven wordt aan de applicatie\-architectuur. (bron: NORA) + +**IT-infrastructuur** + +De IT-infrastructuur laag beschrijft met welke methoden en standaarden invulling gegeven kan geven aan het fysieke transport van digitale gegevens (data) binnen het stelsel. (bron: NORA) + + +Grondslagen +------------- + +Zie onderdeel Grondslagen en juridisch kader waarin de relevante grondslagen zijn beschreven. De toegepaste standaarden om invulling te kunnen aan de grondslagen zijn te vinden in onderdeel Standaarden. + +Methoden om invulling te geven aan grondslagen (WAMS, WPG, AVG, WGS, WGPGA, WDO, Wmebv, EU data wetten) binnen het stelsel zijn: + +- Transitie van estafette model naar netwerkmodel, uitwisselen gebeurtenissen, inzage verstrekking, ketenindex/tijdslijnen +- Het Afsprakenstelsel Jeugd, Zorg en Veiligheidsdomein (bounded context) zelf +- Privacy by design benaderingen denk aan Data minimalisatie zoals gebruik van informatiearme berichten +- Privacy enhancing technologies, in opvolgende plateau’s, maar denk ook aan de huidige Middenvelder dienst +- Security by design + +Er zijn ook fundamentele grondslagen die zorgen dat organisaties in het Jeugd, Zorg en Veiligheidsdomein kunnen samenwerken, denk o.a. aan Europees Verdrag tot Bescherming van de Rechten van de Mens, Internationaal Verdrag voor de Rechten van het Kind, Jeugdwet 2015 en WAMS. + +Organisatie +------------- + +De organisatie voert een taak / wettelijke taak uit en beschikt over primaire en secondaire processen om daar uitvoering aan te geven. In deze context zijn de processen Verbinding aangaan, Samen onderzoeken, Samen Beslissen, Doen wat werkt en Samen leren relevant. Zodat er een toekomstbestendige, transparante en effectieve samenwerking ontstaat, met de burger en ketenpartners, digitaal ondersteund binnen één netwerk (netwerkmodel). Die samenwerking helpt om de taak van de organisatie uit te voeren en huidig ervaren knelpunten op te lossen. Zie de onderdelen Introductie, Werking van het stelsel en Samenwerkfuncties. + +Informatie +------------- + +Deze laag bevat architectuurcomponenten die relevant zijn voor het maken van de architectuur waarin de aspecten van informatie (zoals begrippen en informatiemodellen) in balans worden gebracht met de afgesproken diensten. (bron: NORA) + +De NORA schrijft dat deze laag architectuurcomponenten bevat zoals begrippen en informatiemodellen en het balans brengen daarvan met de afgesproken diensten. + +De afgesproken diensten zijn de diensten nodig voor de uitvoering van Samenwerkfuncties en worden door de organisaties aangeboden. De diensten maken gebruik van Samenwerkpatronen. Met de Samenwerkpatronen kan immers invulling gegeven worden aan Samenwerkfuncties en met de Samenwerkfuncties aan het Samenwerkproces. Naast de door organisaties aangeboden diensten zijn er centrale diensten, de Ketenvoorzieningen. Deze zijn nodig binnen de federatie om de complexiteit voor afzonderlijke aangesloten organisaties te verminderen. + +Om onderling federatief en effectief te kunnen samenwerken zijn informatiemodellen opgesteld per functie (zie @@@volgt) en een Begrippenmodel. Hoe we hier binnen het Afsprakenstelsel mee werken is vastgelegd in Afspraken. Zo eenvoudig is de architectuurinformatielaag van het Afsprakenstelsel. Dat is ook nodig omdat in een stelsel met zoveel organisaties eenvoud en complexiteitreductie essentieel is. + +### Bounded context +Binnen het Jeugd, Zorg en Veiligheidsdomein is er sprake van één bounded context. + +Een bounded context is een duidelijk afgebakend gebied waarin begrippen, afspraken en logica eenduidig en consistent zijn gedefinieerd. Alles wat binnen die grens valt, gebruikt dezelfde begrippen en modellen, maar buiten die context kunnen termen en implementaties anders zijn. Bounded context is een concept uit “Domain Driven Design”. Daarin wordt gesteld dat het onderkennen van bounded contexten belangrijk is omwille van consistentie en duidelijkheid van begrippen, isolatie van modellen, afstemming bedrijfsdoelen, beheersing van complexiteit, autonomie van partijen. + +Binnen de bounded context is het domeinmodel consistent, wordt een gemeenschappelijke taal gesproken en kan onafhankelijk van andere contexten worden ontwikkeld en onderhouden. Onder het domeinmodel verstaan we de kernconcepten en hun onderlinge relaties en bijbehorende termen, definities en (business) regels. Deze zijn binnen het domein gelijk voor iedereen en vormen de basis voor het ontwerp (en implementatie) van oplossingen. + +![Alt text]({{ site.baseurl }}/assets/bc.png) + +Omdat uitgegaan wordt van één gezamenlijk proces, waarbij services gelijk zijn, ongeachte de serviceprovider, kan uitgegaan worden van één begrippenkader en één data model. Dit resulteert in één conceptueel en logisch model waarin entiteiten, relaties en betekenissen gelijk zijn. Binnen de bounded context wordt gebruik gemaakt van dezelfde definities en (business) regels. + +Als toestandsveranderingen zich voordoen moet het domein op de hoogte worden gebracht. Betekent dat er sprake is van gebeurtenisgedrevenheid. Relevante toestandsveranderingen kunnen worden gebracht via meldingen en notificaties, of gehaald via services. Beide varianten moeten worden ondersteund. + +Daarbij geven basisprincipes uit moderne concepten als data-mesh aan dat de verantwoordelijkheid voor gegevens klip en klaar dienen te zijn. Dat geldt ook voor de data-lineage en herkomst van gegevens. Van gegevens moet altijd de context bekend zijn. Gegevens ontstaan in de context van een bedrijfsproces. Om die als informatie betekenisvol te kunnen hergebruiken en begrijpen in de samenwerking moeten ze eenduidig zijn. Uniforme begrippen zijn daarvoor onontbeerlijk. Dat gaat verder dan een woordenlijst: het gaat om de relaties tussen begrippen, op het niveau van professionals.   + +Gegevensbescherming is daarbij “by design” in het platform ingebed. Dit gaat verder dan onderlinge convenanten. De gegevensbescherming is ‘by design’ ingebed in de architectuur op het niveau van de professional, zijn taak, informatiebehoefte en doelbinding, en om wille van privacy leveren datadiensten voor sturing, informatie die niet herleidbaar zijn naar natuurlijke personen. + +De bronhouder en oorspronkelijke dienstverlener verschuift zijn aandacht van aansluiten op de keten naar het proactief en dienstverlenend beschikbaar stellen voor samenwerken. De ketenpartners zorgt voor het duurzaam beschikbaar houden, notificeren, ter inzage bieden en archiveren van informatie in het belang van de samenwerking. Archivering heeft een sterke relatie met bewaartermijnen. Daarbij kan het zo zijn dat verschillende organisaties of afdelingen verschillende bewaarregimes hanteren of wettelijk gezien moeten hanteren. Dit omdat gegevens in een bepaalde context vernietigd of juist gearchiveerd moeten worden. Verder geldt dat verschillende sectoren onderworpen kunnen zijn aan verschillende wettelijke bewaar- en vernietigplichten. + +In de architectuur rekening dat gegevens domein overschrijdend gebruikt moeten kunnen worden. Een organisatie zal immers te maken kunnen hebben met meerdere domeinen. Voor een aantal organisaties zal dit eerder standaard zijn dan de uitzondering. Dat doen we door gegevens met context en betekenis te kunne leveren, de ontkoppeling van data en processen, door het gebruik van standaarden en het gebruik van standaard koppelvlakken. + +### Consistentie van gegevens +Gedistribueerde systemen, zoals waar in het Jeugd Zorg en Veiligheidsdomein sprake van is, zullen moeten beslissen welke mate van consistentie van gegevens gehanteerd wordt of wenselijk is. In het Afsprakenstelsel gaan we er van uit dat gegevens niet strikt consistent kunnen zijn. Tenslotte kan het zo zijn dat gegevens niet tijdig zijn aangepast door alle deelnemende organisaties, bijvoorbeeld door een bepaalde verwerkingstijd of downtime van services. Zie CAP theorema; In deze theorie wordt gesteld dat in een gedistribueerd systeem twee van de drie volgende eigenschappen tegelijkertijd gegarandeerd kan worden: Consistentie (C), Beschikbaarheid (A), Partitietolerantie (P), waarbij een gedistribueerde systeem altijd partitietolerant dient te zijn. Daarom is het uitgangspunt dat er sprake moet zijn van uiteindelijke consistentie, waarbij tijdelijke inconsistenties worden toegestaan, maar dat gegarandeerd wordt dat alle deelnemers uiteindelijke dezelfde gegevenswaarden zullen hebben.  + +Om consistentie in het gedistribueerde systeem te beheersen, worden verschillende technieken toegepast: +- Gebeurtenis gestuurde communicatie: Gebruik van asynchrone berichtgeving om gegevenswijzigingen tussen services te propageren. +- Gebeurtenis stores: Door het opslaan van onwijzigbare (immutable) gebeurtenissen ontstaat een centrale, gezaghebbende bron van alle gebeurtenissen. De tijdlijn van events is altijd consistent, uitgaande dat events als atomaire transacties worden aangeboden aan de store. Het voordeel is dat deze tijdlijn direct een audittrail betreft. Het kunnen opvragen van events zorgt tevens voor een “replay” mogelijkheid, waardoor eventuele inconsistenties kunnen worden opgelost. +- CQRS (Command Query Responsibility Segregation): Scheiding van lees- en schrijfoperaties om consistentie-uitdagingen te verminderen. CQRS maakt het mogelijk om geoptimaliseerde query’s (al dan niet vooraf gedefinieerd) te draaien voor bepaalde use cases. +- Compenserende transacties: Implementatie van logica om inconsistenties te corrigeren wanneer ze worden gedetecteerd. + +Bij het bevragen van verschillende services, in het JZV domein, kan niet worden gegarandeerd dat een strikt consistent beeld wordt afgegeven. Het gevolg van een dergelijke “uncommitted read” is dat bij bevraging van verschillende bronnen een inconsistent beeld kan bestaan. De voorraad aan events (al dan niet verwerkt bij ketenpartners) echter geeft een consistent beeld. + +Applicatie +------------- + +NORA geeft aan dat de applicatielaag beschrijft met welke methoden en standaarden invulling gegeven wordt aan de applicatie\-architectuur. + +De standaarden zijn beschreven in het onderdeel Principes en standaarden. Een van de methoden waarmee invulling gegeven wordt aan de applicatie-architectuur is het Afsprakenstelsel zelf. Daarbij zijn de Besturingsrollen en Organisatorische rollen van belang, maar in de context van de architectuur vooral ook de Technische rollen. In  onderstaande figuur zijn deze schematisch weergeven. + +![Alt text]({{ site.baseurl }}/assets/rollen.png) + +### Aanbieden en afnemen systeemrollen +Er zijn de rollen van aanbieden en afnemen. Het zijn de deelnemende organisatie die informatie aanbieden, maar ook kunnen afnemen van andere organisaties. Hiervoor worden de Samenwerkpatronen en Standaarden gebruikt. Organisaties dienen deze patronen en standaarden te ondersteunen alsmede het informatiemodel en begrippenkader. Wat daarvoor nodig is kan worden nagegaan via onderdeel Aansluiten en Impactbepaling. + +De zaaksystemen / dossiersystemen / primaire processystemen van de organisaties van belang voor deze rol en van nog groter belang is de data (zie Informatielaag) welke deze verwerken. Vanuit architectuur bezien is ontkoppeling van werkprocessen, applicaties en data het uitgangspunt (zie Common Ground). Wanneer dit goed is ingevuld kan data eenvoudig beschikbaar gesteld worden aan de eigen systemen en die van andere organisaties waar toegestaan. + +Andersom moeten de zaaksystemen / dossiersystemen / primaire processystemen van de organisatie data kunnen bevragen bij de bron. Ook moeten ze zorgen dat data op een juiste wijze wordt opgeslagen in de datalaag, denk aan de kwaliteit van de data, aan metadatering, etc. + +### Vertrouwenssysteemrollen +Er is sprake van samenwerking in een federatief verband. Bij federatie speelt vertrouwen een belangrijke rol. Er zijn daarom vertrouwenssysteemrollen en voorzieningen. Organisaties zijn zelf verantwoordelijk voor authenticatie en autorisatie, echter zijn er rollen die zorgen voor waarborgen zoals de ledenaministrator en verzekeraar betrouwbaarheid, maar zijn er ook rollen waar voorzieningen worden geleverd zoals vanuit de vertrouwensleverancier (PKIoverheid, maar denk ook aan leverancier voor IDP lokalisatie) en bevoegde uitgever (van attesten en tokens). Zie onderdeel Toegang en Policy-based Access Control. + +### Beheersysteemfuncties +Naast de stelselbeheer welke technische rollen toekent, zijn er ketenvoorzieningbeheerders welke de ketenvoorzieningen leveren. Er zijn verschillende typen ketenvoorzieningen: +- Voorzieningen voor lokalisatie (vindbaarheid) +- Voorzieningen voor aanleveren en ophalen van gebeurtenissen (connectiviteit en uitwisseling) +- Voorzieningen voor transformatie, o.a. van oude (estafette) naar nieuwe (netwerk) model (de zogenoemde Sylvester dienst(en)) + +Opmerking: "Sylvester" is een andere naam voor Oudejaarsavond, de dag voor Nieuwjaarsdag (31 december). De term is vernoemd naar Paus Silvester I, wiens feestdag op 31 december valt. + +De ketenvoorzieningen vullen de intermediar functie in zoals gedefinieerd binnen Common Ground. Zie navolgende figuur (bron: VNG). + +![Alt text]({{ site.baseurl }}/assets/comg1.png) + +Merk op dat REST-API verkeer volledig decentraal verloopt, dat wil zeggen dat zonder dat er hiervoor ketenvoorzieningen nodig zijn. Slechts een optionele ketenvoorziening, de API catalog, speelt hier een rol voor de vindbaarheid van REST-API. Beter gesteld de vindbaarheid van de decentrale API Catalogs / DevPortals want daarnaar verwijst de keten API Catalog. Deze decentrale opzet is mogelijk zonder dat complexiteit voor organisaties ontstaat, sterker het reduceert deze. Verder sluit deze benadering aan bij de keuze en wens: afspraken voor standaarden en standaarden voor diensten. + +Bij de uitwisseling van gebeurtenissen is wel sprake van een ketenvoorziening, namelijk om gebeurtenissen aan te leveren dan wel op te halen, zie onderdeel Techniek.  Deze voorziening is nodig: +- om adressering complexiteit te reduceren, anders zou elke organisatie zich afzonderlijk moeten kunnen abonneren op channels/topics bij elke andere organisatie in het stelsel +- omdat anders elke organisatie gebeurtenissen afzonderlijk zou moeten persisteren en bevraagbaar moeten maken +- omdat anders elke organisatie complexe onweerlegbare vastlegging van gebeurtenissen persistentie en provenance zou moeten kunnen leveren +- het aan elkaar relateren van gebeurtenissen anders gedistribueerd zou moeten plaatsen vinden wat een hoge complexiteit kent + +Het wil niet zeggen dat organisaties dit niet zelf kunnen. Zeker organisaties met een interne of externe ICT dienstverlener van hoge kwaliteit en met hoog kennisniveau zouden dit kunnen invullen, echter maakt de inzet van een ketenvoorziening het voor alle partijen een stuk eenvoudiger en minder complex. Dit is essentieel gelet het aanzienlijke aantal partijen in het domein en de wisselende omvang en expertise niveau van de gerelateerde ICT dienstverleners. + +IT-infrastructuur +------------- + +NORA geeft aan dat de IT-infrastructuurlaag beschrijft met welke methoden en standaarden invulling gegeven wordt aan het fysieke transport van digitale gegevens (data) binnen het stelsel. + +Gelet het aantal organisaties binnen het stelsel en de diversiteit daarin wordt het fysieke transport gerealiseerd via het internet via de daaraan gelieerde standaarden zoals TCP/IP, HTTPS, etc. Voor transport over de fysieke netwerkdrager wordt FSC gebruikt (voor vercijfert transport op basis van contracten). + +Elke organisatie beschikt over een eigen IT-infrastructuur. Deze zullen op verschillende manieren zijn ingericht, wat ook geen probleem is zolang deze maar compatibel zijn met de standaarden en afspraken. + +Bepaalde ketenvoorzieningen zouden als onderdeel van de IT-infrastructuurlaag gezien kunnen worden, met name in het kader van het fysiek transport van digitale gegevens (CORV2). Omdat CORV2 echter meer levert dan transport is deze gepositioneerd binnen de applicatielaag. + +Decentraal kunnen organisaties beschikken over Firewalls, Web Application Firewalls, Proxies, Reverse Proxies, API Gateways, API Management oplossingen, ebMS Gateways, IDP’s, etc. Deze vallen onder de architectuur van de betreffende organisaties en beschrijving daarvan is hier niet wenselijk en nodig. + +Common Ground +------------- + +Common Ground draait in de kern om een structurele hervorming van de gemeentelijke informatievoorziening, door op een andere manier om te gaan met gegevens. De basisgedachte van Common Ground is: +- data worden losgekoppeld van werkprocessen en applicaties. +- data worden bevraagd bij de bron, in plaats van ze veelvuldig te kopiëren en op te slaan. + +Om dit te realiseren, werken partijen samen op basis van vier uitgangspunten: +- gegevens worden uniform gemaakt; +- gegevens worden opgehaald met API’s; +- er wordt gewerkt met één gemeenschappelijke integratielaag; +- data blijven in de bron. + +Centraal staat het onderscheid tussen dienstafnemers en dienstenaanbieders. Data is ontkoppelt van diensten en van procesinrichting (en dus ook van applicaties) en interactie. Communicatie tussen dienstafnemers en dienstenaanbieders vindt plaats via een intermediair. Zie onderstaande figuur (bron: VNG). + +![Alt text]({{ site.baseurl }}/assets/comg2.png) + +Navolgende figuur (bron: VNG) schetst dit in meer detail. Zie voor informatie de site van de VNG rond Commond ground. + +![Alt text]({{ site.baseurl }}/assets/comg3.png) diff --git a/_posts/2025-09-28-techniek.md b/_posts/2025-09-28-techniek.md new file mode 100644 index 0000000000..750e45f015 --- /dev/null +++ b/_posts/2025-09-28-techniek.md @@ -0,0 +1,469 @@ +--- +title: Techniek +author: lg +date: 2025-09-29 +category: Jekyll +layout: post +--- + +Introductie. Binnen de jeugd, zorg en veiligheidsketens willen we flexibel en transparant digitaal samenwerken. Dat lukt met miljoenen burgers en tussen de honderden partners in het sociaal domein alleen als we dat standaardiseren. Daarvoor ontwikkelden we 15 standaard samenwerkfuncties, digitale gereedschappen die iedere partner kan opnemen in zijn eigen casussysteem. + +De huidige digitale infrastructuur CORV, de collectieve opdracht routeervoorziening, moeten we verbeteren om die nieuwe samenwerking te ondersteunen. Samenwerken volgens CORV nú werkt als een estafette: van een verzender wordt een opdrachtbericht naar een ontvanger gestuurd, die een resultaatbericht terugstuurt. In die berichten zit veel informatie. De ontvanger bewaart en hergebruikt die informatie. + +Nadelen van deze manier van samenwerken zijn: +1. Andere professionals en burgers hebben geen weet van die opdracht of resultaat en ze hebben geen toegang tot de informatie die erin staat +2. De verzender van een bericht kan de kwaliteit en actualiteit van de kopie niet waarborgen +3. De verzender van een bericht heeft geen controle over het gebruik van zijn informatie + +Deze nadelen gaan we verhelpen in de volgende versie van CORV: CORV 2.0. We breiden CORV uit met 2 nieuwe gegevensuitwisselingen: Notificeren en Inzien (aanvullend op de bestaande gegevensuitwisseling Opdracht). + +Notificeren wordt gebruikt om andere professionals en burgers te laten weten wat er in de samenwerking gebeurt. De aanbieder van een samenwerkfunctie deelt de gebeurtenissen bij iedere verandering. Een ontvanger kan zich daarop abonneren. Zo’n notificatie is informatie-arm: ze bevatten precies genoeg informatie om te bepalen of ze relevant kunnen zijn voor de ontvanger. De notificaties worden gemaakt volgens de standaard ‘CloudEvents’. De voordelen van zo’n notificatie zijn: +1. Doordat je actief wordt geïnformeerd, kun je besluiten te anticiperen op, of parallel te werken met partners +2. Doordat je fijnmazig op de hoogte bent, kun je flexibel reageren in kleine acties +3. Je kunt gericht werken, besluiten wanneer en waarover je contact zoekt en informatie deelt + +Inzien betekent dat een aanbieder gegevensdiensten vanuit zijn bron, zijn casussysteem, aanbiedt. Dit kan zowel spontaan als op basis van een Notificatie worden opgevraagd. Inzien verloopt via de Digikoppeling standaard (Digikoppeling Koppelvlakstandaard REST-API). De voordelen van Inzien zijn: +1. De ketenafhankelijkheid vermindert: je kunt op ieder gewenst moment met actuele informatie werken +2. De transparantie en traceerbaarheid van de overheid neemt toe doordat ook historische informatie op termijn betrouwbaar beschikbaar is +3. Zo kunnen alle professionals in het eigen casussysteem werken en tegelijk een virtueel “dossier” inzien, opgebouwd door inzage bij bronnen van anderen. +4. En de burger heeft inzage en kan participeren via een te realiseren burgervoorziening. +5. Hiermee ontstaat een betrouwbaar integraal beeld van de kennis in het netwerk voor wie dat nodig heeft + +Dit alles staat of valt natuurlijk met vertrouwen. Daarvoor gaan we in CORV 2.0 de identiteit (wie je bent) en autorisatie (wat je mag) van de afnemer door de aanbieder laten controleren. Daarvoor stappen we naar een schaalbare, beheerbare afsprakenstelsel van toegang verlenen op persoonsniveau. We omarmen daarbij de Europese en Nederlandse toegangsstandaards, voor zowel de burger als voor de professional. Voor de burgers bijvoorbeeld DigiD, eHerkenning en de Wallet. Voor professionals de federatieve toegangsoplossingen van het zorg, gemeentelijk en justitieel domein. En we gaan convenanten en doelbinding vertalen in autorisatieregels. + +De voordelen van dit zero trust beveiligingsmodel zijn: +- Geautomatiseerde toegangsverlening wordt mogelijk door vooraf afgesproken autorisatieregels +- Toename van privacy: met informatie bij de bron kan de aanbieder fijnmazig, contextueel en adaptief toegang verlenen +- Je krijgt pas toegang tot Opdrachten, Notificaties en Inzage als je identiteit, bevoegdheid en doelbinding digitaal is aangetoond. + +CORV 2.0 vraagt een stevige verandering voor partners en pakketleveranciers. Partners moeten via een nieuw ontkoppelpunt, een API gateway, op CORV 2.0 aansluiten. Op dat ontkoppelpunt zijn de diensten gepubliceerd die je gebruikt, wordt de identiteit en toegang gecontroleerd en de data beschikbaar gesteld. Pakketleveranciers moeten de samenwerkfuncties met Notificaties, Abonnementen en Inzien/Inzage in hun pakket implementeren. + +Aanbieders en Afnemers kunnen, op basis van de gestandaardiseerde bouwstenen en uitwisselstandaarden, veel samen af. Vertrekpunt is daarom dat CORV 2.0 federatief en gedecentraliseerd kan werken. Toch voorzien we ook ondersteunende functies in het midden op CORV 2.0 . We denken dan aan: + +- Een toegangscatalogus met de identiteit van instanties, professionals en centrale autorisatieregels +- Een dienstencatalogus met een centraal overzicht van beschikbare (data)diensten +- Een Herkomst en Notificatie register: waarin gebeurtenissen worden gelogd +- Tot slot Silvester diensten: tijdelijke diensten die helpen de migratie naar CORV 2.0 te maken + +CORV 2.0 (CORV2) wordt zo een gedistribueerde oplossing van API en gebeurtenissen-voorzieningen. Daarmee maken we weer een belangrijke stap naar netwerksamenwerking onder de vingertoppen. + +CORV1 +------------- + +> ##### Consultatie +{: .block-warning } + +CORV (Collectieve Opdracht Routeer Voorziening) verbindt sinds de decentralisaties rond 2015 de gemeentewereld, zorgwereld en justitiewereld om bilateraal berichten te kunnen uitwisselen. Ketenpartners hebben een aansluiting op de CORV via het gemeente, zorg of justitienet. Het betreft een centrale dienst in het zogenoemde hub-spoke model. De routeervoorziening is de centrale hub waar de spokes, lees de verschillende organisaties zijn aangesloten. Via CORV worden berichten tussen organisaties uitgewisseld op basis van asynchroon berichtenverkeer (ebMS). CORV maakt gebruik van een push-push patroon. Dat betekent dat berichten van de melder naar CORV worden geduwd, waarbij CORV vervolgens de berichten ook duwt naar de ontvanger. CORV kent verschillende aanvullende services, naast routeren, denk bijvoorbeeld aan vertalen en monitoring. + +De CORV voorziening is gebaseerd op het justitiële service interface (JSI) platform. Dit platform bestaat uit bibliotheken (libraries), componenten, die het realiseren van workflow, translatie en transformatie snel en gestandaardiseerd kunnen. De JSI kent verschillende gestandaardiseerde bouwstenen om service orkestratie, (gegevens)translatie en (protocol)transformatie te realiseren. De JSI componenten zijn gebaseerd op de programmeertaal Python. + +CORV ondersteunt het estafette informatie model goed, maar doet dit vooral op basis van een verouderend protocol (ebMS) en een verouderende methodiek ebMS/WUS berichtenuitwisseling. Die veroudering zorgt (op termijn) voor beperkte ondersteuning door leveranciers, minder makkelijk aan te trekken talent dat kennis van heeft van deze techniek, beperkte ondersteuning voor nieuwe wensen en benodigdheden zoals netwerkmodel ondersteuning en ondersteuning van gebeurtenisgedrevenheid. + +Vandaar dat CORV2 ontwikkelt wordt. CORV2 ondersteunt zowel estafette model als netwerkmodel, zowel ebMS als REST API, zowel berichten als vraag-antwoord (REST API) als gebeurtenissen (events). CORV2 zal op termijn geen ebMS/WUS meer ondersteunen. Die termijn zal naar verwachting echter minimaal een decennium zijn. Vandaar dat CORV2 ook een overbruggingsdienst zal bevatten of deze naast CORV2 gepositioneerd zijn. Deze overbruggingsdienst is ook wel bekend onder de naam Silvester. Deze dienst zal berichten conform estafette model kunnen omzetten naar berichten/events conform netwerkmodel en vice versa. Dus ebMS berichten kunnen omzetten naar REST API berichten of events en andersom. + +Via het afsprakenstelsel wordt invulling gegeven aan het netwerkmodel. CORV2 is daarbij een, zei het essentieel, hulpmiddel. + +Overwegingen CORV2 +------------- + +> ##### Consultatie +{: .block-warning } + + +### CQRS +CQRS (Command Query Responsibility Segregation) is een architecturaal patroon dat lees- en schrijfoperaties in een systeem scheidt. Het belangrijkste principe is dat methoden die de status van een systeem wijzigen (commands en events) gescheiden worden van methoden die data opvragen (queries). + +CQRS is een belangrijke stap in event-gedreven oplossingen om verschillende redenen: +- Het verbetert de schaalbaarheid door lees- en schrijfworkloads onafhankelijk te kunnen schalen. +- Het maakt optimalisatie mogelijk van datamodellen voor specifieke use cases, met aparte schema's voor lezen en schrijven. +- Het vereenvoudigt de integratie met event sourcing, waarbij alle statuswijzigingen als events worden opgeslagen. +- Het ondersteunt betere prestaties en flexibiliteit in complexe domeinen door gespecialiseerde lees- en schrijfmodellen te gebruiken. +- Het verbetert de beveiliging door de toegang tot schrijfoperaties beter te kunnen controleren. + +Als een dergelijke CQRS data bron wordt opgenomen in bijvoorbeeld een NoSQL oplossing als graph ontstaan er meerdere voordelen: +- Verbeterde zoekbaarheid: Gegevens zijn eenvoudiger te vinden door geoptimaliseerde opslag en indexering. +- Flexibele datarelaties: Alternatieve dataformaten zoals NoSQL en graph databases maken het leggen en bevragen van complexe relaties tussen gegevens eenvoudiger. +- Snellere query-uitvoering: Geoptimaliseerde indexering zorgt voor efficiënte zoekopdrachten, inclusief mogelijkheden voor full-text zoeken, fuzzy search en geavanceerde zoekfuncties. +- Kunstmatige intelligentie en machine learning: AI en machine learning kunnen patronen en relaties in grote datasets ontdekken, voorspellingen doen over systeemuitval of prestatieknelpunten, en data-gedreven beslissingen ondersteunen. +- Efficiëntere analyse: Het gebruik van flexibele dataformaten vergemakkelijkt het analyseren en verbinden van gegevens, waardoor diepgaandere inzichten mogelijk zijn. + +### Ontkoppeling via REST API, ook voor events +Gebruik van een API layer / API Proxy ontkoppelt en voorkomt het implementeren van business logica op een centrale plek (dus in CORV2). Het is een generieke best practice geen business logica op een centrale plek te realiseren en zeker niet binnen een federatieve omgeving. Door een REST API-koppelvlak te implementeren, creëren organisaties een uniforme interface voor het lezen en schrijven van events. Dit bevordert de consistentie in dataverwerking en vereenvoudigt de integratie met diverse systemen en applicaties. Het API-koppelvlak fungeert als een abstractielaag, waardoor onderliggende complexiteiten van event storage en retrieval worden verborgen voor de consumenten van de API. Veelal gaan we uit van een request / response REST API koppelvlak. Een API kan ook een event koppelvlak bezitten. REST API’s kunnen geïntegreerd zijn in Even Brokers. REST API’s kunnen zcih registeren op webhooks om asynchrone notificaties te ontvangen zodat een polling mechanisme niet nodig is. + +### Graph database +Wanneer een graph database wordt gebruikt als event store, ontstaan er enkele unieke voordelen: +- Rijke relaties: Graph databases kunnen complexe relaties tussen events en entiteiten efficiënt modelleren en bevragen. +- Flexibele queries: Het maakt geavanceerde traversals en patroonherkenning mogelijk tussen gerelateerde events. +- Schaalbaarheid: Graph databases presteren goed bij het verwerken van grote hoeveelheden onderling verbonden data. +- Contextbehoud: De graph-structuur helpt bij het behouden van de context rond events. + +CORV2 is daarom gebaat bij de toepassing van graph database als event store. + +### Data lineage / Data provenance +Data lineage of data provenance is het vastleggen van de volledige levenscyclus van gegevens, van hun oorsprong tot hun huidige staat, en het is belangrijk om verschillende redenen. Ten eerste helpt het bij het verifiëren van de datakwaliteit en betrouwbaarheid door een duidelijke geschiedenis van transformaties te bieden. Daarnaast maakt het de dataverwerking transparant en houdt het gegevensverwerkers verantwoordelijk voor hun acties, wat bijdraagt aan de integriteit van gegevens. + +Bovendien ondersteunt data lineage organisaties bij het voldoen aan wettelijke en industriële standaarden door de nauwkeurigheid en legitimiteit van gegevens te waarborgen. Het stelt ontwikkelaars en data-analisten ook in staat om de oorsprong en transformatie van gegevens te traceren, waardoor fouten efficiënt kunnen worden opgespoord en gecorrigeerd. Dit proces helpt verder bij het opbouwen van vertrouwen in de gegevens door de herkomst en authenticiteit ervan te bevestigen. Tot slot bevordert data lineage de reproduceerbaarheid van onderzoeksresultaten door een gedetailleerde trail van gegevensbewerkingen te bieden. Hierdoor kunnen organisaties de integriteit van hun gegevens waarborgen, besluitvorming ondersteunen en voldoen aan steeds strengere eisen op het gebied van gegevensbeheer en privacy. + +Event stores passen goed bij data lineage of data provenance om verschillende redenen: +- Chronologische vastlegging: Event stores leggen gebeurtenissen chronologisch vast, wat perfect aansluit bij het traceren van de herkomst en transformatie van data over tijd. +- Onveranderlijke geschiedenis: Events worden opgeslagen in een onveranderlijk formaat, waardoor een betrouwbare en volledige historische weergave van alle datawijzigingen behouden blijft. +- Gedetailleerde tracking: Elke datawijziging wordt als een afzonderlijk event opgeslagen, wat een zeer gedetailleerd inzicht geeft in hoe data is getransformeerd en verplaatst. +- Reconstructie van toestanden: Door events sequentieel af te spelen, kan de toestand van data op elk willekeurig moment in de geschiedenis worden gereconstrueerd. +- Foutcorrectie en audittrail: Event stores bieden mechanismen voor foutcorrectie zonder de originele events te wijzigen, wat cruciaal is voor nauwkeurige data lineage. +- Flexibiliteit in analyse: De eventgebaseerde structuur maakt het gemakkelijk om complexe queries uit te voeren en datastromen te analyseren, wat essentieel is voor data provenance. + +### Event Datamodel +Het is essentieel dat er een gestandaardiseerd keten Event Datamodel toegepast wordt en dat model wordt beheerd. Standaardisatie van het event data model biedt verschillende voordelen voor organisaties die event sourcing toepassen. + +Ten eerste zorgt een gestandaardiseerd event datamodel voor consistentie en interoperabiliteit binnen en tussen systemen. Dit maakt het gemakkelijker om events uit te wisselen, te verwerken en te interpreteren, ongeacht waar ze zijn gegenereerd of worden gebruikt. Standaardisatie bevordert ook de schaalbaarheid en flexibiliteit van event-gebaseerde systemen, omdat nieuwe componenten of diensten eenvoudiger kunnen worden geïntegreerd wanneer ze een gemeenschappelijk datamodel volgen. + +Daarnaast is het juiste beheer van het event data model cruciaal voor de langetermijnwaarde en bruikbaarheid van de opgeslagen events. Events zijn immers de onveranderlijke feiten die de basis vormen van het systeem. Een goed beheerd datamodel zorgt ervoor dat events begrijpelijk en bruikbaar blijven, zelfs als de systemen en processen eromheen evolueren. Dit is vooral belangrijk omdat events vaak worden gebruikt om de volledige geschiedenis van een systeem te reconstrueren of om complexe analyses uit te voeren. + +Het beheer van het event data model moet rekening houden met de dynamische aard van bedrijfsprocessen en datarelaties. Entiteiten en hun relaties kunnen veranderen over tijd, en het datamodel moet flexibel genoeg zijn om deze veranderingen te accommoderen zonder de integriteit van historische data te compromitteren. Dit vereist een zorgvuldige aanpak van datamanagement, waarbij veranderingen in het model worden gedocumenteerd en backward compatibility wordt gewaarborgd. + +Door een gestandaardiseerd en goed beheerd event data model te hanteren, kunnen organisaties de volle potentie van event sourcing benutten. Het stelt hen in staat om betrouwbare audit trails te maintainen, complexe analyses uit te voeren, en systemen te bouwen die robuust en aanpasbaar zijn aan veranderende zakelijke behoeften. + + +Gebeurtenissen (events) +------------- + +![Alt text]({{ site.baseurl }}/assets/eventshl.png) + +> ##### Consultatie +{: .block-warning } + +### Identificeren en uitsturen van gebeurtenissen +Binnen het stelsel willen we gebeurtenissen kunnen delen. Bijvoorbeeld: “Wij Politie hebben zojuist melding xyz gedaan bij Veilig Thuis”. Een eerste vraag is dan hoe we gebeurtenissen kunnen identificeren en uitsturen vanuit de bron, lees het systeem dat de desbetreffende partij gebruikt. Hier zijn grosso modo de volgende mogelijke manieren voor: +1. Het (business/zaak)systeem ondersteunt native het genereren en uitsturen van events. +2. Het (business/zaak)systeem ondersteunt eventcreatie en verzending nog niet, maar dit kan in het systeem worden ingebouwd. +3. Het (business/zaak)systeem ondersteunt eventcreatie en verzending niet, maar met ‘External Event Capture’ functionaliteit kunnen alsnog events worden gegenereerd en uitgestuurd. + +Denk bij dit laatste aan het monitoren van applicatie logging (log scraping), database triggers/capture (CDC) of automation hooks (RPA of automation tool). Zodoende kunnen events worden geïdentificeerd, geëxporteerd, onderschept of gesynthetiseerd en vervolgens worden uitgestuurd. + + +> ##### Consultatie +{: .block-warning } + +### Gebeurtenissen vormgeven en verzenden +Een gebeurtenis wordt vormgeven binnen de CloudEvents standaard en conform het NL GOV profile for CloudEvents. De daadwerkelijke inhoud is afgeleid van het betreffende informatiemodel van de betreffende samenwerkfunctie (zie Samenwerkfuncties). Objecten en attributen volgen waar afgesproken de definities van het Begrippenkader. + +De gebeurtenis wordt verzonden naar de CORV2 event broker. Deze biedt hiervoor een REST API aan (REST API Proxy naar Event Platform event-log/topic). De REST API wordt aangeroepen en het event via deze API aangeleverd. De REST API is beschreven in het API Management DevPortal van CORV2. + + + +> ##### Consultatie +{: .block-warning } + +### Gebeurtenissen ontvangen en interpreteren +De organisatie welke gebeurtenissen wil of moet ontvangen, heeft het ontvangen daarvan in eigen hand. De organisatie kan via de betreffende REST API (REST API Proxy naar Event Platform event-log/topic) een ‘pull’ actie uitvoeren en zodoende (relevante) gebeurtenissen ophalen. + +Uiteraard is toegang nodig tot deze REST API en de gebeurtenissen. Wat betreft gebeurtenissen zijn hier twee varianten: +1. De betreffende gebeurtenissen zijn voor de gehele keten toegankelijk. Merk op dat de gebeurtenis (het event) weinig informatie bevat en er een inzage verzoek nodig is voor meer informatie. +2. De betreffende gebeurtenissen zijn alleen toegankelijk voor partijen die een toegangsverzoek hebben gedaan, dat is gehonoreerd. Zij ontvangen dan een token waarmee de gebeurtenissen toegankelijk worden. Ook hier zal doorgaans een inzage verzoek nodig zijn voor meer informatie. + +Het genoemde inzage verzoek kent een eigen toegangsverleningsproces (authenticatie/autorisatie). + +Interpretatie van gebeurtenissen wordt gefaciliteerd door enerzijds de CloudEvent standaard. De REST API response bevat de in de CloudEvents standaard en conform het NL GOV profile for CloudEvents vormgegeven event. Anderzijds door event informatiemodel. Dit gaat over wat in het Cloud Event wordt geplaatst (welke attributen/headers). Dit is ook wel bekend onder de noemer Schema registry pattern. Een Schema registry levert versioning en backward and forward compatibility. Verder wordt de interpretatie gefaciliteerd door het informatiemodel en daarmee ook door de definitie van objecten en attributen conform het keten Begrippenkader en door de samenwerkfunctie (zie Samenwerkfuncties). + + + +> ##### Consultatie +{: .block-warning } + +### Gebeurtenissen verwerken +Ontvangen en (kunnen) interpreteren is niet voldoende. Gebeurtenissen moeten kunnen worden verwerkt in het (business/zaak)systeem. Hier zijn grosso modo de volgende mogelijke manieren voor: +1. Het (business/zaak)systeem ondersteunt native events subscription en verwerking. Het systeem kan de events verwerken, ‘parsen’ en acties nemen op basis van de inhoud van de events. +2. Het (business/zaak)systeem ondersteunt events subscription en verwerking nog niet, maar dit kan in het systeem worden ingebouwd. +3. Het (business/zaak)systeem ondersteunt eventcreatie en verzending niet, maar met ‘middleware services’ kunnen de events alsnog worden verwerkt en acties uitgezet worden, bijvoorbeeld door transformatie naar systeem API calls, system calls, database mutaties of UI automation acties. + +Onderdeel van de verwerking van gebeurtenissen is het analyseren daarvan via bijvoorbeeld business rules of workflow engines. Op basis van de analyse kunnen acties worden uitgezet (binnen het systeem / de applicatie). Dit kan binnen de applicatie zelf of binnen daarvoor bestemde (middleware) services. + +### Gebeurtenissen routeren +Binnen het stelsel moeten gebeurtenissen tussen verschillende organisaties uitgewisseld kunnen worden. Technisch bezien zou dat direct kunnen, dus zonder centrale of gedeelde voorzieningen. In praktische zin echter niet gelet onder andere complexiteit en schaalbaarheid. Er is voor de uitwisseling van gebeurtenissen dus een gedeelde voorziening nodig (CORV2). + +De uitwisseling en routering van de gebeurtenissen kan in een publish/subscribe (pub/sub)model. Doorgaans wordt hiervoor gekozen wanneer sprake is van gelijksoortige omgevingen en daardoor ook native pub/sub interfaces gebruikt kunnen worden, of wanneer het aantal organisaties waarmee wordt uitgewisseld beperkt is. In dit geval is van geen van beide sprake. Vandaar dat gekozen wordt voor een benadering in hogere mate loosely coupled is dan pub/sub. Die benadering maakt gebruik van REST API interfaces die voor de logg/stream/topic interfaces geplaatst worden en van het push/pull model (in plaats van pub/sub). Organisaties (event producers) sturen gebeurtenissen via een gedefinieerde standaard REST API naar de Event Hub (CORV2), ontvangende organisaties (consumers) bevragen (pull) de Event Hub op nieuwe berichten. + + +Bevragingen en opdrachten (REST API) +------------- + +![Alt text]({{ site.baseurl }}/assets/apihl.png) + +> ##### Consultatie +{: .block-warning } + +### Identificeren en uitsturen van vraag of opdracht +Binnen het stelsel moet informatie opgevraagd kunnen worden of opdrachten uitgezet. Ook kan sprake zijn dat informatie moet worden gewijzigd of verwijderd. Meer technisch geformuleerd zouden we kunnen spreken over CRUD. CRUD staat voor Create, Read, Update en Delete. REST API’s zijn zeer geschikt voor dit type operaties. Op basis van het Keteninformatiemodel, het Begrippenmodel en Samenwerkingsfuncties en Samenwerkpatronen kunnen vragen of opdrachten worden samengesteld in de vorm van REST-API calls. + +Als reeds bekend is welke REST-API we nodig hebben kan deze worden aangeroepen. Als dit nog niet het geval is kan deze worden opgezocht door de API Catalog te raadplegen. + +De REST API’s calls kunnen direct vanuit het (zaak)systeem/applicatie worden gedaan of kunnen specifieke (micro)services worden ingezet. + + +> ##### Consultatie +{: .block-warning } + +### Vragen/opdrachten vormgeven en verzenden +De verwerking van de ontvangen response vindt plaats in het (zaak)systeem/applicatie of daaraan gerelateerde specifieke (micro)services. + +> ##### Concept +{: .block-danger } + +### Vragen/opdrachten verwerken +Aanbieders van de REST-API publiceren deze in hun API DevPortal. Daar is in meer detail na te gaan hoe de API calls vormgegeven dienen te worden, hoe toegang kan worden aangevraagd etc. Verder helpen het Keteninformatiemodel, het Begrippenmodel en Samenwerkingsfuncties en Samenwerkpatronen bij de vormgeving van de calls. Andersom helpen deze ook hoe de REST API’s door de aanbieder ervan gebouwd en aangeboden dienen te worden. + + +> ##### Consultatie +{: .block-warning } + +### Typen REST-API’s +Enerzijds zullen er wat resources-API’s genoemd worden zijn. Deze volgen de interne / domeinspecifieke resources met overeenkomstige duidelijke, consistente, zelfstandige naamwoorden (nouns) conform de API design rules. Deze zullen doorgaans worden geabstraheerd achter wat we keten-API’s noemen. Die volgen het afgesproken Keteninformatiemodel en het Begrippenkader en daarmee niet noodzakelijkerwijs de achterliggende resource benamingen (binnen het systeem/applicatie en het informatiemodel daarvan). Deze keten-API’s kunnen meerdere achterliggende resources-API’s benaderen om bijvoorbeeld het aantal API call’s te reduceren. De keten-API’s kunnen ook achterliggende business-API’s benaderen. Een business API richt zich op bredere bedrijfsprocessen of business capabilities als resource. In plaats van data-objecten op een lager niveau richt een business API zich op functionele eenheden die een businessdoel dienen. Dat in tegenstelling tot een resource-API welke is gebouwd rondom het concept van resources en daarmee van data entiteiten of objecten die via unieke URI's worden geïdentificeerd. + + +> ##### Consultatie +{: .block-warning } + +### Combinatie (zoals inzage na gebeurtenis) + +Binnen de Samenwerkfuncties zal nadrukkelijk ook een combinatie worden gebruikt. Een organisatie kan een notificatie doen (event uitsturen), andere organisaties kunnen op basis van het event een bevraging doen (REST-API). + +Deze werkwijze heeft als bijkomstig voordeel dat REST API authenticatie en autorisatie hergebruikt kan worden. Daardoor kan de complexiteit van het toegangslandschap worden gereduceerd. + +Werking CORV2 +------------- + +> ##### Consultatie +{: .block-warning } + +De werking van CORV2 is in meer detail hieronder uitgebeeld en beschreven. + +![Alt text]({{ site.baseurl }}/assets/corv2funct.png) + +Stappen: +1. Aanvragen van een autorisatie token voor event-log/topic (alleen voor gesloten topics) +2. Opvragen van het schema +3. Aanleveren van events (push) +4. Opvraag events insturen (pull initiatie), response bevat request-id +5. Opvragen event (pull) aan de hand van het request-id + +CORV2 componenten: +- **Schema registry** – Opslag van event data schema’s t.b.v. versioning, backward/forward compatibility, validatie en voorkomen van breaking changes +- **REST API (Proxy)** – Transformatie van event streams naar REST API voor ontkoppeling en abstractie +- **Event broker** – Ontvangen, routeren en doorgeven van events +- **House keeping service** – Opschonen, retentie van event logs/topics +- **Writer services** – Database en Blockchain writers voor (immutable en onweerlegbare) opslag van events + +Er wordt hiermee een asynchrone benadering gevolgd. Organisaties sturen events naar CORV2 (push), andere organisaties halen deze daar op (pull). De ‘pull’ vindt in twee stappen plaats (4 en 5 in de figuur). In de eerste stap geeft een organisatie aan in welke events deze organisatie interesse heeft. CORV geeft een request-id terug en gaat een query definiëren aan de hand van het verzoek. De organisatie vraagt met het request-id in een tweede stap of de events beschikbaar zijn. Als dat het geval is stuurt CORV2 het event of de events terug op basis van de query en het request-id. Deze benadering zorgt voor schaalbaarheid en performance. + +CORV2 slaat events op om de asynchrone bevraging daarvan mogelijk te maken. Primair slaat CORV2 de events echter op om een ketenindex van gebeurtenissen mogelijk te maken. Daarmee kunnen bijvoorbeeld gebeurtenistijdslijnen zichtbaar worden gemaakt. Bij de opslag wordt gezorgd dat verbanden tussen events kunnen worden gelegd , de events onveranderlijk zijn (immutable/ append only) en onweerlegbaar, maar ook dat events vindbaar en te ‘queryen’ zijn. Hiervoor worden verschillende technologieën toegepast: provenance, block chain en graph. + +Provenance: +W3C Provenance (PROV) is een standaard die beschrijft hoe je de herkomst, geschiedenis en afleiding van data kunt vastleggen en uitwisselen. Het draait om het modelleren van wie, wat, wanneer en hoe data is ontstaan of veranderd. + +Provenance betekent letterlijk "herkomst". In de context van data en W3C PROV gaat het om informatie over: +- Entiteiten: de data of objecten zelf. +- Activiteiten: processen of handelingen die data creëren, wijzigen of gebruiken. +- Agenten: personen, organisaties of systemen die verantwoordelijk zijn voor activiteiten. + +Naast deze kernelementen kent PROV-DM (het PROV Data Model) relaties: +- wasGeneratedBy: een entity is voortgebracht door een activiteit. +- wasDerivedFrom: een entity is afgeleid van een andere. +- wasAttributedTo: een entity is toegeschreven aan een agent. +- used: een activiteit gebruikte een entity. +- wasAssociatedWith: een activiteit werd uitgevoerd door een agent. + +De provenance-informatie helpt bij het beoordelen van de betrouwbaarheid, kwaliteit, verantwoordelijkheid en herleidbaarheid van data. + +Provenance wordt gebruikt om events in PROV-DM formaat op te slaan en relaties (een ketting van events) te kunnen makenDit gaat om het command deel van CQRS (zie eerdere toelichting CQRS). Voor het query deel wordt graph toegepast (zie verderop) + +Block chain: +Blockchain is een gedecentraliseerde digitale technologie waarmee gegevens veilig, transparant en onveranderlijk worden opgeslagen in blokken die met elkaar verbonden zijn in een keten. Hiermee wordt invulling geven aan de immutable-, append only- en onweerlegbaarheidsaspecten. + +Graph: +Een graph database is een type database waar gegevens opgeslagen kunnen worden in de vorm van knooppunten (nodes) en relaties (edges), waardoor complexe verbanden tussen data efficiënt en intuïtief kunnen worden gemodelleerd en geanalyseerd. De Graph wordt toegepast om events bevraagbaar te maken, of wel voor het query deel van CQRS. + +Koppelvlakken +------------- + +> ##### Consultatie +{: .block-warning } + +De asynchrone koppelvlakken van CORV2 zijn REST-API koppelvlakken i.v.m. ontkoppeling en hergebruik van de authenticatie en autorisatie aanpak en voorzieningen bij REST-API. + +Event worden beschreven conform CloudEvents en het NL GOV profile for CloudEvents. De API’s worden beschreven conform AsyncAPI + +CloudEvents beschrijft de minimale, gestandaardiseerde event‑envelope: welke contextvelden (specversion, id, source, type, datacontenttype, dataschema, extensions) er zijn en hoe die seraliseert in binary of structured mode. + +AsyncAPI is het OpenAPI‑achtige model voor asynchrone APIs: het beschrijft servers/brokers, channels (topics), berichten, operationele bindingen en payload‑schema’s; het dwingt de vorm van je API‑contract af en ondersteunt tooling zoals documentatie en codegeneratie. + +| Attribuut | CloudEvents | AsyncAPI | Combinatie | +|-----------------------|-----------------------------------------------------------------|----------------------------------------------------------------|------------------------------------------------------------------------------------------------------| +| Scope | Standaard voor event‑envelope / metadata | Specificatie voor volledige async API (channels, messages, servers) | Gebruik CloudEvents voor berichten; AsyncAPI voor documentatie van kanalen en contracten | +| Hoofddoel | Interoperabele event‑beschrijving | Ontwerp, documentatie en tooling voor messaging APIs | Documenteer CloudEvents‑gebaseerde events in AsyncAPI | +| Format / binding | Definieert contextvelden en serialisatie modes (binary/structured) | Beschrijft channels, bindings (Kafka, AMQP, HTTP) en berichtschema’s | Map CloudEvents velden naar bindings die AsyncAPI beschrijft | +| Schema en validatie | Verwijst naar dataschema (dataschema veld) maar specificeert geen payload‑DSL | Ondersteunt JSON Schema / Avro etc. voor payloads en genereert code/validators | Gebruik AsyncAPI om het payload‑schema (zoals JSON Schema) te hosten en te valideren. | +| Tooling | Geen | Tooling voor docs, codegen, mock servers en contract testing | Gebruik AsyncAPI tooling voor docs en contracttests en optioneel voor Event Catalog / DevPortal. | + + + + +Toegang +------------- + +> ##### Consultatie +{: .block-warning } + +Zowel bij gebeurtenissen als bij vraag- en antwoord patronen kan informatie pas worden gezien of geraadpleegd als er daartoe toegang is. De ontvangende of vragende partij zal zich moeten authentiseren (bewijzen wie je bent) en moeten worden geautoriseerd (toegangsrechten ontvangen) voor toegang. + +In voorliggende context gaat het vooral om toegangsverlening door de ene organisatie aan een andere organisatie. Binnen samenwerkingsverbanden/ketens wordt hierbij vrijwel altijd het concept van federatieve toegangsverlening toegepast. Federatieve toegangsverlening is een manier om op een veilige en gecontroleerde wijze toegang te regelen tot gegevens en systemen, waarbij meerdere organisaties samenwerken op basis van onderling vertrouwen. + +Er zijn verschillende manieren van toegangsverlening: +In toegangsverlening tussen overheden: +- Organisatie identificatie(nummer) en certificaat +- Persoon + Organisatie en rol (RBAC) +- Persoon + Attributen/claims/policies (ABAC/CBAC/PBAC) + +Bij toegangsverlening van bedrijven, intermediairs, eenmanszaken, stichtingen, etc. naar overheid of dienstaanbieders: +- eHerkenning - eHerkenning is een persoonsgebonden zakelijk inlogmiddel waarmee gebruikers namens hun organisatie veilig kunnen inloggen bij verschillende (overheids)diensten, zoals gemeenten, ministeries, verzekeraars en pensioenfondsen. + +Bij toegangsverlening van burger naar overheid of dienstaanbieders +- eIDAS (DigiD – het Nederlandse nationale inlogmiddel dat is aangesloten op eIDAS) +- Self Sovereign Identitity attributen + +Binnen federatieve toegangsverlening speelt vertrouwen een rol. Denk aan vertrouwen in verordeningen als eIDAS en hun implementatie, vertrouwen in de sterkte van inlogmiddelen, vertrouwen in claims en attributen zoals deze door een organisatie worden aangeleverd etc. + +### OIN en certificaat +Een veel toegepaste toegangsverlening bij system2system gegevensuitwisseling is op basis van Organisatie identifier (Organisatie-Identificatienummer (OIN)) en (PKI-Overheid)certificaat. Dit is dan ook wat we in het stelsel in eerste instantie zullen gaan toepassen. Een organisatie krijgt toegang op basis van OIN en certificaat en worden afspraken gemaakt wie toegang kan en mag krijgen. De aanvragende partij regelt deze toegang in en de leverende partij vertrouwd op de gemaakte afspraken en implementatie daarvan. Tussen beide partijen wordt een beveiligd en versleuteld communicatie opgezet op basis van de OIN’s en certificaten. Wat betreft certificaten is het gebruik van PKI-Overheid certificaten binnen het stelsel verplicht. + +### OIN en certificaat FSC variant +FSC is een standaard die beschrijft hoe (overheids)organisaties op een gestandaardiseerde, veilige en schaalbare manier gegevens met elkaar kunnen uitwisselen zonder afhankelijk te zijn van een centrale partij. FSC werkt op een zelfde manier als hiervoor beschreven bij OIN en certificaat maar belooft schaalbaarheid, en bevat mogelijkheden om afspraken (contracten) gedigitaliseerd te kunnen maken. Verder is FSC een voorgeschreven standaard (zie Forum Standaardisatie). FSC is een betrekkelijk nieuwe standaard. Zo zijn er eind 2025 nog weinig tot geen productionele inter-organisatie implementaties. De standaard wordt eind 2025 nog niet ondersteund door leveranciers. Wel is er een Open Source software implementatie beschikbaar (OpenFSC) waarmee organisatie kunnen testen. De verwachting is dat FSC gebruik in de toekomst zal groeien. Binnen het stelsel willen we FSC dan ook gaan ondersteunen en afhankelijk van de ontwikkelingen daar mogelijk volledig op over gaan in de toekomst. + +### Persoon + Organisatie en rol +In plaats van organisatie kan ook toegang worden verleend op basis van persoon, organisatie en rol (RBAC). RBAC kan in de praktijk leiden tot een explosie van rollen. De toepassing van RBAC kan een tussenstap zijn naar Attributen/claims/policies gebaseerde toegang. RBAC kan worden gestapeld op OIN en certificaat gebaseerde toegang. + +Een groot aantal rijksoverheid partijen waaronder JenV hebben een federatief stelsel waarin de verschillende gebruikersregistraties worden ontsloten via het SAML en OIDC/OAuth protocol. Personen in deze registraties kunnen op deze wijze geauthentiseerd worden. Personen kunnen inloggen met verschillende middelen en die middelen kunnen van verschillende sterkte zijn (denk aan password vs authenticator-app vs hardtoken). Er is dus ook verschil in betrouwbaarheidsniveau’s of wel Level of assurance (LOA). Zie in dit kader bijvoorbeeld het JenV Trustframework. + +### Attributen/claims/policies +Een andere benadering rond toegangsverlening is toegangsverlening op basis van attributen/claims/policies. De toegang vragende partij levert attributen/claims aan zoals wie het is die toegang wil, en bijvoorbeeld van welke organisatie deze persoon is, welke rol deze persoon heeft, aan welk dossier de toegangsaanvraag gelieerd is. De toegang verlenende partij beslist op basis van deze attributen/claims of de toegang verstrekt wordt. De toegang verlenende partij kan dat doen op basis van vooraf gedefinieerde policies. Dit type toegang is te stapelen op OIN en certificaat gebaseerde toegang. Binnen het stelsel willen we zoveel mogelijk naar deze manier van toegangsverlening bewegen. Ook hier geldt dat federatiebe stelsels en bijbehorende gebruikersregistraties kunnen worden gebruikt voor de toegangsverlening (zie beschrijving bij Persoon + Organisatie en rol). + +### Attributen/claims/policies FTV variant +Zoals FSC een variant is op het industriewijde mutual tls toegangsconcept (OIN/Certificaat benadering) en inmiddels een standaard. Zo wordt er ook gewerkt aan de FTV standaard als variant op het industriewijde ABAC/PBAC toegangsconcept en eveneens als standaard. FTV staat voor Federatieve Toegangsverlening. Het is een moderne standaard en methodiek om toegangsbeheer binnen het federatieve datastelsel (FDS) te organiseren. Aan FTV wordt eind 2025 nog gewerkt en de ontwikkeling zal tot in 2026 en mogelijk verder doorlopen. Ook FTV is te stapelen op FSC. De verwachting is dat FTV gebruik in de toekomst zal groeien. Binnen het stelsel willen we FTV dan ook gaan ondersteunen en afhankelijk van de ontwikkelingen daar mogelijk volledig op over gaan in de toekomst. + +FTV gebruikt AuthZEN als basisstandaard voor toegangsbeheer. AuthZEN is een open standaard binnen de OpenID Foundation die de interface standaardiseert tussen het Policy Enforcement Point (PEP) en het Policy Decision Point (PDP), wat essentieel is voor externalized authorization management. Het bevat een informatiemodel en APIs om toegangsbeslissingen real-time te maken op basis van wie toegang vraagt, wat wordt gevraagd, en in welke context dit plaatsvindt. FTV bouwt voort op AuthZEN voor het centraal beheren van toegangsregels en het maken van toegangsbeslissingen, waardoor toegang tot gegevens en diensten flexibel en veilig kan worden geregeld binnen federatieve omgevingen. + +### eHerkenning +eHerkenning is met name bedoeld voor toegang van bedrijven, intermediairs, eenmanszaken, stichtingen, etc. naar overheden en dienstaanbieders. Als hier binnen het stelsel sprake van is of gaat worden, dan zal eHerkenning voor deze toegangsverlening worden toegepast. + +DigiD en eHerkenning ondersteunen de SAML standaard. Voor de toekomst is de verwachting dat DigiD/eHerkenning ook de OpenID Connect en OAuth standaard zullen ondersteunen. Daar zullen we dan naar overstappen. Verder zal een (medewerker van) een bedrijf zich in de toekomst met een Wallet kunnen identificeren. + +### eIDAS /DigiD +eIDAS en DigiD zijn bedoeld voor digitale toegangsverlening waarbij de gebruiker zich online identificeert en authentiseert om toegang te krijgen tot digitale diensten van de overheid en organisaties met een publieke taak. Als hier binnen het stelsel sprake van is of gaat worden, dan zal eIDAS /DigiD voor deze toegangsverlening worden toegepast. + +DigiD en eHerkenning ondersteunen de SAML standaard. Voor de toekomst is de verwachting dat DigiD/eHerkenning ook de OpenID Connect en OAuth standaard zullen ondersteunen. Daar zullen we dan naar overstappen. Verder zal een burger zich in de toekomst met een Wallet kunnen identificeren, zie Self Sovereign Identitity. + +### Self Sovereign Identitity +Dit is een visie op identiteiten waarbij de gebruiker zelf centraal staat. De identiteit attributen zijn dan niet gebonden aan een specifieke partij of site. Ze zijn en blijven van en onder controle van de gebruiker. De gebruiker kan de eigen identiteit voorzien van allerlei verklaringen die deels van henzelf komen (bijv. email adres) en deels van andere partijen. Gebruikers bepalen zelf aan wie ze de verklaringen en gegevens verstrekken en er worden geen gegevens verstrekt die niet nodig zijn. +Deze visie is terug te vinden in een aantal Wallet (apps). + +Policy-Based Access Control +------------- + +> ##### Concept +{: .block-danger } + +Binnen het afsprakenstelsel wordt gebruik voor gegevensraadpleging gebruik  gemaakt van authenticatie, autorisatie en in een federatief model policy based model. De kern van het PBAC stelsel wordt beheerd door Vertrouwensleverancier en maakt gebruik van open-source componenten, waaronder Open Policy Agent (OPA). + +Het PBAC stelsel bestaat uit de volgende onderdelen: + +- **Policy Enforcement Point (PEP)** + Voert het toegangsbesluit uit. Het controleert of een gebruiker toegang krijgt en handhaaft het besluit (toestaan of weigeren). +- **Policy Decision Point (PDP)** + Neemt het toegangsbesluit. Het evalueert de beleidsregels op basis van de aanvraag en informatie van andere punten. +- **Policy Retrieval Point (PRP)** + Slaat de beleidsregels op en levert ze aan de PDP wanneer die een besluit moet nemen. +- **Policy Administration Point (PAP)** + Beheert en definieert de beleidsregels. Dit is de plek waar beheerders beleid aanmaken, wijzigen of verwijderen. +- **Policy Information Point (PIP)** + Verzamelt extra contextuele informatie (zoals gebruikersattributen of omgevingsgegevens) die nodig is voor de PDP om een besluit te nemen. + +Tevens uit: + +- **Autorisatieserver** + Verantwoordelijk voor het uitgeven en beheren van toegangsrechten (zoals tokens). Ze controleert de identiteit van gebruikers en bepaalt op basis van beleid of en welke toegang wordt verleend. +- **Resource-server** + Bevat de beschermde gegevens of diensten en verleent alleen toegang als de gebruiker een geldig toegangs- of autorisatietoken kan tonen, uitgegeven door de autorisatieserver. + +De **Audience** (doelgroep of ontvanger) is de partij waarvoor het access token bedoeld is — meestal de resource-server. + +![Alt text](//www.plantuml.com/plantuml/png/VPB1ZjCm48RlVGeh9rOeuiu1RTXKgo8E9Hk92nStcIPM7JiQZyl2qpEJh9MK1cvkv_jc_XdbCP16YeFTXOjneqOzgC4xt_Je1r244PHQrLeuwsYfXbSghEdS08vK0uu0cTlfXZogxCaQS9Gf7TJyv1f2Gzfr5bHMHAPCq6GW05u19vB_xL-cdxVqqLlJ_595EnXd0Y5htgcZDuv-k7V7ulWmwVpOz2eWD73LTb6gf5JRIWcD2JT3ocIKsyR1dJqEVoKx9EaWqeQr5wi1kU5YxPEr5wlLf4ywi5FoIzKUEkuHnZZ15GGVkKC-tsqM1IoQ1aAGgM_tp-EOVrgV-AFAQdy1fxMxejPTnl2gdBV-fsDZreN-yhrMSzkSHCpMtT5qFJ4kePbDCRdJRmyNIRf_gJyyenxxRr_LUyND7gI1yBc5CzsCUeOfKWjArXTEm6NAik44w_bp0i0t8ryljS1fagJypvYq-h7SsaKmhiX1x_SzGR3Ha302hUvocBWdxmXUoQIl1PGVEKCdrzmnioGi_y4Za8_e0C4jKrBWQf8-WmNJ1eGERE01lROppFKKkxmdxriN2MVnZZv1Fv6xHt1j7EmV) + +Er zijn verschillende inrichtingen mogelijk zoals volledige decentrale inrichting, een centrale inrichting en een hybride inrichting. Er worden beproevingen gedaan op dit vlak, voor nu wordt uitgegaan van een inrichting zoals hieronder beschreven. De kern daarvan is: **decentrale uitvoering en beslissen, centrale kaders en vertrouwen**. + +Decentrale componenten bij de organisaties zelf: + +- Vanzelfsprekend de Resource-server en PEP voor toepassen van de policies (verantwoordelijkheid) Bronhouder +- PDP, bij de resource-eigenaar voor autonome beslissingen; kan centrale regels inladen +- PIP, lokale bronattributen blijven bij de organisatie; er kan sprake zijn van externe en centrale bronattributen +- PAP, voor het definiëren van de lokale beleidsregels +- Autorisatieserver, verifieert identiteiten en levert claims/tokens, maakt onderdeel uit van toegangsfederatie en kan verifiëren bij Identity Providers (IDP’s) van andere organisaties (via IDP-broker). + +Gemeenschappelijke delen welke organisaties zelf kunnen toepassen, maar elkaar daar wel voor nodig hebben: +- Toepassing van PKIoverheid voor de benodigde PKI-infrastructuur +- Toepassing FSC voor mutual TLS verbindingen op basis van contracten (potentieel gebruik van FDS FSC-directory en catalog) + +Centrale delen en informatie/beheer toegang gerelateerde afspraken (beide geleverd door de Vertrouwensleverancier): +- Afspraken t.a.v. PKIoverheid, FSC +- Attribute-/claim-normalisatie mapping/normalisatie van attributen (schemas/entitlements) zodat claims van verschillende organisaties consistent zijn +- PAP ketenvoorziening t.b.v. gezamenlijke normen, -taxonomie (namen van attributen/rollen) en “baseline policies” +- PRP ketenvoorziening, t.b.v. verspreiding van centrale/baseline policies en gemeenschappelijke modules +- Federation broker, voor token brokering (audience scoping, token exchange) + +Deze inrichting levert op: +- Autonomie & performance: handhaving (PEP) en beslissen (PDP) dicht bij de resource. +- Consistentie & vertrouwen: policy-kaders, attributenschema en sleutels centraal. +- Privacy by design: attributen blijven waar ze ontstaan; alleen noodzakelijke, genormaliseerde claims delen. +- Schaalbaarheid: elke organisatie beheert eigen policies/identiteiten, terwijl de federatie het “spelregelboek” en de trust laag levert. + + +### Autoriseren +Voor het uitvoeren van activiteiten zijn autorisaties noodzakelijk. Voorbeelden van activiteiten zijn: lezen, schrijven, aanpassen en verwijderen van data. + +Schematische weergave aanvragen van autorisatie (REST/GraphQL voorbeeld): +![Alt text](https://www.plantuml.com/plantuml/png/XP3HoXCn48Nl-nJ3UjDTx7QrhHSYqbhH1r14K2zYScn3aqcPP8luzCxkAd_v_q9l0dFEd2-7sUPYfFGnpFB9yzc8YHGJ9tkK5455UX1TUGw_J1_AP_mkk-0F7C65h3uGtPiPMvBGFlX1Dfcgzq1WH7NdarfNkgUiugq_6zsgThrcV3R58qCka6f8gdhyyqdd2VmFkNXxRRocfddHqixmHSm1J1V3P1vmJVETvzccCvuFyb49tWv6zCuXr0g-ejs0lspfYmdU0N8Bq3Ht2QkMtY4bKKIWiSfOwYS2lCk20qAkwIvctT8-SP4KfYhEWosU_g_9wL93QDFIHp1aY819K58lhDDOmLYBdAca4rWR_B_mcyMtPmBtO_7rSOTNBNr8VOa8phDUUwIikswvxbRBJTVLiotOzJ7y1G00) + +| # | Processtap | Beschrijving | +| --- | --- | --- | +| 1 | Aanvragen van autorisatie | De Client vraagt autorisatie aan bij het token endpoint van de autorisatieserver. | +| 2 | Valideer authenticatiemiddel | De autorisatieserver valideert de client op basis van het aangeboden authenticatiemiddel (bijv. certificaat). | +| 3 | Beoordeel scope | De autorisatieserver doorloopt voor elke aanvraag de rule-engine om de aangevraagde scopes te beoordelen. | +| 4 | Controleer audience | De rule-engine valideert de aangevraagde scopes op basis van ingestelde beleidsregels. | +| 5 | Genereer en retourneer | Als de aanvraag succesvol is, wordt een access-token gegenereerd met de goedgekeurde scopes en resources. | +| 6 | Foutmeldingen | Fouten in de aanvraag of van de server worden geretourneerd. | + +Autorisatieserver: +Bij een autorisatieserver kunnen deelnemers toestemming tot autorisatie aanvragen. De autorisatieaanvraag voldoet aan de OAuth 2.0 standaard. Het resultaat van de aanvraag is een access-token (JWT). Toegang tot deze autorisatieserver is beperkt tot alleen deelnemers en alleen via het token-endpoint waarvoor een vertrouwd authenticatiemiddel vereist is. Momenteel alleen met gebruik van een PKIoverheid systeemcertificaat. + +Client Credential Flow: +OAuth 2.0 ondersteunt verschillende "flow standaarden" (ook wel grants genoemd) om toegang te verlenen. Voor server-naar-server communicatie wordt meestal de “Client Credential Flow” toegepast. Deze “Client Credential flow” wordt ook gebruikt bij het aanvragen van toestemming tot autorisatie bij de autorisatieserver. + +Scope: +Een (OAuth) scope geeft het bereik van autorisatie tot een resource aan. Een scope kan een deelnemer bij de autorisatieserver aanvragen. Systemen gebruiken een OAuth scope om na te gaan welke acties een client mag doen. De autorisatieserver vereist dat de client in het autorisatieverzoek een scope parameter specificeert. De scope geeft het bereik aan waarvoor autorisatie wordt aangevraagd en daarmee beperkt en specificeert de scope welke gegevens of functionaliteiten de client kan bevragen of gebruiken. Een scope is opgebouwd uit de combinatie van resource_type en de benodigde toegang. + +Audience: +- Als je in OAuth een Access-token aanvraagt, moet je specificeren wie of wat de uiteindelijke ontvanger van deze token is, deze ontvanger wordt aangeduid als Audience. Dit helpt om te verzekeren dat het token alleen kan worden gebruikt bij de bedoelde resource-server en nergens anders. +- Het opgeven van een Audience is verplicht. +- Er is één Audience toegestaan. +- De audience moet een valide “https” URL zijn. De Audience is de afgeschermde URL van de resource-server welke ook alleen de Policy Enforcement Point van de resource-server vertrouwd. + +Access-token request: +Een Access-token request is een toegangsverzoek om toegang te krijgen tot een resource-server. In een Access-token request wordt aangegeven namens wie het request wordt uitgevoerd. Dit kan op twee manieren, als de partij zelf of als actor namens een partij. In beide gevallen wordt een request gedaan met een PKIoverheid systeemcertificaat (authenticatiemiddel) om te bepalen wie de partij is. Om toegang te krijgen, moet in het tokenaanvraagproces naast het systeemcertificaat ook worden aangegeven namens welke partij de actor handelt (naam of code). De actor fungeert als vertegenwoordiger van de instantie en zorgt ervoor dat toegangsverzoeken correct en veilig worden geautoriseerd, zodat altijd duidelijk is namens welke partij de aanvraag wordt uitgevoerd. Wanneer als actor een request wordt ingediend, moet het token worden uitgebreid met een “access_token/sub” element. Dit element bevat de identificatie van de partij waarvoor een token wordt opgehaald. + + + + + + + + + + diff --git a/_posts/2025-09-29-ketenvoorzieningen.md b/_posts/2025-09-29-ketenvoorzieningen.md new file mode 100644 index 0000000000..31d7840593 --- /dev/null +++ b/_posts/2025-09-29-ketenvoorzieningen.md @@ -0,0 +1,49 @@ +--- +title: Stelselvoorzieningen +author: lg +date: 2025-09-29 +category: Jekyll +layout: post +--- + +> ##### Consultatie +{: .block-warning } + +Binnen de keten leveren de verschillende partijen diensten en is sprake van een federatief landschap. Idealiter zijn er geen centrale voorzieningen, of wel ketenvoorzieningen, nodig. In die zin volgen we een zelfde uitgangspunt als het Federatief Datastelsel (FDS): “afspraken boven standaarden boven voorzieningen”. Echter zullen ketenvoorzieningen niet te voorkomen zijn. Zie ook CORV. Voor de werking van het stelsel zullen de volgende ketenvoorzieningen nodig zijn: +1. Event Provenance Store en Event Hub +2. Diensten Catalogus (optioneel) +3. API Catalogus (optioneel) + +Daar waar “optioneel” is aangeven, is geen sprake van een noodzaak, maar van een potentieel nut. Dit type voorzieningen zal niet in het eerste plateau worden gerealiseerd, maar mogelijk in opvolgende plateau’s. + + +Event Provenance Store en Event Hub +------------- + +Om relevante gebeurtenissen te kunnen vinden en customer journey of tijdlijnen mogelijk te maken is een ketenindex nodig en de gestructureerde (graph based) opslag van events in een onveranderlijke chronologische volgorde. Dus een voorziening die dit levert voor binnen keten uitgewisselde gebeurtenissen of wel een Event Provenance Store. Er moeten in grote hoeveel heden gebeurtenisgegevens (events) kunnen worden ontvangen, gedistribueerd, opgeslagen in logs/topics, etc. Er is hiervoor een streamingplatform nodig, we noemen dat de Event Hub. Merk op dat de ketenpartners vaak ook zullen beschikken over streamingplatformen, we noemen deze Event Brokers. Het verschil tussen Event Hub en Event Broker is dat de Event Hub meer geschikt is voor efficiënt verwerken van grote hoeveelheden event data en is daarvoor geoptimaliseerd. Ook geeft de term Event Hub in deze context aan dat het een centrale voorziening betreft in een hub-spoke architectuur. + + +Diensten Catalogus (optioneel) +------------- + +De Diensten Catalogus is een centrale voorziening in de keten waarin de diensten die aangeboden worden door de keten- of samenwerkingspartners binnen de Jeugd, Zorg en Veiligheidsketen worden beschreven en gepubliceerd. De dienstencatalogus bevat gegevens over een dienst, de aanbiedende ketenpartner, de toegestane afnemende ketenpartners, de contactgegevens bij de aanbieder, de URL voor het aanvragen van de dienst, en de minimale vereiste gegevens voor het ‘bestellen’ van de dienst en een verwijzing naar de bij de dienst behorende SLA. Er moet, niet vrijblijvend, altijd een contract, convenant of andersoortige afspraak tussen afnemer en aanbieder aan het leveren van een dienst ten grondslag liggen. Deze en eventuele bijbehorende DPIA of andersoortige afspraken kunnen eventueel ook via de Dienstencatalogus ontsloten worden. + + +API Catalogus (optioneel) +------------- + +Idealiter zijn API goed vindbaar. De API Catalogus voorziening vormt een centrale plek om keten API’s te kunnen vinden. De API Catalogus voorziening verwijst door naar de centrale API Catalogi / DevPortals. REST API is immers een decentraal patroon en afhankelijkheden van centrale voorzieningen zijn ongewenst. De API Catalogus voorziening maakt het zoeken slechts eenvoudiger en levert een totaal overzicht van de keten API’s op één plek. Dat is handig, maar geen vereiste. + + +Transformatie dienst (optioneel, mogelijk onvermijdbaar) +------------- + +De communicatie tussen verschillende domeinen die hun eigen protocollen, eigen datamodellering en eigen semantiek voeren vraagt om een vertaalservice. Naast deze verschillen moet het verschil tussen verschillende versies en release kalenders van services en clients worden opgevangen. Een verschil tussen service (bron) en client (gebruiker) zal altijd opgelost moeten worden. In een zuivere API gedachte zijn de clients en de service loosely coupled, wat het translatie en transformatie probleem bij de ontvanger van de gegevens legt. + +In het meest ideale geval worden services, zoals ze worden gedefinieerd overal hetzelfde toegepast én volgen ze allemaal volgens dezelfde releasekalender nieuwe versies. Dat is echter een utopie en zal nooit voorkomen. Vandaar dat berichttransformatie en protocol translatie functies zijn die ook CORV2 zal moeten ondersteunen. Het vertalen van berichten is een standaard functie van het huidige CORV. Doorgaans is standaard vertaling niet mogelijk en in plaats daarvan moet vrijwel altijd maatwerk worden ingezet. + +Het centraal transformeren van gegevens verlangt veel kennis van de bron en de ontvangende partij. Vooral als deze vertalingen complexe “IF THEN ELSE” constructies bevatten. Ze zijn kostbaar om te onderhouden en relatief foutgevoelig. Omdat we verwachten dat het aantal services zal stijgen is het zaak om deze transformaties (als wel de translaties) tot een minimum te beperken. Een landschap dat via transformaties is gekoppeld is sterk monolithisch. Dergelijke transformaties centraal uitvoeren is ongewenst en dient dus alleen te worden gedaan als dit realistisch niet anders kan en dienen in principe altijd tijdelijk te zijn (ter overbrugging). + +Bericht transformatie kan (en zal dat in de praktijk waarschijnlijk zijn) tijdelijk ook nodig zijn ter overbrugging van de transitie van CORV1 naar CORV2 als migratie dienst. Deze dienst is ook wel bekend onder de benaming Silvester diensten. + + diff --git a/_posts/2025-09-30-afspraken.md b/_posts/2025-09-30-afspraken.md new file mode 100644 index 0000000000..a3940bd5d3 --- /dev/null +++ b/_posts/2025-09-30-afspraken.md @@ -0,0 +1,83 @@ +--- +title: Afspraken +author: lg +date: 2025-09-29 +category: Jekyll +layout: post +--- + +Realisatie afspraken +------------- + +> ##### Concept +{: .block-danger } + +Niet alle beschreven functionaliteiten en technische voorzieningen kunnen tegelijk gerealiseerd worden. De realisatie zal in fasen worden uitgevoerd waarbij steeds naar een vastgesteld en afgesproken plateau wordt gewerkt. + +### Plateau 1 afspraken +Toegang +1. We passen voor dit plateau minimaal de huidige authenticatie op organisatieniveau (Organisatie identifier en certficate) toe. Voor latere scopes onderzoeken de beweging naar nieuwere vormen van identifier, certficate en contract authenticatie (FSC), authenticatie op niveau persoon/professional en daarmee o.a. OIDC/Oauth, FTV, DigiD en Wallet, en combinatie daarvan (FSC + FTV). +2. Bij toegangsverlening op basis van Organisatie identifier en certficate wordt OIN gebruikt als identifier en uitsluitend PKIoverheid certificaten. + +Toegang burgerportaal +1. Bij toegangsverlening voor burgers, denk aan het burgerportaal, gebruiken we DigiD waarbij de authentiserende persoon over een BSN moet beschikken. +2. Voor de te realiseren samenwerkfuncties binnen dit plateau gerelateerd aan het burgerportaal is betrouwbaarheidsniveau voor toegang “Substantieel” voldoende. Samenwerkfuncties die een hoger niveau vereisen vallen buiten dit plateau. +3. In de context van DigiD/eherkenning passen we SAML toe en stappen (in hogerliggende plateua’s) naar OIDC/Oauth over zodra dat wordt ondersteund door DigiD/eherkenning +4. Binnen dit plateau kan niet worden uitgegaan dat de identiteit van de persoon die het portaal gebruikt doorgeven kan worden bij inzage bij ketenpartners. Er wordt onderzocht hoe dit gerealiseerd kan worden in situatie waar dit nodig is en is toegestaan binnen opvolgende plateau’s. +5. We gebruiken voor dit plateau (voor het burgerportaal) de gezagsinformatie van de BRP en dienen Gezagsdiensten te zijn om dat te kunnen en mogen. Gezagsdiensten zijn bestuursorganen en enkele daartoe aangewezen instanties, die rechtmatig toegang hebben tot de BRP volgens de Wet BRP en het Besluit BRP. + +Gebeurtenissen +1. Binnen dit plateau werken we met gebeurtenissen die voor alle ketenpartijen toegankelijk zijn en mogen zijn. Voor latere plateau’s onderzoeken we autorisatie/abonneren op bepaalde gebeurtenissen/topics. +2. De gebeurtenissen bevatten genoeg informatie om een inzage te kunnen doen via het (REST API) inzage patroon. Zodoende wordt dus de toegangsverlening daarvan hergebruikt en is de informatie alleen zichtbaar voor partijen met toegang tot die informatie. +3. Voor dit plateau vertrekken we met in de gebeurtenissen opgenomen de persoon/BSN waar de gebeurtenis betrekking op heeft. Voor latere plateau’s onderzoeken we of pseudonimisering, etc. meerwaarde heeft en noodzakelijk is. +4. We gaan in plateau uit van één centrale Event Provenance Store en Event Hub. Voor latere scopes onderzoeken we of er nut en noodzaak is om in het stelsel meerdere event stores op te nemen. +5. Binnen dit plateau realiseren via filtering dat waar dat wenselijk is gebeurtenissen niet meer bevraagd kunnen worden. + +Architectuur afspraken +------------- + +> ##### Concept +{: .block-danger } + +1. Het jeugd, zorg en veiligheidsdomein vormt één domein met één bounded context. Een domein is afgebakend, autonoom gebied is waarin één coherent domeinmodel geldt en alle partijen dat model hanteren. +2. De informatievoorziening in het jeugd, zorg en veiligheidsdomein is gefedereerd en centrale voorzieningen worden alleen toegepast als dat nodig is. +3. Het jeugd, zorg en veiligheidsdomein kent een uniforme dienstverlening. Deze uniforme benadering waarborgt consistentie, interoperabiliteit en gelijkwaardigheid binnen het netwerk. Elke deelnemer, ongeacht grootte of specifieke context, neemt deel vanuit zijn eigen rol in dit samenwerkverband en verbind zich aan het leveren van deze vastgestelde diensten volgens gezamenlijk overeengekomen standaarden en kwaliteitsnormen. Zie het samenwerkproces, de samenwerkfuncties en de samenwerkpatronen. +4. Binnen het jeugd, zorg en veiligheidsdomein wordt dezelfde taal gesproken. Uit het uitgangspunt “domein oriëntatie” volgt logisch dat uitgegaan wordt van één gemeenschappelijk semantisch, schematisch en syntactisch model. Populair gezegd spreken we, binnen het samenwerkverband, dezelfde taal. +5. Informatie wordt waar mogelijk en zinvol eenmalig opgeslagen en meervoudig gebruikt. Het kernidee is dat er voor elke soort informatie één leidende bron bestaat, één verantwoordelijke. In plaats van gegevens te kopiëren of over te nemen, wordt informatie steeds opnieuw opgehaald uit deze originele bron, één verantwoordelijke partij. Let wel, een verantwoordelijke partij kan een andere partij de bevoegdheid gegeven om deze gegevens beschikbaar te maken. Eenmalig opslaan en meervoudig gebruik zorgt er voor dat: de gegevens altijd up-to-date zijn, meer zekerheid over de juistheid van gegevens bestaat, er geen inconsistenties ontstaan door verouderde kopieën; we uitgaan van één actuele en historische waarheid, de integriteit van de data beter gewaarborgd blijft. +6. Gegevens zijn voorzien van context. Gegevens (in welke vorm dan ook) zijn altijd voorzien van contextuele gegevens. Door consequent context te koppelen aan gegevens wordt een robuuste basis voor geïnformeerde besluitvorming en effectieve data-gedreven processen gelegd. Dit zorgt voor een beter begrip, verhoogt de betrouwbaarheid en bevordert het juiste gebruik van de data. +7. Het jeugd, zorg en veiligheidsdomein is een gedistribueerd systeem, of kan minimaal als zodanig worden gezien, met een eventual consistency kenmerk naast availability en partition tolerance (zie het CAP theorem). +8. De bronhouder geeft toegang tot gegevens (op  basis van afspraken). In beginsel moet elke bronhouder autonoom de voorwaarden bepalen voor toegang tot zijn gegevens via hun API’s. Deze benadering waarborgt de integriteit, veiligheid en het juiste gebruik van data. Gebruikers die toegang wensen tot deze gegevens, committeren zich aan het naleven van de gestelde voorwaarden. Dit creëert een transparant en verantwoord ecosysteem voor gegevensuitwisseling, waarbij de rechten en plichten van zowel bronhouders als gebruikers duidelijk zijn gedefinieerd en gerespecteerd. +9. Flexibiliteit en aanpasbaarheid (waar dat kan) waardoor ingespeeld kan worden op veranderingen en nieuwe wensen of vereisten. Door: een modulaire opbouw, een business agnostische ICT benadering, een event gedreven benadering, real-time reactievermogen, afstemming op bedrijfsprocessen, API-first benadering, configureerbare workflows. + + +Technische afspraken +------------- + +> ##### Concept +{: .block-danger } + +Deze afspraken zijn van toepassing voor de deelnemers aan het afsprakenstelsel. Ze zijn gericht op het realiseren van een gedistribueerd stelsel met zo min mogelijk afhankelijkheden en koppelingen. De technische afspraken zijn onderverdeeld in drie categorieën: Algemeen, Semantiek gerelateerd, Gebeurtenissen gerelateerd en REST API gerelateerd. + +### Algemeen +1. Er is sprake van gefedereerde gedistribueerde systemen, waarbij monolithische centralistische concepten worden vervangen door oplossingen die gekenmerkt worden door het terugdringen van afhankelijkheden. +2. Er worden alleen centrale gedeelde (keten)voorzieningen gerealiseerd als dat nodig is. + +### Semantiek gerelateerd +3. Binnen het Jeugd, Zorg en Veiligheiddomein wordt het Metamodel voor Informatiemodellering (MIM) gehanteerd en beheerd als kader voor het opstellen van informatiemodellen. + +### Gebeurtenissen gerelateerd +4. Voor het verzamelen, opslaan en distribueren van grote hoeveelheden gebeurtenisgegevens (events) is een centrale Event Hub nodig binnen het Stelsel. Een Event Hub is een gedistribueerd streamingplatform dat wordt gebruikt voor het verwerken en beheren van realtime datastreams (van gebeurtenissen/notificaties). +5. Er wordt een Ketenindex gerealiseerd, die customer journeys of ‘tijdlijnen’ mogelijk maakt. Omdat relevante gebeurtenissen gevonden kunnen worden, kunnen deze op een tijdlijn worden geplaatst. Het kunnen volgen (track en trace) van personen, objecten en concepten (en procesgangen) maakt integrale beelden mogelijk. Omdat het een verwijzing betreft kan eventueel een verdiepingsvraag worden gesteld. +6. Events (gebeurtenissen) ten behoeve van onder andere de ketenindex (en daarmee tijdslijnen) slaan we op in een centrale Event Store. Een Event Store is een gespecialiseerde database die gebeurtenissen (events) opslaat in een onveranderlijke, chronologische volgorde. Deze biedt daarmee een volledige historische weergave van alle veranderingen. +7. De Event Store maakt net als de Event Hub deel uit van CORV2. +8. De Event Store levert naast customer journeys of ‘tijdlijnen’ ook ondersteuning ten behoeve van data lineage / data provenance. +9. Binnen CORV2 hanteren we CQRS (Command Query Responsibility Segregation), oftewel het scheiden van het schrijf- en lees-datamodel. +10. Voor gebeurtenissen-uitwisseling in CORV2 context hanteren we een ontkoppelde variant via een REST API layer (API Proxy) om een toestand of gebeurtenis op te vragen, dus een pull model (en niet het native publish-subscribe model, waarbij producenten events publiceren en consumenten deze events kunnen consumeren via native interfaces). +11. Binnen de keten hanteren we een gestandaardiseerd Event Datamodel. + +### REST API gerelateerd +12. REST API calls binnen de keten verlopen decentraal, dus direct tussen partijen zonder tussenkomst van een centrale component. Als centrale component is slechts een API Catalog beschikbaar, deze is om API’s vindbaar te maken en daarmee ondersteunend van aard. +13. REST API’s verbonden aan Samenwerkfuncties en Samenwerkpatronen volgen de specificaties daarvan. + + + diff --git a/_posts/2025-10-01-randvoorwaarden.md b/_posts/2025-10-01-randvoorwaarden.md new file mode 100644 index 0000000000..89d80bff8d --- /dev/null +++ b/_posts/2025-10-01-randvoorwaarden.md @@ -0,0 +1,12 @@ +--- +title: Randvoorwaarden +author: lg +date: 2025-10-15 +category: Jekyll +layout: post +--- + +> ##### Concept +{: .block-danger } + +- Aansluitende of deelnemende organisatie in het stelsel dienen rechtmatig toegang hebben tot de BRP volgens de Wet BRP en het Besluit BRP. diff --git a/_posts/2025-10-02-aansluiten.md b/_posts/2025-10-02-aansluiten.md new file mode 100644 index 0000000000..c95c0f0da1 --- /dev/null +++ b/_posts/2025-10-02-aansluiten.md @@ -0,0 +1,153 @@ +--- +title: Aansluiten +author: lg +date: 2025-10-24 +category: Jekyll +layout: post +--- + +> ##### Concept +{: .block-danger } + +Aansluitvoorwaarden +------------- +Om aan te sluiten op het Jeugd, Zorg en Veiligheid Afsprakenstelsel en de voordelen daarvan te kunnen benutten is het nodig: +1. Te voldoen aan het geheel van afspraken en standaarden dat veilige en betrouwbare uitwisseling van gegevens borgt binnen het domein. +2. De relevante eigen koppelvlakken en systemen in te richten volgens deze afspraken en standaarden.​ +3. De samenwerkfuncties en samenwerkpatronen te implementeren. + +Aansluitstappen +------------- +Een aansluitende organisatie kan de volgende stappen volgen: +1. Kennis nemen van doel, achtergronden, principes, randvoorwaarden en techniek (zie leeswijzer). +2. De afspraken na te gaan en een impact bepaling uitvoeren op organisatie, processen en techniek +3. Stappen nemen om aan het geheel van afspraken en standaarden te kunnen voldoen. +4. Eventuele procesmatige aanpassingen voorbereiden of maken. +5. Relevante eigen koppelvlakken en systemen aanpassen zodat deze voldoen aan de afspraken. +6. De koppelvlakken en systemen zodanig aan te passen dat deze het realiseren van samenwerkfuncties en samenwerkpatronen in basis ondersteunen (het mogelijk maken deze te realiseren). +7. Een aantal essentiële samenwerkfuncties en samenwerkpatronen implementeren. +8. De overige samenwerkfuncties en samenwerkpatronen geleidelijk verder implementeren. + +Impact bepaling +------------- +Binnen voorgenoemde stappen is een essentiële stap het uitvoeren van een impact bepaling. Die kan voor elke organisatie anders zijn. Hieronder is een vragenlijst opgenomen die kan helpen bij de impact bepaling en tevens een concreter beeld geeft van wat hiervoor eenvoudigweg genoemd is het implementeren van proces, koppelvlak en systeem aanpassingen. + +De impact bepaling kan gedaan worden in drie delen. Waarbij in het eerste deel alleen gekeken wordt naar de theoretische en strategische aspecten, in het tweede deel langs de lijnen van samenwerkpatronen en in het derde deel langs de lijnen van samenwerkfuncties. + +Als hieronder over kosten wordt gesproken moet gedacht worden aan zowel eenmalige kosten als terugkomende kosten zoals die gerelateerd aan beheer (beheerkosten). + +### Deel I +Voer een analyse uit t.a.v. doelen, principes, afspraken en het stelsel in de breedte. Ga na wat de impact zou zijn van de beweging naar het Afsprakenstelsel voor de organisatie en de processen. Kijk minimaal naar de volgende aspecten met hun mogelijke impact: +1. De beweging van estafette model naar netwerkmodel en het ontstaan van een ketenindex (tijdlijnen), welke beide impact kunnen hebben op processen, weliswaar positief, maar vragen ook aandacht voor datakwaliteit, schrijfwijze, etc. +2. Het bewegen naar en toepassen van gebeurtenis gedrevenheid en event driven architectures. Past deze ontwikkeling bij beweging die organisatie wil maken en hoe ver is de organisatie daar al in. +3. Het bewegen naar en toepassen van halen bij de bron en REST-API architectures. Past deze ontwikkeling bij beweging die organisatie wil maken en hoe ver is de organisatie daar al in. +4. De geleidelijke uitfasering van ebMS. +5. Het uitgangspunt van één bounded context en daarmee één semantisch model en begrippenkader binnen het Jeugd, Zorg en Veiligheidsdomein, voor ten minste de onderlinge koppelvlakken. +6. De potentiële vertaling van semantisch model en begrippenkader naar de binnenwereld van de organisatie welke mogelijk een ander semantisch model en begrippenkader hanteert of geen van beide. +7. Het ontstaan van mogelijkheden waarbij een organisatie soms zelf geen directe baten ervaart, maar het collectief wel, wat kan leiden tot financieringsvragen en vraagstukken over rol en taak.     + +### Deel II +In dit deel wordt de impact van het implementeren van de samenwerkpatronen Gebeurtenis Ontvangen/ Gebeurtenis Melden, Inzake Verzoek/ Inzake Leveren, en Opdracht Aanvragen / Opdracht Leveren geanalyseerd inclusief generieke daarvoor benodigde onderdelen. Met implementatie bedoelen we hier de inrichting en of aanpassing van koppelvlakken en systemen om deze patronen te kunnen toepassen. De analyse van hoe deze worden toegepast volgt in het derde deel. + +Gebeurtenis Ontvangen / Gebeurtenis Melden +Voor de impactbepaling wordt onderstaande schets gebruikt en vanuit twee perspectieven, die van gebeurtenissen ontvangen en gebeurtenissen melden. + +![Alt text]({{ site.baseurl }}/assets/events.png) + +Gebeurtenis Ontvangen: +Om gebeurtenissen te ontvangen zijn er geen voorzieningen bij de ontvangende organisatie nodig als API Management, Event Platform, etc. Daarom zijn deze wit en grijs weergegeven. Dat wil niet zeggen dat deze niet ingezet kunnen worden. Zo is het denkbaar de events te ontvangen via een event platform, maar vereiste is dat niet. + +Om de impact als ontvanger van gebeurtenissen te bepalen kunnen de volgende vragen worden gesteld: +- Kan mijn systeem aangepast worden om events te ontvangen? Kan mijn systeem de ontvangen events verwerken en beschikbaar maken voor de gebruikers van het systeem? Moet het daarvoor aangepast worden, hoeveel tijd vergt dat en welke kosten zijn ermee gemoeid? +- Als mijn systeem niet aangepast kan worden, kunnen er services worden toegepast (ontwikkelt worden) die deze functionaliteit kunnen invullen in samenhang met het systeem. Wat zijn daar de kosten van en hoeveel tijd en inspanning vergt dat? +- Als integratie met het systeem niet mogelijk is, kan een separate functionaliteit worden gerealiseerd. Wat zijn daar de kosten van en hoeveel tijd en inspanning vergt dat? +- Als het gewenst is een event platform in te zetten, is dat al aanwezig? Zo ja; wat zijn de configuratie kosten/inspanning? Zo nee; wat zijn de kosten en wat is inspanning om zo’n platform te realiseren? + +Gebeurtenis Melden: +Om gebeurtenissen te melden zijn geen voorzieningen bij de verzendende organisatie nodig zoals API Management. Denkbaar is dat de verzendende organisatie een event platform gebruikt, maar vereist is dat niet. + +Om de impact als verzender van gebeurtenissen te bepalen kunnen de volgende vragen worden gesteld: +- Is mijn (common ground gebaseerde) ICT infrastructuur geschikt om events te verzenden? Moet deze daarvoor aangepast worden, hoeveel tijd vergt dat en welke kosten zijn ermee gemoeid? +- Kan mijn systeem aangepast worden om events te verzenden of de verzending daarvan te triggeren? Moet het daarvoor aangepast worden, hoeveel tijd vergt dat en welke kosten zijn ermee gemoeid? +- Als mijn systeem niet aangepast kan worden, kunnen er services worden toegepast (ontwikkelt worden) die deze functionaliteit kunnen invullen in samenhang met het systeem. Wat zijn daar de kosten van en hoeveel tijd en inspanning vergt dat? +- Als het gewenst is een event platform in te zetten, is dat al aanwezig? Zo ja; wat zijn de configuratie kosten/inspanning? Zo nee; wat zijn de kosten en wat is inspanning om zo’n platform te realiseren? + +Inzage Verzoek / Inzage Leveren +Voor de impactbepaling wordt onderstaande schets gebruikt en vanuit twee perspectieven, die van inzake verzoeken en van inzage leveren. + +![Alt text]({{ site.baseurl }}/assets/inzage.png) + +Inzage Verzoek +Om inzage te doen zijn er geen voorzieningen bij de vragende organisatie nodig als API Management, event platformen etc. Daarom zijn deze wit en grijs weergegeven. Er zijn eveneens geen centrale voorzieningen nodig zoals een Event provenance store en event hub. Ook een centrale API catalog is niet noodzakelijk hoewel deze wel handig kan zijn om de API’s voor inzage te vinden waarbij de centrale catalog zal doorverwijzen naar de API devportals/catalogs bij de aanbiedende organisatie. + +Om de impact te bepalen om verzoeken om inzage te kunnen doen, kunnen de volgende vragen worden gesteld: +- Kan mijn systeem aangepast worden om inzage verzoeken te doen en de response te ontvangen en verwerken? Moet het daarvoor aangepast worden, hoeveel tijd vergt dat en welke kosten zijn ermee gemoeid? +- Als mijn systeem niet aangepast kan worden, kunnen er services worden toegepast (ontwikkelt worden) die deze functionaliteit kunnen invullen in samenhang met het systeem. Wat zijn daar de kosten van en hoeveel tijd en inspanning vergt dat? +- Als integratie met het systeem niet mogelijk is, kan een separate functionaliteit worden gerealiseerd. Wat zijn daar de kosten van en hoeveel tijd en inspanning vergt dat? + +Inzage Leveren: +Om inzage te leveren dient een inzage (REST API) service te worden aangeboden. Doorgaans zal deze worden aangeboden via een API Management oplossing. Er moet toegang aangevraagd en verleend kunnen worden. De API Management en bijbehorende Devportal kan daar een rol in spelen inclusief toegangsservices binnen de API Management oplossing of daaraan gekoppeld. + +Om de impact te bepalen van het inzage leveren beschikbaar te stellen, kunnen de volgende vragen worden gesteld: +- Beschik ik al over een API Management oplossing? Zo ja; wat zijn de configuratie kosten/inspanning? Zo nee; wat zijn de kosten en wat is inspanning om zo’n voorziening te realiseren? +- Is mijn (common ground gebaseerde) ICT infrastructuur geschikt om inzage te leveren? Moet deze daarvoor aangepast worden, hoeveel tijd vergt dat en welke kosten zijn ermee gemoeid? + +Opdracht Aanvragen / Opdracht Leveren (REST API) +Voor de impactbepaling wordt onderstaande schets gebruikt en vanuit twee perspectieven, die van opdrachten aanvragen en opdrachten leveren. Dit met behulp van REST-API’s (en dus niet via ebMS). + +![Alt text]({{ site.baseurl }}/assets/opdrachtrestapi.png) + +Opdracht Aanvragen: +De benadering lijkt sterk op een Inzage Verzoek. Zie de vragen daar aangeven. In dit geval wordt er met de REST API call echter geen informatie opgevraagd, maar een opdracht ingestuurd (REST API POST). + +Opdracht Leveren: +Hoe de ontvangende partij de opdracht uitvoert kan zeer divers zijn en afhankelijk van de opdracht. Er kan een event worden gestuurd waarin wordt gemeld dat de opdracht is ontvangen, geweigerd, wat de status van uitvoering is of dat het event is uitgevoerd. In die gevallen kunnen min of meer dezelfde vragen gesteld worden als bij Gebeurtenis Melden. Wel zal extra aandacht besteed moeten worden aan de impact op systemen en processen om van opdracht tot melding te kunnen komen. Dit is een complexer patroon dan eerder behandelde patronen. Een opdracht kan ook zijn het klaar zetten van specifieke informatie voor Inzage, zie daarvoor de vragen bij Inzage Leveren waarbij opgemerkt dat hier sprake is van een complexer patroon dan Inzage Leveren op zichzelf. + +Opdracht Aanvragen / Opdracht Leveren (ebMS) +Opdracht Aanvragen en Opdracht Leveren via ebMS is een bestaande praktijk, zie navolgende figuur. De impactvraag is hier welke kosten gemoeid zijn bij het in de lucht houden van beide benaderingen tijdens de overgangsfase. + +![Alt text]({{ site.baseurl }}/assets/opdrachtebms.png) + +Generieke elementen +Alle voorgaande aspecten maken gebruik van generieke bouwstenen rond toegang en logging. Bij deze bouwstenen zouden de volgende vragen gesteld kunnen worden. + +OIN/Certificaat toegang (>plateau 1): +Dit is de meest eenvoudige methode van toegangssverlening en de meeste organisaties zullen deze reeds toepassen. + +- Beschikt mijn organisatie over processen om PKIOverheid certificaten te kunnen aanvragen en toepassen? Zo nee; welke inspanning en kosten zouden ermee gemoeid zijn deze processen in te richten. +- Kan ik toegang verlenen op basis van OIN/PKIOverheid certificaat? +- Zijn er afspraken gemaakt met de organisaties waarmee ik een koppeling wil of moet maken? + +FSC (>plateau 1) +- Kan ik de Federatieve Service Connectiviteit (FSC) standaard ondersteunen of doe ik wellicht dat al? +- Beschik ik over virtual servers of een container platform om FSC componenten op te kunnen laten landen? Ondersteunt mijn leverancier FSC? Zo nee; welke inspanning en kosten zouden ermee gemoeid zijn FSC te gaan ondersteunen. + +FTV (>plateau 1) +- Ondersteunt mijn infrastructuur Federatieve Toegangsverlening, OIDC, OaAuth, AuthZen, ABAC, PBAC? Zo nee; welke inspanning en kosten zouden ermee gemoeid zijn FTV te gaan ondersteunen. + +Logging +- Beschikt mijn organisatie over logging en monitoring voorzieningen waarnaar alle verschillende services en componenten naar kunnen loggen? Zo nee; welke inspanning en kosten zouden ermee gemoeid zijn een logging voorziening te realiseren. + +Common Ground +- Ondersteunt mijn informatievoorziening het Common Ground gedachtengoed en is mijn data losgekoppeld van applicaties en werkprocessen? Zo nee; welke inspanning en kosten zouden ermee gemoeid zijn deze beweging te maken. +- Hoe voorkom ik dat ik door aanpassingen aan mijn systeem, om aan te sluiten op het afsprakenstelsel, geen monolithische maatwerkapplicatie krijg die afwijkt van het Common Ground gedachtengoed en op termijn tot hoge (transitie) kosten gaat leiden?    + +### Deel III +Uitgaande dat we de samenwerkpatronen Gebeurtenis Ontvangen/ Gebeurtenis Melden, Inzake Verzoek/ Inzake Leveren, en Opdracht Aanvragen / Opdracht Leveren kunnen ondersteunen (technisch), en wellicht al enkele eerste samenwerkfuncties in productie hebben gebracht, is een vervolgvraag welke impact het heeft om de resterende functies te implementeren. Denkbaar is dat de eerste samenwerkfuncties meer moeite en inspanning vergen dan opvolgende, maar ook dat er aanzienlijke verschillen kunnen zitten in implementatieinspanning en kosten tussen de verschillende functies. Deze kunnen weer afhangen van het achterliggende systeem en de ICT infrastructuur en dus ook per organisatie verschillen. Per samenwerkfunctie zal de vraag gesteld moeten worden wat de realisatie behelst, wat de inspanning is en welke kosten ermee gemoeid zijn. Dus ten aanzien van de samenwerkfuncties: +- Uitwisselen Melding +- Vaststellen Identiteit & Relaties +- Bepalen Bekendheid & Verrijking +- Werken aan Preventie +- Uitvoeren Triage & Taxatie +- Opstellen Analyse & Advies +- Inzien en Deelnemen door de Burger +- Overleggen over de Casus +- Uitwisselen Uitkomst Overleg +- Opstellen & Regisseren Plan +- Uitvoeren Actie +- Nazorg en Afsluiten Casus +- Inzien beschikbare diensten +- Inrichten en Bijsturen Samenwerking +- Monitoren samenwerking + +Dit zal vooraf en zonder ervaringscijfers moeilijk zijn in te schatten. Het advies is daarom om hier een eerste schatting te maken en die bij te stellen op basis van ervaringscijfers zodra die beschikbaar komen. diff --git a/assets/apihl.png b/assets/apihl.png new file mode 100644 index 0000000000..46e041aa33 Binary files /dev/null and b/assets/apihl.png differ diff --git a/assets/bc.png b/assets/bc.png new file mode 100644 index 0000000000..fddc5968f6 Binary files /dev/null and b/assets/bc.png differ diff --git a/assets/comg1.png b/assets/comg1.png new file mode 100644 index 0000000000..e88c0da526 Binary files /dev/null and b/assets/comg1.png differ diff --git a/assets/comg2.png b/assets/comg2.png new file mode 100644 index 0000000000..40ca2316f7 Binary files /dev/null and b/assets/comg2.png differ diff --git a/assets/comg3.png b/assets/comg3.png new file mode 100644 index 0000000000..a21fdddafe Binary files /dev/null and b/assets/comg3.png differ diff --git a/assets/conpro.png b/assets/conpro.png new file mode 100644 index 0000000000..39c45eb93a Binary files /dev/null and b/assets/conpro.png differ diff --git a/assets/corv2funct.png b/assets/corv2funct.png new file mode 100644 index 0000000000..908c4d99f9 Binary files /dev/null and b/assets/corv2funct.png differ diff --git a/assets/domein.png b/assets/domein.png new file mode 100644 index 0000000000..ba79e5e0a6 Binary files /dev/null and b/assets/domein.png differ diff --git a/assets/event.png b/assets/event.png new file mode 100644 index 0000000000..4e20cb318f Binary files /dev/null and b/assets/event.png differ diff --git a/assets/eventshl.png b/assets/eventshl.png new file mode 100644 index 0000000000..44ae079834 Binary files /dev/null and b/assets/eventshl.png differ diff --git a/assets/handenblauwlogo.png b/assets/handenblauwlogo.png new file mode 100644 index 0000000000..9c613133bf Binary files /dev/null and b/assets/handenblauwlogo.png differ diff --git a/assets/handenblauwlogolong.png b/assets/handenblauwlogolong.png new file mode 100644 index 0000000000..66ad4157c5 Binary files /dev/null and b/assets/handenblauwlogolong.png differ diff --git a/assets/handenblauwlogosmall.png b/assets/handenblauwlogosmall.png new file mode 100644 index 0000000000..48f32ec672 Binary files /dev/null and b/assets/handenblauwlogosmall.png differ diff --git a/assets/inzage.png b/assets/inzage.png new file mode 100644 index 0000000000..b563c2e78f Binary files /dev/null and b/assets/inzage.png differ diff --git a/assets/metro.png b/assets/metro.png new file mode 100644 index 0000000000..47837019ff Binary files /dev/null and b/assets/metro.png differ diff --git a/assets/metronew1.png b/assets/metronew1.png new file mode 100644 index 0000000000..8fd5c39f26 Binary files /dev/null and b/assets/metronew1.png differ diff --git a/assets/opdrachtebms.png b/assets/opdrachtebms.png new file mode 100644 index 0000000000..9eab3ba952 Binary files /dev/null and b/assets/opdrachtebms.png differ diff --git a/assets/opdrachtrestapi.png b/assets/opdrachtrestapi.png new file mode 100644 index 0000000000..f39aa5416e Binary files /dev/null and b/assets/opdrachtrestapi.png differ diff --git a/assets/processamenwerkingcyclus.png b/assets/processamenwerkingcyclus.png new file mode 100644 index 0000000000..49e66ad208 Binary files /dev/null and b/assets/processamenwerkingcyclus.png differ diff --git a/assets/rollen.png b/assets/rollen.png new file mode 100644 index 0000000000..6ade9643ea Binary files /dev/null and b/assets/rollen.png differ diff --git a/assets/samenwerkfuncties.png b/assets/samenwerkfuncties.png new file mode 100644 index 0000000000..cd8255fae4 Binary files /dev/null and b/assets/samenwerkfuncties.png differ diff --git a/assets/samenwerkfuncties1.png b/assets/samenwerkfuncties1.png new file mode 100644 index 0000000000..6de279fbf9 Binary files /dev/null and b/assets/samenwerkfuncties1.png differ diff --git a/handenblauwlogolong.png b/handenblauwlogolong.png new file mode 100644 index 0000000000..96ef8c8b1c Binary files /dev/null and b/handenblauwlogolong.png differ