MedMij:Vprepub-2020.01/Kwalificatie FAQ

Uit informatiestandaarden
< MedMij:Vprepub-2020.01
Versie door Narin Esmaeel (overleg | bijdragen) op 18 mrt 2021 om 13:00 (MM-1553: Toevoeging informatie over het correct gebruik van de kwalificatiescripts Duidelijkere verwijzing naar contactmogelijkheden binnen het kwalificatieproces en verdere verduidelijking van het proces)
Naar navigatie springen Naar zoeken springen

Issue icon.png

Dit is een werkpagina.

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

Kwalificatie Proces

Wat is de gemiddelde doorlooptijd van een (pre-)kwalificatie

Een kwalificatieslot start altijd op maandag.

De gemiddelde doorlooptijd voor een DVP kwalificatie bedraagt één werkweek en voor een DVZA twee werkweken.

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 twee werkweken en start altijd op maandag.
    • In de eerste week wordt het materiaal technisch beoordeeld en indien deze positief is bevonden, vindt de functionele beoordeling plaats in week twee.
    • Indien het materiaal niet volledig is, wordt dat op maandag in de eerste week al teruggekoppeld. Er vindt geen technische en functionele beoordeling plaats.
    • Indien er op technisch vlak blokkerende punten zijn wordt dit op vrijdag in de eerste week teruggekoppeld. Er vindt geen functionele beoordeling plaats.
    • Indien er op technisch vlak geen blokkerende punten zijn wordt de functionele beoordeling uitgevoerd en vindt terugkoppeling plaats op vrijdag in de tweede week.

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 pre-kwalificatie, kwalificatie, kwalificatie 2 etc.?

De termen pre-kwalificatie, kwalificatie, kwalificatie 2, etc. zijn arbitrair. De pre-kwalificatie is het eerste toetsmoment en de kwalificatie het tweede toetsmoment. Indien je positief door de pre-kwalificatie heen komt, is er geen vervolg meer nodig voor dezelfde gegevensdienst. De pre-kwalificatie is dus gelijk aan de kwalificatie en dient 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 pre-kwalificatie en kwalificatie 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?

Nee, dat kan niet. Om er zeker van te zijn dat we het materiaal kunnen ontvangen en volgens de procedurele afspraken kunnen beoordelen, kan het materiaal alleen worden aangeleverd indien er een kwalificatieslot gepland staat. Afwijken hiervan kan alleen in overleg met en na akkoord van het kwalificatiecentrum.

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.

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:V2020.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:V2020.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 

<!-- Bijvoorbeeld -->
<entry>
    <fullUrl value="urn:oid:2.16.840.1.113883.2.4.6.6.90000258.4.6.525"/>
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: 
<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
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: 
<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. 
<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)
Overgenomen van "https://informatiestandaarden.test-nictiz.nl/index.php?title=MedMij:Vprepub-2020.01/Kwalificatie_FAQ&oldid=55041"