MedMij:Vprepub-2020.01/Kwalificatie FAQ

Kwalificatie Proces

Wat is de gemiddelde doorlooptijd van een kwalificatie

Een kwalificatieslot start altijd op maandag.

De gemiddelde doorlooptijd voor zowel een DVP als DVZA kwalificatie bedraagt één werkweek.

Wanneer krijg ik terugkoppeling over mijn kwalificatie?

• Een DVP kwalificatie beslaat één werkweek en start altijd op maandag.
  • Indien het materiaal niet volledig is of er blokkerende punten zijn op technisch vlak (geen 100% score op de Touchstone testexecutie), wordt dat op maandag al teruggekoppeld.
  • Indien het materiaal volledig is en er geen blokkerende punten worden gevonden op technisch vlak, wordt het materiaal functioneel beoordeeld en vindt er uiterlijk vrijdag finale terugkoppeling plaats.
• Een DVZA kwalificatie beslaat één werkweek en start altijd op maandag.
  • In de week wordt het materiaal zowel functioneel als technisch (parallel) beoordeeld.
  • Indien het materiaal niet volledig is, wordt dat op maandag al teruggekoppeld. Er vindt geen technische en functionele beoordeling plaats.
  • Indien er op technisch vlak en/of functionele beoordeling blokkerende punten naar voren zijn gekomen, dan wordt dit op vrijdag teruggekoppeld.

Hoe moet ik de schermprinten aanleveren?

Op de kwalificatiepagina tref je de aanleverformaten onder het kopje kwalificatiebenodigdheden. In het aanleverformat wordt aangegeven of de screenshots per scenario of per sectie uit een scenario aangeleverd dienen te worden.

Wat is het verschil tussen een kwalificatie 1, kwalificatie 2, kwalificatie 3, etc.?

De kwalificatie 1 is het eerste toetsmoment en de kwalificatie 2 is het tweede toetsmoment. Indien je positief door de kwalificatie 1 heen komt, is er geen vervolg meer nodig voor dezelfde gegevensdienst. De kwalificatie 1 dient daarom niet gebruikt te worden als “oefenmoment” om het systeem functioneel of technisch te testen.

Normaliter spreken we een herstelperiode van één week af tussen de kwalificaties om alle fouten te herstellen. Mocht er behoefte zijn aan meer tijd om de blokkerende punten te herstellen, dan kan dat ingepland worden. Indien tijdens de kwalificatie niet alle blokkerende punten zijn opgelost dient er een nieuw kwalificatieslot aangevraagd te worden. We spreken dan over kwalificatie 2, 3 enzovoorts.

Ik heb mijn materiaal hersteld, kan ik het direct aanleveren?

Materiaal wordt beoordeeld in het geplande kwalificatieslot. Wanneer het materiaal eerder af is, dan kan het materiaal alvast worden ingediend. Wanneer er ruimte bij ons vrij komt zullen we het materiaal eerder in behandeling nemen. Maar hiervoor bieden wij geen garantie, die geven we wel voor het geplande slot.

Ik wil graag een (technisch) expert spreken over mijn kwalificatie of Touchstone. Hoe kan ik dat het snelst doen?

Het snelste kun je hen bereiken door een issue te loggen in  BITS, onder het project voor de MedMij-standaarden. Hier komt het direct bij de juiste experts terecht. Vragen rondom lopende kwalificaties kunnen ook gesteld worden via kwalificatie@medmij.nl.

Ik kan niet het volledige kwalificatiescript ondersteunen, wat nu?

Om veilige gegevensuitwisseling te kunnen garanderen is het van belang dat het volledige kwalificatiescript wordt ondersteund. Kun je hier niet aan voldoen, is het van belang dit ruim voorafgaand aan je kwalificatie te loggen via BITS, onder het project voor de MedMij-standaarden t.a.v. de informatiestandaard die je wil kwalificeren. Kaart je dit pas aan tijdens kwalificatie of wordt dit tijdens kwalificatie door de (technische) kwalificatiespecialist geconstateerd, zal dit leiden tot vertraging in het kwalificatieproces. Zie ook de procedurele eisen op de kwalificatiepagina.

Ik loop uit en ben bang dat ik mijn acceptatieslot niet ga redden, wat nu?

Kwalificatie is een voorwaarde voor Acceptatie. Zodra er vermoeden is van uitloop, wordt het aangeraden contact op te nemen met Acceptatie om de mogelijkheden te bespreken.

Ik ben een integrator en kan geen schermprinten aanleveren, wat nu?

Het doel van kwalificatie is: een betekenisvol oordeel vellen of een systeem de systeemrol conform de in de informatiestandaard gestelde eisen op juiste wijze ondersteunt. Zie ook onze factsheet voor DVZA kwalificaties.

Welke kwalificatiescripts moet ik doorlopen?

Van de actuele gegevensdiensten waarop gekwalificeerd kan worden, bestaan er meerdere MedMij versies. Hierbij is het belangrijk dat het kwalificatiescript gekozen wordt waarin het nummer staat dat overeenkomt met het MedMij versienummer waarop er gekwalificeerd wordt. Als je bijvoorbeeld kwalificeert op de BgZ 2020.01, dient het kwalificatiescript benaderd te worden vanuit de map waarin 2020.01 in de titel staat: Nictiz/FHIR3-0-2-MM202001-Cert. Wanneer er gebruik wordt gemaakt van het verkeerde script, kan het materiaal helaas niet meegenomen worden.

Functionele Kwalificatie

Waar vind ik de eisen terug?

Het is belangrijk alle functionele en technische eisen goed door te nemen en geïmplementeerd te hebben voorafgaand aan de kwalificatiepogingen. De eisen die gesteld worden, verschillen per gegevensdienst.

• Op de kwalificatiepagina staan de uitgangspunten en procedurele eisen voor kwalificatie. Hier vind je eveneens de addenda en de kwalificatiescripts.
• Voor een actueel overzicht van gegevensdiensten, met een verwijzing naar kwalificatie-informatie per systeemrol, raadpleeg de MedMij Catalogus. Via de catalogus kan doorgeklikt worden naar het functioneel ontwerp en technisch ontwerp per systeemrol.

Binnen de standaard wordt een oudere zibversie vereist, dan de laatste release van zibs. Mag een nieuwere versie van de zib worden geïmplementeerd?

• De informatiestandaarden die worden gebruikt binnen MedMij zijn gebaseerd op de 2017 publicatie van de zibs. Binnen MedMij wordt er niet op zibs maar op gegevensdiensten gekwalificeerd, die gebaseerd zijn op een informatiestandaard. Een gegevensdienst kan herkend worden aan de unieke systeemrolcode die eraan toe is gekend. Een overzicht van de actuele gegevensdiensten is terug te vinden in de MedMij Catalogus. Doordat er wordt gekwalificeerd op gegevensdiensten is de publicatie van de zibs die in een informatiestandaard worden gebruikt leidend. Zodoende zijn op dit moment alle gegevensdiensten die uitgaan van zibs gebaseerd op de 2017 publicatie. Wanneer een (kandidaat-)deelnemer ervoor kiest om een nieuwere versie van de zibs te implementeren moet er rekening mee worden gehouden dat deze niet compatibel zijn met de versies die vereist zijn voor uitwisseling binnen het afsprakenstelsel.

Hoe werkt de variabele T?

Voor veel 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.

De functionele testscripts beschrijven in de addenda testgegevens waarin datumvelden 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 T-datum wordt afgegeven 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 2021 is T datum in week 11 gelijk aan 15 maart 2021.

Hoe stel ik datum T in?

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 11 gelijk aan 15 maart 2021.

Hoe werken 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. 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.

Technische Kwalificatie

Het technisch op de juiste manier FHIR-berichten genereren, blijkt in de praktijk vaak niet bij de eerste kwalificatie goed te gaan en levert daarmee vertraging op in het kwalificatieproces. Om het kwalificatieproces soepeler te laten verlopen, is een overzicht gemaakt van fouten in de FHIR-berichten die het vaakst opduiken tijdens de technische kwalificatie. In het hieronder volgende overzicht wordt duidelijk gemaakt:

• Welke informatiestandaard wordt geraakt.
• Wat de fout betreft.
• Waar de fout doorgaans in het bericht te vinden is.
• De ernst van de fout (blokkerend betekent dat herkwalificatie nodig is).
• Uitleg over de fout met, waar mogelijk, links naar de relevante informatie en/of een stuk voorbeeldcode over wat verwacht wordt in de technische kwalificatie.

Het is sterk aan te raden om zelf voorafgaand aan de kwalificatie met behulp van deze tabel te controleren of FHIR-berichten correct worden gegenereerd. Bij verdere vragen kan een ticket worden ingeschoten in BITS op het MedMij-project.

Verder is het mogelijk om de technische kwalificatiesscripts ter naslagwerk in te zien. Deze zijn te vinden in de Nictiz-testscripts-repository op GitHub.

Disclaimer: de gegeven voorbeelden zijn in XML, dit kan in de praktijk ook JSON zijn.

Informatiestandaard	Veelvoorkomende fouten	Element	Blokkerend	Uitleg
Alle	De codesysteem-OID uit een zib wordt gebruikt om de URI voor .system mee te construeren	.coding.system	Ja	Het FHIR-profiel schrijft voor welke URI gebruikt dient te worden, zie MedMij:Vprepub-2020.01/FHIR IG#Code system URIs.
Alle, vanaf publicatie 2020.01	De server retourneert een lege Bundle als de resource niet wordt ondersteund	Bundle.resource	Ja	Als een niet-ondersteunde resource wordt bevraagd, dient de server een OperationOutcome te retourneren met not supported in .code. Zie de MedMij:Vprepub-2020.01/FHIR_IG#Handling_errors.
Alle	Resource.id ontbreekt	Resource.id	Ja, maar	Zie FHIR IG: when is id expected?
Alle	Bundle.entry.fullUrl en Resource.id zijn niet consistent	Resource.id	Ja, maar	Zie FHIR IG: fullUrls and references in Bundles Fout <!-- fullUrl met een foutieve AllergyIntolerance.id --> <entry> <fullUrl value="http://example.org/fhir/AllergyIntolerance/f9125272-8305-11ea-5462-020000000000"/> <resource> <AllergyIntolerance> <id value="allergy-01"/> -------- <!-- fullUrl met een foutieve Practitioner.id --> <entry> <fullUrl value="urn:oid:2.16.528.1.1007.3.3.2222"/> <resource> <Practitioner> <id value="practitioner-01"/> Goed <!-- --> <entry> <fullUrl value="http://example.org/fhir/AllergyIntolerance/f9125272-8305-11ea-5462-020000000000"/> <resource> <AllergyIntolerance> <id value="f9125272-8305-11ea-5462-020000000000"/> -------- <!-- --> <entry> <fullUrl value="urn:oid:2.16.528.1.1007.3.3.2222"/> <resource> <Practitioner> <id value="2.16.528.1.1007.3.3.2222"/>
Alle	Bundle.entry.fullUrl mag niet een relatieve URL zijn	Bundle.entry.fullUrl	Ja	Indien Bundle.entry.fullUrl URL's zijn, moeten deze absoluut zijn en niet relatief. De references binnen een resource mogen wel relatief te zijn als dit een URL is. Verwacht in fullUrl is een absolute URL, een UUID of een OID. Zie https://www.hl7.org/fhir/STU3/bundle-definitions.html#Bundle.entry.fullUrl https://www.hl7.org/fhir/STU3/bundle.html#bundle-unique https://www.hl7.org/fhir/STU3/bundle.html#references" <!-- Bijvoorbeeld --> <entry> <fullUrl value="urn:oid:2.16.840.1.113883.2.4.6.6.90000258.4.6.525"/>
Alle	Gerefereerde resources worden als contained resource opgeleverd		Ja, tenzij	Contained resources worden gebruikt wanneer deze resources niet zelfstandig kunnen bestaan, of wanneer de standaard dit voorschrijft (dit laatste is het geval bij PDF/A). Het is geen oplossing voor resources waarvan de server geen stabiele URL kan opleveren. Zie FHIR IG: Including referenced resources
Alle	FHIR-resources bevatten niet alle in het script gevraagde informatie		Ja, maar	Voor kwalificatie doeleinden is het verplicht om alle informatie zoals vermeld in het addendum, mee te geven in het FHIR-bericht of te tonen in de user interface. FHIR-profielen maken het mogelijk dat bepaalde informatie niet in alle gevallen bekend is en dwingen dus weinig af. Bij kwalificatie echter is de informatie wel bekend via het kwalificatiescript. Uitzonderingen kunnen gemaakt worden, bijvoorbeeld indien een XIS een bepaalde zib of data-element niet ondersteund. Per item dient dit voorafgaand kwalificatie te worden besproken en gewogen. https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2019.01_Kwalificatie#Kwalificatie_scripts
Alle	FHIR-resources valideren niet tegen het verwachte profiel		Ja	Controleer voor elk profiel in Simplifier of alle verplichte elementen zijn meegenomen. Deze verplichte elementen hoeven niet altijd onderdeel te zijn van het addendum. De validator in Touchstone geeft hier naar alle waarschijnlijkheid een foutmelding over, maar hoeft niet te resulteren in een gefaalde test. Let daarom goed op of de test een 'w' voor warning oplevert. Bij onduidelijkheid omtrent de waarschuwing kan een ticket in BITS worden aangemaakt.
Alle	Datatype Reference, Coding of CodeableConcept mist display	Meerdere elementen per resource mogelijk	Ja	Bij elke reference en CodeableConcept is een display value verplicht. Zie hiervoor de specificaties van het reference datatype in MedMij: https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2019.01_FHIR_IG#Use_of_the_reference_datatype https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2019.01_FHIR_IG#Use_of_coded_concepts <generalPractitioner> <reference value="Organization/nl-core-organization-01"/> <display value="Maatschap Vaste Huisarts"/> </generalPractitioner>
Alle	Extensie code-specification waarin de zibwaarde staat, ontbreekt	Meerdere elementen per resource mogelijk	Ja, op plaatsen waar de mapping niet 1-op-1 is	De extensie code-specification is bedoeld voor het meegeven van de oorspronkelijke zibwaarde als de FHIR-resource dat op die plaats niet direct toelaat. Dat zijn vaak statuscodes waarvoor FHIR zelf verplichte terminologie heeft. Om geen zibinformatie kwijt te raken, bijvoorbeeld omdat de mapping op de FHIR codes niet geheel 1-op-1 is, is meegeven van de zibwaarde dus van belang. Bijvoorbeeld: gender (https://zibs.nl/wiki/Patient-v3.1(2017NL)), adres (soort, landcode, nummergebruik https://zibs.nl/wiki/Adresgegevens-v1.0(2017NL), naam (use, https://zibs.nl/wiki/Naamgegevens-v1.0.1(2017NL)) en eventueel andere. <gender value="male"> <extension url="http://nictiz.nl/fhir/StructureDefinition/code-specification"> <valueCodeableConcept> <coding> <system value="http://hl7.org/fhir/v3/AdministrativeGender"/> <code value="M"/> <display value="Man"/> </coding> </valueCodeableConcept> </extension> </gender>
Alle	Burgerservicenummer mag niet worden gebruikt in query en/of resources		Ja	Het MedMij-afsprakenstelsel definieert op basis van vigerende wetgeving dat burgerservicenummers niet mogen worden uitgewisseld. Uitzondering vormen plaats waar het onredelijk of onmogelijk is om te eisen dat deze worden verwijderd, zoals in een PDF-document. Gebruik in query-parameters zoals patient of subject, in een Bundle.link, als Patient.id, Patient.identifier en andere gestructureerde locaties op basis van BSN is niet toegestaan.
Alle	Resource.text ontbreekt. Ook bekend als Narrative	Resource.text	Ja, maar	Resource.text is SHOULD en moet dan een klinisch relevante/veilige samenvatting bieden van hetgeen in de resource staat. Om discussie te voorkomen over wat wel of niet klinisch relevant is, wordt geadviseerd om alle elementen uit het bericht, toe te voegen aan de narrative. Een ontvanger MAG deze gebruiken om te tonen. Slechts in een enkel geval zoals bij conformance resources (StructureDefinition, ValueSet etc.) een text element met status empty te gebruiken. Uitzondering op dit alles is de contained resource. Deze MAG GEEN text hebben. Zie https://www.hl7.org/fhir/STU3/domainresource-definitions.html#DomainResource.text https://www.hl7.org/fhir/STU3/narrative.html
Alle	FHIR server heeft geen CapabilityStatement, of kan deze niet opleveren met de verwachte minimale inhoud bij de informatiestandaard		Ja	Geen CapabilityStatement beschikbaar op het /metadata endpoint. Dit is een SHALL vanuit de FHIR spec: https://www.hl7.org/fhir/stu3/http.html#2.21.0
Alle	Bundle van type searchset moet Bundle.link bevatten	Bundle.link	Ja	Bundle.link heeft een SHALL in de FHIR spec, zie voor meer informatie: http://hl7.org/fhir/STU3/bundle-definitions.html#Bundle.link https://www.hl7.org/fhir/stu3/search.html#conformance <link> <relation value="self"/> <url value="http://nictiz.wildfhir.org/fhir3-i2/AllergyIntolerance?"/> </link>
Alle	HumanName mist extensies voor het identificeren van de verschillende naamdelen	HumanName.family	Ja	Bij HumanName.family wordt een extensie verwacht die extra informatie geeft over de naamdelen, zoals voorgeschreven door de zib. https://zibs.nl/wiki/Naamgegevens-v1.0.1(2017NL) https://simplifier.net/NictizSTU3-Zib2017/nl-core-humanname <family value="Jongeneel-de Haas"> <extension url="http://hl7.org/fhir/StructureDefinition/humanname-own-name"> <valueString value="Jongeneel"/> </extension> <extension url="http://hl7.org/fhir/StructureDefinition/humanname-partner-prefix"> <valueString value="de "/> </extension> <extension url="http://hl7.org/fhir/StructureDefinition/humanname-partner-name"> <valueString value="Haas"/> </extension> </family> <given value="Irma"> <extension url="http://hl7.org/fhir/StructureDefinition/iso21090-EN-qualifier"> <valueCode value="CL"/> </extension> </given> <given value="I."> <extension url="http://hl7.org/fhir/StructureDefinition/iso21090-EN-qualifier"> <valueCode value="IN"/> </extension> </given>
Alle	Address mist extensies voor het identificeren van de verschillende adresdelen	Address.line	Ja	Bij Address.line wordt een extensie verwacht die gebruikt wordt om elk specifiek onderdeel van het Address de kunnen onderscheiden, zoals voorgeschreven door de zib. https://zibs.nl/wiki/Adresgegevens-v1.0(2017NL) https://simplifier.net/NictizSTU3-Zib2017/nl-core-address <address> <extension url="http://fhir.nl/fhir/StructureDefinition/nl-core-address-official"> <valueBoolean value="true"/> </extension> <use value="home"/> <type value="both"/> <line value="Straatweg 12bII"> <extension url="http://hl7.org/fhir/StructureDefinition/iso21090-ADXP-streetName"> <valueString value="Straatweg"/> </extension> <extension url="http://hl7.org/fhir/StructureDefinition/iso21090-ADXP-houseNumber"> <valueString value="12"/> </extension> <extension url="http://hl7.org/fhir/StructureDefinition/iso21090-ADXP-buildingNumberSuffix"> <valueString value="bII"/> </extension> </line>
PDF/A	Onjuist gebruik of afwezigheid identifier en/of masteridentifier	resource.masterIdentifier of resource.Identifier	Ja	De DocumentManifest.masterIdentifier en DocumentReference.masterIdentifier dienen door het XIS zelf te worden gegeneerd, met een eigen system. De .masterIdentifier is de versie specifieke identifier waar de .identifier een versie onafhankelijke identifier kan zijn (https://www.hl7.org/fhir/stu3/documentmanifest-definitions.html#DocumentManifest.masterIdentifier)