mp:Draft Testen Kickstart Hybride

Aan deze pagina wordt momenteel gewerkt.

Inleiding

Dit detail testplan is onderdeel van het Master Testplan Kickstart en biedt een overzicht van alle testactiviteiten vanuit de Kickstart Medicatieoverdracht ten behoeve van het testen van de hybride situatie.

Testplan

Testdoel

• Het gemigreerde MP9.3 systeem kan berichtenstromen van/naar MP6.12 en EDIFACT systemen verwerken/versturen in de hybride situatie
  • De inhoudelijke mapping tussen het MP9.3 datamodel en MP6.12/EDIFACT datamodel vindt correct plaats
• Medicatiegegevens uit meerdere formaten (MP6.12-verstrekkingen in MP9-TA formaat) worden correct geconsolideerd
• Correct toepassen van signalering op mogelijk duplicate medicatiegegevens
• Het proces van handmatig ontdubbelen van medicatiegegevens wordt ondersteund door het informatiesysteem
• De BTD transformeert MP6.12 Verstrekkingen correct naar MP9-TA formaat

Scope

Binnen scope

• Berichtenuitwisseling in de hybride situatie: de systemen zullen zowel MP9 als oudere berichtenstromen (MP6.12 en/of EDIFACT) moeten ondersteunen:
  
  • Standaarden:
    • MP9.3
    • MP6.12
    • EDIFACT
  • Dit betreft de uitwisseling van de transacties: zoals weergegeven onder Relevante transacties, m.u.v. de transacties tussen MP9.3 systemen onderling
  • De inhoudelijke mapping tussen bovenstaande standaarden
  • Berichten transformatiedienst (BTD): zorgt voor conversie van MP6.12-verstrekkingen vanuit MP6.12-AIS'en naar een MP9-TA formaat
• Ontdubbelen in de hybride situatie bij de MP9.3 systemen onderling, zoals weergegeven onder Relevante transacties
  • Het proces van toekennen van identificaties en het kunnen relateren van medicatiegegevens op basis van deze identificaties
  • Het toepassen van signalering op mogelijke duplicate medicatiegegevens na raadplegen
  • Het proces van handmatig ontdubbelen, na eventuele signalering op duplicate medicatiegegevens
  • Het consolideren van medicatiegegevens in meerdere formaten in de hybride situatie: MP6.12-verstrekkingen in MP9-TA formaat. (dit is buiten scope van het testplan Consolidatie)
• Testuitvoer met niet-Kickstart leveranciers tijdens de testfases PoC en Lab

Buiten scope

• Migratie: het omzetten van de medicatiegegevens in de lokale database van een systeem naar een datamodel dat ook MP9-bouwstenen ondersteunt
• Testfase Praktijk: De uitvoering van deze fase wordt gecoördineerd door de penvoerders van beide regio's. Hiervoor wordt een apart testplan opgesteld
• Beschikbaar stellen van medicatiegebruik (MGB) geregistreerd door de patiënt, vanuit een PGO. Zie PGO
• (Regressie-)test op berichtenverkeer:
  • MP9.3 systemen onderling (wordt getest vanuit het regulier testplan Kickstart)
  • MP6.12 systemen onderling
  • EDIFACT systemen onderling
  • MP6.12 en EDIFACT systemen
  • Bestaande uitwisselingen (bijvoorbeeld: communicatie met TRIS)
• M.b.t de transacties Raadplegen/Beschikbaarstellen medicatiegegevens (MA, MGB, WDS, TA, MTD): Sturen/Ontvangen wordt niet getest. Uitgangspunt: bij Sturen/Ontvangen stelt de sturende partij vooraf vast of er geen sprake is van dubbelingen.
• Berichtenstromen waarin medicatiegegevens opgenomen zijn die niet vallen onder de MP6.12, EDIFACT of MP9.3 standaard, zijn buiten scope van de set 2025
• Het consolideren van medicatiegegevens in andere formaten dan MP9 en MP6.12-verstrekkingen in MP9-TA formaat in de hybride situatie

Testbasis

• Implementatiehandboek Migratie en Hybride
• Raadplegen en reconciliëren
• https://informatiestandaarden.nictiz.nl/wiki/mp:Vdraft_kickstart_MigratieHybride/Identificaties_en_hun_onderlinge_relaties

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.

	Fase	Ontwikkel	PoC	Lab
Berichtenuitwisseling in de hybride situatie tussen de standaarden MP9.3, MP6.12 en EDIFACT
MP6.12	1 & 4	***	*	**
EDIFACT	2 & 5	***	*	**
Berichten transformatiedienst (BTD)	4	*	I	I
Ontdubbelen in de hybride situatie bij de MP9.3 systemen onderling Het proces van toekennen van identificaties en het kunnen relateren van medicatiegegevens op basis van deze identificaties Het toepassen van signalering op mogelijke duplicate medicatiegegevens na raadplegen Het proces van handmatig ontdubbelen, na eventuele signalering op duplicate medicatiegegevens Consolideren van medicatiegegevens in meerdere formaten (MP6.12-verstrekkingen in MP9-TA formaat)	3 & 6	***	*	**

Legenda:

• * Beperkte dynamische test
  
• ** Gemiddelde dynamische test
  
• *** Zware dynamische test
  
• S Statisch testen
  
• I Impliciet testen

Hulpmiddelen (tools) en omgevingen

Ontwikkeltesten

6.12 berichten

Interoplab validator

De te versturen 6.12 berichten tijdens de Ontwikkeltestfase worden door het 9.3 systeem verstuurd naar Interoplab.
Hier worden deze berichten gevalideerd met behulp van een schematron, zoals beschreven in Valideren berichten

Parasoft simulator

De te ontvangen 6.12 berichten tijdens de Ontwikkeltestfase worden vanuit Parasoft verstuurd naar het 9.3 systeem.
De leverancier toont vervolgens aan dat het bericht correct is ontvangen en verwerkt.
Voor het sturen van berichten vanuit Parasoft wordt deze procedure gehanteerd.

EDIFACT berichten

Enovation/E-Zorg testfunctionaliteit

Ten behoeve van het testen van berichtenuitwisseling tijdens de testfases Ontwikkel, PoC en Lab wordt gebruik gemaakt van Enovation/E-Zorg testfunctionaliteit. Leveranciers die niet zijn aangesloten bij Enovation kunnen gebruik maken van de Enovation validator van het Validatieloket. Indien gewenst, neem contact op met het Validatieloket: validatie@medicatieoverdracht.nl

Met behulp van de testaccounts van deze leveranciers worden onderstaande tests ondersteund:

1. Ontwikkeltest:
   1. Aantonen dat verzonden EDIFACT-berichten valide zijn met behulp van de Enovation/E-Zorg validator. De validatierapporten en geteste berichten worden als bewijsmateriaal toegevoegd in het Interoplab-script.
   2. Aantonen dat relevante EDIFACT-berichten ontvangen en verwerkt worden. De leverancier toont aan dat de voor hen relevante EDIFACT-berichten technisch succesvol ontvangen én verwerkt worden in het eigen systeem. Dit geldt in elk geval voor de berichten die vanuit het testplatform worden aangeboden, maar mag – indien beschikbaar – ook op basis van testberichten die de leverancier reeds zelf bezit.

Als bewijs worden minimaal de volgende elementen aangeleverd:

• Een korte toelichting op welke berichten verwerkt zijn en hoe deze verwerking plaatsvindt
• Bewijsmateriaal zoals:
  • Screenshots waaruit correcte verwerking blijkt
  • Eventuele validatie- of verwerkingsrapportages

Doel is om aan te tonen dat berichten zonder fouten worden ontvangen én geautomatiseerd of handmatig correct verwerkt worden.

1. PoC ketentest en Lab test:

Aantonen dat EDIFACT-berichtenuitwisseling in de keten succesvol plaatsvindt. Dit houdt in dat berichten tussen ketenpartijen onderling correct worden verzonden, ontvangen en verwerkt. Bewijsvoering vindt plaats zoals hierboven beschreven.

Testresultaten

De testresultaten, waaronder eventueel geconstateerde bevindingen, worden als volgt geregistreerd en behandeld:

Ontwikkeltest

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 ketentest

De uitgevoerde Interoplab testscripts worden beoordeeld zoals beschreven in Beoordelen testresultaten PoC

Lab test

De uitgevoerde Interoplab testscripts worden beoordeeld door de zorgverleners vanuit de betroken Kickstart regio’s.

ARCHIEF

Vragen/Acties

Dit is een draft versie van het testplan. Onderstaande wordt niet overgenomen in de gepubliceerde versie.

Vragen

MOET DEZE PUNTEN NIET ALS STORY OP DE BACKLOG?| Michiel ;)

Nr.	Indiener	Vraag	Antwoord	Ticket (evt.)
1	BartK	Welke niet volwaardige MP9 standaarden zijn wel/niet in scope (en hoe hiermee om te gaan)?
2	BartK	Wat zijn de procedures bij nieuwe inzichten, zoals beschreven onder Kaders?
3	BartK	Wat is de status van de Toedienlijsten?
4	BartK	BTD tijdens de PoC expliciet of impliciet testen?	zie actie 5
5	BartK	Scopebepaling Inhoudelijke mapping (bv. MP6.12 > MP9.x? (bv. datumvelden (registratiedatum))) (zie tabel1) ZorgAB: Hoe door applicaties vaststellen dat sprake is van welke standaard (en wat dus wel/niet te sturen/ontvangen)? ...	Inhoudelijke mapping: in scope (ontwikkeltest) ZorgAB: bespreken met VZVZ. Nieuwe actie aangemaakt.
6	BartK	proactief reconciliëren van (deel)populaties. Wat is dit?	Heeft betrekking op stap 5. Bv. GDS proactief zsm reconcilieren omdat je wil dat dossier op orde is. Niet wachten op GDS rol. Denk ook aan toedien-patienten
7	Shenaida	Bij 2.2 ..... Documentatie met details omtrent de transformatiedienst wordt verwezen naar bits issue, terwijl de ticket gereed is met een wiki pagina. Tekst aanpassen?	Wordt verwerkt in nieuwe versie
8	Shenaida	Welke medicatie bouwstenen zitten in de transformatiedienst van VZVZ? Vanuit welke systemen wordt raadplagen gedaan, EVS, AIS, HIS, ZIS?	Zie 'Relevante transacties'
9	Shenaida	"Zorgverleners zullen actuele en recent gestopte medicatie zorgvuldig reconciliëren volgens MP9. Dit gebeurt niet bij historische informatie tenzij daar directe aanleiding voor is. Dit zorgt er ook voor dat zorgverleners niet onnodig belast worden met reconciliatietaken (administratieve lasten) voor historische medicatie die vandaag niet echt belangrijk meer is." --> wel testen? welke consequenties heeft dit? dat in de hisotrie wel veel dubbelen staan als er veel geraadpleegd wordt? of komt historie niet mee bij raadplegen? Historie bij ELZ/AZ betreft afgelopen 4 maanden.
10	Shenaida	hoe worden stap 1 en 2 getest? Wat wordt daar getest? (migratie en hybride is toch stap 4 en 5). Volgen leveranciers altijd stap 1 en 2 vooraf stap 4 en 5?	Deze vraag heeft betrekking op de Kickstart stappen 3 (voorschrijven), 4 (verificatie en gebruiken), 5 (verstrekken), 6 (toedienen)
11	BartK	proactief reconciliëren van (deel)populaties. Wat is dit?	dubbel, zie 6
12	BartK	EVS’en, zoals huisarts- en ziekenhuisinformatiesystemen (HIS’en en ZIS’en), moeten, indien mogelijk, achterhalen of het gaat om in- of externe voorschriften. Wat indien niet mogelijk?
13	BartK	Transitiefase: hoe ziet deze er uit? (bv. vanaf wanneer (na migratie) gaan applicaties raadplegen/ontvangen en beschikbaar stellen/sturen. Welke procedures (en rol van LSP)?
14	BartK	MP9 wisselt toedieningsschema’s technisch uit volgens het FHIR-datatype Timing. MP6.12 maakt gebruik van het HL7v3-datatype GTS (General Timing Specification). Hier wordt gesproken over FHIR vs v3, terwijl MP9 niet enkel FHIR betreft. Hoe zit dit?
15	BartK	Presentatie 20230509 - hybride situatie (BartK) Wat is de relatie tot het huidige testmateriaal? Wat wordt gedaan met EDIFACT? Dia 5: wat is een medicatieopdracht? (wat zegt deze dia?) Dia 11: hoe wordt gegarandeerd dat MBH-id wereldwijd uniek is? Dia 17 en verder: betreft dit allen situatie 1a? Is/was er gepland meer te beschrijven?
16	BartK	Wat gebeurd er met ontvangen Vooraankondigingen/Voorschriften/Uitvoeringsbevestigingen? (zie onderstaande tabel)
17	BartK	Wat is een MP6.12 MVE? (zelfde als MP6.12 TA?)
18	BartK	Zie onderstaande tabel: wat is het veschil tussen voor/na beschikbaar stellen?
19	BartK	Nader te bepalen ZorgAB: (in scope?) Hoe door applicaties vaststellen dat sprake is van welke standaard (en wat dus wel/niet te sturen/ontvangen)? Onderdeel van Acceptatie Impliciet PoC Toedienlijsten?

Transactie	Verwerking/reconciliatie	Mapping	Consolidatie
MP9.3	Verschil tussen voor/na beschikbaar stellen? vóór beschikbaar stellen na beschikbaar stellen	NVT	Wordt getest vanuit testplan Consolidatie
MP6.12 Vooraankondiging
MP6.12 TA	Verschil tussen voor/na beschikbaar stellen? 6.12 Verstrekking vóór beschikbaar stellen 6.12 Verstrekkingen na beschikbaar stellen*	Medicatieproces 9 (MP9) versie 3.0.0 en versie 6.12 Transactie Verstrekkingenvertaling (conversie MP 6.12 verstrekkingenlijst naar MP-9 TA)	Gelden hiervoor andere regels?
EDIFACT Voorschrift
EDIFACT Uitvoeringsbevestiging

• PrescriptionId (relatieMA)
  • Impact duplicaat?

Acties

Nr.	Indiener	Actie	Tickets
1	BartK	Dit testplan aansluiten op MTP/DTP (ontwikkel/PoC/Lab) Exit criteria per fase aanpassen tabel MTP aanpassen
2	BartK	Aanmaken ontwikkelscripts stap 3: EDIFACT - ...	NICTIZ-2054 NICTIZ-17794 NICTIZ-17797 NICTIZ-4475
3	BartK	Relevante transacties stap 5 TRIS & ETDR
4	BartK	Sluit 'Beoordelen testresultaten Ontwikkel' aan op de beoogde Ontwikkeltests?
5	BartK	Testaanpak/-resultaten ontwikkel/PoC bespreken met Miranda en Maarten (voorstel:) Ontwikkel: expliciet PoC: impliciet	19-6: Meeting met Miranda/Maarten ingepland op 25-6
6	BartK	Lab aanpak bespreken met Loanne/Marleen
7	BartK	Bevindingenproces Lab aanmaken/bespreken met Loanne/Marleen
8	BartK	ZorgAB in scope? Bespreken met VZVZ	19-6: Meeting met Miranda/Maarten ingepland op 25-6
9	BartK	Leveranciers van buiten de Kickstart (bv. PharmaPartners) betrekken voor testen hybride situatie? Zie ook 10
10	BartK	Randvoorwaarden / entry criteria PoC: Zijn leveranciers met EDIFACT/6.12 systemen nodig?
11	BartK	VZVZ/Michiel: kan ZorgAB ingezet worden voor PoC om met 6.12 systemen te testen?
12	BartK	Vanuit Refinement: Testinfrastructuur afstemmen met VZVZ	NICTIZ-17836 19-6: Meeting met Miranda/Maarten ingepland op 25-6
13	BartK	EDIFACT Uitvoeringsbevestiging = stap5
14	BartK	Prioritering mapping MP6.12 > MP9.3
15	BartK	Check: draaiboek (inhoud) bruikbaar?	NICTIZ-16195

• 

Pagina Historie

Datum	Omschrijving
9 oktober 2025	Teststrategie BTD: beperkt dynamisch
29 september 2025	Expliciete beschrijving van consolidatie meerdere formaten verwijderd (zie MOVAL-1595)
19 september 2025	Paragraaf Lab uitgewerkt
15 september 2025	PoC Script 12.1 is buiten scope: verwijderd uit overzichten
27 maart 2025	Nummering EDIFACT ontwikkelscripts aangepast
17 maart 2025	Inleiding aangepast
18 februari 2025	Nummering 6.12 ontwikkelscripts aangepast. Ontdubbelen ontwikkel: concept ingevoerd
17 februari 2025	Testdoel 'Correct toepassen van signalering op mogelijk duplicate medicatiegegevens' i.p.v. 'technisch ontdubbelen'. Term Reconciliëren is verwijderd. Scope: 'Het toepassen van signalering op mogelijke duplicate medicatiegegevens na raadplegen.' i.p.v. 'technisch ontdubbelen' 'Het proces van handmatig ontdubbelen' aangevuld met 'na eventuele signalering op duplicate medicatiegegevens.' 'Consolideren medicatiegegevens uit meerdere formaten' niet langer sub van 'technisch ontdubbelen'. Teststrategie: bovenstaande tevens hier doorgevoerd.
13 februari 2025	Teststrategie aangepast: Lab is overal ** Lab BTD: I Scope: Het consolideren van medicatiegegevens in meerdere formaten in de hybride situatie: alleen MP6.12-verstrekkingen in MP9-TA formaat. (MP6.12 en EDIFACT zijn buiten scope) MP6.12 herkwalificatie is buiten scope
22 januari 2025	Hulpmiddelen (tools) en omgevingen toegevoegd
11 juni 2024	Concept