Met modulair functioneel testen wordt bedoeld, dat per applicatie module de input en output van het relevante proces wordt beoordeeld.
...
Zoals beschreven, is door de methodiek van VIPP Babyconnect Interoperabiliteit Geboortezorg, 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.
Rekenvoorbeeld:
Stel, er zijn 5 bronsystemen, 5 PGO’s, en 5 viewers. En ieder bronsysteem communiceert op een eigen manier met de PGO’s en viewers.
Dan zijn de mogelijke combinaties 5 x 5 x 5 = 125, waarbij de oorzaak van een fout in verschillende onderliggende delen gezocht moet worden
Stel dat er een “eenheid van taal” is waar elke module mee werkt. Dus, een bron systeem levert “eenheid van taal”, een PGO en een viewer, gebruiken de “eenheid van taal”
...
Als elk module per stuk getest wordt, dan zijn er 5 + 5 + 5 = 15 testen nodig, een fout is dan direct toe te wijzen aan de betreffende module. Als blijkt dat elke module voldoet moet er wel overzicht testen gedaan worden, maar dat is alleen ter acceptatie.
Het functioneren van het netwerk wordt weldegelijk geheel moet wel degelijk alsnog getest, maar dan met een kleine testdataset. Dit vermindert de complexiteit van testwerkzaamheden en bespaart een aanzienlijke hoeveelheid tijd en middelen.
Modulair functioneel testen bestaat 4 onderdelen die hierboven genummerd schematisch staan weergegeven:
Fixtures: Maken van functioneel kwalificatiemateriaal en fixtures (voor uitleg zie hieronder).
Kwalificatiemateriaal is de naam die Nictiz heeft gegeven aan al het testmateriaal wat nodig is voor het kwalificeren van een
Publiceren: Kan een zorgaanbieder correct publiceren (beschikbaar stellen)?
Raadplegen, 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 gegevens verzamelen?
Het woord verzamelen is door medMij gegeven aan de functie voor het ophalen van gegevens bij zorgaanbieders. De burger kan in het eigen PGO beschikbare gegevens verzamelen.
...
Fixtures
Dit zijn FHIR-resources die door de CMIO van VIPP Babyconnect, en specialisten van Nictiz zijn gemaakt en waarvan met zekerheid is vastgesteld dat ze conform de specificaties van de informatiestandaard Geboortezorg zijn. Het maken van deze fixtures moet als eerste stap gebeuren voordat er getest kan gaan worden (#0 in het schema hierboven). Deze resources worden vervolgens telkens bij elke module als vergelijkingsmateriaal ingezet.
Bij het testen van het publiceren/beschikbaar stellen wordt de output vergeleken met de fixtures. Bij het testen van het verzamelen bij de PGO’s worden de fixtues als bron gebruikt. En bij het testen van het raadplegen met de viewer, worden de fixtures als bron gebruikt.
| Info |
|---|
Wat is FHIR? (spreek uit als fire) FHIR = Fast Healthcare Interoperability Resources De Fast Healthcare Interoperability Resources-standaard is een reeks regels en specificaties voor het uitwisselen van elektronische gezondheidszorggegevens. Het is ontworpen om flexibel en aanpasbaar te zijn, zodat het kan worden gebruikt in een breed scala aan omgevingen en met verschillende zorginformatiesystemen. Wikipedia (Engels) https://nictiz.nl/standaarden/overzicht-van-standaarden/hl7-fhir/ |
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 use-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 Nictiz.
| Info |
|---|
Wat is een testomgeving? Een testomgeving is een beschermde groep van toepassingen en applicaties waarmee veilig testen kunnen worden uitgevoerd. Testen worden niet uitgevoerd in de live omgevingen van zorgaanbieders. Een testomgeving is zoveel mogelijk gelijk aan een live omgeving. |
In de 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 use-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, dat wil 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.
Bronsystemen kunnen incrementeel ontsloten worden aan de hand van een groeipad. Bijvoorbeeld:
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, vastgestelde 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”
De XML output van het XIS, wordt vergeleken met de vastgestelde testset
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 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.
Om dit geheel te monitoren wordt het gereedschap InteropLab toegepast. Binnen InteropLab worden de testen uitgevoerd en de resultaten gerapporteerd.
Aanpak bij publiceren PDF/A
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. 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.
Raadplegen, functie start viewer (SSO)
Vanuit het bronsysteem moet een zorgverlener een viewer kunnen activeren via een SSO-koppeling. In de SSO-koppeling worden de identificerende attributen van de zorgverlener/zorgaanbieder verwerkt. Zie het Afsprakenstelsel voor meer informatie over dit proces en deze rollen.
Bij het proces raadplegen SSO moet het aanleveren van vereiste credentials worden getest:
● Identificatie: de identiteit van de zorgverlener, de identiteit van de zorgaanbieder
○ Authenticatie: de authenticatie wordt uitgevoerd vanuit de viewer
○ Autorisatie: de autorisatie wordt opgevraagd vanuit de viewer na authenticatie,
○ Lokalisatie: De lokalisatie wordt geactiveerd vanuit de viewer,
○ Adressering: de adressering wordt opgevraagd vanuit de viewer op basis van de lokalisatie,
○ Toestemming: toestemming van de cliënt voor het raadplegen van gegevens wordt opgevraagd vanuit de viewer, na authenticatie en na lokalisatie.
Uitgangspunten
● Deze testen vinden plaats in de productieomgeving van de leverancier van het XIS gekoppeld aan de genoemde testomgeving.
● Bij een SaaS-systeem (verloskunde, kraam) wordt per bronsysteem en viewer getest en niet de zorgverlener of de zorgaanbieder. Dit testwerk gebeurt door de kartrekker-regio tijdens de eerste implementatie.
● Bij on-premise-oplossingen (echo, ziekenhuis) wordt per bronsysteem én viewer én zorgaanbieder getest, niet de zorgverlener. Dit testwerk zal dus door alle zorgaanbieders die gebruikmaken van deze combinatie moeten worden uitgevoerd.
● de viewer hoeft hier niet getest te worden, die heeft een eigen test
Aanpak
Een zorgverlener legt een testpersoon vast in het eigen systeem (alleen identificerende gegevens) t.b.v. de SSO-koppeling.
De zorgaanbieder wordt toegevoegd aan het individueel zorgnetwerk van de testzwangere.
De zorgverlener activeert de viewer De credentials worden beoordeeld
De resultaten van de testen worden gerapporteerd in InteropLab
Resultaten
● SaaS oplossing: bij akkoord is de combinatie bronsysteem-SSO gekwalificeerd voor het activeren van een viewer.
● On-premise oplossing bij akkoord is de combinatie bronsysteem-SSO gekwalificeerd voor het activeren van een viewer.
● De resultaten van de test zijn inzichtelijk voor de deelnemers, de overige regio’s, het landelijk programmabureau en Nictiz.
Raadplegen, functie de viewer zelf
...
Bij het proces raadplegen moet ook een deel van de voor digitale gegevensuitwisseling benodigde generieke functies worden getest:
● Identificatie: ontvangen van de credentials van identiteit van zorgverlener en van de identiteit zorgaanbieder,
● Authenticatie: UZI register openen en vaststellen of de zorgverlener daadwerkelijk is wie hij/zij beweert te zijn,
● Autorisatie: Vanuit UZI register rol opvragen en register rol/zib matrix openen. toekennen van rechten aan zorgverlener om gegevens in te zien,
● Lokalisatie: eigen FHIR server bevragen over care team. bij welke zorgaanbieders bevinden zich welke gegevens van de cliënt,
● Adressering: Zorg-AB openen op basis van zorgaanbieders in care team. opvragen van het digitale adres van de zorgaanbieder,
● Toestemming: Eigen FHIR server bevragen over consent. toestemming van de cliënt voor het raadplegen van gegevens.
Uitgangspunten
● Deze testen vinden plaats in de productieomgeving van de leverancier van de viewer gekoppeld aan de genoemde testomgeving.
● Bij een SaaS-systeem (verloskunde, kraam) wordt per bronsysteem en viewer getest en niet de zorgverlener of de zorgaanbieder. Dit testwerk gebeurt door de kartrekker-regio tijdens de eerste implementatie.
● Bij on-premise-oplossingen (echo, ziekenhuis) wordt per bronsysteem én viewer én zorgaanbieder getest, niet de zorgverlener. Dit testwerk zal dus door alle zorgaanbieders die gebruikmaken van deze combinatie moeten worden uitgevoerd.
● Er hoeft niet gewacht te worden met testen totdat de viewer het volledige PWD kan raadplegen. Er kan begonnen worden met het testen van bijv. de integrale zwangerschapskaart, afhankelijk van het beoogde groeipad.
● De generieke functies identificatie, authenticatie en autorisatie in het bronsysteem (dossiertoegang) behoren zorgaanbieders nu sowieso al op orde te hebben, dus deze vallen buiten de scope van dit testprotocol.
● De generieke functies autorisatie (raadpleegbare informatie), lokalisatie, adressering en toestemming zijn wel onderdeel van het testprotocol en worden getest in InteropLab.
● Wanneer het medisch autorisatieprotocol beschikbaar komt, wordt dit opgenomen in dit testprotocol.
Aanpak
Een zorgverlener legt een testpersoon vast in het eigen systeem (alleen identificerende gegevens) t.b.v. de SSO-koppeling.
De zorgaanbieder wordt toegevoegd aan het individueel zorgnetwerk van de testzwangere.
De zorgverlener activeert de viewer en raadpleegt de relevante fixtures.
Samen met een informatieanalist van Nictiz worden de in de viewer getoonde gegevens vergeleken met de verwachte gegevens op basis van de fixtures en patiënt journeys.
De zorgaanbieder wordt verwijderd uit het individueel zorgnetwerk van de testzwangere.
De zorgverlener activeert de viewer en probeert de relevante fixtures opnieuw te raadplegen.
Er wordt gecontroleerd of logging correct heeft plaatsgevonden: is er inzichtelijk wie er wat wanneer heeft geraadpleegd?
De resultaten van de testen worden gerapporteerd.
Resultaten
● bij akkoord is de viewer gekwalificeerd voor het raadplegen van de geteste dataset.
● De resultaten van de test zijn inzichtelijk voor de deelnemers, de overige regio’s, het landelijk programmabureau en Nictiz.
Verzamelen
Het proces verzamelen, waarbij cliënten hun gegevens in een PGO (module E in het schema hierboven) ophalen, staat beschreven in het MedMij Afsprakenstelsel.
Uitgangspunten
● Deze testen vinden plaats in de productieomgeving van de leverancier gekoppeld aan de genoemde testomgeving.
● Er wordt per PGO en DVZA getest en niet de zorgverlener of de zorgaanbieder. Dit testwerk gebeurt door de kartrekker-regio tijdens de eerste implementatie.
● De dataset is de Integrale zwangerschapskaart zoals beschreven in de Informatiestandaard Geboortezorg (IZK in het schema op pagina 9)
Aanpak
De leverancier activeert een PGO voor een testzwangere.
De informatieanalist haalt de relevante fixtures met de gegevensdienst Verzamelen integrale zwangerschapskaart via de DVZA op bij (een) fictieve zorgaanbieder(s) in de testomgeving.
De informatieanalist vergelijkt de in de PGO getoonde gegevens met de verwachte gegevens op basis van de fixtures en patiënt journeys.
De resultaten van de test worden gerapporteerd.
Resultaten
● Bij akkoord zijn de PGO en DVZA gekwalificeerd voor de gegevensdienst Verzamelen integrale zwangerschapskaart.
● De resultaten van de test zijn inzichtelijk voor de deelnemers, de overige regio’s, het landelijk programmabureau, MedMij en Nictiz.
Delen
...
| Info |
|---|
Wat is PWD? PWD = Perinataal Woordenboek en Dataset De informatiestandaard Geboortezorg noemen we ook wel PWD: het Perinataal Woordenboek en Dataset. Deze zorgt voor eenduidige informatievoorziening tussen zorgverleners en onderzoekers die betrokken zijn bij verloskundige, gynaecologische, kindergeneeskundige & kraamzorg voor de zwangere en het (ongeboren) kind. https://nictiz.nl/standaarden/informatiestandaarden/geboortezorg/ |