pa:VDraft Toetsingskader: verschil tussen versies
| Regel 4: | Regel 4: | ||
{| class="wikitable" | {| class="wikitable" | ||
|- | |- | ||
| − | ! | [https://informatiestandaarden.nictiz.nl/wiki/pa:Hoofdproces Hoofdpagina Productarchitectuur] | [https://informatiestandaarden.nictiz.nl/wiki/pa:Productarchitectuurprincipes Productarchitectuurprincipes] | [https://informatiestandaarden.nictiz.nl/wiki/pa:VDraft_Toetsingskader Toetsingskader | + | ! | [https://informatiestandaarden.nictiz.nl/wiki/pa:Hoofdproces Hoofdpagina Productarchitectuur] | [https://informatiestandaarden.nictiz.nl/wiki/pa:Productarchitectuurprincipes Productarchitectuurprincipes] | [https://informatiestandaarden.nictiz.nl/wiki/pa:VDraft_Toetsingskader Toetsingskader] | [https://informatiestandaarden.nictiz.nl/wiki/pa:VDraft_Toetsingscriteria Toetsingscriteria] |
|} | |} | ||
| − | + | =Doel= | |
De toetsingscriteria dragen bij aan de consistentie en samenhang tussen informatiestandaarden en ondersteunen daarmee de zorgbrede interoperabiliteit. Ze vormen een concrete uitwerking van de overkoepelende productarchitectuurprincipes en bieden kaders voor het ontwerpen van informatiestandaarden. | De toetsingscriteria dragen bij aan de consistentie en samenhang tussen informatiestandaarden en ondersteunen daarmee de zorgbrede interoperabiliteit. Ze vormen een concrete uitwerking van de overkoepelende productarchitectuurprincipes en bieden kaders voor het ontwerpen van informatiestandaarden. | ||
| − | + | =Reikwijdte= | |
De toetsingscriteria zijn van toepassing op: | De toetsingscriteria zijn van toepassing op: | ||
* het ontwerp van nieuwe informatiestandaarden; | * het ontwerp van nieuwe informatiestandaarden; | ||
| Regel 15: | Regel 15: | ||
De criteria gelden voor alle informatiestandaarden die onder beheer staan van Nictiz. | De criteria gelden voor alle informatiestandaarden die onder beheer staan van Nictiz. | ||
| − | + | =Karakter en status van toetsingscriteria= | |
| − | + | ==Definitie== | |
Toetsingscriteria zijn ontwerpregels die de productarchitectuurprincipes vertalen naar toetsbare eisen. Ze bieden houvast bij het beoordelen van ontwerpen en bevorderen de eenduidigheid in de toepassing van architectuur. | Toetsingscriteria zijn ontwerpregels die de productarchitectuurprincipes vertalen naar toetsbare eisen. Ze bieden houvast bij het beoordelen van ontwerpen en bevorderen de eenduidigheid in de toepassing van architectuur. | ||
| Regel 24: | Regel 24: | ||
* welke regels gelden voor het gebruik van generieke standaarden binnen een informatiestandaard. | * welke regels gelden voor het gebruik van generieke standaarden binnen een informatiestandaard. | ||
| − | + | ==Niveau van verplichting== | |
Elk toetsingscriterium kent een niveau van verplichting, afhankelijk van de status van de onderliggende documentatie: | Elk toetsingscriterium kent een niveau van verplichting, afhankelijk van de status van de onderliggende documentatie: | ||
* Verplicht: gebaseerd op documentatie met een definitieve status of waarover brede consensus bestaat. | * Verplicht: gebaseerd op documentatie met een definitieve status of waarover brede consensus bestaat. | ||
| Regel 58: | Regel 58: | ||
|} | |} | ||
| − | + | =Toepassing= | |
De toetsingscriteria vormen het kader voor: | De toetsingscriteria vormen het kader voor: | ||
* het opstellen van ontwerpdocumentatie door de beheerder van een informatiestandaard; | * het opstellen van ontwerpdocumentatie door de beheerder van een informatiestandaard; | ||
| Regel 64: | Regel 64: | ||
* de borging van interoperabiliteit binnen het stelsel van informatiestandaarden. | * de borging van interoperabiliteit binnen het stelsel van informatiestandaarden. | ||
| − | + | =Proces= | |
| − | + | ==Ingangstoets== | |
Bij het opstellen van een nieuw ontwerp van een informatiestandaard wordt een ingangstoets uitgevoerd. | Bij het opstellen van een nieuw ontwerp van een informatiestandaard wordt een ingangstoets uitgevoerd. | ||
Deze toets vindt plaats in één of meerdere werksessies waarin het Productarchitectuurteam en de beheerder van de informatiestandaard gezamenlijk de ontwerpplannen beoordelen. Een tweede beheerteam van een andere informatiestandaard kan deelnemen in het kader van peer review. | Deze toets vindt plaats in één of meerdere werksessies waarin het Productarchitectuurteam en de beheerder van de informatiestandaard gezamenlijk de ontwerpplannen beoordelen. Een tweede beheerteam van een andere informatiestandaard kan deelnemen in het kader van peer review. | ||
| Regel 71: | Regel 71: | ||
Afwijkingen of mogelijke afwijkingen worden vastgelegd op de [https://nictiz.atlassian.net/wiki/spaces/POB/pages/340099187/Product+Architectuur?atlOrigin=eyJpIjoiM2YyM2YzMTY4ODQ4NDIzZjk5NzE5NGM4N2FiMjBkOGUiLCJwIjoiYyJ9 interne Productarchitectuur Confluence-pagina] en geregistreerd als Jira-tickets. | Afwijkingen of mogelijke afwijkingen worden vastgelegd op de [https://nictiz.atlassian.net/wiki/spaces/POB/pages/340099187/Product+Architectuur?atlOrigin=eyJpIjoiM2YyM2YzMTY4ODQ4NDIzZjk5NzE5NGM4N2FiMjBkOGUiLCJwIjoiYyJ9 interne Productarchitectuur Confluence-pagina] en geregistreerd als Jira-tickets. | ||
| − | + | ==Monitoring== | |
De opvolging van acties bij geconstateerde afwijkingen vindt plaats via de Productarchitectuur Confluence-pagina, met verwijzingen naar de onderliggende Jira-tickets. | De opvolging van acties bij geconstateerde afwijkingen vindt plaats via de Productarchitectuur Confluence-pagina, met verwijzingen naar de onderliggende Jira-tickets. | ||
| Regel 77: | Regel 77: | ||
De productarchitect signaleert nieuwe afwijkingen die kunnen ontstaan tijdens de verdere uitwerking van de ontwerpplannen. | De productarchitect signaleert nieuwe afwijkingen die kunnen ontstaan tijdens de verdere uitwerking van de ontwerpplannen. | ||
| − | + | ==Toets voorafgaand aan publicatie== | |
Het voldoen aan de toetsingscriteria is een voorwaarde voor publicatie van een informatiestandaard. | Het voldoen aan de toetsingscriteria is een voorwaarde voor publicatie van een informatiestandaard. | ||
Bij geconstateerde afwijkingen beoordeelt de Productarchitectuurboard, op basis van de onderbouwing, of publicatie kan doorgaan. | Bij geconstateerde afwijkingen beoordeelt de Productarchitectuurboard, op basis van de onderbouwing, of publicatie kan doorgaan. | ||
| Regel 83: | Regel 83: | ||
Afwijkingen van verplichte of aanbevolen criteria worden vastgelegd en periodiek geëvalueerd om te bepalen of aanpassing van het toetsingskader nodig is. | Afwijkingen van verplichte of aanbevolen criteria worden vastgelegd en periodiek geëvalueerd om te bepalen of aanpassing van het toetsingskader nodig is. | ||
| − | + | =Beheer= | |
De toetsingscriteria worden beheerd door het Productarchitectuurteam en vastgesteld door de Productarchitectuurboard van de afdeling Productontwikkeling & Beheer van Nictiz. In het Productarchitectuurteam is tevens het Architectuurteam van de afdeling Strategie & Advies van Nictiz vertegenwoordigd. | De toetsingscriteria worden beheerd door het Productarchitectuurteam en vastgesteld door de Productarchitectuurboard van de afdeling Productontwikkeling & Beheer van Nictiz. In het Productarchitectuurteam is tevens het Architectuurteam van de afdeling Strategie & Advies van Nictiz vertegenwoordigd. | ||
Versie van 31 okt 2025 om 16:45
 |
This article or section is in the middle of an expansion or major restructuring and is not yet ready for use. |
This page has been removed from search engines' indexes.
| Hoofdpagina Productarchitectuur | Productarchitectuurprincipes | Toetsingskader | Toetsingscriteria |
|---|
Inhoud
Doel
De toetsingscriteria dragen bij aan de consistentie en samenhang tussen informatiestandaarden en ondersteunen daarmee de zorgbrede interoperabiliteit. Ze vormen een concrete uitwerking van de overkoepelende productarchitectuurprincipes en bieden kaders voor het ontwerpen van informatiestandaarden.
Reikwijdte
De toetsingscriteria zijn van toepassing op:
- het ontwerp van nieuwe informatiestandaarden;
- het beheer en de doorontwikkeling van bestaande informatiestandaarden.
De criteria gelden voor alle informatiestandaarden die onder beheer staan van Nictiz.
Karakter en status van toetsingscriteria
Definitie
Toetsingscriteria zijn ontwerpregels die de productarchitectuurprincipes vertalen naar toetsbare eisen. Ze bieden houvast bij het beoordelen van ontwerpen en bevorderen de eenduidigheid in de toepassing van architectuur.
De toetsingscriteria specificeren:
- welke generieke standaarden (en welke versies daarvan) moeten worden toegepast;
- welke regels gelden voor het gebruik van generieke standaarden binnen een informatiestandaard.
Niveau van verplichting
Elk toetsingscriterium kent een niveau van verplichting, afhankelijk van de status van de onderliggende documentatie:
- Verplicht: gebaseerd op documentatie met een definitieve status of waarover brede consensus bestaat.
- Aanbevolen: afgeleid van documentatie met een alfa- of bètastatus die nog niet volledig is gevalideerd of beproefd.
Wanneer een ontwerp van een informatiestandaard afwijkt van een toetsingscriterium, legt de beheerder van de standaard deze afwijking gemotiveerd en gedocumenteerd vast volgens het comply or explain-principe. Bij afwijkingen van verplichte toetsingscriteria geeft de beheerder aan hoe op termijn alsnog aan het criterium zal worden voldaan.
De volgende niveaus worden gehanteerd:
| Niveau | Betekenis |
|---|---|
| MUST | Verplicht. Essentieel voor het realiseren van interoperabiliteit en samenhang tussen informatiestandaarden. |
| MUST NOT | Niet toegestaan. Toepassing is in alle gevallen uitgesloten. |
| MUST NOT | Niet toegestaan. Toepassing is in alle gevallen uitgesloten. |
| SHOULD | Sterk aanbevolen. Afwijking is mogelijk, mits gemotiveerd en verantwoord. |
| SHOULD NOT | Wordt afgeraden. Toepassing is toegestaan, maar alleen met een onderbouwde motivatie. |
| MAY | Optioneel. Toepassing is toegestaan, maar niet verplicht. |
Toepassing
De toetsingscriteria vormen het kader voor:
- het opstellen van ontwerpdocumentatie door de beheerder van een informatiestandaard;
- de toetsing tijdens besluitvorming over acceptatie of wijziging van een informatiestandaard door het Productarchitectuurteam en de Productarchitectuurboard;
- de borging van interoperabiliteit binnen het stelsel van informatiestandaarden.
Proces
Ingangstoets
Bij het opstellen van een nieuw ontwerp van een informatiestandaard wordt een ingangstoets uitgevoerd. Deze toets vindt plaats in één of meerdere werksessies waarin het Productarchitectuurteam en de beheerder van de informatiestandaard gezamenlijk de ontwerpplannen beoordelen. Een tweede beheerteam van een andere informatiestandaard kan deelnemen in het kader van peer review.
Afwijkingen of mogelijke afwijkingen worden vastgelegd op de interne Productarchitectuur Confluence-pagina en geregistreerd als Jira-tickets.
Monitoring
De opvolging van acties bij geconstateerde afwijkingen vindt plaats via de Productarchitectuur Confluence-pagina, met verwijzingen naar de onderliggende Jira-tickets.
Elke informatiestandaard heeft een toegewezen productarchitect die fungeert als eerste aanspreekpunt voor vragen en advies over productarchitectuur.
De productarchitect signaleert nieuwe afwijkingen die kunnen ontstaan tijdens de verdere uitwerking van de ontwerpplannen.
Toets voorafgaand aan publicatie
Het voldoen aan de toetsingscriteria is een voorwaarde voor publicatie van een informatiestandaard. Bij geconstateerde afwijkingen beoordeelt de Productarchitectuurboard, op basis van de onderbouwing, of publicatie kan doorgaan.
Afwijkingen van verplichte of aanbevolen criteria worden vastgelegd en periodiek geëvalueerd om te bepalen of aanpassing van het toetsingskader nodig is.
Beheer
De toetsingscriteria worden beheerd door het Productarchitectuurteam en vastgesteld door de Productarchitectuurboard van de afdeling Productontwikkeling & Beheer van Nictiz. In het Productarchitectuurteam is tevens het Architectuurteam van de afdeling Strategie & Advies van Nictiz vertegenwoordigd.
Wijzigingen of aanvullingen worden vastgesteld na consultatie van betrokken stakeholders en gepubliceerd in de meest recente versie van dit document.
De toetsingscriteria kennen een hogere wijzigingsfrequentie dan de meer stabiele, overkoepelende productarchitectuurprincipes.
Documenthistorie
| Versie | Status | Datum | Wijziging |
|---|---|---|---|
| 0.1.0-alfa.1 | draft | 30-10-2025 |
Voor het opstellen van deze pagina is ChatGPT gebruikt als hulp voor het verbeteren van de schrijfstijl en zinsstructuur en voor grammaticacontrole.
