Versie van 2 dec 2024 om 16:38

Aan deze pagina wordt momenteel gewerkt.

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

3 Touchstone

Om FHIR-implementaties van een informatiestandaard te beproeven en te kwalificeren is de Touchstone-simulatieomgeving beschikbaar. Dit is een online platform waarmee leveranciers zelf tests kunnen uitvoeren en validatieresultaten kunnen inzien. Nictiz stelt de hiervoor benodigde testscripts beschikbaar. Deze komen overeen met de functionele testscripts bij een informatiestandaard.

Algemene opmerkingen over het gebruik van de simulator:

De simulator is niet bedoeld voor loadtesten, maar voor inhoudelijke controles tegen informatiestandaarden;
Nictiz vraagt verantwoord gebruik van deze simulator, neem bij twijfel over gebruik contact op.

3.1 Account aanmaken

Leveranciers hebben een eigen bedrijfsaccount nodig voor hun organisatie op Touchstone. Er zijn verschillende abonnementsvormen beschikbaar, waaronder een gratis abonnement. Deze optie (Open) biedt die alle mogelijkheden om te kunnen testen en kwalificeren, maar kent wel limieten, onder meer het aantal tests dat per dag kan worden uitgevoerd.

Voor het aanmaken van een organisatie op Touchstone kunnen de stappen op https://touchstone.aegis.net/touchstone/userguide/html/registration-and-login/membership.html gevolgd worden.

Let op dat de "Name" van de organisatie het liefst herkenbaar moet zijn voor Nictiz en dat er niet bijvoorbeeld de naam van een onder ontwikkelaar wordt ingevuld. Dit vereenvoudigt het aanmeldproces.

Let op dat Touchstone standaard e-mailadressen en de organisatie van geregistreerde gebruikers toont. Individuele gebruikers kunnen dit in de instellingen van hun account aanpassen.

3.2 Meer informatie

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

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

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

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

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

6.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)

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

6.3 Meer informatie

7 Interoplab

Interoplab wordt ingezet tijdens de ontwikkel, PoC en Lab fase.

Na het overzicht van de gehanteerde statussen wordt ten behoeve van de testuitvoer een instructie voor het gebruik van Interoplab gegeven.
Daarna wordt per testfase het proces rondom het beoordelen van de testresultaten beschreven.

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

7.2 Testuitvoer

Navigeer naar de testscripts:

Log in in Interoplab.
Klik op 'Continue' bij Medicatieoverdracht.
Kies voor de gewenste tegel 'Test Manager POC' / 'Test Manager Lab' / 'Test Manager Ontwikkel'.
Navigeer naar Testing / Test execution.

Stel vast welk testscript je wil uitvoeren en start deze (bepaal, indien van toepassing, hierbij alvast met welke mede-leverancier je deze gaat uitvoeren en met welke rol (sturen/ontvangen/raadplegen/beschikbaar stellen)):

Klik op het groene pijltje bij het betreffende testscript (Let op: selecteer het testscript met de juiste rol).
Klik op de groene plus-knop (en voeg eventueel hier je mede-leverancier toe (selecteer deze, klik op 'Add' en 'Add selected partner(s)')).
Klik op het groene pijltje rechtsonder. Hierna is een testinstance aangemaakt.

Voer de aangemaakte testinstance (samen) uit:

Lees de Test Description goed door.
Voer de beschreven teststappen uit.
Voeg bewijsmateriaal toe waar gevraagd/van toepassing.
Controleer of de status van 'Running' naar 'To be verified' is veranderd.

Controleer ten behoeve van het beoordelen van de testresultaten tevens:

Zijn alle teststappen uitgevoerd? (Heeft elke teststap een status (Failed / To be verified / Skip test)?)
Zijn comments toegevoegd waar nodig? (Bijvoorbeeld indien de status Failed of Skip test is geselecteerd)
Is bewijsmateriaal toegevoegd?

7.3 Valideren berichten

In progress: MOTRELLO-164

7.4 Beoordelen testresultaten

De werkwijze voor het vastleggen van BITS bevindingen is beschreven onder [1]

7.4.1 Ontwikkel

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

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.

7.4.1.1 Verified (Test OK)

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

7.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):

Blokkerend: Een blokkerende bevinding moet worden opgelost om de validatie te behalen.
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).
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).
Toelichting vereist: Toelichting vereist betekend dat de bevinding nader toegelicht moet worden, waarbij deze na de toelichting alsnog blokkerend zou kunnen worden.
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.

7.4.1.3 Registreren bevindingen

Bevindingen worden geregistreerd in het BITS project van de leverancier. De werkwijze hiervoor is beschreven onder BITS ontwikkel bevindingen

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

7.4.2 PoC

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

Controleert het Testteam op volledigheid & correctheid van schematrons.
1. Indien niet volledig wordt de status aangepast naar 'Failed' en wordt de leverancier geïnformeerd via het MOPOC BITS project.
  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 schematrons wordt de status aangepast naar 'Failed' en wordt een bevinding aangemaakt in het MOPOC BITS project en toegewezen aan de betreffende leverancier.
Indien voorgaande akkoord is beoordelen Informatieanalisten de schermafdrukken. Ook hier kunnen bevindingen worden geconstateerd, waardoor de status aangepast wordt naar 'Failed' en een bevinding wordt aangemaakt in het MOPOC BITS project en toegewezen aan de betreffende leverancier.

7.4.2.1 Verified (Test OK)

Indien het Testteam en Informatieanalisten vaststellen dat alle teststappen volledig en succesvol zijn uitgevoerd, krijgt het testscript de status 'Verified'. In het BITS project van de leveranciers zal het ticket dezelfde status krijgen.

7.4.2.2 Failed (Test Niet OK)

Als het Testteam en/of de Informatieanalisten een (potentiële) bevinding constateren wordt hiervoor in het MOPOC BITS project 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):

Blokkerend: Een blokkerende bevinding moet worden opgelost om de validatie te behalen.
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).
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).
Toelichting vereist: Toelichting vereist betekend dat de bevinding nader toegelicht moet worden, waarbij deze na de toelichting alsnog blokkerend zou kunnen worden.
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.

7.4.2.3 Registreren bevindingen

Bevindingen worden geregistreerd in het MOPOC BITS project. De werkwijze hiervoor is beschreven onder BITS PoC bevindingen

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

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

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

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

9 Proves AORTA on FHIR

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

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

10.1 Ontwikkel bevindingen

Voor bevindingen geconstateerd tijdens de ontwikkelfase wordt onderstaande gehanteerd (aanvullend op de handleiding BITS validatieloket):

Maak een nieuw issue en voer onderstaande velden in:

Project: selecteer het project van de leverancier
Issuetype: Bevinding
Status: Open
Samenvatting: <Naam Interoplab testscript>: korte omschrijving van de bevinding
Beschrijving: Voer (waar mogelijk) onderstaande in:
- Reproductiepad: welke handelingen zijn uitgevoerd
- Verwacht resultaat: wat is het verwacht gedrag
- Werkelijk resultaat: wat ging er 'fout'
- Testinstance: voeg de permanent link van de uitgevoerde Interoplab testinstance toe
Uitvoerder: wijs het issue toe aan de juiste persoon, afhankelijk van of nadere (interne) analyse of herstel nodig is.
Oordeel: zie Testen Kickstart Bevindingen

Noteer na het aanmaken van het issue de code hiervan.

Zoek vervolgens in het BITS project van de leverancier het gerelateerde ontwikkel issue en open deze.

Klik op Link issue
Selecteer 'is related to'
Voer de code van de aangemaakte bevinding in.

Hierdoor is de bevinding aangemaakt en gekoppeld aan het BITS issue van het PoC testscript, waardoor deze verder geanalyseerd/hersteld kan worden.

10.2 PoC bevindingen

Voor bevindingen geconstateerd tijdens de PoC wordt onderstaande gehanteerd (aanvullend op de handleiding BITS validatieloket):