Validatie

1 Validatie

De validatie bestaat uit twee formele toetsmomenten:

1. Kwalificatie
2. Pre-livegangvalidatie

1.1 Kwalificatie

1.1.1 Entry Criteria

Leverancier

• De ontwikkelfase is succesvol afgerond.
• De Ketentest is succesvol afgerond.
• De functionele acceptatietest is succesvol afgerond.
• Heeft een volledig ingevulde en geaccordeerde ConformiteitsCheck MO (zip bestand)

Programma Medicatieoverdracht

• De kwalificatiescripts zijn beschikbaar gesteld.

1.1.2 Acties ter voorbereiding

Betrokkenen	Actie
Programma MO	Leverancier toegang geven tot de juiste validatiescripts in de Kwalificatiesimulator
Programma MO, Leveranciers	Connectietest: Controleren of instellingen zoals IP adressen en poorten correct staan geconfigureerd, zodat de kans op connectiviteitsissues tijdens de validatie wordt geminimaliseerd. Voor bespreken validatiescripts: Vaststellen dat de leverancier weet welke validatiescripts uitgevoerd moeten worden en welke informatie gelogd moet worden. Bespreken en accorderen van conformiteitscheck
Leveranciers	Compleet maken conformiteitscheck

1.1.3 Uitvoering

Met behulp van de simulatoren worden er voor de relevante transacties kwalificatiescripts uitgevoerd.

1.1.4 Afronding

De leverancier levert op basis van de uit te voeren validatiescripts de benodigde informatie aan. Hierna wordt er een moment geplant met het Validatieloket waarop de resultaten worden besproken, en waar nodig nog relevante kwalificatiescripts worden doorlopen.

De geconstateerde bevindingen worden gelogd in het BITS-project van de leverancier. In overleg met de inhoudsdeskundige wordt de zwaarte van de bevinding bepaald.

1.1.5 Exit Criteria

De leverancier heeft alle fases succesvol doorlopen en de benodigde validatie informatie aangeleverd. De validatiescripts zijn succesvol doorlopen, waarmee wordt aangetoond dat:

1. De transactie ontvangen, gewijzigd en eenduidig getoond kan worden.
2. Het product functioneel werkt, de invoervelden getoond kunnen worden en de informatie logisch op het scherm staat.
3. Er een correct, volledig en actueel medicatieoverzicht getoond kan worden op basis van uitgebreide historie uit meerdere bronnen.
4. De aanwezige bevindingen zijn niet blokkerend.

1.2 Bevindingen

De aangeleverde informatie (vooraf en tijdens het validatiemoment) worden door inhoud deskundigen van het programma beoordeeld. Hieruit kunnen bevindingen voortkomen, deze worden gelogd in het project van de leverancier.
Bevindingen zijn te classificeren in:

Type bevindingen
Bij de bevinding wordt altijd aangegeven wat het oordeel is. Er zijn vijf mogelijkheden (zoals ook vastgesteld in paragraaf 3.2 van de gebruikershandleiding BITS):

1. Blokkerend: Een blokkerende bevinding moet worden opgelost om de validatie te behalen.
2. Niet Blokkerend met aantekening: De niet blokkerende bevinding met aantekening moeten in de toekomst opgelost worden (waarbij bij afgifte van de validatie afgestemd wordt op welke termijn dat exact is).
3. Niet Blokkerend: Niet blokkerend betekend dat de bevinding niet van toepassing is op de validatie (doordat bijvoorbeeld een element ook niet binnen komt en daardoor niet getoond kan worden).
4. Toelichting vereist: Toelichting vereist betekend dat de bevinding nader toegelicht moet worden, waarbij deze na de toelichting alsnog blokkerend zou kunnen worden.
5. Advies: Advies betekend dat er een advies gegeven wordt op de gekozen oplossing vanuit het validatieloket.

1.3 Pre-livegang validatie

In de pre-livegang validatie worden de volgende onderdelen getoetst:

1. Wijzigingen als gevolg van nieuwe release van de standaard
2. Regressietest (indien van toepassing)
3. VZVZ Acceptatietest

1.3.1 Randvoorwaarden

• De leverancier heeft alle voorgaande testen succesvol afgerond
• Alle openstaande bevindingen zijn besproken
• Er zijn geen blokkerende bevindingen
• Eventuele afwijkingen ten opzichte van de specificaties zijn geaccordeerd

1.3.2 Wijzigingen als gevolg van een nieuwe release van de standaard

Doordat een leverancier per stap gekwalificeerd kan worden, is het mogelijk dat na verloop van tijd een nieuwere versie van de informatiestandaard geldt dan waartegen gekwalificeerd was. Relevante wijzigingen kunnen additionele testen rechtvaardigen. Dit wordt beoordeeld door Team Beheer MP9.

1.3.3 Regressietest

De regressietest bestaat uit het herhalen van één of meerdere van de bestaande kwalificatietesten. Doel is om te controleren dat er geen nieuwe fouten in de software zijn geïntroduceerd na de vorige kwalificatie.

1.3.4 VZVZ Acceptatietest

Door VZVZ wordt beoordeeld of de software voldoet aan de aansluiteisen van het LSP, zoals vastgelegd in het PvE. De VZVZ Acceptatietest wordt uitgevoerd op de acceptatieomgeving (XTO1) (Aanvragen testaansluiting).

Er wordt getoetst op de volgende domeinen:

• Algemene eisen
• Opleverend, Opvragend en VWI/AR
• Ontvangend, Versturend en ZORG-AB
• Abonnementenregister (betreft abonneren en notificeren)
• Abonnementenregister Sync & VWI/AR Sync

Infrastructuur & generieke voorzieningen
Deze scripts zijn gebaseerd op de Pakketten van Eisen gepubliceerd door VZVZ. Elke leverancier krijgt specifiek gegenereerde scripts op basis van het type systeem en het te toetsen onderdeel.
De complete scripts zijn gepubliceerd op de wiki: Testscripts algemene eisen MP9 & Generieke voorzieningen (zip bestand).

1.3.4.1 Testomgeving

Informatie m.b.t. IP-adressen is te vinden bij Tooling & omgevingen.

• XTO-1: Op deze omgeving wordt getest met systemen die al verregaand voldoen aan de standaard, en op deze omgeving wordt de validatie uitgevoerd. Daarnaast worden op deze omgeving eventuele ‘formele’ onderlinge testen uitgevoerd.

PGO & DVA
PGO's en DVA's valideren hun product in de Medmij testomgeving. Meer informatie over hoe hier toegang toe te krijgen is vinden bij Tooling & omgevingen.

2 PAGINAHISTORIE

Datum	Omschrijving
1 februari 2024	Gepubliceerd