Bronhoudersdeel serviceafspraken
- Dennis de Gouw
VERSIE: 25-05-2023 STATUS: definitief
Incrementele implementatie
Het iWlz-netwerkmodel wordt incrementeel geïmplementeerd aan de hand van het afsprakenstelsel iWlz-netwerkmodel. Het eerste deel dat wordt geïmplementeerd is het Indicatieregister. Voor deze implementatiestap zijn alle onderdelen van dit artikel van toepassing. Voor de implementatiestap Indicatieregister is de hieronder genoemde Bronhouder de deelnemer CIZ.
Inleiding
In dit deel van de serviceafspraken worden de bepalingen beschreven die specifiek zijn voor deelnemers die de systeemrol bronhouder vervullen, de bronhouders. De scope van dit netwerkdeel beperkt zich tot het netwerk vanaf de bron-applicatie tot het component waar de bronhouder geen opdrachtgever of verantwoordelijke voor is.
- 1 1. Algemene beschikbaarheid (uptime) van het netwerkpunt Indicatieregister
- 2 2. Beheerprocessen bronhouders Indicatieregister
- 3 3. Beschikbaarheidsbeheer Indicatieregister
- 4 4. Onderhoudstijden Indicatieregister
- 5 5. Calamiteiten Indicatieregister
- 6 6. Inzichtelijkheid verversing afgeleide databases Indicatieregister
- 7 7. Beheer en beschikbaarstelling testomgeving Indicatieregister
- 8 8. Retourmeldingen indicatieregister Indicatieregister
1. Algemene beschikbaarheid (uptime) van het netwerkpunt Indicatieregister
Bronhouders zorgen voor een beschikbaarheid van minimaal 99,5 % van hun deel van het netwerkpunt waarover de deelnemers gegevens met elkaar uitwisselen. Onderhoud en verstoringen bij bronhouders worden door de bronhouder bij de operationeel netwerkbeheerder aangemeld en vervolgens door de operationeel netwerkbeheerder gecommuniceerd. De bronhouder is eindverantwoordelijk voor het informeren van de overige deelnemers van het netwerk over planbaar onderhoud. Het onderhoud wordt zoveel mogelijk buiten kantoortijden (tussen 08:30 en 17:00) uitgevoerd.
2. Beheerprocessen bronhouders Indicatieregister
2.1 Incidentbeheer bronhouders
Bronhouders zijn verantwoordelijk voor de inrichting van het eigen incidentbeheerproces, waarbij geldt dat incidenten door de centrale servicedesk aangemeld kunnen worden en opgepakt worden tussen 8:30 en 17:00 uur.
Prestatienorm | Meetmethode | Bijzonderheden |
|---|---|---|
Incidenten worden door gebruikers gemeld bij de eerstelijns ondersteuning van de eigen organisatie. Deze eerstelijns ondersteuning doet onderzoek naar het incident en stelt urgentie en impact vast. | Rapportage | Interne procedures voor het melden van incidenten kunnen per deelnemer verschillen. De algemene regel is dat eindgebruikers niet zelf contact opnemen met de centrale servicedesk, maar dat dit altijd gaat via de servicedesk van de eigen organisatie. |
Het Incidentbeheerproces is beschreven, vastgesteld en beschikbaar voor alle partijen. Waarbij specifiek ingegaan wordt op de verantwoordelijkheden die een bronhouder heeft mbt Incidentbeheer (zoals een impactanalyse voor het uitvallen van (een deel) van de bron). | Handmatig |
|
Beschrijf de bereikbaarheid van de eerstelijns servicedesk van de bronhouders. | Handmatig | Partijen zijn vrij het eigen incidentbeheerproces in te richten, maar dragen er zorg voor dat incidenten op maandag tot en met vrijdag van 8:30 tot 17:00 uur aangemeld kunnen worden en gedurende deze tijden ook worden behandeld. Incidentmeldingen die aangeleverd worden buiten de openstellingstijden worden zoveel mogelijk opgepakt. |
2.2 Probleembeheer bronhouders
Prestatienorm | Meetmethode | Bijzonderheden |
|---|---|---|
De bronhouder houdt actief bij welke incidenten tot problemen leiden die structureel moeten worden opgelost en komt hiervoor met concrete voorstellen richting klankbordgroep of technische klankbordgroep. | Rapportage |
|
In de klankbordgroep worden problemen rondom functionele zaken in de standaarden geïdentificeerd en geprioriteerd voor oplossing. | Rapportage |
|
De technische klankbordgroep bespreekt problemen rondom technische zaken in het netwerk en prioriteert deze voor oplossing. | Rapportage |
|
2.3 Capaciteitsbeheer bronhouders
Iedere op het iWlz-netwerk aangesloten partij monitort zelf actief de capaciteit van de infrastructuur waarover de gegevens worden getransporteerd en verwerkt.
Prestatienorm | Meetmethode | Bijzonderheden |
|---|---|---|
Bronhouders monitoren de benodigde capaciteit en schakelen waar nodig extra capaciteit bij om aan de vraag te kunnen voldoen. | Meting |
|
Gegevens leverende partijen zorgen ervoor dat gebruikte infrastructuur en hard- en software van voldoende niveau blijft om de normen in de Netwerk SLA te behalen. | Meting |
|
2.4 Continuiteitsbeheer bronhouders
Prestatienorm | Meetmethode | Bijzonderheden |
|---|---|---|
Iedere gegevens leverende partij draagt zorg voor een ingericht continuïteitsbeheerproces waarmee bij calamiteiten de dienstverlening conform deze iWlz netwerk serviceafspraken hersteld kunnen worden. Deze activiteiten en maatregelen worden in een continuïteitsplan vastgelegd. | Handmatige meting |
|
Continuïteitsbeheer omvat ook en sluit ook aan op maatregelen die erop zijn gericht om het optreden van een calamiteit te voorkomen. Partijen zijn vrij hier zelf invulling aan te geven, maar moeten bij calamiteiten handelen conform de afspraken daarover in dit afsprakenstelsel (zie paragraaf 5. Calamiteiten).
2.5 Configuratiebeheer bronhouders
Iedere gegevens leverende partij is zelf verantwoordelijk voor de inrichting van het eigen configuratiebeheer.
2.6 Logging, monitoring en rapportage bronhouders
Iedere bronhouder is zelf verantwoordelijk voor de inrichting van logging, monitoring en rapportage en de bijbehorende bewaartijden conform NEN 7513.
2.7 Kwaliteitsbeheer
De bronhouder is verantwoordelijk voor controles op de kwaliteit van de data en services die de bronhouder aanbiedt. De eisen waarvan de data (o.a. uitwisselformaat, actualiteit) en services (o.a. interface) moeten voldoen worden beschreven in de uitwisselprofielen van de registers.
3. Beschikbaarheidsbeheer Indicatieregister
Iedere op het iWlz netwerk aangesloten partij is zelf verantwoordelijk voor de beschikbaarheid van de eigen infrastructuur (netwerk) en componenten (Datastations e.d.). Onderscheid wordt gemaakt in beschikbaarheid ten behoeve van de eigen organisatie en beschikbaarheid waarbij andere organisaties afhankelijk zijn van deze beschikbaarheid. De eerste valt buiten de scope van de iWlz netwerk serviceafspraken.
Prestatienorm | Meetmethode | Bijzonderheden |
|---|---|---|
Netwerkpartijen zorgen voor beschikbaarheid van alle componenten die onderdeel uitmaken van de iWlz gegevensleveringen die vallen onder de scope van deze serviceafspraken aan de verschillende (netwerk)partijen tussen 8:30 en 17:00 uur op werkdagen. Buiten de afgesproken prestatienorm zijn de registers zoveel als mogelijk beschikbaar. | Meting | - |
Netwerkpartijen hebben een proces ingericht waarmee andere netwerkpartijen bewaakte openstelling buiten de prestatienorm van systemen en bronnen kunnen aanvragen. | Verzoeken tot bewaakte openstelling worden uiterlijk twee weken vooraf aangevraagd. Verzoeken tot bewaakte openstelling worden door de gegevensleverende netwerkpartij uiterlijk vier dagen voor de gevraagde openstelling afgehandeld. | Aanvragen voor extra openstelling verlopen via de centrale servicedesk. N.B. een aanvraag is een verzoek en kan ook afgewezen worden. |
4. Onderhoudstijden Indicatieregister
Gepland onderhoud op productieomgevingen, uitgevoerd door (één van) de partijen, aan (een onderdeel van) de diensten vindt zo veel mogelijk plaats buiten de afgesproken openstellingstijden (8:30-17:00 uur). Hiervan mag enkel afgeweken worden wanneer het gepland onderhoud niet verstorend is of wanneer voor het gepland onderhoud goedkeuring van de Stuurgroep iWlz is. Vastlegging hiervan vindt plaats in de notulen van de Stuurgroep iWlz of per mail. De in het Netwerk vastgestelde releasemomenten zijn terug te vinden in het document Releasebeheer iWlz en de bijbehorende releasekalender.
Prestatienorm | Meetmethode | Bijzonderheden |
|---|---|---|
Verstorend onderhoud vindt binnen de vastgestelde onderhoudsmomenten plaats. | Geconstateerde afwijkingen worden vastgelegd en gemeld bij de Centrale Servicedesk. Maandelijks wordt hierover gerapporteerd. | Tijdens de onderhoudsmomenten kan de beschikbaarheid van de diensten niet worden gegarandeerd. Verstorende afwijkingen van standaard onderhoudsvensters en binnen service-windows moeten worden gepubliceerd. Dit kan worden gedaan door deze aan te melden bij de centrale servicedesk van de operationeel netwerkbeheerder. indicatieregister N.B. In de implementatiestap Indicatieregister worden de deelnemers door de bronhouder zelf geïnformeerd. |
Partijen die buiten de eerder vastgestelde onderhoudsmomenten werkzaamheden willen uitvoeren, melden dit zo snel mogelijk bij de centrale servicedesk, die dit vervolgens communiceert naar de afnemers. |
|
|
5. Calamiteiten Indicatieregister
Iedere partij maakt na het optreden van een calamiteit zo snel mogelijk inzichtelijk wat de gevolgen hiervan zijn voor de afnemers en komt met een oplostermijn voor de herstelactiviteiten om de dienstverlening te herstellen. Communicatie hierover verloopt primair via de Stuurgroep iWlz. De leden van de Stuurgroep iWlz informeren hun eigen achterban.
Definitie calamiteit
Een calamiteit is een ongeplande situatie met onbeschikbaarheid van diensten en producten tot gevolg, waarbij verwacht wordt dat de duur van de onderbreking de afgesproken drempelwaarden uit de SLA zal overschrijden. Calamiteiten zijn altijd een prioriteit 1 incident. Een calamiteit kan ook buiten het service window optreden als de verwachting bestaat dat het incident niet voor het begin van het service window weer beschikbaar is.
Voorbeelden van calamiteiten zijn Brand in het datacentrum, kabelbreuk door graafwerkzaamheden, hackpogingen (P&B gerelateerd incident) en dergelijke.
Bij calamiteiten wordt altijd het reguliere incidentbeheerproces gevolgd echter start direct het proces van escalatie via de voorzitter van de Stuurgroep iWlz. Door de centrale servicedesk wordt vervolgens met de houder van het incident de communicatie verzorgd richting de afnemers.
6. Inzichtelijkheid verversing afgeleide databases Indicatieregister
Elke bronhouder draagt zorg voor inzichtelijkheid van de actualiteit van de aangeboden data. Te allen tijde wordt getracht de aangeboden data zo actueel mogelijk te houden. De partijen hebben hiervoor een inspanningsverplichting.
7. Beheer en beschikbaarstelling testomgeving Indicatieregister
Iedere bronhouder dient een testomgeving beschikbaar te stellen. Deze testomgevingen worden gebruikt in de volgende situaties:
Bij het toetreden van nieuwe deelnemers tijdens de onboarding.
Het onboardingproces bevat een procedure waarin een onboarding-test is vastgelegd.
Bij het testen van nieuwe software releases van het iWlz netwerkmodel.
Per release zal een release-testplan worden opgesteld. Afhankelijk van de aard van de wijzigingen zal de omvang hiervan verschillen.
Zolang het estafettemodel en het netwerkmodel naast elkaar operationeel zijn zal de frequentie van de software-releases 1 keer per jaar zijn.
De testomgeving die de bronhouder beschikbaar stelt heeft dezelfde functionele en technische inrichting als het productiesysteem en is instaat om met de andere testomgevingen te communiceren op de manier zoals dat gebruikelijk is in de productieomgeving. Het verschil tussen de test- en productieomgeving zit hem met name op het niveau van de data. In de testomgeving zal gewerkt worden met een beperkte set representatieve fictieve data. In overleg met de bronhouders en afnemers wordt deze standaard datatestset samengesteld. Bij iedere nieuwe software release moet gekeken worden of de standaard datatestset aangepast moet worden, bijvoorbeeld om het mogelijk te maken een nieuw veld te testen.
Daarnaast zal in overleg met leveranciers steeds gekeken worden welke software versies op de testomgevingen draaien. Dit is met name relevant bij het testen van nieuwe releases.
Prestatienorm | Meetmethode | Bijzonderheden |
|---|---|---|
Bronhouders stellen voor het register representatieve data en services beschikbaar om te kunnen testen. |
|
|
Het gebruik van productiedata in de testomgeving is niet toegestaan. |
| De stelselbeheerder Zorginstituut publiceert bij nieuwe releases een lijst met fictieve BSN’s voor testdoeleinden. Zie: https://www.istandaarden.nl/binaries/content/assets/istandaarden/iwlz/iwlz-2.3-losse-bestanden/landelijk-ketentestplan-iwlz-2.3---bijlage-2-lijst-fictieve-bsns.xlsx |
Bronhouders zijn verplicht om op verzoek van andere deelnemers testdata beschikbaar te stellen, waarmee de deelnemers in staat is om te testen. |
|
|
Deelnemers dienen bij hun dienstverlener aan te geven wat zij gaan testen en welke onderdelen van de testomgeving gebruikt gaan worden (gegevens van partij, belasting etc.). |
|
|
Beschikbaarheid testomgeving voor bronhouders: 90% binnen kantoortijden (tussen 08:30 en 17:00 uur). | Storingen die de beschikbaarheid aantasten worden geregistreerd. Handmatig wordt hieruit de beschikbaarheid berekend. | Bronhouders moeten voor onderhoud op de testomgeving ook onderhoudswindows beschikbaar stellen |
8. Retourmeldingen indicatieregister Indicatieregister
Bronhouder is verantwoordelijk voor het correct vullen van de indicatie in het register. In het geval de afnemer de gegevens niet kan verwerken omdat ze niet aan de istandaarden voldoen, dan heeft de afnemer de mogelijkheid om dit te melden aan de bronhouder (afkeur).
Bronhouder is dan verantwoordelijk voor het corrigeren van de onjuiste gegevens en het opnieuw notificeren van de afnemer. De afnemer kan vervolgens de (gecorrigeerde) indicatiegegevens opnieuw ophalen en verwerken.
8.1 Reactietermijnen Indicatieregister
De afnemer is verantwoordelijk voor het tijdig melden van afkeur aan de bronhouder. De bronhouder is daaropvolgend verantwoordelijk voor het tijdig corrigeren van de afkeur.
Actie | Actiehouder | Termijn | Route * |
|---|---|---|---|
Melden afkeur | Afnemer | 1 werkdag | meldnr CIZ: … beschikbaarheid: … |
Corrigeren afkeur | Bronhouder | 1 werkdag | Corrigeren gegevens** Vervolgens nieuwe notificatie |
*De afkeur wordt buiten het netwerk om gemeld bij de bronhouder totdat retourmeldingen/terugmeldingen onderdeel zijn van het netwerk.
**In eerste instantie zal dat een nieuw indicatiebesluit zijn met een nieuwe logische sleutel combinatie. In de eindsituatie zal het desbetreffende record van het afgegeven indicatiebesluit ge-update worden (OP180 estafettemodel).