Huidige versie van 25 mrt 2024 om 21:16

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
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:V2019.01_Kwalificatie_aansluiten

6 Gebruik van de simulator

6.1 Authorization tokens

Voor uitleg over gebruik van de simulator en tokens, zie MedMij:V2019.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.3 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.

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