MedMij:Vsuperdraft Kwalificatie: verschil tussen versies

Uit informatiestandaarden
Naar navigatie springen Naar zoeken springen
(3 generiekere punten toegevogd (bullets 1,2 en 4))
k (Algemene voorwaarden)
 
(34 tussenliggende versies door 3 gebruikers niet weergegeven)
Regel 7: Regel 7:
 
=Introductie=
 
=Introductie=
 
<section begin=medmij_kwalificatie_introductie />
 
<section begin=medmij_kwalificatie_introductie />
−
Op MedMij informatiestandaarden met bijbehorende gegevensdiensten zijn Nictiz kwalificaties van toepassing. Kwalificaties vinden plaats per [[MedMij:Register_van_informatiestandaarden|systeemrol]]. Een systeemrol implementeert een stuk functionaliteit zoals gedefinieerd in de informatiestandaard en heeft een systeemrolcode, de transactie en uitwisselingsstandaard.
+
Op MedMij informatiestandaarden met bijbehorende gegevensdiensten zijn Nictiz kwalificaties van toepassing.  
 +
 
 +
Kwalificaties vinden plaats per [[MedMij:Register_van_informatiestandaarden|systeemrol]]. Deze vormt de koppeling van een MedMij informatiestandaard aan een, in de catalogus vermelde, gegevensdienst. Deze kwalificaties worden uitgevoerd door Nictiz.
  
 
Kwalificatiescripts en meer informatie over een kwalificatie is te vinden via de betreffende paragrafen onder [[MedMij:Vsuperdraft_Kwalificatie#Kwalificatiebenodigdheden|kwalificatiebenodigdheden]].<section end=medmij_kwalificatie_introductie />
 
Kwalificatiescripts en meer informatie over een kwalificatie is te vinden via de betreffende paragrafen onder [[MedMij:Vsuperdraft_Kwalificatie#Kwalificatiebenodigdheden|kwalificatiebenodigdheden]].<section end=medmij_kwalificatie_introductie />
 +
=Algemene voorwaarden voor kwalificatie=
 +
Een leverancier kan starten met een kwalificatie, als hij voldoet aan onderstaande voorwaarden:
 +
# Kennis en begrip van MedMij afsprakenstelsel.
 +
# Kennis over de te gebruiken infrastructuur of het netwerk waarover uitgewisseld wordt en de toegang daartoe, inclusief authenticatie/autorisatie etc.
 +
# Kennis en begrip van de betreffende MedMij informatiestandaard, zoals beschreven op de informatiestandaarden wiki van Nictiz.
 +
# Kennis en begrip en het kunnen toepassen van de verschillende tabellen, waardenlijsten en andere referenties die de informatiestandaard gebruikt.
 +
# Kennis en begrip en het naleven van de aandachtspunten zoals beschreven in het document '''2. Addenda - Kwalificaties''' als bijlage bij de betreffende informatiestandaard.
 +
# Alle gegevens die de kwalificerende partij zelf moet invoeren zijn te vinden in de kwalificatiedocumentatie. Onjuist ingevoerde gegevens (ook tijd/datum etc.) zullen leiden tot vertraging van en kunnen blokkerend zijn voor het kwalificatieproces.
 +
# '''Inhoudelijke informatie, beschreven in de informatiestandaard, moet altijd toegankelijk zijn voor de eindgebruiker. De leverancier levert voor deze informatie schermafdrukken op voor controle.'''
 +
# Deze kwalificatie toetst geen infrastructurele eisen.
 +
 +
=Algemene eisen voor kwalificatie=
 +
Onderstaand zijn de beoordelingskaders beschreven waarbij is aangegeven waar een MedMij (kandidaat-)deelnemer kennis en begrip van dient te hebben om te kunnen kwalificeren naast de bijbehorende algemene uitgangspunten die beschreven zijn in paragraaf drie "Uitgangspunten voor kwalificatie". Daarnaast worden de procedurele eisen beschreven waar men ook aan dient te voldoen om te kunnen kwalificeren.
  
−
=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.
 
 
==Inhoudelijke eisen==
 
==Inhoudelijke eisen==
 
===Beoordelingskader specifieke eisen===
 
===Beoordelingskader specifieke eisen===
Regel 21: Regel 33:
 
'''DVZA:''' een DVZA is in staat alle informatie behorende bij een gegevensdienst, conform het testscript, 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.     
 
'''DVZA:''' een DVZA is in staat alle informatie behorende bij een gegevensdienst, conform het testscript, 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 via de referenties in de gegevens. 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 wordt sterk afgeraden om zelf termen te vertalen omdat vertaalfouten tot serieuze problemen in klinische of administratieve interpretatie kunnen leiden.
+
''DVP en DVZA''
 +
* 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. 
 +
* Voor elke informatiestandaard met bijbehorende gegevensdiensten is een '''functioneel ontwerp''' aanwezig waarin de use cases worden gespecificeerd. Deze geeft uitgebreide achtergrondinformatie over de algemene werking van de informatiestandaard.
 +
 
 +
''DVZA specifiek''
 +
* Voor elke gegevensdienst is een '''addendum''' aanwezig waarin beschreven staat welke functionele data-elementen bestaande uit concept-labels en waardes dienen te worden verstuurd naar Touchstone.
  
 
====Beoordelingskader 2:====
 
====Beoordelingskader 2:====
−
Een '''DVP''' en een '''DVZA''' moeten voldoen aan de functionele eisen van de betreffende gegevensdienst.
+
Een '''DVP''' en een '''DVZA''' dienen te voldoen aan de functionele eisen van de betreffende gegevensdienst.
−
* Hiervoor is voor elke informatiestandaard met bijbehorende gegevensdiensten een functioneel ontwerp aanwezig waarin de use cases worden gespecificeerd. 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).  
+
 
 +
''DVP en DVZA''
 +
* Hiervoor is voor elke informatiestandaard met bijbehorende gegevensdiensten een functioneel ontwerp aanwezig waarin de use cases worden gespecificeerd. Deze geeft uitgebreide achtergrondinformatie over de algemene werking van de informatiestandaard. 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).  
  
 
====Beoordelingskader 3:====
 
====Beoordelingskader 3:====
 
Een '''DVP''' en een '''DVZA''' is in staat technisch correcte berichten te sturen en te ontvangen.   
 
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 waarin 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 Touchstone beschikbaar. Voordat men een gegevensdienst aanlevert ter kwalificatie, moet men het script hiervan succesvol kunnen doorlopen. Andere algemene Touchstone gerelateerde opmerkingen staan op de kwalificatiepagina onder het kopje “Gebruik van de simulator”. Het is van groot belang dat een leverancier hier kennis en begrip van heeft, het betreft namelijk punten aangaande alle beoordelingskaders.
 
  
−
===Beoordelingskader onafhankelijke eisen===
+
''DVP en DVZA''
−
 
+
* Hiervoor is voor elke informatiestandaard met bijbehorende gegevensdiensten een technisch ontwerp oftewel de “MedMij FHIR Implementation Guide” aanwezig waarin 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.
−
Onafhankelijk van het beoordelingskader 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.
 
  
 
==Procedurele eisen==
 
==Procedurele eisen==
−
Naast bovengenoemde '''inhoudelijke eisen''' moet men ook voldoen aan '''procedurele eisen''' om te kunnen kwalificeren.  
+
Naast bovengenoemde '''inhoudelijke eisen''' dient men ook te voldoen aan '''procedurele eisen''' om te kunnen kwalificeren.  
  
 
* Streef ernaar om het certificering-testscript - ook bekend als ''test executie'' - Touchstone 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 kwalificatietraject niet onnodig te vertragen wordt er dus van leveranciers geacht om genoemde richtlijn te handhaven.   
 
* Streef ernaar om het certificering-testscript - ook bekend als ''test executie'' - Touchstone 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 kwalificatietraject niet onnodig te vertragen wordt er dus van leveranciers geacht om genoemde 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.  
+
* Wanneer niet kan worden voldaan aan de functionele en/of technische eisen van een gegevensdienst, dient dit te worden aangegeven voorafgaand aan een kwalificatie. Dit voorkomt onnodige vertraging.
−
Voor een DVP geldt dat er schermafdrukken moeten worden gemaakt van de interface van een PGO.  
+
* Het kwalificatiemateriaal dient 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.  
−
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 een DVP geldt dat er schermafdrukken dienen te worden gemaakt van de interface van een PGO.  
−
Voor zowel DVP’s én DVZA’s geldt dat schermafdrukken moeten overeenkomen met de Touchstone test executie die is bijgevoegd in het kwalificatiemateriaal. Wanneer hier niet aan wordt voldaan leidt dit tot afwijzing.
+
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 dienen te worden gemaakt. schermafdrukken van andere interfaces zoals van een XDS worden afgekeurd.  
 +
Voor zowel DVP’s én DVZA’s geldt dat schermafdrukken dienen te overeenkomen met de Touchstone test executie die is bijgevoegd in het kwalificatiemateriaal. Wanneer hier niet aan wordt voldaan leidt dit tot afwijzing.
  
 
=Uitgangspunten voor kwalificatie=
 
=Uitgangspunten voor kwalificatie=
Regel 52: Regel 69:
 
<section begin=Uitgangspunten_Systeemrol_Raadplegen />
 
<section begin=Uitgangspunten_Systeemrol_Raadplegen />
 
* De set van de gegevensdienst is bewust als één geheel vastgesteld. Daarvoor kwalificeer je wel/niet binnen de MedMij context.  
 
* De set van de gegevensdienst is bewust als één geheel vastgesteld. Daarvoor kwalificeer je wel/niet binnen de MedMij context.  
−
* Een PGO raadpleegt altijd de gehele gegevensdienst en daarmee dus alle secties (altijd alle FHIR searches).
+
* Een DVP dient alle functionele data-elementen conform de dataset van de informatiestandaard te tonen aan de gebruiker. De uitzonderingen per gegevensdienst zijn beschreven in de bijbehorende functionele ontwerpen.
−
* 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 als gegevens technisch niet beschikbaar gesteld kunnen worden.<section end=Uitgangspunten_Systeemrol_Raadplegen />
+
* Een DVP biedt de gebruiker inzicht in de ontvangen respons. Als er géén gegevens beschikbaar gesteld worden, kan dat zijn omdat er geen informatie beschikbaar is bij de DVZA of vanwege een technische foutmelding. Er volgt bijvoorbeeld een foutmelding indien de resource, een specifieke zib, niet wordt ondersteund in het bronsysteem. Het is een belangrijk inzicht voor de gebruiker als gegevens technisch niet beschikbaar gesteld kunnen worden.<section end=Uitgangspunten_Systeemrol_Raadplegen />
 
* Bij de betreffende systeemrol wordt gebruik gemaakt van losse queries en niet van bundeling als batch, onder andere om aan performance bezwaren tegemoet te komen.
 
* Bij de betreffende systeemrol wordt gebruik gemaakt van losse queries en niet van bundeling als batch, onder andere om aan performance bezwaren tegemoet te komen.
  
 
==Systeemrol 'Beschikbaarstellen' (DVZA)==
 
==Systeemrol 'Beschikbaarstellen' (DVZA)==
 
Hieronder volgen de generieke uitgangspunten voor de kwalificatie van de systeemrol 'Beschikbaarstellen':  
 
Hieronder volgen de generieke uitgangspunten voor de kwalificatie van de systeemrol 'Beschikbaarstellen':  
−
<section begin=Uitganspunten_Systeemrol_Beschikbaarstellen />
+
<section begin=Uitgangspunten_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.   
+
* Een DVZA dient de gehele gegevensdienst te ondersteunen. Uitzonderingen worden toegelicht in het bijbehorende functionele ontwerpen en kwalificatiescript.
−
 
+
* DVZA geeft technisch correct antwoord op alle searches ongeacht of de gegevens in de bronsystemen beschikbaar zijn. DVZA 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:
+
* Mochten gegevens niet beschikbaar gesteld kunnen worden, dan is uit de respons naar de raadpleger te herleiden waardoor dit veroorzaakt wordt:
 
**veroorzaakt door het ontbreken van de informatie
 
**veroorzaakt door het ontbreken van de informatie
−
**veroorzaakt doordat het XIS dit technisch niet kan leveren.   
+
**veroorzaakt doordat het bronsysteem 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.  
+
* In het geval dat een vraag om gegevens goed wordt verwerkt door de DVZA, 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 de DVZA 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.<section end=Uitganspunten_Systeemrol_Beschikbaarstellen />
+
* Als er technisch iets niet goed gaat, stuurt de DVZA 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 bronsysteem. Deze moet ingebouwd worden door het bronsysteem. Hierop wordt de DVZA ook gekwalificeerd.<section end=Uitgangspunten_Systeemrol_Beschikbaarstellen />
  
 
=Kwalificatie aansluiten op de kwalificatieomgeving=
 
=Kwalificatie aansluiten op de kwalificatieomgeving=
−
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 Touchstone beschikbaar. Documentatie over het aansluiten van een kwalificatie op de kwalificatie omgeving, is te vinden op de pagina Kwalificatie aansluiten in de sectie [[MedMij:V2019.01_Kwalificatie_aansluiten#Configureren_simulator|configureren simulator]].
+
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 Touchstone beschikbaar. Voordat men een gegevensdienst aanlevert ter kwalificatie, dient men het script hiervan succesvol kunnen doorlopen. Documentatie over het aansluiten van een kwalificatie op de kwalificatie omgeving, is te vinden op de pagina Kwalificatie aansluiten in de sectie [[MedMij:V2019.01_Kwalificatie_aansluiten#Configureren_simulator|configureren simulator]].
  
 
=Gebruik van de simulator=
 
=Gebruik van de simulator=
Regel 81: Regel 98:
  
 
==Variable T datum==
 
==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.
+
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.'''
 
'''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.'''
Regel 88: Regel 105:
  
 
===Kwalificatie testgegevens===
 
===Kwalificatie testgegevens===
−
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 kandidaatdeelnemers om de testgegevens in het systeem te registreren.
+
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 kwalificatieteam.  
+
Het vullen van de Nictiz WildFHIR server kon in het verleden door (kandidaat-)deelnemers 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 kwalificatieteam.  
  
 
'''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.'''  
 
'''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.'''  
Regel 106: Regel 123:
 
In de FHIR datatypes ''dateTime'' (indien uren en minuten worden gebruikt) en ''instant'' is de tijdzone verplicht. De tijdzone kan daarom niet worden weggelaten uit de testgegevens.
 
In de FHIR datatypes ''dateTime'' (indien uren en minuten worden gebruikt) en ''instant'' is de tijdzone verplicht. De tijdzone kan daarom niet worden weggelaten 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.
+
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.
  
 
=Kwalificatiebenodigdheden=
 
=Kwalificatiebenodigdheden=
Regel 229: Regel 246:
 
* [[Media:Aanleverformat - Raadplegen eAfspraak.zip|3. Aanleverformat - Raadplegen eAfspraak.zip]]
 
* [[Media:Aanleverformat - Raadplegen eAfspraak.zip|3. Aanleverformat - Raadplegen eAfspraak.zip]]
  
−
=====DVZA======
+
=====DVZA=====
 
Transactie: beschikbaarstellen
 
Transactie: beschikbaarstellen
 
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen eAfspraak.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen eAfspraak.pdf]]
 
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen eAfspraak.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen eAfspraak.pdf]]
Regel 236: Regel 253:
  
 
==Zelfmetingen==
 
==Zelfmetingen==
−
[ in afwachting van Camiel]
 
 
===Meetwaarden vitale functies===
 
===Meetwaarden vitale functies===
−
====Use case: verzamelen====
+
====Use case: delen & verzamelen====
 
=====DVP=====
 
=====DVP=====
−
Transactie: raadplegen & transactie: sturen  
+
Transactie: raadplegen & sturen  
 
* [[Media:1. Kwalificatiescript - MedMij Raadplegen en Sturen Zelfmetingen.pdf|1. Kwalificatiescript - MedMij Raadplegen en Sturen Zelfmetingen.pdf]]
 
* [[Media:1. Kwalificatiescript - MedMij Raadplegen en Sturen Zelfmetingen.pdf|1. Kwalificatiescript - MedMij Raadplegen en Sturen Zelfmetingen.pdf]]
 
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen en Sturen Zelfmetingen.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen en Sturen Zelfmetingen.pdf]]
 
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen en Sturen Zelfmetingen.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen en Sturen Zelfmetingen.pdf]]
Regel 246: Regel 262:
  
 
=====DVZA=====
 
=====DVZA=====
−
Transactie: beschikbaarstellen & transactie: ontvangen  
+
Transactie: beschikbaarstellen & ontvangen  
 
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen en Ontvangen Zelfmetingen.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen en Ontvangen Zelfmetingen.pdf]]
 
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen en Ontvangen Zelfmetingen.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen en Ontvangen Zelfmetingen.pdf]]
 
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen en Ontvangen Zelfmetingen.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen en Ontvangen Zelfmetingen.pdf]]
 
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen en Ontvangen Zelfmetingen.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen en Ontvangen Zelfmetingen.pdf]]
 
* [[Media: Aanleverformat - Beschikbaarstellen en Ontvangen Zelfmetingen.zip|3. Aanleverformat - Beschikbaarstellen en Ontvangen Zelfmetingen.zip]]
 
* [[Media: Aanleverformat - Beschikbaarstellen en Ontvangen Zelfmetingen.zip|3. Aanleverformat - Beschikbaarstellen en Ontvangen Zelfmetingen.zip]]
−
 
−
===Zelfmetingen vitale functies===
 
−
====Use case: delen====
 
−
=====DVP=====
 
−
=====DVZA=====
 
  
 
==PDF/A==
 
==PDF/A==
−
[in afwachting van Camiel]
 
 
===Documenten===
 
===Documenten===
−
====Use case: verzamelen====
+
====Use case: verzamelen & delen====
 
=====DVP=====
 
=====DVP=====
−
Transactie: raadplegen & transactie: sturen  
+
Transactie: raadplegen & sturen  
 
* [[Media:1._Kwalificatiescript_-_MedMij_Raadplegen_en_Sturen_PDFA.pdf|1. Kwalificatiescript - MedMij Raadplegen en Sturen PDFA.pdf]]
 
* [[Media:1._Kwalificatiescript_-_MedMij_Raadplegen_en_Sturen_PDFA.pdf|1. Kwalificatiescript - MedMij Raadplegen en Sturen PDFA.pdf]]
 
* [[Media:2._Addenda_-_Kwalificatiescript_-_MedMij_Raadplegen_en_Sturen_PDFA.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen en Sturen PDFA.pdf]]
 
* [[Media:2._Addenda_-_Kwalificatiescript_-_MedMij_Raadplegen_en_Sturen_PDFA.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen en Sturen PDFA.pdf]]
Regel 267: Regel 277:
  
 
=====DVZA=====
 
=====DVZA=====
−
Transactie: beschikbaarstellen & transactie: ontvangen
+
Transactie: beschikbaarstellen & ontvangen
 
* [[Media:1._Kwalificatiescript_-_MedMij_Beschikbaarstellen_en_Ontvangen_PDFA.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen en Ontvangen PDFA.pdf]]
 
* [[Media:1._Kwalificatiescript_-_MedMij_Beschikbaarstellen_en_Ontvangen_PDFA.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen en Ontvangen PDFA.pdf]]
 
* [[Media:2._Addenda_-_Kwalificatiescript_-_MedMij_Beschikbaarstellen_en_Ontvangen_PDFA.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen en Ontvangen PDFA.pdf]]
 
* [[Media:2._Addenda_-_Kwalificatiescript_-_MedMij_Beschikbaarstellen_en_Ontvangen_PDFA.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen en Ontvangen PDFA.pdf]]
 
* [[Media: Aanleverformat_-_Beschikbaarstellen_en_Ontvangen_PDFA.zip|3. Aanleverformat - Beschikbaarstellen en Ontvangen PDFA.zip]]
 
* [[Media: Aanleverformat_-_Beschikbaarstellen_en_Ontvangen_PDFA.zip|3. Aanleverformat - Beschikbaarstellen en Ontvangen PDFA.zip]]
−
 
−
====Use case: delen====
 
−
=====DVP=====
 
−
=====DVZA=====
 
  
 
==Huisartsgegevens==
 
==Huisartsgegevens==
Regel 323: Regel 329:
  
 
==Basisgegevens Langdurige Zorg==
 
==Basisgegevens Langdurige Zorg==
−
[in afwachting van Camiel]
 
 
===Basisgegevens Langdurige Zorg===
 
===Basisgegevens Langdurige Zorg===
 
====Use case: verzamelen====
 
====Use case: verzamelen====
Regel 341: Regel 346:
 
* [[MedMij:V1.0_BgLZ1.0.0-KwalificatieAddendumScenario1.3|2. Addenda voor inhoudelijke gegevens Beschikbaarstellen/Raadplegen Basisgegevens Langdurige Zorg - scenario 1.3]]
 
* [[MedMij:V1.0_BgLZ1.0.0-KwalificatieAddendumScenario1.3|2. Addenda voor inhoudelijke gegevens Beschikbaarstellen/Raadplegen Basisgegevens Langdurige Zorg - scenario 1.3]]
 
* [[Media:3. Aanleverformat - Beschikbaarstellen Basisgegevens Langdurige Zorg.pptx.zip|3. Aanleverformat - Beschikbaarstellen Basisgegevens Langdurige Zorg.zip]]
 
* [[Media:3. Aanleverformat - Beschikbaarstellen Basisgegevens Langdurige Zorg.pptx.zip|3. Aanleverformat - Beschikbaarstellen Basisgegevens Langdurige Zorg.zip]]
 +
 +
==Vragenlijsten==
 +
===Antwoorden op vragenlijst, Verwijzing naar vragenlijsten en Vragenlijsten ===
 +
[DRAFT | In afwachting van Victor / Aura | Hier komt een inleidende tekst m.b.t. vragenlijsten. Een KD dient voor beide transacties te kwalificeren]
 +
====Use case: verzamelen & use case: delen====
 +
=====DVP=====
 +
Transactie: raadplegen & sturen
 +
* [[Media:1. Kwalificatiescript - MedMij Raadplegen en Sturen Vragenlijsten.pdf|1. Kwalificatiescript - MedMij Raadplegen en Sturen Vragenlijsten.pdf]]
 +
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen en Sturen Vragenlijsten.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen en Sturen Vragenlijsten.pdf]]
 +
 +
=====DVZA=====
 +
Transactie: beschikbaarstellen & ontvangen
 +
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen en Ontvangen Vragenlijsten.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen en Ontvangen Vragenlijsten.pdf]]
 +
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen en Ontvangen Vragenlijsten.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen en Ontvangen Vragenlijsten.pdf]]
 +
 +
 +
  
 
<section end=medmij_kwalificatiescripts />
 
<section end=medmij_kwalificatiescripts />
  
 
<!--[[Categorie:Kwalificatie]]-->
 
<!--[[Categorie:Kwalificatie]]-->

Huidige versie van 9 jun 2020 om 09:20


1 Introductie

Op MedMij informatiestandaarden met bijbehorende gegevensdiensten zijn Nictiz kwalificaties van toepassing.

Kwalificaties vinden plaats per systeemrol. Deze vormt de koppeling van een MedMij informatiestandaard aan een, in de catalogus vermelde, gegevensdienst. Deze kwalificaties worden uitgevoerd door Nictiz.

Kwalificatiescripts en meer informatie over een kwalificatie is te vinden via de betreffende paragrafen onder kwalificatiebenodigdheden.

2 Algemene voorwaarden voor kwalificatie

Een leverancier kan starten met een kwalificatie, als hij voldoet aan onderstaande voorwaarden:

  1. Kennis en begrip van MedMij afsprakenstelsel.
  2. Kennis over de te gebruiken infrastructuur of het netwerk waarover uitgewisseld wordt en de toegang daartoe, inclusief authenticatie/autorisatie etc.
  3. Kennis en begrip van de betreffende MedMij informatiestandaard, zoals beschreven op de informatiestandaarden wiki van Nictiz.
  4. Kennis en begrip en het kunnen toepassen van de verschillende tabellen, waardenlijsten en andere referenties die de informatiestandaard gebruikt.
  5. Kennis en begrip en het naleven van de aandachtspunten zoals beschreven in het document 2. Addenda - Kwalificaties als bijlage bij de betreffende informatiestandaard.
  6. Alle gegevens die de kwalificerende partij zelf moet invoeren zijn te vinden in de kwalificatiedocumentatie. Onjuist ingevoerde gegevens (ook tijd/datum etc.) zullen leiden tot vertraging van en kunnen blokkerend zijn voor het kwalificatieproces.
  7. Inhoudelijke informatie, beschreven in de informatiestandaard, moet altijd toegankelijk zijn voor de eindgebruiker. De leverancier levert voor deze informatie schermafdrukken op voor controle.
  8. Deze kwalificatie toetst geen infrastructurele eisen.

3 Algemene eisen voor kwalificatie

Onderstaand zijn de beoordelingskaders beschreven waarbij is aangegeven waar een MedMij (kandidaat-)deelnemer kennis en begrip van dient te hebben om te kunnen kwalificeren naast de bijbehorende algemene uitgangspunten die beschreven zijn in paragraaf drie "Uitgangspunten voor kwalificatie". Daarnaast worden de procedurele eisen beschreven waar men ook aan dient te voldoen om te kunnen kwalificeren.

3.1 Inhoudelijke eisen

3.1.1 Beoordelingskader specifieke eisen

3.1.1.1 Beoordelingskader 1:

DVP: een DVP is in staat 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 alle informatie behorende bij een gegevensdienst, conform het testscript, 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.

DVP en DVZA

  • 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.
  • Voor elke informatiestandaard met bijbehorende gegevensdiensten is een functioneel ontwerp aanwezig waarin de use cases worden gespecificeerd. Deze geeft uitgebreide achtergrondinformatie over de algemene werking van de informatiestandaard.

DVZA specifiek

  • Voor elke gegevensdienst is een addendum aanwezig waarin beschreven staat welke functionele data-elementen bestaande uit concept-labels en waardes dienen te worden verstuurd naar Touchstone.

3.1.1.2 Beoordelingskader 2:

Een DVP en een DVZA dienen te voldoen aan de functionele eisen van de betreffende gegevensdienst.

DVP en DVZA

  • Hiervoor is voor elke informatiestandaard met bijbehorende gegevensdiensten een functioneel ontwerp aanwezig waarin de use cases worden gespecificeerd. Deze geeft uitgebreide achtergrondinformatie over de algemene werking van de informatiestandaard. 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).

3.1.1.3 Beoordelingskader 3:

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

DVP en DVZA

  • Hiervoor is voor elke informatiestandaard met bijbehorende gegevensdiensten een technisch ontwerp oftewel de “MedMij FHIR Implementation Guide” aanwezig waarin 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.

3.2 Procedurele eisen

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

  • Streef ernaar om het certificering-testscript - ook bekend als test executie - Touchstone 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 kwalificatietraject niet onnodig te vertragen wordt er dus van leveranciers geacht om genoemde richtlijn te handhaven.
  • Wanneer niet kan worden voldaan aan de functionele en/of technische eisen van een gegevensdienst, dient dit te worden aangegeven voorafgaand aan een kwalificatie. Dit voorkomt onnodige vertraging.
  • Het kwalificatiemateriaal dient 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 dienen te 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 dienen te worden gemaakt. schermafdrukken van andere interfaces zoals van een XDS worden afgekeurd. Voor zowel DVP’s én DVZA’s geldt dat schermafdrukken dienen te overeenkomen met de Touchstone test executie die is bijgevoegd in het kwalificatiemateriaal. Wanneer hier niet aan wordt voldaan leidt dit tot afwijzing.

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

4.1 Systeemrol 'Raadplegen' (DVP)

Hieronder volgt het generieke uitgangspunt voor de kwalificatie van de systeemrol 'Raadplegen':

  • De set van de gegevensdienst is bewust als één geheel vastgesteld. Daarvoor kwalificeer je wel/niet binnen de MedMij context.
  • Een DVP dient alle functionele data-elementen conform de dataset van de informatiestandaard te tonen aan de gebruiker. De uitzonderingen per gegevensdienst zijn beschreven in de bijbehorende functionele ontwerpen.
  • Een DVP biedt de gebruiker inzicht in de ontvangen respons. Als er géén gegevens beschikbaar gesteld worden, kan dat zijn omdat er geen informatie beschikbaar is bij de DVZA of vanwege een technische foutmelding. Er volgt bijvoorbeeld een foutmelding indien de resource, een specifieke zib, niet wordt ondersteund in het bronsysteem. Het is een belangrijk inzicht voor de gebruiker als gegevens technisch niet beschikbaar gesteld kunnen worden.
  • Bij de betreffende systeemrol wordt gebruik gemaakt van losse queries en niet van bundeling als batch, onder andere om aan performance bezwaren tegemoet te komen.

4.2 Systeemrol 'Beschikbaarstellen' (DVZA)

Hieronder volgen de generieke uitgangspunten voor de kwalificatie van de systeemrol 'Beschikbaarstellen':

  • Een DVZA dient de gehele gegevensdienst te ondersteunen. Uitzonderingen worden toegelicht in het bijbehorende functionele ontwerpen en kwalificatiescript.
  • DVZA geeft technisch correct antwoord op alle searches ongeacht of de gegevens in de bronsystemen beschikbaar zijn. DVZA stelt alle gegevens beschikbaar voor zover aanwezig.
  • Mochten gegevens niet beschikbaar gesteld kunnen worden, dan is uit de respons naar de raadpleger te herleiden waardoor dit veroorzaakt wordt:
    • veroorzaakt door het ontbreken van de informatie
    • veroorzaakt doordat het bronsysteem dit technisch niet kan leveren.
  • In het geval dat een vraag om gegevens goed wordt verwerkt door de DVZA, 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 de DVZA deze gegevens niet heeft, maar de vraag wel goed begrepen heeft.
  • Als er technisch iets niet goed gaat, stuurt de DVZA 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 bronsysteem. Deze moet ingebouwd worden door het bronsysteem. Hierop wordt de DVZA ook gekwalificeerd.

5 Kwalificatie aansluiten op de kwalificatieomgeving

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 Touchstone beschikbaar. Voordat men een gegevensdienst aanlevert ter kwalificatie, dient men het script hiervan succesvol kunnen doorlopen. Documentatie over het aansluiten van een kwalificatie op de kwalificatie omgeving, is te vinden op de pagina Kwalificatie aansluiten in de sectie configureren simulator.

6 Gebruik van de simulator

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

6.1 Authorization tokens

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

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

6.2.1 Kwalificatie testgegevens

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 (kandidaat-)deelnemers 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 kwalificatieteam.

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.

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

6.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 weggelaten 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.

7 Kwalificatiebenodigdheden

Het kwalificatiemateriaal voor de meest recente versies van de verschillende gegevensdiensten is in dit hoofdstuk te vinden. Een overzicht van de verschillende versies van de informatiestandaarden met bijbehorende gegevensdiensten kan men raadplegen op de pagina Register van informatiestandaarden.

7.1 Basisgegevensset Zorg

7.1.1 BgZ

7.1.1.1 Use case: verzamelen

7.1.1.1.1 DVP

Transactie: raadplegen

7.1.1.1.2 DVZA

Transactie: beschikbaarstellen

7.2 Labuitwisseling

7.2.1 Laboratoriumresultaten

7.2.1.1 Use case: verzamelen

7.2.1.1.1 DVP

Transactie: raadplegen

7.2.1.2 DVZA

Transactie: beschikbaarstellen

7.3 Medicatieproces

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

7.3.1 Medicatiegegevens

7.3.1.1 Use case: verzamelen

7.3.1.1.1 DVP

Transactie: raadplegen

7.3.2 Medicatieoverzicht

7.3.2.1 Use case: verzamelen

7.3.2.1.1 DVP

Transactie: raadplegen

7.3.3 Verstrekkingenvertaling

7.3.3.1 Use case: verzamelen

7.3.3.1.1 DVP

Transactie: raadplegen

7.3.3.1.2 DVZA

Transactie: beschikbaarstellen

7.4 AllergieIntolerantie

7.4.1 AllergieIntolerantie gegevens

7.4.1.1 Use case: verzamelen

7.4.1.1.1 DVP

Transactie: raadplegen

7.4.1.1.2 DVZA

Transactie: beschikbaarstellen

7.4.2 Medicatiegerelateerde allergie- en intolerantiegegevensvertaling

7.4.2.1 Use case: verzamelen

7.4.2.1.1 DVP

Transactie: raadplegen

7.4.2.1.2 DVZA

Transactie: beschikbaarstellen

7.5 eAfspraak

7.5.1 eAfspraak

7.5.1.1 Use case: verzamelen

7.5.1.1.1 DVP

Transactie: raadplegen

7.5.1.1.2 DVZA

Transactie: beschikbaarstellen

7.6 Zelfmetingen

7.6.1 Meetwaarden vitale functies

7.6.1.1 Use case: delen & verzamelen

7.6.1.1.1 DVP

Transactie: raadplegen & sturen

7.6.1.1.2 DVZA

Transactie: beschikbaarstellen & ontvangen

7.7 PDF/A

7.7.1 Documenten

7.7.1.1 Use case: verzamelen & delen

7.7.1.1.1 DVP

Transactie: raadplegen & sturen

7.7.1.1.2 DVZA

Transactie: beschikbaarstellen & ontvangen

7.8 Huisartsgegevens

7.8.1 Huisartsgegevens

7.8.1.1 Use case: verzamelen

7.8.1.1.1 DVP

Transactie: raadplegen

7.8.1.1.2 DVZA

Transactie: beschikbaarstellen

7.9 Basisgegevens GGZ

7.9.1 GGZ

7.9.1.1 Use case: verzamelen

7.9.1.1.1 DVP

Transactie: raadplegen

7.9.1.1.2 DVZA

Transactie: beschikbaarstellen

7.10 Beelden

7.10.1 Beelden

7.10.1.1 Use case: delen

7.10.1.1.1 DVP

Transactie: sturen

7.10.1.1.2 DVZA

Transactie: ontvangen

7.11 Basisgegevens Langdurige Zorg

7.11.1 Basisgegevens Langdurige Zorg

7.11.1.1 Use case: verzamelen

7.11.1.1.1 DVP

Transactie: raadplegen

7.11.1.1.2 DVZA

Transactie: beschikbaarstellen

7.12 Vragenlijsten

7.12.1 Antwoorden op vragenlijst, Verwijzing naar vragenlijsten en Vragenlijsten

[DRAFT | In afwachting van Victor / Aura | Hier komt een inleidende tekst m.b.t. vragenlijsten. Een KD dient voor beide transacties te kwalificeren]

7.12.1.1 Use case: verzamelen & use case: delen

7.12.1.1.1 DVP

Transactie: raadplegen & sturen

7.12.1.1.2 DVZA

Transactie: beschikbaarstellen & ontvangen




Overgenomen van "https://informatiestandaarden.test-nictiz.nl/index.php?title=MedMij:Vsuperdraft_Kwalificatie&oldid=27773"