MedMij:Vprepub-2020.01/Kwalificatie FAQ

Uit informatiestandaarden
< MedMij:Vprepub-2020.01
Versie door Ahenket (overleg | bijdragen) op 25 aug 2020 om 08:34 (Correctie van 2019.01 links naar 2020.01 links)
Naar navigatie springen Naar zoeken springen

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.

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.

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.
  • Het Register van Informatiestandaarden bevat de binnen het MedMij-afsprakenstelsel toegelaten informatiestandaarden. Via het register kan doorgeklikt worden naar het functioneel ontwerp en technisch ontwerp per informatiestandaard.

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 standaarden voor MedMij zijn inderdaad gebaseerd op de zibversie 2017 release. Binnen MedMij wordt niet op zibs maar op informatiestandaarden gekwalificeerd. Daarom zijn de zibs die in een standaard worden gebruikt leidend.
  • Het advies is om zibs versie 2017 in te bouwen, omdat deze momenteel ondersteund worden in het MedMij-afsprakenstelsel. 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 oudere 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 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.

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 46 gelijk aan 11 november 2019.

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 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=35135"