Skip to main content
Skip table of contents

MMAF-286 SR Nieuwe opzet Testbeleid

Omschrijving Changelog, met daarin:

  • Titel Jira ticket

  • Naam te wijzigen pagina

  • Korte omschrijving v.d. aanpassing in voltooid verleden tijd.

Nieuwe opzet Testbeleid

Gewijzigde pagina’s:

  • Begrippenlijst

  • Testbeleid

  • Testen (nieuw)

  • Testen van gegevensdienst (nieuw)

  • Operationeel proces testen (nieuw)

De informatie op de pagina “Testbeleid” is volledig herzien door het in gebruik nemen van de testvoorziening. Informatie over “Testen” is opgenomen in een eigen onderdeel binnen de “Afsprakenset”. De “Begrippenlijst” is aangevuld met begrippen vanuit testen.

Impact op:

  • DVP
  • DVA
  • Geen van beiden

Te informeren Stakeholders

  • Acceptatie
  • R&A beheer
  • Regie
  • CCDA
  • Security
  • Relatiebeheer
  • Communicatie
  • MM Loket
  • Stichting MM
  • Ontwikkeling MM Afsprakenstelsel

Moeten afbeeldingen/mockups aangepast worden?

  • Ja
  • Nee

Aan te passen versies afsprakenstelsel

MedMij Afsprakenstelsel 3.0.0 optioneel

Classificatie

  • Patch
  • Minor
  • Major

Implementatie Termijn

publicatie in eerstvolgende major release 2024

Gerelateerde tickets (o.a. ticket van deze ticket)

User StoryMMAF-284 - Review van de analyse tbv het volwassenheidsmodel [time box] Done

User StoryMMAF-286 - Testbeleid en Volwassenheidsmodel SR's reviewen en opnemen in release V3 Done

User StoryMMAF-290 - Aanmaken van Confluence Space Testscenario's afsprakenstelsel Done

Eerst wijziging doorvoeren: MMOS-344/MMAF-209, SR-MM-AS Opstellen SR-s Cataloguseisen in het MM-AS (input vanuit St MedMij)

Status

  • Staat klaar voor release in afsprakenstelsel
  • Verwerkt in afsprakenstelsel

Uitwerking

Zet bij de locatie (en indien van toepassing bij de “In te voegen links (optioneel)”) de link naar de confluence space (bijv. MedMij Afsprakenstelsel 2), zet hier niet de link naar scroll view pagina. Is het een tabel benoem dan bij de locatie ook de rij.

Kopieer voor de oude en de nieuwe tekst ook de regel voor en na de aan te passen zin.

In de kolom Oude tekst, maak de verwijderde of gewijzigde stukken rood en streep ze door
In de kolom Nieuwe tekst, geef de nieuwe stukken hebben deze blauwige/groenige kleur.

Wil je een link toevoegen maak het woord paars in de kolom “Nieuwe tekst” en zet de link in de kolom In te voegen links (optioneel).

Door te voeren wijzigingen

Structuur

Opmerking aan Redactie: hieronder de nieuwe structuur; nieuwe pagina is aangegeven met aanduiding (nieuw) erachter. De andere pagina’s zijn bestaand en onveranderd en dienen om de juiste plek en inspringing aan te geven.

  • Afsprakenset

    • Normenkader informatiebeveiliging

    • Testen (nieuw)

      • Testbeleid (Huidige pagina wordt volledig aangepast)

        • Testen van gegevensdienst (nieuw)

      • Operationele processen testen (nieuw)

    • Beleid

Nieuwe pagina’s

Locatie:

  • Afsprakenset

    • Normenkader informatiebeveiliging

    • Testen (nieuw)

      • Testbeleid (Huidige pagina wordt volledig aangepast)

        • Testen van gegevensdienst (nieuw)

      • Operationele processen testen (nieuw)

    • Beleid

Oude tekst: n.v.t., nieuwe pagina

Nieuwe tekst

Testen

Om de interoperabiliteit en het vertrouwen in het stelsel te borgen, moeten deelnemers aantonen dat zij de Architectuur en technische specificaties en de Gegevensdiensten die zij ontsluiten op de juiste manier ondersteunen. De (kandidaat-)deelnemer doorloopt bij toetreding en tijdens deelname verplichte testen. De testen bepalen of de (kandidaat-)deelnemer voldoende in staat is om de afspraken uit de architectuur en technische specificaties waar te maken en de gegevensdiensten op de juiste manier te gebruiken. 

Nieuwe tekst

In te voegen links

Opmerking aan redactie

Om de interoperabiliteit en het vertrouwen in het stelsel te borgen, moeten deelnemers aantonen dat zij de Architectuur en technische specificaties en de Gegevensdiensten die zij ontsluiten op de juiste manier ondersteunen.

https://afsprakenstelsel.medmij.nl/asverplicht/mmverplicht/architectuur-en-technische-specificaties

Dit is niet de ‘afsprakenstelsel 3’ link - die is nog niet aangemaakt op 22 maart 2024


Locatie

https://afsprakenstelsel.medmij.nl/asverplicht/mmverplicht/testbeleid

Oude tekst

Testbeleid

Om de interoperabiliteit en het vertrouwen in het stelsel te borgen, moeten deelnemers aan tonen de Architectuur en technische specificaties en de Gegevensdiensten die zij ontsluiten op de juiste manier te ondersteunen. De deelnemer doorloopt bij toetreding en tijdens deelname testen. De testen bepalen of de deelnemer voldoende in staat is om de afspraken uit de architectuur en technische specificaties waar te maken en de gegevensdiensten op de juiste manier te gebruiken. Stichting MedMij toetst niet de volledige implementatie, maar richt zich op risico’s, interoperabiliteit tussen deelnemers en cruciale maatregelen voor het vertrouwen in MedMij.

De testresultaten hebben een beperkte geldigheidsduur van 365 dagen vanaf het positief doorlopen van de test. Uitzondering daarop zijn de testresultaten met betrekking tot de ondersteuning van Systeemrollen, deze hebben een onbeperkte geldigheid. 

Toelichting

Gedurende de geldigheid van een Gegevensdienst is een Deelnemer verantwoordelijk de Systeemrollen te ondersteunen volgens de daarbij behorende specificaties (zie verantwoordelijkheid 2 op de Applicatielaag). Sommige Kwalificatieloketten bieden een externe toets op de correcte implementatie van de Systeemrollen als een deelnemer dit wenst:

  • na een wijziging in zijn applicatie (voor Dienstverleners Persoon of Dienstverleners Zorgaanbieder),

  • in een achterliggend bronsysteem (voor Dienstverleners Zorgaanbieder),

  • en/of in combinatie met een applicatie met achterliggend bronsysteem (voor Dienstverleners Zorgaanbieder). 

Bij het aanvragen en inplannen van de hernieuwde test stelt de Deelnemer in overleg met de beheerorganisatie vast tegen welke versie van het MedMij Afsprakenstelsel zij de test uitvoeren (zie Change- en releasebeleid). 

Wanneer is testen noodzakelijk? We onderscheiden de volgende situaties:

  1. De Deelnemer wil erkend worden als ontsluiter van een Gegevensdienst;

  2. Hertest op initiatief van de Deelnemer, omdat de geldigheidsduur van diens testresultaten dreigt te verlopen. 

  3. Twijfel over de naleving van de afspraken;

  4. Hertoetreding als bedoeld in artikel 14.3 van de Deelnemersovereenkomst.

Situatie 1: De deelnemer wil erkend worden als ontsluiter van een gegevensdienst

In situatie 1 moet de deelnemer op grond van het Gegevensdienstenbeleid aantonen dat:

(A) de relevante usecases uit de Architectuur en technische specificaties,

(B) de algemene verantwoordelijkheden uit de Architectuur en technische specificaties en

(C) de systeemrollen uit de Gegevensdienst
goed worden ondersteund.

Voor (A) geldt het volgende schema:

Enlarges the table by opening it in a full screen dialogOpen

Scope van de test (relevante usecases)

Usecase(s) behorende
bij de Gegevensdienst

Dienstverlener
persoon

Dienstverlener
aanbieder

Verzamelen

Verzamelen

Opvragen Aanbiederslijst

Opvragen Gegevensdienstnamenlijst

Verzamelen

Opvragen OAuth Client List

Opvragen Gegevensdienstnamenlijst

Delen

Delen

Opvragen Aanbiederslijst

Opvragen Gegevensdienstnamenlijst

Delen

Opvragen OAuth Client List

Opvragen Gegevensdienstnamenlijst

Abonneren

Abonneren

Notificeren

Abonneren

Notificeren

De functies moeten worden beschouwd inclusief de bijbehorende verantwoordelijkheden en de formele regels in de relevante Informatiemodellen.

Onder (B) wordt verstaan: de verantwoordelijkheden, inclusief de functie Opvragen Whitelist.

Voor (C) geldt dat in de Catalogus te vinden is waar de ondersteuning van de Systeemrollen behorend bij een Gegevensdienst kan worden aangetoond. De test op de Systeemrollen gebeurt in een opstelling die afwijkt van de productiesituatie. Het streven is om de toets in deze opstelling met zo min mogelijk aanvullende inspanningen van de deelnemer uit te voeren. Aanvullende technische inspanning blijft echter nodig. Deelnemers committeren zich via hun deelname aan het afsprakenstelsel aan deze inspanningen. De beheerder van de betreffende informatiestandaard heeft informatie over de kwalificatie.

De deelnemer kan zich voorbereiden op testen (A) en (B) in de permanente testomgeving (MedMij zandbak) van Stichting MedMij. Voor testen (C) kan de deelnemer zich voorbereiden in de testomgeving van de partij die deze toets verzorgt. Voor (A) en (B) geldt verder dat eerdere positieve testen voor een functie of de algemene verantwoordelijkheden niet opnieuw hoeven te worden uitgevoerd als de deelnemer erkend wil worden als ontsluiter van een nieuwe gegevensdienst.

Situatie 2

De beperking van de geldigheidsduur van de testresultaten is onderdeel van het Nalevingsbeleid. Wanneer de geldigheid van de testresultaten verloopt, dreigt opschorting van de Deelnemersovereenkomst, in het kader van artikel 7, lid 3. Het verlopen van de testresultaten wordt gezien als één mogelijkheid waarop niet-naleving geconstateerd wordt.

Deelnemers zijn zelf verantwoordelijk voor het inplannen van de testen voor het herbevestigen van de geldigheid van hun implementatie, voordat de geldigheid van bestaande testresultaten verloopt. Daarbij stelt de Deelnemer in overleg met de beheerorganisatie vast tegen welke actieve versie van het MedMij Afsprakenstelsel de test zal worden uitgevoerd (zie Change- en releasebeleid).

Bij het succesvol doorlopen van de hertest zijn de nieuwe testresultaten opnieuw 365 dagen geldig.

Situatie 2

Het testbeleid wil eraan bijdragen dat Deelnemers een voorspelbare ontwikkelkalender voor hun implementatie kunnen hanteren, afgestemd op de regelmatige releasemomenten van het MedMij Afsprakenstelsel (zie Change- en releasebeleid) en de hertesten.

Heracceptatie voor (A) en (B)

In Situatie 2 geldt voor het vaststellen van

(A) de relevante usecases uit de Architectuur en technische specificaties en 

(B) voor het vaststellen van de algemene verantwoordelijkheden uit de Architectuur en technische specificaties, dat de heracceptatietest is te beschouwen als een ‘apk’ voor MedMij-deelnemers.

Doel is om vast te stellen of de implementatie van de deelnemer voldoet aan de eisen van één van de actieve versies van het Afsprakenstelsel, de (her-)bevestiging van een implementatie op (A) en (B). (Zie Change- en releasebeleid voor uitleg over de versies van het afsprakenstelsel.)

In overleg tussen deelnemer en de beheerorganisatie wordt bepaald of de test tegen de geldige laatst gepubliceerde of de verplichte versie van het Afsprakenstelsel wordt uitgevoerd.  Doordat de heracceptatietesten zijn los gekoppeld van toetreding en van de uitrol van releases van het Afsprakenstelsel, kunnen deelnemer zelf hun ontwikkeltempo en moment van uitrol van een koppelvlak versie bepalen.

Situaties 3 en 4

In situaties 3 en 4 wordt per geval bekeken wat er opnieuw getest moet worden. De geldigheid van eerdere positieve testresultaten kunnen in deze situaties vervallen.

Nieuwe tekst

Testbeleid 

Opmerking bij het testen van gegevensdiensten: dit wordt beschreven in onderstaand beleid en geldt vooralsnog naast het eerdere Testbeleid. Tot die tijd blijft daarom ook de informatie onder Testen van gegevensdienst van toepassing.

Het is de verantwoordelijkheid van de (kandidaat)-deelnemer dat de functionaliteit correct werkt zoals beschreven in het MedMij Afsprakenstelsel en dat deze interoperabel is met de systemen van andere deelnemers.  Bij elke release van het MedMij Afsprakenstelsel bepaalt MedMij de reikwijdte van het testen, inclusief welke testplannen moeten worden doorlopen en aan welke criteria moet worden voldaan, voordat in productie mag worden gegaan. Deze afspraken garanderen uniformiteit en een gelijk speelveld en worden opgenomen in een openbaar testplan, dat wordt gepubliceerd via de Testmethodiek.

 

In de vorm van afspraken: 

De (kandidaat-)deelnemer is verantwoordelijk voor de kwaliteit van het eigen product. Zelf grondig testen van de applicatie en relevante koppelingen is randvoorwaardelijk om deze kwaliteit op te leveren en vast te stellen. 

Beleid.test.001

De (kandidaat-)deelnemer is verantwoordelijk voor de interoperabiliteit en het opbouwen van vertrouwen bij andere deelnemers, met betrekking tot de implementatie van nieuwe functionaliteiten of systemen. 

Beleid.test.002

De (kandidaat-)deelnemer moet de verplichte testscenario’s aantoonbaar succesvol doorlopen, voor het behalen of behouden van het MedMij label.

Beleid.test.003

De deelnemer is verantwoordelijk bij wijzigingen die mogelijke impact hebben op de functionaliteit en/of interoperabiliteit, om opnieuw de relevante verplichte testscenario’s succesvol te doorlopen.

Beleid.test.004

De deelnemer is verantwoordelijk om eenmaal per jaar de heracceptatie succesvol te doorlopen bij de Beheerorganisatie. Zie Proces vernieuwing erkenning van Deelnemer onder Operationele processen.

Beleid.test.005

MedMij is verantwoordelijk voor het bieden van een testvoorziening. Zodoende ontstaat er een gelijk speelveld voor alle deelnemers en kan MedMij actief deelnemers faciliteren. 

Beleid.test.006

MedMij is verantwoordelijk voor het bespreken van een voorgenomen testscenario met de deelnemers middels een expertsessie, alvorens deze wordt vastgesteld. 

Beleid.test.007

MedMij is verantwoordelijk voor het tijdig publiceren van vastgestelde testscenario’s in afstemming met de deelnemers. 

Beleid.test.008

MedMij is verantwoordelijk voor het testen van voorgenomen wijzigingen, indien deze invloed kunnen hebben op de functionaliteit. 

Beleid.test.009

MedMij is verantwoordelijk voor het aantoonbaar succesvol doorlopen van verplichte testscenario’s en zal deze resultaten publiceren via de Testmethodiek.

Beleid.test.010

MedMij zal bij elke minor of major release van het MedMij afsprakenstelsel bijbehorende verplichte testscenario’s publiceren.

Beleid.test.011

MedMij zal bij wijzigingen van de catalogus bijbehorende verplichte testscenario’s publiceren, indien deze invloed hebben op de functionaliteit en/of interoperabiliteit.

Beleid.test.012

MedMij is verantwoordelijk voor het minstens eenmaal per jaar organiseren van een verplichte ketentest.

Beleid.test.013

Het bestuur van Stichting MedMij kan in individuele gevallen akkoord geven om af te wijken van verplichte scenariotesten.

Beleid.test.014

Verplichte testplannen

De verplichte testplannen zijn in ontwikkeling.  

In te voegen links

Nieuwe tekst

In te voegen links

Opmerking aan redactie

Tot die tijd blijft daarom ook de informatie onder Testen van gegevensdienst van toepassing.

Link naar nieuw aan te maken pagina met titel Testen van gegevensdienst

Deze afspraken garanderen uniformiteit en een gelijk speelveld en worden opgenomen in een testplan, dat wordt gepubliceerd via de Testmethodiek, dat openbaar is. 

Link naar nieuw aan te maken pagina Testmethodiek binnen space Testmethod

Space: https://vzvz.atlassian.net/wiki/spaces/Testmethod ; pagina nog niet aangemaakt op 22 maart 2024

Zie Proces vernieuwing erkenning van Deelnemer onder Operationele processen.

https://afsprakenstelsel.medmij.nl/asverplicht/mmverplicht/operationele-processen

Dit is niet de ‘afsprakenstelsel 3’ link - die is nog niet aangemaakt op 22 maart 2024

MedMij is verantwoordelijk voor het aantoonbaar succesvol doorlopen van verplichte testscenario’s en zal deze resultaten publiceren via de Testmethodiek.

Link naar nieuw aan te maken pagina Testmethodiek binnen space Testmethod

Space: https://vzvz.atlassian.net/wiki/spaces/Testmethod ; pagina nog niet aangemaakt op 22 maart 2024


Testen van gegevensdienst

Opmerking aan redactie: voordat onderstaande pagina wordt aangemaakt, eerst wijzigingen onder MMOS-344/MMAF-209, SR-MM-AS Opstellen SR-s Cataloguseisen in het MM-AS (input vanuit St MedMij) doorvoeren, daarna pas onderstaande nieuwe tekst voor pagina Testen van gegevensdienst.

Locatie:

  • Afsprakenset

    • Normenkader informatiebeveiliging

    • Testen (nieuw)

      • Testbeleid (Huidige pagina wordt volledig aangepast)

        • Testen van gegevensdienst (nieuw)

      • Operationele processen testen (nieuw)

    • Beleid

Oude tekst: n.v.t., nieuwe pagina

Nieuwe tekst

Testen van gegevensdienst

Erkenning van Deelnemer als ontsluiter van een Gegevensdienst 

Deelnemers ontsluiten Gegevensdiensten via het MedMij-netwerk voor en namens gebruikers. Voordat een Deelnemer in deze rol wordt erkend, dient zij aan te tonen de Gegevensdienst op de juiste manier te ondersteunen. In de Catalogus staat per Gegevensdienst beschreven welke relevante Systeemrollen uit de bijbehorende Informatiestandaard en welke usecase uit de Architectuur en technische specificaties ondersteund dienen te worden. Daarnaast is in het Gegevensdienstenbeleid uiteengezet hoe deze worden ontwikkeld en onderhouden en hoe hun beschikbaarheid aan de hand van volwassenheidsniveaus wordt bepaald. Indien een Deelnemer nog niet over een erkenning voor een vereiste Gegevensdienst beschikt, dan dient deze partij eerst deze erkenning te behalen. Hieronder staat verder beschreven hoe de ondersteuning van de Gegevensdienst en, indien nodig, de usecase, kan worden aangetoond. Stichting MedMij ziet erop toe dat aan alle voorwaarden wordt voldaan, alvorens erkenningen worden afgegeven.

Toelichting

Gedurende de geldigheid van een Gegevensdienst is een Deelnemer verantwoordelijk de Systeemrollen te ondersteunen volgens de daarbij behorende specificaties (zie verantwoordelijkheid 2 op de Applicatielaag). Het Kwalificatieloket biedt een externe toets op de correcte implementatie van de Systeemrollen als een deelnemer dit wenst:

  • na een wijziging in zijn applicatie (voor Dienstverleners Persoon of Dienstverleners Zorgaanbieder),

  • in een achterliggend bronsysteem (voor Dienstverleners Zorgaanbieder),

  • en/of in combinatie met een applicatie met achterliggend bronsysteem (voor Dienstverleners Zorgaanbieder). 

De deelnemer wil erkend worden als ontsluiter van een gegevensdienst

De deelnemer moet aantonen dat goed worden ondersteund:

(A) de relevante usecases uit de Architectuur en technische specificaties,

(B) de algemene verantwoordelijkheden uit de Architectuur en technische specificaties en

(C) de systeemrollen uit de Gegevensdienst.

Voor (A) geldt het volgende schema:

Scope van de test (relevante usecases)

Usecase(s) behorende
bij de Gegevensdienst

Dienstverlener
persoon

Dienstverlener
aanbieder

Verzamelen

Verzamelen

Opvragen Aanbiederslijst

Opvragen Gegevensdienstnamenlijst

Verzamelen

Opvragen OAuth Client List

Opvragen Gegevensdienstnamenlijst

Delen

Delen

Opvragen Aanbiederslijst

Opvragen Gegevensdienstnamenlijst

Delen

Opvragen OAuth Client List

Opvragen Gegevensdienstnamenlijst

Abonneren

Abonneren

Notificeren

Abonneren

Notificeren

De functies moeten worden beschouwd inclusief de bijbehorende verantwoordelijkheden en de formele regels in de relevante Informatiemodellen.

Onder (B) wordt verstaan: de verantwoordelijkheden, inclusief de functie Opvragen Whitelist.

Voor (C) geldt dat in de Catalogus te vinden is waar de ondersteuning van de Systeemrollen behorend bij een Gegevensdienst kan worden aangetoond. De test op de Systeemrollen gebeurt in een opstelling die afwijkt van de productiesituatie. Het streven is om de toets in deze opstelling met zo min mogelijk aanvullende inspanningen van de deelnemer uit te voeren. Aanvullende technische inspanning blijft echter nodig. Deelnemers committeren zich via hun deelname aan het afsprakenstelsel aan deze inspanningen. De beheerder van de betreffende informatiestandaard heeft informatie over de kwalificatie.

De deelnemer kan zich voorbereiden op testen (A) en (B) in de permanente testomgeving (MedMij zandbak) van Stichting MedMij. Voor testen (C) kan de deelnemer zich voorbereiden in de testomgeving van de partij die deze toets verzorgt. Voor (A) en (B) geldt verder dat eerdere positieve testen voor een functie of de algemene verantwoordelijkheden niet opnieuw hoeven te worden uitgevoerd als de deelnemer erkend wil worden als ontsluiter van een nieuwe gegevensdienst.

In te voegen links

Nieuwe tekst

In te voegen links

Opmerking aan redactie

Daarnaast is in het Gegevensdienstenbeleid uiteengezet hoe deze worden ontwikkeld en onderhouden en hoe hun beschikbaarheid aan de hand van volwassenheidsniveaus wordt bepaald.

https://afsprakenstelsel.medmij.nl/asverplicht/mmverplicht/gegevensdienstenbeleid

Dit is niet de ‘afsprakenstelsel 3’ link - die is nog niet aangemaakt op 22 maart 2024

De functies moeten worden beschouwd inclusief de bijbehorende verantwoordelijkheden en de formele regels in de relevante Informatiemodellen.

https://afsprakenstelsel.medmij.nl/asverplicht/mmverplicht/informatiemodellen

Dit is niet de ‘afsprakenstelsel 3’ link - die is nog niet aangemaakt op 22 maart 2024

Voor (C) geldt dat in de Catalogus te vinden is waar de ondersteuning van de Systeemrollen behorend bij een Gegevensdienst kan worden aangetoond.

https://catalogus.medmij.nl/overzicht/actueel/actuele-gegevensdiensten


Locatie:

  • Afsprakenset

    • Normenkader informatiebeveiliging

    • Testen (nieuw)

      • Testbeleid (Huidige pagina wordt volledig aangepast)

        • Testen van gegevensdienst (nieuw)

      • Operationele processen testen (nieuw)

    • Beleid

Oude tekst: n.v.t., nieuwe pagina

Nieuwe tekst

Operationele processen testen

Het onderdeel ‘Operationele processen testen’ geeft op hoofdlijnen een overzicht van de belangrijkste testprocessen waarbij deelnemers een rol spelen.

Testproces als onderdeel van (her-)acceptatie van (Kandidaat-)Deelnemer  

  • Doel: Het testproces als onderdeel van (her-)acceptatie van (Kandidaat-)Deelnemer heeft als doel te toetsen of de (Kandidaat-)Deelnemer voldoet aan het MedMij afsprakenstelsel. 

  • Initiatie: (Kandidaat-)Deelnemer wordt getoetst op conformatie aan het MedMij afsprakenstelsel. 

  • Afspraken over het proces:
    Operationele afspraken zijn vastgesteld in lijn met het Testbeleid

  1. Testproces voor (Kandidaat-)Deelnemers: 

    1. (Kandidaat-)Deelnemers moeten alle relevante simulatortesten doorlopen voordat ze contact opnemen met de Beheerorganisatie voor (her)acceptatie. 

    2. De (Kandidaat-)deelnemer moet een rapportage aanleveren waarin wordt aangetoond dat alle relevante simulatortesten met succes zijn doorlopen. 

    3. De Beheerorganisatie zal op basis van deze rapportage beoordelen of er nog technische problemen zijn die moeten worden opgelost voordat er wordt geaccepteerd. 

  2. Verantwoordelijkheid van MedMij: 

    1. De Beheerorganisatie zal bij elke minor en optionele major release van het MedMij afsprakenstelsel de reikwijdte van het testen afstemmen tijdens expertsessies met deelnemers, inclusief welk testplan moet worden aangetoond en aan welke criteria moet worden voldaan. Deze afspraken worden opgenomen in de Testmethodiek

    2. De Beheerorganisatie zal een simulator ter beschikking stellen om de overeengekomen specificaties te kunnen toetsen.

  3. Verantwoordelijkheid van de (Kandidaat-)deelnemer: 

    1. De (Kandidaat-)deelnemer is verplicht de simulator te gebruiken voor het uitvoeren van de verplichte testscenario’s. De simulator levert bewijs van de uitgevoerde test(en) en de testresultaten, welke moeten worden overlegd aan de Beheerorganisatie. 

  4. Acceptatie en Ketentest: 

    1. De (Kandidaat-)deelnemer neemt contact op met de Beheerorganisatie wanneer ze klaar is voor (her)acceptatie. 

    2. MedMij organiseert minstens eenmaal per jaar een verplichte ketentest. 

  1. Monitoring en Handhaving: 

    1. De Beheerorganisatie is verantwoordelijk voor het monitoren van de naleving van de operationele afspraken. 

    2. Bij niet-naleving van de afspraken treedt het nalevingsbeleid in werking.

  2. Resultaat: 

    1. Deelnemer blijft erkend als deelnemer van MedMij. Stichting MedMij heeft het betreffende register aangepast. De deelnemer wordt geïnformeerd over de doorgevoerde wijziging.

    2. De kandidaat-deelnemer heeft voldaan aan dit onderdeel van het Toetredingsproces.

  3. Uitzonderingen: (Kandidaat-)deelnemer voldoet niet aan de vereisten van het MedMij afsprakenstelsel en wordt niet (langer) erkend als deelnemer. 

In te voegen links

Nieuwe tekst

In te voegen links

Opmerking aan redactie

Operationele afspraken zijn vastgesteld in lijn met het Testbeleid

Link naar nieuw aan te maken pagina met titel Testbeleid

Deze afspraken worden opgenomen in de Testmethodiek

Link naar nieuw aan te maken pagina Testmethodiek binnen space Testmethod

Space: https://vzvz.atlassian.net/wiki/spaces/Testmethod ; pagina nog niet aangemaakt op 22 maart 2024

Bij niet-naleving van de afspraken treedt het nalevingsbeleid in werking.

https://afsprakenstelsel.medmij.nl/asverplicht/mmverplicht/nalevingsbeleid

Dit is niet de ‘afsprakenstelsel 3’ link - die is nog niet aangemaakt op 22 maart 2024

De kandidaat-deelnemer heeft voldaan aan dit onderdeel van het Toetredingsproces.

https://afsprakenstelsel.medmij.nl/asverplicht/mmverplicht/toetredingsproces

Dit is niet de ‘afsprakenstelsel 3’ link - die is nog niet aangemaakt op 22 maart 2024


Verwijzingen vanaf andere pagina’s

Locatie

Oude tekst

Nieuwe tekst

In te voegen links (optioneel)

https://afsprakenstelsel.medmij.nl/asverplicht/mmverplicht/operationele-processen

de Gegevensdienst horende Informatiestandaard(zie Testbeleid en Catalogus).

Link naar nieuw aan te maken pagina met titel Testbeleid

https://afsprakenstelsel.medmij.nl/asverplicht/mmverplicht/operationele-processen

de ondersteuning van de aanvullende functionaliteit middels een toets te laten zien (zie Testbeleid).

Link naar nieuw aan te maken pagina met titel Testbeleid

https://afsprakenstelsel.medmij.nl/asverplicht/mmverplicht/toetredingsbeleid

als ontsluiter van minimaal één gegevensdienst (zie Gegevensdienstenbeleid en Testbeleid).

Link naar nieuw aan te maken pagina met titel Testbeleid

https://afsprakenstelsel.medmij.nl/asverplicht/mmverplicht/nalevingsbeleid

  • De test bij de erkenning van een deelnemer als ontsluiter van een gegevensdienst (zie Testbeleid);

Link naar nieuw aan te maken pagina met titel Testbeleid


Begrippen

Locatie:

https://afsprakenstelsel.medmij.nl/asverplicht/mmverplicht/begrippenlijst

Oude tekst: n.v.t., nieuwe begrippen om toe te voegen

Nieuwe tekst

Begrip 

Definitie 

Domein 

Synoniemen 

Functionaliteit

Alle functies, applicaties en koppelingen, die gerelateerd zijn aan het MedMij Afsprakenstelsel.

Alle domeinen

Ketentest 

Een testvariëteit die een business proces van begin tot eind test. Daarbij worden één of meer systemen getest met testgevallen die buiten het systeem beginnen en ook weer buiten het systeem eindigen.

Alle domeinen 

Simulator

Een speciaal t.b.v. testen gemaakt onderdeel dat de werking van de DVA of de DVP of een andere systeemfunctie nabootst.

Alle domeinen

Simulatortest 

Test van applicatie tegen simulator.

Alle domeinen 

 

Testgeval

Een set van precondities, inputs, acties, verwachte resultaten en postcondities waarmee wordt onderzocht of het systeem onder gedefinieerde omstandigheden het gewenste gedrag vertoont.

Alle domeinen

Testmethodiek

Plek met informatie behorend bij het hoofdstuk Testen in het MedMij Afsprakenstelsel. Bevat o.a. het Testplan, de acceptatiecriteria en overige informatie rondom testen. 

Alle domeinen 

 Testbeleid

Testplan

Plan van aanpak als referentiekader gedurende het organiseren en de uitvoering van de tests inclusief een beschrijving van de activiteiten, de planning en testscenario’s. Het testplan bevat dus NIET een beschrijving van de tests, zoals testgevallen, zelf.

Alle domeinen

Mastertestplan, Plan van aanpak

Testscenario

Opeenvolging van testgevallen om deze op een efficiënte manier handmatig of geautomatiseerd uit te voeren.

Alle domeinen 

Testscript

De test automatiseringscode behorend bij een of meer testscenario's om tests geautomatiseerd uit te voeren.

Alle domeinen 

Testtool

Een geautomatiseerd hulpmiddel dat ondersteuning biedt aan één of meer testactiviteiten, zoals plannen, beheren, specificeren of uitvoeren.

Alle domeinen

Testvoorziening 

Verzameling van testtools om tegen te kunnen testen. 

Alle domeinen 

Validatie

Via objectief bewijs bevestigen dat de behoeften voor een specifiek gebruik zijn vervuld. ("is het juiste systeem gebouwd") Zie ook: verificatie.

Alle domeinen

Verificatie

Via objectief bewijs bevestigen dat aan de beschreven specificaties is voldaan. ("is het systeem juist gebouwd") Zie ook: validatie.

Alle domeinen

Review

Zijn de volgende acties uitgevoerd?

  • Alle rijen in de tabel zijn ingevuld
  • Er staan geen taal- en spelfouten in de aanpassingen
  • De juiste locatie is ingevoerd
  • (Indien van toepassing) de link(s) is/zijn correct toegevoegd
  • (Indien van toepassing) de vereiste afbeeldingen zijn aangepast

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.