mp:Draft Testen Kickstart Testaanpak PGO: verschil tussen versies
(→Teststrategie) |
|||
Regel 45: | Regel 45: | ||
<FONT color=orange>dit is in feite entry criterium & uitgangssituatie: moet succesvol uitgevoerd zijn. Ander linkje per fase</FONT> | <FONT color=orange>dit is in feite entry criterium & uitgangssituatie: moet succesvol uitgevoerd zijn. Ander linkje per fase</FONT> | ||
==Entry Criteria== | ==Entry Criteria== | ||
+ | |||
+ | =Testbasis= | ||
+ | |||
+ | * [https://informatiestandaarden.nictiz.nl/wiki/mp:Testen_Kickstart Kickstart] | ||
+ | * [https://www.vzvz.nl/diensten/gemeenschappelijke-diensten/lsp LSP+] | ||
+ | * [https://informatiestandaarden.nictiz.nl/wiki/mp%3ADraft_Testen_Kickstart_Ontwikkelfase Kickstart - Ontwikkelfase] | ||
+ | * [https://informatiestandaarden.nictiz.nl/wiki/mp:Testen_Kickstart_Proof_of_Concept_(PoC) Kickstart - PoC] | ||
=Teststrategie= | =Teststrategie= |
Versie van 4 mrt 2025 om 14:56
Inhoud
[verbergen]Inleiding
Dit detail testplan biedt een overzicht van alle testactiviteiten vanuit de Kickstart Medicatieoverdracht ten behoeve van het testen van stap 5/6 voor de PGO's. Het testplan is opgesteld omdat het testen van Persoonlijke Gezondheidsomgevingen (PGO’s) een andere aanpak vereist dan het testen van informatiesystemen van zorgaanbieders. PGO’s zijn gericht op directe interactie met de patiënt en halen gegevens op via MedMij. Hierdoor ligt de focus op de correcte uitwisseling van gegevens volgens gestandaardiseerde FHIR-profielen en de begrijpelijke weergave van deze gegevens in de PGO. Het doel van dit testplan is om ervoor te zorgen dat de gegevensuitwisseling en presentatie in PGO’s foutloos, volledig en gebruiksvriendelijk is.
Testdoel
Tijdens deze fase wordt aangetoond dat:
- Medicatiegegevens worden succesvol uitgewisseld tussen zorgaanbieder-systemen en PGO’s via de DVA.
- Geraadpleegde gegevens correct worden verwerkt en getoond.
- PGO’s moeten in staat zijn om medicatiegegevens accuraat op te vragen in verschillende volgorden (bijvoorbeeld 1/2/3 of 2/3/1) tussen zorgaanbieders, zonder verwijzing naar eerdere bouwstenen.
Scope
Binnen scope
nog een beetje te 'fuzzy' -> aangepast
De uitwisseling van medicatiegegevens van zorginformatiesystemen naar PGO’s
De uitwisseling tussen zorginformatiesystemen (zoals AIS, ZIS en EVS) en PGO’s verloopt via de MedMij-afspraken. Dit betekent dat PGO’s medicatiegegevens moeten kunnen ophalen via een DVA (Dienstverlener Zorgaanbieder), die de gegevens uit een bronsysteem raadpleegt.
- Tijdens het testen wordt gecontroleerd of een PGO via MedMij een correcte aanvraag kan doen.
- Het testproces valideert of de bronsystemen (zoals een AIS of ZIS) de juiste gegevens verstrekken.
- Er wordt geverifieerd of de uitwisseling voldoet aan de vereiste MedMij-standaarden en of de communicatie via de MedMij-gegevensdiensten correct verloopt.
Het ophalen en correct weergeven van medicatie-informatie
Patiënten moeten in hun PGO een volledig en correct overzicht krijgen van hun medicatiegegevens. Dit betekent dat gegevens zoals medicijnnaam, dosering, start- en stopdatum, en herhaalrecepten goed worden opgehaald en weergegeven.
- Er wordt getest of de PGO alle relevante medicatiegegevens correct ophaalt en of er geen gegevens ontbreken.
- De test valideert of de medicatie-overzichten in de PGO correct worden weergegeven, inclusief lopende en beëindigde medicatie.
- Er wordt gecontroleerd of gegevens op een begrijpelijke manier aan de patiënt worden getoond (bijvoorbeeld geen technische codes of foutieve data).
Het testen van de juiste implementatie van FHIR-profielen en MedMij-standaarden
De gegevensuitwisseling tussen PGO’s en zorgsystemen verloopt via FHIR-profielen, zoals MedicationRequest, MedicationStatement en MedicationDispense. Deze profielen bepalen hoe medicatiegegevens gestructureerd en uitgewisseld worden.
- Er wordt getest of zorginformatiesystemen de juiste FHIR-profielen gebruiken en correct implementeren.
- De test valideert of de PGO’s de ontvangen FHIR-berichten correct interpreteren en verwerken.
- Er wordt gecontroleerd of de berichten voldoen aan de MedMij-validatieregels, zodat gegevensuitwisseling gestandaardiseerd en foutloos verloopt.
* Ook DVA's: alleen LSP+, of ook isoft en ... (ticket aanmaken)
Buiten scope
Hybride
Hybride testen zijn opgenomen in het Hybride testplan, wat betekent dat dit onderdeel al op een andere manier wordt afgedekt. De PGO-testaanpak richt zich specifiek op de werking en uitwisseling binnen PGO's en niet op de bredere hybride teststrategie.
Ontwikkel
De ontwikkelfase is bedoeld voor leveranciers en ontwikkelaars om hun systemen te bouwen en technisch te testen. Dit valt buiten de PGO-testaanpak, omdat PGO-testen plaatsvinden in een latere fase, wanneer systemen al (grotendeels) ontwikkeld en klaar voor functionele validatie zijn.ontwikkeltest wijkt niet af
Reguliere raadplegen scripts
De reguliere raadpleeg-scripts hebben betrekking op de algemene uitwisseling van gegevens in zorgsystemen, los van het specifieke proces binnen PGO’s. PGO’s volgen een andere route voor het ophalen van gegevens, met een focus op patiënttoegang via MedMij-standaarden. Hierdoor vallen de standaard raadplegen-scripts buiten de specifieke PGO-testaanpak. De rol van DVA en de ondersteuning van zorgaanbieders zijn hierbij relevant, maar worden niet meegenomen in de PGO-specifieke testdoelen, omdat PGO’s een andere aanpak en infrastructuur hanteren voor gegevensuitwisseling.
Voorbereiding
https://informatiestandaarden.nictiz.nl/wiki/mp:Draft_Testen_Kickstart_Proof_of_Concept_(PoC)_Consolidatie dit is in feite entry criterium & uitgangssituatie: moet succesvol uitgevoerd zijn. Ander linkje per fase
Entry Criteria
Testbasis
Teststrategie
Op basis van de vastgestelde scope wordt in onderstaand overzicht weergegeven binnen welke testfase het onderdeel wordt getest.
Naar aanleiding van de onderlinge samenhang en gefaseerde aanpak zijn hierin onderdelen samengevoegd.
Testfasen
PoC
Fase 1
Om de PGO's te laten testen zal het eindresultaat van de consolidatiescripts van stap 5 (fase 1 & 2) als uitgangssituatie worden gebruikt voor de PGO scripts. Vanuit de eindsituatie van de consolidatiescripts kunnen we gaan testen voor de PGO’s. Aan het einde van ieder script zal er een eindsituatie zijn in combinatie met BSN's. Er zullen verschillende bouwstenen beschikbaar zijn per BSN. Deze bouwstenen zullen moeten worden opgevraagd door de PGO's in verschillende volgordes. Deze volgordes zijn nader te bepalen. Het is de bedoeling dat deze volgordes op de minst gunstige manier worden opgesteld zodat goed getest kan worden of de PGO's er uiteindelijk een kloppend verhaal van kunnen maken. Deze volgorders zullen verder in deze testaanpak worden beschreven.
Deze testaanpak zal gemaakt worden voor fase 1 en 2. Voor fase 3 gaat hoogstwaarschijnlijk parasoft ingezet moeten worden tijdens de consolidatie. Dus voor de de PGO’s zal ook parasoft ingezet moeten worden voor fase 3 aangezien er geen uitgangssituatie zal zijn gecreëerd door BSN’s met leveranciers.
Hieronder zijn de bouwstenen weergegeven die opvraagbaar zijn vanuit consolidatie MBH B. Wanneer MBH B script 1 + 2 van consolidatie fase 1 zijn uitgevoerd is er een uitgangssituatie gecreëerd voor de scripts voor de PGO’s. De PGO's kunnen de onderstaande bouwstenen opvragen.
MBH B:
Uitgangssituatie:
- Voorschrijver 1: Stop-MGB B.2
- Voorschrijver 2: MA B.2 & MGB B.2
- Verstrekker: TA B.2 & Stop-TA B.2
Volgorde te testen: 1, 3, 2
Hieronder is te zien bij welk systeem een bepaalde bouwsteen op te vragen is. Hierboven staan de bouwstenen genummerd. Er is een volgorde aangegeven waarin de bouwstenen opgevraagd moeten worden bij de verschillende systemen.
Script 1 | Verwacht resultaat | |
---|---|---|
BSN | X | |
Voorschrijver 1 | Stop-MGB B.2 | Stop-MGB B.2 is geraadpleegd |
Voorschrijver 2 | MA B.2 & MGB B.2 | MA B.2 & MGB B.2 is geraadpleegd |
Verstrekker | TA B.2 & Stop-TA B.2 | TA B.2 & Stop-TA B.2 is geraadpleegd |
MBH C:
Uitgangssituatie:
- Voorschrijver 1: Stop-MA C.2
- Voorschrijver 2: MA C.2
- Verstrekker: TA C.2 & Stop-TA C.2
Volgorde te testen: 3, 1, 2
Hieronder is te zien bij welk systeem een bepaalde bouwsteen op te vragen is. Hierboven staan de bouwstenen genummerd. Er is een volgorde aangegeven waarin de bouwstenen opgevraagd moeten worden bij de verschillende systemen.
Script 1 | Verwacht resultaat | |
---|---|---|
BSN | X | |
Voorschrijver 1 | Stop-MA C.2 | Stop-MA C.2 is geraadpleegd |
Voorschrijver 2 | MA C.2 | MA C.2 is geraadpleegd |
Verstrekker | TA C.2 & Stop-TA C.2 | TA C.2 & Stop-TA C.2 is geraadpleegd |
Lab
Volgt
Testontwerp
Testdata
Hulpmiddelen (tools) en omgevingen
Voor het testen van de PGO’s binnen PoC stap 5/6 worden gespecialiseerde testtools ingezet om de interoperabiliteit, functionaliteit en robuustheid van de berichtenuitwisseling te valideren. Twee essentiële tools in dit proces zijn InteropLab en Parasoft.
Interoplab
InteropLab wordt gebruikt als validatieomgeving om de interoperabiliteit tussen PGO’s en zorgaanbiedersystemen te testen. Het stelt ons in staat om transacties te analyseren, afwijkingen in berichtenverkeer te identificeren en de naleving van gestandaardiseerde informatiestromen (zoals HL7 FHIR) te controleren.
Binnen InteropLab kunnen PGO’s hun implementaties valideren tegen vastgestelde testscenario’s. Dit omvat onder andere:
- Het testen van correcte gegevensuitwisseling tussen PGO’s en bronsystemen.
- Validatie van FHIR-profielen en conformiteit aan Nictiz-specificaties.
- Analyseren van logging en response-gedrag bij verschillende query-varianten (zoals variërende opvraagvolgordes van medicatiegegevens).
- Detecteren van semantische en syntactische afwijkingen in de berichtuitwisseling.
Parsoft
Binnen deze PoC wordt Parasoft ingezet als een gesimuleerd XiS-systeem dat fungeert als extra gegevensbron voor de PGO’s. Dit betekent dat PGO’s Parasoft kunnen raadplegen op dezelfde manier als een regulier AIS, EVS of ZIS, zonder afhankelijk te zijn van live bronsystemen.
De inzet van Parasoft binnen deze testomgeving biedt meerdere voordelen:
- Beschikbaarheid van testdata: Parasoft bevat testdatasets die representatief zijn voor echte patiëntgegevens, waardoor PGO’s hun opvragingen onder realistische omstandigheden kunnen testen.
- Gedragssimulatie van een XiS-systeem: Parasoft gedraagt zich als een volwaardig bronsysteem en genereert responses zoals een echt AIS, EVS of ZIS dat zou doen.
Lab
hier moeten we wat zeggen over aansluiting op LSP+ (VZVZ / Miranda / Joël). Verder ook relatie met aanpak andere DVA's
Testresultaten
De testresultaten, waaronder eventueel geconstateerde bevindingen, worden als volgt geregistreerd en behandeld:
Ontwikkel
De leverancier toont met behulp van screenshots aan dat is voldaan aan het beschreven verwachte resultaat.
Het Testteam beoordeeld de testresultaten zoals beschreven in Beoordelen testresultaten Ontwikkel
PoC
De uitgevoerde Interoplab testscripts worden beoordeeld zoals beschreven in Beoordelen testresultaten PoC
Lab
Vragen/Acties
Pagina Historie
Datum | Omschrijving |
---|---|
1 februari |
Concept |