Met modulair functioneel testen wordt bedoeld dat per applicatie de input en output van het relevante proces wordt beoordeeld. Zoals beschreven, is door de methodiek van VIPP Babyconnect de gegevensuitwisseling tussen de applicaties gestandaardiseerd. Hierdoor is het mogelijk om de testwerkzaamheden op te knippen en is het niet nodig om het publiceren en raadplegen van volledige datasets in alle mogelijke combinaties van applicaties te testen. Het functioneren van het netwerk wordt weldegelijk alsnog getest, maar dan met een kleine testdataset. Dit vermindert de complexiteit van testwerkzaamheden en bespaart een aanzienlijke hoeveelheid tijd en middelen.
Zorgaanbieder
|
...
Modulair functioneel testen bestaat 4 onderdelen die hierboven genummerd schematisch staan weergegeven:
Fixtures: Maken van functioneel kwalificatiemateriaal en fixtures (voor uitleg zie hieronder).
Publiceren: Kan een zorgaanbieder correct publiceren?
Raadplegen, start starten van een viewer: Kan een zorgaanbieder correct een viewer activeren? (SSO routine)
Raadplegen, de viewer zelf: Kan een zorgverlener via een viewer correct raadplegen en zijn de generieke functies correct ingevuld?
Verzamelen: Kan een PGO correct verzamelen?
...
Voor de fixtures worden gegevens van verschillende testpersonen vastgesteld. Deze testpersonen zijn volledig fictief en zijn niet gebaseerd op daadwerkelijke personen. De testpersonen hebben een volledige zwangerschap doorlopen, echter in verschillende zorgvormen volgens patient journeysuse-cases. Deze gegevens worden vastgelegd in “voorbeeld FHIR-resources” volgens de vastgestelde afspraken. Deze fixtures worden beheerd door Nictiz en staan in de testomgeving, die wordt ingericht door het landelijk programmabureau en /of Nictiz.
In de patient journeys use-cases dienen zoveel mogelijk, zoniet alle van de velden van PWD gebruikt te worden. Indien er aan een dataveld een waardelijst verbonden is, dan wordt hieruit, bij voorkeur willekeurig, een waarde geselecteerd die past binnen de patient journeyuse-case.
Publiceren
Binnen het modulair ontwerp van VIPP Babyconnect zijn er verschillende implementatievarianten van het proces publiceren mogelijk. Hierin onderscheiden we de rollen Registrator (module A in het module model), Extractor (module B0 in het module model) en Convertor (module B1 in het module model). Zorgaanbieders moeten gegevens correct kunnen publiceren, maar dat wil dus niet zeggen dat het gebruikte bronsysteem zelf FHIR-resources moet kunnen leveren. (beschikbare output mag ook geconverteerd worden). Zie het Afsprakenstelsel voor meer informatie over dit proces en deze rollen.
...
Prio1: minimale set aan gegevens die relevant is tijdens een acute situatie
Huidige afspraak (2023) voor verloskunde: kernset +
Prio2: gegevens in PDF/A, bijvoorbeeld een bevalverslag.
Het relevante deel van de Integrale zwangerschapskaart
De rest van het relevante deel van PWD 3.2
Uitgangspunten●
Deze testen vinden plaats in de
...
productieomgeving van de leverancier gekoppeld aan de testomgeving InteropLab.
...
Bij een SaaS-systeem (verloskunde, kraam) wordt per bronsysteem getest. (Niet de zorgverlener of de zorgaanbieder.) Dit testwerk gebeurt door een kartrekker-regio tijdens de eerste implementatie
...
.
...
Reden hiervoor is, dat alle gebruikers van een SaaS systeem, gebruik maken van dezelfde omgeving. Als een SaaS systeem eenmaal getest en goed bevonden is, geldt dat voor alle gebruikers van dat systeem. (SaaS = Software as a Service)
...
Bij on-premise-oplossingen (echo, ziekenhuis) wordt per bronsysteem én zorgaanbieder getest, niet de zorgverlener. Dit testwerk zal dus door alle zorgaanbieders die gebruikmaken van dit systeem moeten worden uitgevoerd.
...
Reden hiervoor is, dat
...
gebruikers van een on premise systeem, gebruik maken van
...
hetzelfde systeem bij die zorgaanbieder. Dat systeem kan echter volledig afwijken van een systeem bij een andere zorgaanbieder, terwijl het van dezelfde leverancier afkomstig is en dezelfde naam draagt.
Afwijkend hiervan zijn systemen die wel on-premise draaien, maar toch dezelfde uitvoering zijn. Voorbeeld hiervan is HIX standaard content.
Er hoeft niet gewacht te worden met testen totdat het bronsysteem het relevante deel van het volledige PWD kan publiceren. Er kan begonnen worden met het testen van bijv. Prio1, afhankelijk van het beoogde groeipad.
...
Aanpak bij publiceren FHIR
Een zorgverlener legt samen met een informatieanalist van Nictiz, een applicatiespecialist en eventueel de CMIO van VIPP Babyconnect een , vastgestelde set sets van gegevens (use-cases) vast in unieke velden van het bronsysteem.
De set van gegevens wordt vanuit het bronsysteem volgens één van de implementatievarianten gepubliceerd naar de testomgeving als FHIR-resources.
Bij variant “direct FHIR” ga naar stap 3
Bij variant “via een convertor”
Voor ADA wordt een testset aangemaakt met de ADA testtool van ZW Connect
De ADA testset wordt geconverteerd door de convertor,
Voor de test van het FHIR resultaat, gaan naar stap 3, Voor de test van de ADA output van het XIS, ga dan hieronder door
De ADA De XML output van het XIS, wordt vergeleken met de vastgestelde testset via compare functie van notepad ++ (plugin)Als compare
Hiervoor wordt een XML test tool gebruikt van ZW Connect
Als de vergelijking ok is, ga dan door naar volgende stap, Als niet ok, dan terug naar het XIS, voor reparaties uit en start de test opnieuw
De ADA XML output van het XIS wordt ook door de convertor gehaald, en verder naar stap 3
De gepubliceerde FHIR-resources worden vergeleken met de fixtures.
De FHIR resources worden zowel semantisch, als syntactisch gevalideerd.
Hiervoor InteropLab gebruikt
Er wordt gecontroleerd of logging correct heeft plaatsgevonden: is er inzichtelijk wie er wat wanneer heeft gepubliceerd?
De resultaten van de test worden gerapporteerd.
...
Een zorgverlener legt samen met een informatieanalist van Nictiz en eventueel de CMIO van VIPP Babyconnect een vastgestelde set van gegevens vast in unieke velden van het bronsysteem. (use cases)
De set van gegevens wordt vanuit de bronsysteem volgens één van de implementatievarianten gepubliceerd naar de testomgeving als PDF/A.
De inhoud van de PDF/A worden vergeleken met de patiënt journeys.
De resultaten van de test worden gerapporteerd.
Resultaten●
SaaS oplossing: bij akkoord is het bronsysteem gekwalificeerd voor het publiceren van de geteste dataset.
...
On-premise oplossing: bij akkoord is de combinatie zorgaanbieder-bronsysteem gekwalificeerd voor publiceren van de geteste dataset.
...
De resultaten van de test zijn gepubliceerd in InteropLab, en zijn inzichtelijk voor de deelnemers, de overige regio’s, het landelijk programmabureau, Nictiz en
...
ministerie VWS.
Specifiek voor het testen van publiceren is er een testomgeving: InteropLab. Dit is een testsysteem voor het uitvoeren van conformiteits- en interoperabiliteitstesten tegen gepubliceerde projectspecificaties en standaarden, zoals FHIR. Hiermee kunnen zowel de transacties als de content van de transacties gevalideerd worden.
Het is binnen InteropLab tevens mogelijk om de implementatie van generieke functies zoals lokalisatie en adressering te testen[TW2] .
. Bij de eerste implementatie wordt door alle regio’s gebruik gemaakt van HINQ. Omdat HINQ een ingebouwde techniek heeft voor lokalisatie en adressering hoeft deze niet extern getest te worden. Daarnaast zijn de normen voor de generieke functies nog niet gereed (gepland gereed 2025)
De uit te voeren testen worden uitgewerkt in testscripts en de behaalde testresultaten zijn inzichtelijk in rapportages, beide vormen het testprotocol. Het is binnen InteropLab mogelijk om verschillende gescheiden omgevingen te creëren, bijv. eigen omgevingen per regio, per leverancier, etc.
...