mp:Testen Ontwikkelfase

Tijdens de ontwikkelfase test de leverancier haar ontwikkelde product zelfstandig tegen een simulator op twee onderdelen: inhoud en infrastructuur. Hiervoor kan gebruik gemaakt worden van het testmateriaal dat beschikbaar is gesteld door Nictiz.

1 Testdoel

Tijdens deze fase wordt aangetoond dat:

• De informatiestandaard inhoudelijk correct is geïmplementeerd.
• Wordt voldaan aan de eisen voor het LSP.

2 Voorbereiding

Om te kunnen testen tijdens de ontwikkelfase is het noodzakelijk dat is voldaan aan onderstaande entry criteria en voorbereidende acties.

2.1 Entry criteria

Leverancier

• De leverancier heeft de ontwikkeling van een deel functionaliteit afgerond en de eigen interne testen succesvol uitgevoerd
• De benodigde accounts zijn aangevraagd/aangemaakt:
  • Voor het testen van HL7v3 berichten tegen de simulator wordt gebruik gemaakt van de Kwalificatiesimulator (Account aanvragen).
  • Voor het testen van HL7 FHIR berichten tegen de simulator wordt gebruik gemaakt van Conformancelab (kwalificatie:V1.0_Handleiding_Conformancelab).

Programma Medicatieoverdracht

• De testscripts en testberichten zijn beschikbaar gesteld.

2.2 Acties ter voorbereiding

Leverancier

• Download het bestand ConformiteitsCheck MO (zip bestand) en vul deze in, zoals beschreven in de instructie.
• Plaats de laatste versie als bijlage in de BITS registratie (Conformiteitscheck - MO) met betrekking tot de voortgang en de Afronding van deze fase.

3 Uitvoering

De leverancier test de software primair op twee onderdelen:

Inhoud
De leverancier test aan de hand van testscripts in de Kwalificatiesimulator/Conformancelab of de informatiestandaard op een correcte wijze is geïmplementeerd.

Infrastructuur
Tijdens de ontwikkelfase beschikt de leverancier over de testomgeving (POC). In deze testomgeving test de leverancier haar applicatie tegen een simulator. Deze omgeving is bedoeld voor leveranciers om alleen, of met elkaar, tijdens de ontwikkeling te testen. Hiermee wordt het berichtenverkeer tijdens de implementatie van de software getest om te kijken of er voldaan wordt aan de eisen voor het LSP.

3.1 Scenario's

Inhoud
Met behulp van de simulatoren worden, voor de relevante transacties, de volgende testscripts uitgevoerd: Testscripts Medicatieproces 9.
Hiervoor zijn de Kwalificatiesimulator/Conformancelab beschikbaar om berichtinhoud te controleren door een vergelijking te maken met vooropgestelde testberichten, welke beschikbaar zijn gesteld op GitHub:

• HL7v3: https://github.com/Nictiz/HL7-mappings/tree/master/ada_2_hl7/mp/9.3.0
• FHIR: https://github.com/Nictiz/HL7-mappings/tree/master/ada_2_fhir-r4/mp/9.3.0

3.2 Testomgevingen

VZVZ
Voor de ontwikkelfase zijn onderstaande omgevingen beschikbaar. Informatie m.b.t. IP-adressen is te vinden bij Tooling & omgevingen.

• PoC+

De PoC+ omgeving kan enkel benaderd worden met authenticatie. Zodra er met authenticatie gewerkt wordt kan dat met UZI-testmiddelen. Dit is bedoeld om programma’s te ondersteunen bij het ontwikkelen van nieuwe functionaliteit en/of Zorgtoepassingen, ter voorbereiding op een nieuwe standaard.

• PoC-

De PoC- testomgeving kan zonder authenticatie benaderd worden. Dit is met name handig wanneer dit nog ontwikkeld moet worden voor de applicatie.

PGO & DVA
PGO's en DVA's testen tijdens deze fase hun product in de Medmij Zandbak testen. Meer informatie over hoe hier toegang toe te krijgen is vinden bij Tooling & omgevingen.

4 Afronding

De leverancier geeft bij het Validatieloket aan dat de testen succesvol zijn uitgevoerd en legt dit vast in de Conformiteitscheck.
De versturende kant (versturen / beschikbaar stellen) wordt getoetst aan de hand van de simulatoren, voor de ontvangende kant (ontvangen / raadplegen) en om te bepalen of er naar de volgende fase gegaan kan worden wordt een check-up moment gepland.

4.1 Exit Criteria

1. De leverancier toont middels de conformiteitscheck aan dat de in Kwalificatiesimulator/Conformancelab​ vastgelegde testscripts voor de relevante transacties succesvol zijn uitgevoerd en toont daarmee aan dat deze transacties inhoudelijk correct zijn.
2. De leverancier toont middels een testrapport aan dat de randvoorwaardelijke generieke voorzieningen succesvol zijn geïmplementeerd.
3. De leverancier voert de in Interoplab vastgelegde Consolidatie testscripts succesvol uit en toont daarmee aan dat:
4. De consolidatie afleidingsregels worden correct toegepast en een correct, volledig en actueel medicatieoverzicht en toedienlijst kan getoond worden op basis van uitgebreide historie uit meerdere bronnen.
5. De aanwezige bevindingen zijn niet blokkerend.

Indien hieraan is voldaan resulteert dit in een Go vanuit het validatieloket om door te gaan naar de Systeemintegratietest.

4.2 Bevindingen

De testresultaten worden beoordeeld door een inhoudsdeskundige van het programma. Hieruit kunnen testbevindingen voortkomen, deze 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.

Resulteert de bevinding in een wijziging dan wordt deze opgenomen in het reguliere wijzigingsproces van het programma.

Wanneer er vragen zijn gedurende het testen kunnen deze als reguliere tickets worden ingediend in het BITS-project van de leverancier.

5 PAGINAHISTORIE

Datum	Omschrijving
18 juni 2026	Exit criteria aangepast; verwijzing naar SIT
10 juni 2026	Overzicht van scenario's stap 5 set 1 en 2 en fasering daarop verwijderd. Overzicht was te gedetailleerd. Verdeling: Stap 5 - Set 1: Afhandelen voorschrift sturen/ontvangen Medicatiegegevens raadplegen/beschikbaar stellen (TA) Medicatiegegevens raadplegen/beschikbaar stellen (MVE) Stap 5 - Set 2: Voorstelgegevens Medicatiegegevens sturen/ontvangen (TA) Medicatiegegevens sturen/ontvangen (MVE)
20 december 2024	Fasering Stap 5,6 aangepast op getrapte livegang Publicatie testaanpak stappen 5,6, WDS & Hybride (voor zover bekend)
15 januari 2024	ConformiteitsCheck toegevoegd Testomgevingen VZVZ toegevoegd Randvoorwaarden en Acceptatiecriteria hernoemd naar Entry en Exit criteria
21 december 2023	Paragraaf Testomgevingen toegevoegd
12 december 2023	Structuur van pagina aangepast Resultaat opgenomen in Werkwijze Randvoorwaarden opgenomen in Voorbereiding Scenario's: Inhoud; directe verwijzing naar Testscripts MP9
1 december 2023	Acceptatiecriteria aangepast
6 juni 2023	Hoofdstuk 6 Acceptatie: gevuld Hoofdstuk 7 Testbevindingen: gevuld
4 mei 2023	Pagina gepubliceerd