Document toolboxDocument toolbox

Testbeleid (MO-112)

>> overal toepassen: dienstverlener persoon, dienstverleners persoon, dienstverlener aanbieder, dienstverleners aanbieder <<

Om de interoperabiliteit en het vertrouwen in het stelsel te borgen, dienenmoeten deelnemers aan te 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 geëquipeerdin 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 ervoor verantwoordelijk de Systeemrollen correct te ondersteunen conformvolgens de daarbij behorende specificaties (conformzie verantwoordelijkheid 2 op de Applicatielaag). Sommige Kwalificatieloketten bieden een externe toets op de correcte implementatie van de Systeemrollen indienals een deelnemer dit wenst:

  • na een wijziging in zijn applicatie (voor Ddienstverleners Persoon of Dienstverleners Zorgaanbieder),
  • in een achterliggend bronsysteem (voor Dienstverleners Zorgaanbieder),
  • en/of in combinatie vanmet 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 actieve versie van het MedMij Afsprakenstelsel de test zal worden uitgevoerdzij de test uitvoeren (zie Change- en releasebeleid). 

Wanneer moet er getest wordenis 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 worden aangetoond 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:


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 vindt plaatsgebeurt 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 te kunnen doenuit te voeren. Aanvullende technische inspanning blijft echter nodig. Deelnemers committeren zich via hun deelname aan het afsprakenstelsel aan deze inspanningen. Informatie over kwalificatie kan worden gevonden bij de beheerder van de betreffende informatiestandaard. De beheerder van de betreffende informatiestandaard heeft informatie over de kwalificatie

De deelnemer kan zich voorbereiden op testen (A) en (B) in een de permanente testomgeving (MedMij zandbak) aangeboden door 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 behoeven 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 wordt begrepen alsis 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 van de wijzenmogelijkheid waarop niet-naleving geconstateerd wordt.

Deelnemers zijn zelf verantwoordelijk voor het laten inplannen van de testen voor het herbevestigen van de geldigheid van hun implementatie, voordat de geldigheid van bestaande testresultaten verloopt. Daarbij stelt 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.

Her-acceptatie 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 her-heracceptatietest als het ware is te beschouwen als een ‘apk’ voor MedMij-deelnemers 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 Aafsprakenstelsel.)

In overleg tussen de 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 her-heracceptatietesten zijn testen is losgekoppeld van toetreding en van de uitrol van releases van het Afsprakenstelsel, kunnen deelnemerzelf hun ontwikkeltempo en moment van uitrol van een koppelvlakversie 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.