MedMij:Vissue-MM-4912/Pre-kwalificatie

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

1 Doelgroep

Deze pagina is bedoeld voor deelnemers en kandidaatdeelnemers die zich willen voorbereiden op de kwalificatie van een informatiestandaard of gegevensdienst. Dit betreffen onder andere XIS-leveranciers, DVA's, DVP's en ontwikkelaars van (gegevensuitwisseling)platforms.

2 Inleiding

2.1 Algemene informatie

Voor toetsing en validatie van de implementatie van informatiestandaarden gebruikt Nictiz een kwalificatiesimulator, die is ingericht op een FHIR-server. De simulator kan berichten verzenden en ontvangen. In de uitwisseling wordt gebruik gemaakt van testpatiënten met fictieve BSN's.

Op de Nictiz kwalificatiesimulator zijn naast scripts voor het doorlopen van kwalificaties ook scripts uitgewerkt voor pre-kwalificatie. Deze scripts helpen de deelnemer of kandidaat deelnemer om:

• inrichting en implementatie van de standaard te toetsen voordat de daadwerkelijke kwalificatie start
• aanpassingen op de eigen inrichting te toetsen bij doorontwikkeling.

Voor een gestroomlijnde implementatie en de juiste informatie zijn er verschillende communicatiekanalen:

• Aanvullende informatie, vragen of opmerkingen kunnen gevonden en geplaatst worden op BITS
• Algemene vragen over Medmij kunnen gemaild worden naar info@medmij.nl

En indien het vragen betreft rondom de procedure en planning van kwalificatie zelf, neem dan contact op via kwalificatie@medmij.nl. Meer informatie over het kwalificatietraject kan gevonden worden op de Medmij-kwalificatiepagina.

2.2 Begrippenlijst

Rondom kwalificatie en de implementatie van informatiestandaarden/gegevensdiensten bij Medmij hanteren wij de volgende begrippen:

DVP	Dit betreft een rol in het MedMij Afsprakenstelsel. Levert een Persoonlijke gezondheidsomgeving, een dienst aan de Persoon voor de regie op zijn gezondheid die minimaal gegevensuitwisseling met de Zorgaanbieder mogelijk maakt middels het MedMij Afsprakenstelsel.
DVA	Dit betreft een rol in het MedMij Afsprakenstelsel. Levert Diensten aan de Zorgaanbieder gerelateerd aan de uitwisseling tussen Persoon en Zorgaanbieder en committeert zich hiervoor aan de naleving van de afspraken van het MedMij Afsprakenstelsel. Tot versie 1.6.0 van het Afsprakenstelsel werd de afkorting "DVZA" gebruikt.
Persoonsdomein	Alle Personen en alle Dienstverleners personen vormen samen het Persoonsdomein.
PGO	Een Persoonlijke gezondheidsomgeving is een dienst aan de Persoon voor de regie op zijn gezondheid die minimaal gegevensuitwisseling met de Zorgaanbieder mogelijk maakt middels het MedMij Afsprakenstelsel.
Testexecutie	Een uitgevoerde set tests op het Touchstone-platform.
Kwalificator	Een ondersteunende tool om (pre-)kwalificatie mee uit te voeren, zoals Touchstone.
Pre-kwalificatie	Een selectie van (functionele) scenario's om de implementatie van een informatiestandaard te ondersteunen en gegevensuitwisseling te valideren.
Touchstone	Een platform waarmee FHIR-communicatie getest kan worden. Nictiz gebruikt dit platform voor het uitvoeren van kwalificaties.
XIS	Het systeem of geheel van de systemen waarin de zorgaanbieder het medisch dossier van de persoon bijhoudt.
Zorgaanbiedersdomein	Alle Zorgaanbieders en alle Dienstverleners zorgaanbieder vormen samen het Zorgaanbiedersdomein.

3 Voorwaarden

Een deelnemer of kandidaatdeelnemer kan gebruik maken van pre-kwalificatie als hij voldoet aan onderstaande voorwaarden:

1. Kennis en begrip van MedMij Afsprakenstelsel.
2. Kennis over de te gebruiken infrastructuur of het netwerk waarover uitgewisseld wordt en de toegang daartoe, inclusief authenticatie/autorisatie etc.
3. Kennis en begrip van de betreffende MedMij informatiestandaard, zoals beschreven op de informatiestandaarden wiki van Nictiz.
4. Kennis en begrip en het kunnen toepassen van de verschillende tabellen, waardenlijsten andere referenties die de informatiestandaard gebruikt.
5. Kennis en begrip dat het succesvol doorlopen van het pre-kwalificatiemateriaal niet leidt tot een Medmij-label, maar dat hiervoor het kwalificatieproces in zijn geheel succesvol doorlopen moet zijn

4 Uitgangspunten

In dit hoofdstuk worden de generieke uitgangspunten bij pre-kwalificatie per systeemrol uiteengezet. Per informatiestandaard of gegevensdienst kan het voorkomen dat er nog 'specifieke' uitgangspunten van toepassing zijn.

4.1 Systeemrol 'Raadplegen' (Persoonsdomein)

Hieronder volgen de generieke uitgangspunten voor de (pre-)kwalificatie van de systeemrol 'Raadplegen':

• De set van de gegevensdienst is bewust als één geheel vastgesteld. Als zodanig is deze gehele set onderdeel van pre-kwalificatie als voorbereiding op de kwalificatie.
• Een PGO dient alle functionele data-elementen conform de dataset van de informatiestandaard te tonen aan de gebruiker. De uitzonderingen per gegevensdienst zijn beschreven in de bijbehorende functionele ontwerpen.
• 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.
• Een PGO biedt de persoon inzicht in herkomst van de verzamelde gegevens en wanneer deze gegevens verzameld zijn. Dit betreft concepten die meer technisch van aard zijn maar voor de eenduidigheid en herleidbaarheid van de gegevens noodzakelijk zijn. Dit betreffen de metagegevens zoals gelogd door de PGO bij ontvangst van de geraadpleegde gegevens.

4.2 Systeemrol 'Beschikbaarstellen' (Zorgaanbiedersdomein)

Hieronder volgen de generieke uitgangspunten voor de (pre-)kwalificatie van de systeemrol 'Beschikbaarstellen':

• Een DVA dient de gehele gegevensdienst te ondersteunen. Uitzonderingen worden toegelicht in de bijbehorende functionele ontwerpen en kwalificatiescripts.
• Een DVA 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 de DVA 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 foutcode moet ingebouwd worden door het XIS. Het pre-kwalificatiemateriaal toest hier (momenteel) niet op, echter zal kwalificatie hierop wel plaatsvinden.

4.3 Systeemrol 'Ontvangen' (Zorgaanbiedersdomein)

Hieronder volgt een generiek uitgangspunt voor de (pre-)kwalificatie van de systeemrol 'Ontvangen':

• Een XIS maakt kenbaar dat de gegevens correct ontvangen zijn of geeft een foutmelding richting de PGO indien het ontvangen bericht deels of niet verwerkt kan worden.
• Een XIS biedt inzicht in herkomst van de ontvangen gegevens, en wanneer deze gegevens ontvangen zijn. Dit betreft concepten die meer technisch van aard zijn, maar voor de eenduidigheid en herleidbaarheid van de gegevens noodzakelijk zijn. Dit betreffen de metagegevens zoals gelogd door het XIS bij ontvangst van de gestuurde gegevens.

4.4 Systeemrol 'Sturen' (Persoonsdomein)

Hieronder volgt een generiek uitgangspunt voor de (pre-)kwalificatie van de systeemrol 'Sturen':

• Een PGO dient alle functionele data-elementen conform de dataset van de informatiestandaard succesvol te sturen naar een XIS.
• De PGO kan aantonen dat het een specifieke selectie van inhoudelijke gegevens succesvol kan sturen naar een XIS.
• Een PGO is in staat gelijktijdig meerdere gegevens (records) conform de dataset van de informatiestandaard te versturen naar een XIS.

5 Aansluiten op de simulator (Touchstone)

Nictiz stelt het testsysteem Touchstone beschikbaar voor het testen van systeemrollen met bijbehorende MedMij-gegevensdiensten als voorbereiding op het kwalificatieproces. MedMij-(kandidaat)deelnemers kunnen Touchstone eveneens gebruiken in de ontwikkel- en testfase voor het vroegtijdig testen en/of valideren van de FHIR berichten.

Voor het aansluiten op Touchstone is een aparte handleiding beschikbaar.

6 Leeswijzer

6.1 Opbouw testscripts

In de testscripts staan de scenario's in het hoofdstuk testscript, onder het kopje Overzicht scenario’s. Het overzicht beschrijft de set scenario's telkens met dezelfde kolomindeling:

• Nummer (Nr.)
• Scenario
• Doel van test
• Verwacht resultaat
• Inhoudelijke gegevens

6.1.1 Nummer (Nr.)

Deze kolom bevat de scenario-nummering. Aan de nummering is af te zien welke scenario's over hetzelfde onderwerp gaan.

6.1.2 Scenario

In deze kolom zijn alle scenario's van het betreffende script beschreven.
De beschrijving van het scenario kan ook aanvullende informatie en instructies bevatten.

6.1.3 Doel van test en Verwacht resultaat

De kolom 'doel van test' beschrijft wat er met het scenario wordt getest. In de kolom daarachter staat per staat scenario aangegeven wat het verwachte resultaat is en wat er moet worden getoond.

6.1.4 Inhoudelijke gegevens

Deze kolom bevat een omschrijving van de gegevens die gebruikt worden bij het uitvoeren van het scenario, bijvoorbeeld persoonsgegevens. Waar mogelijk is deze omschrijving ook een klikbare link naar de tabel met de daadwerkelijke gegevens zoals naam, adres en woonplaats.

6.2 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.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.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).

7 Pre-kwalificatie/testscripts per standaard

	MedMij editie 6	MedMij editie 5		MedMij editie 4
	6.1.4	2020.02	2020.01	2019.01
Pre-kwalificatie/testscripts
AllergieIntolerantie
Basisgegevens GGZ
Beelden
BgLZ
BgZ			BgZ Beschikbaarstellen
			BgZ Raadplegen
Dossierwijzigingsverzoek
eAfspraak
Huisartsgegevens
Laboratoriumresultaten
Medicatieproces
PDF/A
Vaccinatie-Immunisatie
Vragenlijsten
Zelfmetingen			Metingen Beschikbaarstellen
			Metingen Raadplegen
			Zelfmetingen Sturen
			Zelfmetingen Ontvangen
Gedeelde dependencies
MedMij functioneel ontwerp	1.0.2	2020.02	2020.01	2019.01
Zib-publicatie	2020	2017
FHIR-versie	R4	STU3
FHIR-package voor de zibs	nl-core 0.11.0-beta.1	Zib2017 2.2.18		Zib2017 1.3.19
MedMij FHIR IG	1.0.5	2020.02	2020.01	2019.01
MedMij-kwalificatiepagina	1.0.5	2020.02	2020.01	2019.01