mp:Testen Kickstart Laboratoriumtest

Aan deze pagina wordt momenteel gewerkt.

Tijdens de laboratoriumtesten worden testscripts doorlopen door leveranciers én zorgaanbieders. Daarnaast wordt de rol van patiënt ingevuld door het patiëntpanel, gefaciliteerd door sector Patiënt & Client. Hierbij wordt niet alleen naar de technische correctheid van de uitgewisselde informatie gekeken, maar ook naar de functionele bruikbaarheid van het systeem (met name door de eindgebruiker). Daarnaast vindt de acceptatie van de in het kernteam vastgestelde bovensectorale gebruikerseisen plaats.

1 Voorbereiding

Om efficiënt te kunnen testen tijdens de Laboratoriumtest moet zijn voldaan aan onderstaande randvoorwaarden en voorbereidende acties.

1.1 Randvoorwaarden

Leverancier

• Heeft de Proof of Concept fase succesvol afgerond: er is vanuit het Programma Medicatieoverdracht een Go om door te gaan naar de Laboratoriumtest.
• Voor elk uit te voeren testscript zijn mede-leveranciers beschikbaar om de test mee uit te voeren.
  • (Voorbeeld) Voor een voorschrijven test is zowel een sturende, als een ontvangende leverancier nodig
• Voert testen niet enkel met eigen applicaties uit.
  • (Voorbeeld) Indien een leverancier zowel een EVS als een AIS heeft, wordt een testscript niet door één en dezelfde leverancier uitgevoerd.
• Heeft toegang tot de testscripts in Interoplab (Toelichting Interoplab)

Programma Medicatieoverdracht

• De testscripts zijn gereed en ingericht in Interoplab.
  • Per testscript is gedefinieerd wat de leverancier moet voorbereiden.
• Ten behoeve van de tests zijn voldoende testpatiënten (BSN's) beschikbaar.
• Organiseert de Connectathon en voorziet in locatie, uitnodigingen, agenda, etc.
  • Voldoende/geschikte resources beschikbaar gesteld vanuit de Kickstart-regio's.
  • Testonderdersteuning t.b.v. het (test)proces, gebruik van Interoplab, etc.

1.2 Acties ter voorbereiding

Betrokkenen	Actie
Programma MO	Vaststellen testkoppels (leveranciers die samen tests uitvoeren) en te testen testscripts Connectietest/voorbespreking organiseren
Programma MO, Leveranciers	Connectietest: Controleren of instellingen zoals IP adressen en poorten correct staan geconfigureerd, zodat de kans op connectiviteitsissues tijdens de testdagen zelf wordt geminimaliseerd. Voorbespreken testscripts: Vaststellen dat de leveranciers weten welke testscripts uitgevoerd gaan worden en eventuele (inhoudelijke) onduidelijkheden hierin wegnemen. Dry run use case scenario's
Leveranciers	Klaarzetten testdossiers per testscript

2 Uitvoering

De laboratoriumtest wordt uitgevoerd in de vorm van een Connectathon. Alle deelnemers zitten fysiek op een centrale locatie in het land om de tests te doorlopen. Hierdoor kan snel geschakeld worden en kunnen nodige aanpassingen gedaan worden die de doorloop bespoedigen.

2.1 Scenario's

Tijdens de laboratoriumtest wordt er gebruik gemaakt van testscripts die zijn opgesteld op basis van de use case scenario's vanuit de samenwerkingsverbanden.

GERRIT
Use case scenario's en testscripts GERRIT - Patiënt 1tm4 - stap 3-4 - beta versie 3.0

Rijnmond
Use case scenario's en testscripts Rijnmond - patiënt 1-4 - stap 3-4 - beta versie 3.0

De volledige lijst van de gebruikte testscripts is opgenomen in Interoplab.
Tijdens de laboratoriumtest zullen zorgaanbieders, met begeleiding van Kickstart Testcoördinatoren, deze Interoplab testscripts uitvoeren.

Scenario	Interoplab	Koptekst
Voorbeeld	Voorbeeld	Voorbeeld
Voorbeeld	Voorbeeld	Voorbeeld
Voorbeeld	Voorbeeld	Voorbeeld

2.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.

3 Acceptatie

3.1 Werkwijze

De zorgaanbieders voeren tijdens een centraal georganiseerde Connectathon, met ondersteuning van de betrokken leveranciers, de toegewezen Interoplab testscripts uit.
Hiermee worden de documenten 'Usecase scenario's en testen per regio' doorlopen.
De acceptanten vanuit de zorgverleners toetsen hierbij op werkbaarheid van het systeem en de bovensectorale gebruikerseisen op basis van de opgestelde acceptatiecriteria.

3.2 Acceptatiecriteria

1. De zorgaanbieder voert de in Interoplab vastgelegde Use case scenario's succesvol uit en toont daarmee aan dat is voldaan aan de bovensectorale gebruikerseisen:
   1. Besluit en gebruikerseis (VO4): de voorschrijver voert de medicatiebewaking uit, met tot dan toe/op dat moment bekende gegevens, voordat de medicatieafspraak (met of zonder verstrekkingsverzoek) verstuurd en/of benaderbaar gemaakt wordt zodat andere zorgverleners er vanuit kunnen gaan dat op de voorgeschreven medicatie medicatiebewaking is uitgevoerd.
   2. Besluit en gebruikerseis (VO11): wanneer de voorschrijver andermans medicatieafspraak stopt of wijzigt, stuurt het XIS automatisch de (technische) stop-medicatieafspraak naar het XIS van de voorschrijver van de originele medicatieafspraak zodat de zorgverlener geen handmatige handelingen hoeft uit te voeren en er geen afhankelijkheid is als een voorschrijver op dat moment niet (meer) werkzaam is op die afdeling/praktijk.
   3. Besluit (VO16): de voorschrijver die (al dan niet door verplichting in het EVS) toedientijden in de medicatieafspraak meestuurt, beschouwt deze toedientijden standaard als flexibel zodat er van afgeweken kan worden door de apotheker en patiënt tenzij er exacte toedientijden nodig zijn en hier niet van afgeweken kan worden.
2. De aanwezige bevindingen zijn niet blokkerend

4 Bevindingen

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.

5 Pagina historie

Datum	Omschrijving
21 december 2023	Paragraaf Testomgevingen toegevoegd
13 december 2023	Hoofdstuk Resultaat opgenomen in Acceptatie/Werkwijze Hoofdstuk Randvoorwaarden opgenomen in Voorbereiding
12 december 2023	Bovensectorale gebruikerseisen expliciet opgenomen in Acceptatiecriteria Hoofdstuk Scenario's aangepast
8 december 2023	Hoofdstuk Resultaat doorgehaald
6 december 2023	Acceptatie criteria en Bevindingen (1e opzet) toegevoegd
Voorbeeld	Pagina gepubliceerd