MedMij:Vprepub-2020.01/Kwalificatie FAQ
|
|
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 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?
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?
Ik wil graag een (technisch) expert spreken over mijn kwalificatie of Touchstone. Hoe kan ik dat het snelst doen?
Ik kan niet het volledige kwalificatiescript ondersteunen, wat nu?
Ik loop uit en ben bang dat ik mijn acceptatieslot niet ga redden, wat nu?
Ik ben een integrator en kan geen schermprinten aanleveren, wat nu?
Welke kwalificatiescripts moet ik doorlopen?
Functionele Kwalificatie
Waar vind ik de eisen terug?
- 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 <!-- 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:
<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) |