Tooling & omgevingen Kickstart Medicatieoverdracht

1 Algemeen

Nictiz en VZVZ werken in het validatieproces nauw samen. Daar waar de kwalificatiesimulator (van Nictiz) wordt gebruikt om de interoperabiliteit van de inhoud van berichten te testen, ondersteunt en toetst VZVZ de interoperabiliteit van de infrastructuur tussen systemen. Hierbij wordt getoetst of de systemen voldoen aan alle kwaliteitseisen, maar ook of systemen in staat zijn om berichten van andere leveranciers te verwerken én te begrijpen. Onderstaande software, applicaties en ‘omgevingen’ kunnen worden ingezet gedurende het proces.

2 Kwalificatiesimulator

HL7v3 XIS-simulatie applicatie en validatieomgeving (24x7 beschikbaar).

Deze tool wordt gebruikt om een applicatie (in beperkte mate) te simuleren. Het is mogelijk om berichten naar het systeem te versturen en respons te ontvangen. Het is mogelijk voor de leverancier om in te loggen op de omgeving en zelf berichten te versturen naar de eigen applicatie. Validatie is mogelijk tegen de informatiestandaard, met aanvullende validatie per testscenario.

De simulator biedt tijdens de ontwikkeling de mogelijkheid om vooraf gedefinieerde inhoud terug te geven (zoals beschreven in de scripts). Hiermee kan de leverancier kijken of hij de data goed ontvangt en toont. Merk op dat hier vaak vaste inhoud teruggestuurd wordt en dat de simulator geen interne logica heeft voor bijvoorbeeld verwijsindex en query filters.

Ook kan de simulator het systeem bevragen in geval dat het systeem een bronsysteem is. Daarbij is het mogelijk om de patiënt, auteur en query parameters aan te passen. Op het moment dat de patiënt niet aanwezig is in de lijst, kan de BSN ook handmatig worden ingevuld. De simulator heeft voor de vaste huisarts ook de mogelijkheid om een waarneembericht naar het bronsysteem te sturen, zo kan de leverancier controleren of hij het waarneembericht kan ontvangen en verwerken.

De kwalificatiesimulator verzamelt berichten die van en naar een leverancier worden gecommuniceerd in een berichtenlog. Het is voor de leverancier mogelijk om zelf de berichtenlog in te zien, inclusief validatieresultaten.

Algemene opmerkingen over het gebruik van de kwalificatiesimulator:

• de kwalificatiesimulator is niet bedoeld voor loadtesten, maar voor inhoudelijke controles tegen informatiestandaarden;
• Nictiz vereist verantwoord gebruik van deze kwalificatiesimulator, neem bij twijfel over gebruik contact op.
• Alleen bereikbaar op besloten netwerk zorgnet: http(s)://nictiz.ks1.lsp.aorta-zorg.nl

2.1 Account aanvragen

Om gebruik te kunnen maken van de kwalificatiesimulator is een kwalificatieaccount nodig. Dit account kan aangevraagd worden bij het kwalificatieteam (kwalificatie@nictiz.nl).

Voor het configureren van kwalificatieaccount(s) zijn de volgende gegevens per systeem nodig:

• De zorgtoepassingrol(len)
• De naam van de applicatie
• Het versienummer van de applicatie
• Te gebruiken applicatieID (mag fictief zijn)
• Naam van het systeem (Om meerdere testsystemen te onderschedien die aan een kwalificatieaccount zijn gekoppeld)
• URL (of IP/map)
  • Bijvoorbeeld zonder certificaten: http://systeem1.zorgverlener.com/map/
  • Of met certificaten: https://systeem1.zorgverlener.com/map/
• Maakt het systeem gebruik van HTTPS?
  • Alleen van toepassing voor verkeer van de simulator naar het systeem bij de leverancier.
• Keuze kwalificatiesimulator:
  • Bereikbaar via publiek internet: http(s)://kwalificatie.nictiz.nl
  • Alleen bereikbaar op besloten netwerk zorgnet: http(s)://nictiz.ks1.lsp.aorta-zorg.nl
• Personen die toegang tot het account moeten hebben.
  • Geef daarbij graag aan: naam, organisatie, email-adres.

2.2 Meer informatie

• Uitleg over gebruik kwalificatiesimulator
  
• Inloggen op de simulator
  

3 Testomgevingen VZVZ

Het LSP kent drie belangrijke testomgevingen, die allemaal 24x7 beschikbaar zijn:

Testomgeving	Toelichting
Proof of Concept (PoC)	Hier kunnen standaarden in ontwikkeling onderling uitgetest worden. Meerdere leveranciers kunnen zo met elkaar testen, zonder dat ze expliciet hoeven te voldoen aan de standaarden.
PTO	Deze omgeving is bedoeld voor leveranciers om alleen, of met elkaar, door te ontwikkelen en voorafgaande aan een kwalificatie/acceptatie te testen.
XTO	Op deze omgeving wordt getest met systemen die al verregaand voldoen aan de standaard, en op deze omgeving wordt de acceptatie uitgevoerd. Daarnaast worden op deze omgeving eventuele ‘formele’ onderlinge testen uitgevoerd.

3.1 Aanvragen testaansluiting

Voor het doorlopen van de acceptatietest en om aan te sluiten op de testomgevingen moet een aanvraagformulier ingevuld worden. Met de testaansluiting maakt u gebruik van het VZVZ-testnetwerk en de simulatoren. Deze zijn exact hetzelfde ingericht als de productie-omgeving. In de testomgeving kunt u het berichtenverkeer testen tijdens de implementatie in uw software.

Dit formulier en verdere uitleg is te vinden op de website van VZVZ: Aanvraag testomgeving LSP.

3.2 IP-adressen

Omgeving	DNS	IP adres	IP Zorgnet	Aandachtspunt
PoC-	http://zim.poc.lsp.aorta-zorg.nl/kwa13/zimapp/LSP.BS.SoapService.CLS?Url=	13.93.71.170	172.24.3.6
PoC+	https://zim.poc.lsp.aorta-zorg.nl	13.93.71.170	172.24.3.6	Met authenticatie
PTO-2	https://zim.pto2.lsp.aorta-zorg.nl	13.94.227.135	172.24.3.4	Permanente testomgeving: ontwikkelen & testen
XTO-1	https://zim.xto1.lsp.aorta-zorg.nl/	13.93.71.167	172.24.3.5	Acceptatie omgeving
XSG	Uitgaand verkeer	13.94.227.135	172.24.3.4

4 Parasoft

Parasoft is een XIS-simulatie applicatie. Deze tool wordt gebruikt om een applicatie te simuleren (bijvoorbeeld een apotheek systeem, of een huisarts systeem). Hierbij is het mogelijk om specifieke voorbeeld berichten (van een leverancier) te gebruiken, zodat er ‘offline’ tussen leveranciers kan worden getest, maar het is bijvoorbeeld ook mogelijk om een recept naar dit systeem (in de rol van apotheeksysteem) te sturen, en vervolgens ‘gegenereerde’ verstrekkingen op te vragen. Dit is de software dat gekoppeld is aan de testomgevingen waar tijdens het testen gebruik van wordt gemaakt.

4.1 Aanvragen Sturen bericht

Voor het sturen van berichten vanuit Parasoft wordt onderstaande procedure gehanteerd:

• Leverancier stuurt een email naar motestteam@vzvz.nl met het verzoek om een bericht, zoals beschreven in het testscript, te versturen naar hun testapplicatie.
• De dagbeheerder zorgt ervoor dat deze actie wordt uitgevoerd.
• Het testteam informeert de leverancier via een email-reactie dat het bericht is verstuurd.

5 ZORG-AB

ZORG-AB is een gemeenschappelijk adresboek dat alle dienstverleners in de zorg kunnen gebruiken om (technische) gegevens met elkaar uit te wisselen. ZORG-AB is beschikbaar binnen de zorginfrastructuur van het Landelijk Schakelpunt, maar ZORG-AB kan ook gebruikt worden voor andere vormen van (infrastructuren voor) zorgcommunicatie.

ZORG-AB bevat naast noodzakelijke contactinformatie, ook allerlei technische informatie om computers en applicaties met elkaar te kunnen verbinden. Zo zorgt ZORG-AB ervoor dat:

• Alle benodigde informatie om elektronische communicatie mogelijk te maken op één plek staat;
• Zorgpartijen snel en accuraat met elkaar kunnen communiceren;
• Alle zorgpartijen ZORG-AB kunnen gebruiken, ongeacht de infrastructuur die voor de uitwisseling van medische gegevens wordt gebruikt.

5.1 Implementeren van ZORG-AB

Wilt u als XIS-leverancier ZORG-AB implementeren, dan vult u een aansluitformulier in om toegang te krijgen tot de testomgeving. Daarna kunt u aan de slag.

Het aansluitformulier en het aansluit- en acceptatieproces zijn te vinden op de website van VZVZ: ZORG-AB implementeren (leveranciers)

5.2 IP-adressen

Omgeving	DNS	IP adres	IP Zorgnet
ZORG-AB 1A (Zorgnet)	https://zab.test.lsp.aorta-zorg.nl/zab		172.24.3.36
ZAB Endpoint 1B (Zorgnet)	https://zab.test.lsp.aorta-zorg.nl/zab/fhir		172.24.3.36
ZAB Endpoint 1C(Internet)	https://zab.test.aorta-zorg.nl/zab-ro	52.166.167.190
ZAB Endpoint 1D (Internet)	https://zab.test.aorta-zorg.nl/zab-ro/fhir	52.166.167.190

5.3 Meer informatie

• ZORG-AB implementeren (leveranciers)
• Algemene pagina ZORG-AB
• ZORG-AB testapplicatie

6 Interoplab

Interoplab wordt ingezet tijdens de ketentesten, PoC en de Lab fase:

6.1 Statussen

In Interoplab worden onderstaande statussen toegepast.

Status	Omschrijving
Running	Testuitvoer vindt plaats. Behoudt deze status tot de test volledig is afgerond (tenzij je besluit de test te annuleren (zie Aborted)).
To be verified	Nadat alle teststappen, al dan niet succesvol, zijn afgerond worden de testresultaten beoordeeld.
Verified	Alle teststappen zijn volledig en succesvol uitgevoerd.
Failed	Bij het beoordelen van de testresultaten zijn bevindingen geconstateerd.
Partially verified	Wordt niet gebruikt!
Aborted	De uitvoer van het testscript is geannuleerd.

6.2 Testuitvoer

Volgt

6.3 Valideren berichten

Stap 1: Start de validatie
• Zoek in de Proxy het juiste bericht op en valideer deze (extra stappen volgen).

Stap 2: Corrigeer en valideer (indien nodig)
• Als het bericht fouten bevat, kun je deze corrigeren. Kopieer het bericht en plak het in een teksteditor om wijzigingen door te voeren.
• Open de validator en plak het gecorrigeerde of correcte bericht in het validatieveld.
• Start de validatie vanuit de validator. Wacht totdat het resultaat beschikbaar is.

Stap 3: Deel de validatielink
• Nadat de validator klaar is, klik je rechtsboven op ‘Share result’.
• Kopieer de permanente link via het kopieerknopje naast de 'Share result' knop.
• Ga terug naar de Test Instance, klik linksboven op het wereldbolplus-icoontje (🌐+) en plak de URL in het veld.
• Voeg eventueel een korte opmerking toe bij de validatie via het + icoontje.

Stap 4: Problemen melden
Mocht je tijdens de validatie tegen problemen aanlopen:
• Registreer een BITS-ticket.
• Vermeld in het ticket een duidelijke beschrijving van het probleem en verwijs naar de link van de relevante Interoplab Test Instance.

6.4 Beoordelen testresultaten

De werkwijze voor het vastleggen van BITS bevindingen is beschreven onder 10 BITS

6.4.1 Ontwikkel

Zodra een testscript de status 'To be verified' heeft:

1. Controleert het Testteam op volledigheid & correctheid van schermafdrukken.
   1. Indien niet volledig wordt de status aangepast naar 'Failed' en wordt de leverancier geïnformeerd via het BITS project van de leverancier.
      1. De leverancier heeft alsnog de mogelijkheid om het testscript aan te vullen. Hierna wijzigt de leverancier de status naar 'To be verified'. De leverancier informeert het testteam over deze statuswijziging via het aangemaakte BITS ticket.
   2. Bij incorrectheid op basis van schermafdrukken wordt de status aangepast naar 'Failed' en wordt een bevinding aangemaakt in het BITS project van de leverancier en toegewezen aan de leverancier.

Let op: dit betreft een ontwikkeltest. Indien de leverancier zelf constateert dat de testuitvoer niet succesvol is, kan deze besluiten de status te wijzigen naar ‘Aborted’ in plaats van ‘To be verified’.

• Hierdoor wordt deze Interoplab testinstance niet afgerond en dus ook niet beoordeeld door het testteam.
• Na herstel van de bevinding start de leverancier een nieuwe Interoplab testinstance, zodat de testuitvoer nogmaals vastgelegd kan worden.

6.4.1.1 Verified (Test OK)

Indien het Testteam vaststelt dat alle teststappen volledig en succesvol zijn uitgevoerd, krijgt het testscript de status 'Verified'.

6.4.1.2 Failed (Test Niet OK)

Als het Testteam een (potentiële) bevinding constateert wordt hiervoor in het BITS project van de leverancier een bevinding aangemaakt. Hierin wordt verwezen naar de Interoplab testinstance. Na een eventuele analyse wordt deze in BITS toegewezen aan de betreffende leverancier. Het Interoplab testscript krijgt de status 'Failed'.

• Na herstel van de bevinding zal hertest plaats vinden vanuit een nieuwe testinstance.
• Indien er sprake is van een onterechte bevinding wordt deze gesloten in BITS (met toelichting) en krijgt het testscript alsnog de status 'Verified'.

Voor bevindingen worden onderstaande categorieën gehanteerd, welke worden bepaald door Informatieanalisten (eventueel tijdens het wekelijks intern bevindingenoverleg).

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.

De oplostijd van blokkerende bevindingen wordt altijd besproken met de leverancier.

6.4.1.3 Registreren bevindingen

Volgt

Let op: er zullen zich situaties voor doen waarbij bovenstaande afspraken niet volstaan. Deze zullen worden besproken tijdens het wekelijks intern bevindingenoverleg.

6.4.2 PoC

Volgt

7 Medmij Zandbak

In de MedMij Zandbak kunnen PGO's en DVA's de ontwikkeling van hun product testen. Meer specifiek, de interoperabiliteit tussen de verschillende componenten (DVP en DVA). Alle MedMij-deelnemers mogen deze testomgeving gebruiken. Daarnaast kunnen deelnemers onderling tests organiseren en gegevens uitwisselen en nieuw ontwikkelde functionaliteiten uitproberen. In de MedMij Zandbak is het niet mogelijk aan te sluiten met productieomgevingen, of productiedata uit te wisselen.

7.1 Toegang tot MedMij Zandbak

Om je toegang te kunnen geven tot de MedMij Zandbak zijn een aantal technische gegevens nodig. Onderstaand staat de informatie die nodig is voor een DVP of DVA. De informatie kan gestuurd worden naar: acceptatie@medmij.nl

DVP

• Naam van de DVP en deelnemer-ID
• Host name van de pgo-nodes voor front channel verkeer (dit is de URL waar de server te vinden is, bijvoorbeeld: pgo.iets.nl)
• Oauth Cliënt organisatienaam - Gegevensdienst(en) met gegevensdienstID waaronder de deelnemer wil testen.

DVA

• Naam van de DVZA
• Gewenste gegevensdiensten

Een DVA zal, naast eigen gegevens, ook gegevens van een of meer fictieve zorgaanbieder(s) en de te ontsluiten zorgaanbiedersgegevensdiensten moeten aanleveren.

Let op: ook de opgegeven zorgaanbiedersgegevensdienstnodes dienen testnodes te zijn.

7.2 Wat mag niet in de MedMij Zandbak

• Aansluiten met je productieomgeving. Hierop controleren en handhaven we actief.
• Tot patiënt herleidbare gegevens gebruiken. Hierbij is bestaande wet- en regelgeving met betrekking tot het hanteren van patiënt- en persoonsgegevens altijd leidend.

Bovendien gelden de eisen uit het MedMij Afsprakenstelsel ook voor de testomgeving. Niet voldoen aan bovenstaande regels kan gevolgen hebben voor je label.

8 Proves AORTA on FHIR

De omgeving die gebruikt wordt voor het testen met FHIR: volgt

9 BITS

BITS (Beheer Informatie- en Terminologie Standaarden) is inrichting van het product JIRA van Atlassian, ingericht door Nictiz. Via deze web-based applicatie is het mogelijk om issues te melden, bevindingen vast te leggen en wijzigingsverzoeken te doen. Elke leverancier heeft een persoonlijk project waarin zij vragen kunnen stellen gedurende het gehele validatieproces. Ook wordt tijdens de Kickstart de voortgang gemonitord aan de hand van dit project.

9.1 Ontwikkel bevindingen

Volgt

9.2 PoC bevindingen

Volgt

9.3 Meer informatie

• Link naar BITS algemeen
• Link naar openstaande issues Medicatieproces in BITS
• Handleiding BITS validatieloket

10 Pagina historie

Datum	Omschrijving
28 januari 2025	Toegevoegd: Aanvragen Sturen bericht
12 december 2024	Toegevoegd Interoplab: Statussen Beoordelen testresultaten: Ontwikkel
2 februari 2024	Pagina geüpdatet
4 mei 2023	Pagina gepubliceerd