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.
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 use-case uit de Architectuur en technische specificaties ondersteund dienen te worden. Ook geeft de Catalogus aan welke andere Gegevensdiensten worden vereist. Indien een Deelnemer nog niet over een erkenning voor een vereiste Gegevensdienst beschikt, dan dient deze partij eerst deze erkenning te behalen. Stichting MedMij ziet erop toe dat aan alle voorwaarden wordt voldaan, alvorens erkenningen wordt afgegeven.
| Info | ||
|---|---|---|
| ||
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:
|
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:
- De Deelnemer wil erkend worden als ontsluiter van een Gegevensdienst;
- Hertest op initiatief van de Deelnemer, omdat de geldigheidsduur van diens testresultaten dreigt te verlopen.
- Twijfel over de naleving van de afspraken;
- 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:
...
Usecase(s) behorende
bij de Gegevensdienst
...
Dienstverlener
persoon
...
Dienstverlener
aanbieder
...
Verzamelen
Opvragen Aanbiederslijst
Opvragen Gegevensdienstnamenlijst
...
Verzamelen
Opvragen OAuth Client List
Opvragen Gegevensdienstnamenlijst
...
Delen
Opvragen Aanbiederslijst
Opvragen Gegevensdienstnamenlijst
...
Delen
Opvragen OAuth Client List
Opvragen Gegevensdienstnamenlijst
...
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 /wiki/spaces/MMCatalogus/overview 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.
| Info | ||
|---|---|---|
| ||
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
...
| Note |
|---|
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.