Versie van 22 feb 2024 om 15:01

Dit is een tijdelijke pagina met wijzigingen voor issue MM-5132. De gepubliceerde versie vind je hier.

Dit is een werkpagina.

De gepubliceerde versie kan hier gevonden worden: https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2019.01_Ontwerpen

Inhoud

1 Introductie
2 Algemene voorwaarden voor kwalificatie
3 Procedurele eisen voor kwalificatie
4 Uitgangspunten voor kwalificatie
- 4.1 Systeemrol 'Raadplegen' (PGO)
- 4.2 Systeemrol 'Beschikbaarstellen' (XIS)
5 Kwalificatie aansluiten op de kwalificatieomgeving
6 Gebruik van de simulator
- 6.1 Authorization tokens
- 6.2 Variable T datum
7 Kwalificatiescripts

1 Introductie

Op deze informatiestandaard is een Nictiz kwalificatie van toepassing. Kwalificatie vindt plaats per systeemrol.

Enkele systeemrollen vallen binnen de 'subsidieregeling voor PGO-leveranciers (dienstverlener persoon)' die in 2018 is opgesteld door de Dienst Uitvoering Subsidie voor Instellingen. Welke systeemrollen dat betreft vindt u in ToelichtingSubsidie.

Voor meer informatie, stuur een mail naar 'kwalificatie@medmij.nl'.

Kwalificatiescripts en meer informatie over de kwalificatie is te vinden via de betreffende paragraaf op de Kwalificatiepagina.

2 Algemene voorwaarden voor kwalificatie

Een leverancier kan starten met een kwalificatie, als hij voldoet aan onderstaande voorwaarden:

Kennis en begrip van MedMij afsprakenstelsel.
Kennis over de te gebruiken infrastructuur of het netwerk waarover uitgewisseld wordt en de toegang daartoe, inclusief authenticatie/autorisatie etc.
Kennis en begrip van de betreffende MedMij informatiestandaard, zoals beschreven op de informatiestandaarden wiki van Nictiz.
Kennis en begrip en het kunnen toepassen van de verschillende tabellen, waardenlijsten en andere referenties die de informatiestandaard gebruikt.
Kennis en begrip en het naleven van de aandachtspunten zoals beschreven in het document 2. Addenda - Kwalificaties als bijlage bij de betreffende informatiestandaard.
Alle gegevens die de kwalificerende partij zelf moet invoeren zijn te vinden in de kwalificatiedocumentatie. Onjuist ingevoerde gegevens (ook tijd/datum etc.) zullen leiden tot vertraging van en kunnen blokkerend zijn voor het kwalificatieproces.
Inhoudelijke informatie, beschreven in de informatiestandaard, moet altijd toegankelijk zijn voor de eindgebruiker. De leverancier levert voor deze informatie schermafdrukken op voor controle.
Deze kwalificatie toetst geen infrastructurele eisen.

3 Procedurele eisen voor kwalificatie

Naast de bovengenoemde algemene voorwaarden voor kwalificatie dient een kwalificerende (kandidaat-) deelnemer ook te voldoen aan de procedurele eisen voor kwalificatie. Om het kwalificatietraject niet onnodig te vertragen wordt van een (kandidaat-) deelnemer verwacht dat deze de onderstaande procedurele eisen in acht neemt.

Indien niet kan worden voldaan aan de functionele en/of technische eisen van een gegevensdienst, dient dit minimaal 2 weken voorafgaand aan de kwalificatie aangegeven te worden.
De leverancier zorgt dat het systeem dat gekwalificeerd wordt met gelijke functionaliteit en techniek op een later moment in productie genomen wordt. De leverancier zorgt dat de omgeving waarop gekwalificeerd wordt geen omgeving is die productiedata bevat of gaat bevatten.
Indien gebruik gemaakt wordt van de vrijheidsgraden die de gegevensdiensten BgGGZ, BgLZ, BgZ en PDF/a bieden, dient dit minimaal 2 weken voorafgaand aan de kwalificatie aangegeven te worden.
De testexecutie dient 100% succesvol geslaagd te zijn voordat gestart kan worden met de kwalificatie. Indien dit niet het geval is dient dit voorafgaand aan de kwalificatie aangegeven te worden.
Het uitgevoerde certificering-testscript dient niet ouder te zijn dan één week voor de aanlevering van het (pre)kwalificatiemateriaal. Nictiz staat in zijn recht om te bepalen of een test executie is verouderd en daarom af te wijzen.
Bij het instellen van een variabele T datum door een DVA, dient de datum gelijk te zijn aan de datum waarop de Touchstone testexecutie is uitgevoerd.
Voor zowel DVP als DVA geldt dat de schermafdrukken overeen dienen te komen met de uitgevoerde Touchstone testexecutie die is bijgevoegd in het aanleverformat. Wanneer hier niet aan wordt voldaan leidt dit tot een afwijzing.
Het kwalificatiemateriaal dient in het juiste formaat aangeleverd te worden. Gebruik voor het aanleveren van het kwalificatiemateriaal altijd het aanleverformat behorende bij de gegevensdienst. In het aanleverformat staat per dia beschreven welke schermafdruk wordt verwacht.
- Voor een DVP geldt dat er schermafdrukken gemaakt dienen te worden van de interface van een PGO.
- Voor een DVA geldt dat er schermafdrukken gemaakt dienen te worden (van de combinatie) van de achterliggende bronsystemen waarmee men kwalificeert. Let op: Wanneer men voor een nieuwe combinatie van bronsystemen acht te kwalificeren wordt dit behandeld als een nieuwe kwalificatie waarbij ook van die nieuwe combinatie schermafdrukken dienen te worden gemaakt. Schermafdrukken van andere interfaces zoals van een XDS worden afgekeurd.

4 Uitgangspunten voor kwalificatie

In dit hoofdstuk worden de generieke uitgangspunten voor de kwalificatie per systeemrol uiteengezet. Per informatiestandaard kan het voorkomen dat er nog 'specifieke' uitgangspunten op van toepassing zijn, in dat geval, zijn deze opgenomen in een aparte paragraaf onder het hoofdstuk 'Kwalificatie' van het functioneel ontwerp van de informatiestandaard.

4.1 Systeemrol 'Raadplegen' (PGO)

Hieronder volgt het generieke uitgangspunt voor de kwalificatie van de systeemrol 'Raadplegen':

Een PGO biedt de persoon inzicht in de ontvangen respons. Als er géén gegevens beschikbaar gesteld worden, kan dat zijn omdat er geen informatie beschikbaar is in het XIS of vanwege een technische foutmelding. Er volgt bijvoorbeeld een foutmelding indien de resource, een specifieke zib, niet wordt ondersteund in het XIS. Het is een belangrijk inzicht voor de persoon als gegevens technisch niet beschikbaar gesteld kunnen worden.

4.2 Systeemrol 'Beschikbaarstellen' (XIS)

Hieronder volgen de generieke uitgangspunten voor de kwalificatie van de systeemrol 'Beschikbaarstellen':

XIS geeft technisch correct antwoord op alle searches ongeacht of de gegevens in XIS beschikbaar zijn. XIS stelt alle gegevens beschikbaar voor zover aanwezig.

Mochten gegevens niet beschikbaar gesteld kunnen worden, dan is uit de respons voor de persoon te herleiden waardoor dit veroorzaakt wordt:
- veroorzaakt door het ontbreken van de informatie
- veroorzaakt doordat het XIS dit technisch niet kan leveren.

In het geval dat een vraag om gegevens goed wordt verwerkt door het XIS, volgt een respons met daarin 0 tot * FHIR resources die matchen aan de vraag. Als er dus 0 resources in zitten mag de persoon ervan uitgaan dat het XIS deze gegevens niet heeft, maar de vraag wel goed begrepen heeft.

Als er technisch iets niet goed gaat, stuurt het XIS conform de specificaties een foutcode terug samen met een OperationOutcome, waarin de oorzaak wordt getoond. Bijvoorbeeld dat de resource, een specifieke zib, niet wordt ondersteund in het XIS. Deze moet ingebouwd worden door het XIS. Hierop wordt het XIS ook gekwalificeerd.

5 Kwalificatie aansluiten op de kwalificatieomgeving

MedMij biedt leveranciers de mogelijkheid hun producten en diensten te laten testen op correcte implementatie van informatiestandaarden. Documentatie over hoe aan te sluiten is te vinden op: MedMij:Vprepub-2019.01_Kwalificatie_aansluiten

6 Gebruik van de simulator

6.1 Authorization tokens

Voor uitleg over gebruik van de simulator en tokens, zie MedMij:Vprepub-2019.01_Qualification

6.2 Variable T datum

Voor veel, straks alle, kwalificaties wordt er gebruik gemaakt van een variabele datum. Dit is de zogenoemde T datum welke is opgenomen in de functionele testscripts, met name in de addenda, en in de technische testscripts op Touchstone. Deze variabele datum wordt gebruikt om zo dicht mogelijk tegen een productiewaardig scenario te testen en te kwalificeren. Middels de variabele datum kunnen de testgegevens actueel blijven. Deze T datum komt op twee plekken terug, namelijk in de datumvelden van de testgegevens en in de datumparameters in de search URL's. In de volgende twee paragrafen wordt dit toegelicht.

6.2.1 Kwalificatie test gegevens

De functionele testscripts beschrijven in de addenda testgegevens waarin datum velden staan op basis van een T datum. Als ergens staat T – 100D betekent dit: 100 dagen eerder dan de datum die voor T geldt. Deze testgegevens uit de addenda worden vervolgens gebruikt om ofwel de Nictiz WildFHIR server te vullen of door kandidaat deelnemers om de testgegevens in het systeem te registreren.

Het vullen van de Nictiz WildFHIR server kon in het verleden door kandidaatdeelnemers gebeuren door het draaien van het 'load script' op basis van een op te geven variable T. Dit is nu in beheer genomen door het kwalificatie team.

Elke maandag wordt de Nictiz WildFHIR server geschoond en opnieuw gevuld met een testgegevens op basis van een T datum gelijk aan de datum van die maandag.

Bijvoorbeeld in 2019 is T datum in week 46 gelijk aan 11 november 2019.

6.2.2 Parameters in de request URL's

Bij sommige testscenario's wordt een datumfilter gebruikt. Deze datumfilters zijn ook op basis van de variabele T datum. Bij het uitvoeren van het testscript in Touchstone is het mogelijk om bij de setupfase de variabele T datum te geven. Deze T datum staat in relatie tot de testgegevens die op de Nictiz WildFHIR server of het eigen bronsysteem staan. De T datum die hier gebruikt dient te worden, is gelijk aan de datum van de maandag (waarop de gegevens geladen zijn).

Wanneer een andere T datum wordt gebruikt kan het voorkomen dat er geen of te weinig testgegevens terugkomen op de uitgevoerde test. Dit kan er toe leiden dat de test niet slaagt.

6.2.3 Tijdnotatie

Het meegeven van de tijd is bij de gestructureerde einddatum/tijd (dus niet de Resource.text, maar de velden met alleen de datum/tijd) verplicht in de standaard om eventuele verwarring tussen de precieze betekenis van "tot" en "tot en met" te voorkomen.

In de FHIR datatypes dateTime (indien uren en minuten worden gebruikt) en instant is de tijdzone verplicht. De tijdzone kan daarom niet worden weglaten uit de testgegevens.

Touchstone heeft helaas een beperking dat de Nederlandse tijdzone niet berekend kan worden bij een variabele datum. De tijdzone die nu in onze testgegevens staat, was een Nederlandse tijdzone bij de eerste keer invullen van dit scenario met concrete datums. Dit komt niet per definitie overeen met de geldende tijdzone in Nederland voor de (in een test-executie gebruikte, uiteindelijke) datum. In productie moet gerekend worden op een juiste tijdzone en het is dan ook juist om deze tijdzone gewoon te interpreteren, dit betekent dat de gegevens mogelijk soms een uur later of vroeger zijn dan in het addendum staat. Dit is geen reden voor afkeuren in kwalificatie.

6.2.3.1 MedMij request headers

Het MedMij Afsprakenstel verplicht het gebruik van een aantal headers. Voor compatibiliteit met systemen die voldoen aan het Afsprakenstel worden de volgende twee headers toegevoegd binnen alle TestScripts:

De MedMij-Request-ID-header is een willekeurig gegenereerde UUID per request.
De X-Correlation-ID-header is een UUID, gegenereerd per TestScript. Elke request binnen hetzelfde TestScript bevat dus dezelfde waarde voor deze header. Indien er meerdere TestScripts tegelijk geselecteerd worden voor executie, biedt Touchstone ook de mogelijkheid om voor alle geselecteerde TestScripts dezelfde waarde mee te geven.

N.B. Dit mechanisme is niet bedoeld om de werking van deze headers te testen, maar alleen om te zorgen dat de requests geen problemen opleveren voor systemen die het Afsprakenstelsel implementeren.

6.2.4 Variabele T datum

Test- en kwalificatiescenario's werken vaak met relatieve datums, die ervoor zorgen dat scenario's niet gedateerd raken. Een datum 'volgende week' blijft zodoende altijd in de toekomst. Om dit te vertalen naar concrete datums die gebruikt worden tijdens het testen en kwalificeren wordt gewerkt met de zogenaamde T-datum. De betekenis van deze T-datum en waar een deelnemer rekening mee moet houden bij het gebruik hiervan verschilt per rol. Voor iedere rol volgt hierna verdere uitleg.

6.2.4.1 Server: beschikbaarstellen (serve) en client: sturen (send)

Leveranciers die de inhoudelijke gegevens van test- en kwalificatiescenario's in hun bronsysteem invoeren ter voorbereiding op de Touchstone-tests voor beschikbaarstellen (serve) of sturen (send), bepalen een T-datum die zij hanteren bij het invoeren van alle gegevens.

Wanneer de bepaalde T-datum bijvoorbeeld '2022-01-01' is en de kwalificatiescripts spreken van 'T + 400D', berekent de leverancier de datum die 400 dagen ná de bepaalde T-datum ligt. Die datum wordt vervolgens in het bronsysteem ingevoerd bij het betreffende veld – in dit voorbeeld dus '2023-02-05'.

Mogelijke eenheden die gebruik worden bij het verrekenen van de T-datum zijn 'D' (dagen), 'M' (maanden) en 'Y' (jaren).

Wanneer er datums gebruikt worden in de testscenario's, die invloed hebben op de Touchstone-scripts, bijvoorbeeld in de zoekparameters van het scenario "Persoon 1 vraagt alle meetwaarden op in een periode ('T – 30D t/m T')", wordt ook bij het uitvoeren van het betreffende TouchStone-script gevraagd de bepaalde T-datum in te voeren. Touchstone berekent vervolgens zelf de exact benodigde datums. Als de T-datum van het Touchstone-script overeenkomt met die van de ingevoerde gegevens, worden de gevraagde resources opgeleverd.

De verwachting is dat een leverancier de gebruikte T-datum vermeldt bij het aanleveren van de materialen en dat deze datum correspondeert met de aangeleverde screenshots en Touchstone-testexecutie(s).

6.2.4.2 Server: ontvangen (receive) en client: ophalen (retrieve)

Leveranciers die gegevens ophalen of ontvangen tijdens het gebruik van Touchstone, ontvangen testberichten van WildFHIR. Elke maandag worden de gegevens op WildFHIR ververst, waarbij alle datums opnieuw worden berekend met de datum van die maandag als referentie.

Als een client gegevens ophaalt in de week van '2022-08-01', zal, indien het kwalificatiescript spreekt van een veld met als datum 'T + 400D', er een resource opgehaald worden waarin dat betreffende veld gevuld is met de datum '2023-09-05'.

Wanneer er datums gebruikt worden in de testscenario's, die invloed hebben op de Touchstone-scripts, bijvoorbeeld in de zoekparameters van het scenario "Persoon 1 vraagt alle meetwaarden op in een periode ('T – 30D t/m T')", wordt ook bij het uitvoeren van het betreffende Touchstone-script gevraagd de T-datum in te voeren. Hier dient dus de datum van de maandag uit de testweek te worden ingevuld. Touchstone berekent vervolgens zelf de exact benodigde datums. Als de T-datum van het Touchstone-script overeenkomt met de datum die gebruikt is tijdens het verversen van WildFHIR, worden de gevraagde resources opgeleverd.

De verwachting is dat een client tijdens kwalificatie in screenshots datums laat zien die corresponderen met gegevens die opgehaald zijn tijdens de aangeleverde Touchstone-testexecutie(s).

6.2.5 Tijdzones

In de FHIR-datatypes dateTime (indien uren en minuten worden gebruikt) en instant is het verplicht om een tijdzone in te vullen. De tijdzone kan daarom niet worden weglaten uit de testgegevens. Touchstone heeft helaas de beperking dat de Nederlandse tijdzone niet berekend kan worden aan de hand van de T-datum. De tijdzone die nu in onze testgegevens staat is daarom de Nederlandse tijdzone bij de eerste keer invullen van dit scenario met concrete datums. Dit komt niet per definitie overeen met de geldende tijdzone in Nederland voor de (in een testexecutie gebruikte, uiteindelijke) datum. In productie moet gerekend worden op een juiste tijdzone en het is dan ook juist om deze tijdzone gewoon te interpreteren, dit betekent dat de gegevens mogelijk soms een uur later of vroeger zijn dan in het addendum staat. Dit is geen reden voor afkeuren tijdens kwalificatie.

7 Kwalificatiescripts

7.1 Medicatieproces 9.0

Een uitleg van medicatieproces voor PGO's die kwalificeren voor MedMij is beschikbaar in de vorm van:

Bestand (met mp4 opname) van uitleg Medicatieproces met bijbehorende
PowerPoint (in PDF).

Diverse medicatieproces kwalificatiescripts zijn van toepassing voor zowel zorgverlener-patiënt (MedMij) als zorgverlener-zorgverlener gegevensuitwisseling. Deze kwalificatiescripts worden op één plek onderhouden en gepubliceerd. Via deze MedMij pagina wordt direct naar het betreffende kwalificatiescript verwezen (via de link).

7.1.1 Medicatiegegevens

7.1.2 Medicatieoverzicht