1 Introductie

Op MedMij informatiestandaarden met bijbehorende gegevensdiensten zijn Nictiz kwalificaties van toepassing. Kwalificaties vinden plaats per systeemrol. Een systeemrol(code) is gebaseerd op de informatiestandaard inclusief versie, de transactie en uitwisselingsstandaard.

Kwalificatiescripts en meer informatie over een kwalificatie is te vinden via de betreffende paragrafen op de kwalificatiepagina.

2 Algemene voorwaarden voor kwalificatie

[DRAFT] [status: check bij lead overleg] Onderstaand zijn de beoordelingskaders beschreven waarbij is aangegeven waar een MedMij kandidaat-deelnemer kennis en begrip van moet hebben om te kunnen kwalificeren.

2.1 Inhoudelijke eisen

2.1.1 Beoordelingskader specifieke eisen

2.1.1.1 Beoordelingskader 1:

DVP: een DVP is in staat zijn alle informatie behorende bij een gegevensdienst, conform het testscript, te verwerken en op te slaan. Dit betekent voor de transactie “sturen” dat functionele gegevens getoond en verstuurd worden. Dit betekent voor “raadplegen” dat de functionele gegevens getoond en opgeslagen worden.

DVZA: een DVZA is in staat zijn alle informatie behorende bij een gegevensdienst, conform het addenda, te verwerken en op te slaan. Dit betekent voor de transactie “beschikbaarstellen” dat functionele gegevens getoond en verstuurd worden. Dit betekent voor “ontvangen” dat de functionele gegevens getoond en opgeslagen worden.

Voor elke gegevensdienst is een Addendum aanwezig waarin beschreven staat welke functionele data-elementen bestaande uit concept-labels en waardes moeten worden opgeslagen en daarnaast getoond of verstuurd. Op de kwalificatiepagina staat van elke gegevensdienst het bijbehorende Addendum. Het Addendum is een representatie van hetgeen wat door Touchstone wordt uitgestuurd met bijbehorende informatie die door referenties wordt opgehaald. Referenties worden gebruikt om de betekenis, verbanden en eventuele synoniemen en vertalingen van gegevenselementen vast te leggen. Het is noodzakelijk om begrip te hebben over het toepassen van referenties zodat gezondheidsinformatie vanuit het ene systeem dezelfde betekenis blijft houden wanneer deze met een ander systeem wordt uitgewisseld. Het is sterk afgeraden om zelf termen te vertalen omdat vertaalfouten tot serieuze problemen in het medisch terminologiestelsel kunnen leiden.

2.1.1.2 Beoordelingskader 2:

Een DVP en een DVZA moeten voldoen aan de functionele eisen van de betreffende gegevensdienst (indien van toepassing).

Hiervoor is voor elke informatiestandaard met bijbehorende gegevensdiensten een functioneel ontwerp aanwezig en is gespecificeerd per use-case. Deze geeft uitgebreide achtergrondinformatie over de algemene werking van de informatiestandaard, met specifieke praktijksituaties. Voor een concrete situatie is het vastleggen en uitwisselen van informatie beschreven aan de hand van actoren (mensen, systemen) en transacties (welke informatie wordt wanneer uitgewisseld).

2.1.1.3 Beoordelingskader 3:

Een DVP en een DVZA is in staat technisch correcte berichten te sturen en te ontvangen.

Hiervoor is voor elke informatiestandaard met bijbehorende gegevensdiensten een technisch ontwerp oftewel de “MedMij FHIR Implementation Guide” aanwezig en is gespecificeerd per use-case. FHIR is de technische uitwisselingsstandaard waar de MedMij informatiestandaarden op gebaseerd zijn. Het technisch ontwerp geeft uitgebreide technische FHIR-gerelateerde achtergrondinformatie over de werking van een DVP met betrekking tot de betreffende informatiestandaard.
Voor het testen van gegevensdiensten, als voorbereiding op het kwalificatieproces en tevens om door de technische beoordeling te komen van een kwalificatie, is het testsysteem AEGIS/Touchstone beschikbaar. Voordat men een gegevensdienst aanlevert ter kwalificering, moet men het script hiervan draaien om te kijken of het succesvol is. Andere algemene Touchstone gerelateerde opmerkingen staan op de kwalificatiepagina onder het kopje “Gebruik van de simulator”. Het is van uiterst belang dat een leverancier hier kennis en begrip van heeft, het betreft namelijk punten aangaande alle beoordelingskaders.

2.1.2 Beoordelingskader specifieke eisen

Beoordelingskader onafhankelijk dient een leverancier kennis en begrip te hebben van het kwalificatiescript. Het kwalifcatiescript bevat de te doorlopen scripts bij kwalificatie van een bepaalde use-case en gegevensdienst en verdere informatie rondom hetgeen wat beoogd wordt te realiseren in een bepaalde gegevensdienst.

2.2 Procedurele eisen

Naast bovengenoemde inhoudelijke eisen moet men ook voldoen aan procedurele eisen om te kunnen kwalificeren.

Streef ernaar om de Touchstone certification executie niet meer dan een week voor de maandag van het (pre)kwalificatie slot uit te voeren. Nictiz staat in zijn recht om te bepalen of een test executie is verouderd en daarom af te wijzen. Om het kwalificatie traject niet onnodig te vertragen wordt er dus van leveranciers geacht om bovengenoemde richtlijn te handhaven.
Het kwalificatiemateriaal moet in het juiste formaat worden aangeleverd. Gebruik daarom voor het aanleveren van het kwalificatiemateriaal altijd het aanleverformaat wat hoort bij de gegevensdienst waarvoor men wil kwalificeren. In het aanleverformaat staat per slide beschreven wat wordt verwacht. Het hoofdonderdeel van het benodigde kwalificatiemateriaal zijn schermafdrukken.

Voor een DVP geldt dat er schermafdrukken moeten worden gemaakt van de interface van een PGO. Een DVZA wordt geacht om schermafdrukken aan te leveren van de combinatie van de achterliggende bronsystemen waarmee men kwalificeert. Wanneer men voor een nieuwe combinatie van bronsystemen acht te kwalificeren wordt dit behandeld als een nieuwe kwalificatie waarbij dus ook van die nieuwe combinatie schermafdrukken moeten worden gemaakt. schermafdrukken van andere interfaces zoals van een XDS worden afgekeurd. Voor zowel DVP’s én DVZA’s geldt dat schermafdrukken moeten overeenkomen met de Touchstone certification executie die is bijgevoegd in het kwalificatiemateriaal. Wanneer hier niet aan wordt voldaan leidt dit tot afwijzing.

3 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.

3.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 dat gegevens technisch niet beschikbaar gesteld kan worden.

3.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.

4 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

5 Gebruik van de simulator

In de volgende secties zijn aandachtspunten beschreven over de simulator omgeving Touchstone.

5.1 Authorization tokens

Voor uitleg over gebruik van de simulator en tokens, zie MedMij:V2019.01_Qualification

5.2 Variable T datum

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 de PGO te registreren.

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 2020 is de T datum in week 2 gelijk aan 6 januari 2020.

5.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.

5.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.

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.

5.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 Kwalificatiebenodigdheden

6.1 Basisgegevensset Zorg 2.1

6.1.1 DVP

Transactie: raadplegen

6.1.2 DVZA

Transactie: beschikbaarstellen

6.2 Labuitwisseling 1.1

6.2.1 DVP

Transactie: raadplegen

6.2.2 DVZA

Transactie: beschikbaarstellen

6.3 Medicatieproces 9.0

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

MedMij:Vsuperdraft Kwalificatie

1 Introductie

2 Algemene voorwaarden voor kwalificatie

2.1 Inhoudelijke eisen

2.1.1 Beoordelingskader specifieke eisen

2.1.1.1 Beoordelingskader 1:

2.1.1.2 Beoordelingskader 2:

2.1.1.3 Beoordelingskader 3:

2.1.2 Beoordelingskader specifieke eisen

2.2 Procedurele eisen

3 Uitgangspunten voor kwalificatie

3.1 Systeemrol 'Raadplegen' (PGO)

3.2 Systeemrol 'Beschikbaarstellen' (XIS)

4 Kwalificatie aansluiten op de kwalificatieomgeving

5 Gebruik van de simulator

5.1 Authorization tokens

5.2 Variable T datum

5.2.1 Kwalificatie test gegevens

5.2.2 Parameters in de request URL's

5.2.3 Tijdnotatie

6 Kwalificatiebenodigdheden

6.1 Basisgegevensset Zorg 2.1

6.1.1 DVP

6.1.2 DVZA

6.2 Labuitwisseling 1.1

6.2.1 DVP

6.2.2 DVZA

6.3 Medicatieproces 9.0

6.3.1 Medicatiegegevens

6.3.1.1 DVP

6.3.2 Medicatieoverzicht

6.3.2.1 DVP

6.3.3 Verstrekkingenvertaling

6.3.3.1 DVP

6.3.3.2 DVZA

6.4 AllergieIntolerantie 2.0

6.4.1 AllergieIntolerantie

6.4.1.1 DVP

6.4.1.2 DVZA

6.4.2 AllergieIntolerantieVertaling

6.4.2.1 DVP

6.4.2.2 DVZA

6.5 eAfspraak 1.1

6.5.1 DVP

6.5.2 DVZA

6.6 Zelfmetingen 1.2

6.6.1 DVP

6.6.2 DVZA

6.7 PDF/A 2.0

6.7.1 DVP

6.7.2 DVZA

6.8 Huisartsgegevens 1.1

6.8.1 DVP

6.8.2 DVZA

6.9 Basisgegevens GGZ 1.1

6.9.1 DVP

6.9.2 DVZA

6.10 Beelden 1.0

6.10.1 DVP

6.10.2 DVZA

6.11 Basisgegevens Langdurige Zorg 1.0

6.11.1 DVP

6.11.2 DVZA

Navigatiemenu

Zoeken