MedMij:Vsuperdraft Kwalificatie

Uit informatiestandaarden
Versie door Jessica Apeldoorn (overleg | bijdragen) op 22 apr 2020 om 14:23 ("DVP en DVZA")
Naar navigatie springen Naar zoeken springen


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

2.1 Inhoudelijke eisen

2.1.1 Beoordelingskader specifieke eisen

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

2.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).

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

2.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.
  • 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.

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

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

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

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

5 Gebruik van de simulator

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

5.1 Authorization tokens

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

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

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

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

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

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

6.1 Basisgegevensset Zorg

6.1.1 BgZ

6.1.1.1 Use case: verzamelen

6.1.1.1.1 DVP

Transactie: raadplegen

6.1.1.1.2 DVZA

Transactie: beschikbaarstellen

6.2 Labuitwisseling

6.2.1 Laboratoriumresultaten

6.2.1.1 Use case: verzamelen

6.2.1.1.1 DVP

Transactie: raadplegen

6.2.1.2 DVZA

Transactie: beschikbaarstellen

6.3 Medicatieproces

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

6.3.1 Medicatiegegevens

6.3.1.1 Use case: verzamelen

6.3.1.1.1 DVP

Transactie: raadplegen

6.3.2 Medicatieoverzicht

6.3.2.1 Use case: verzamelen

6.3.2.1.1 DVP

Transactie: raadplegen

6.3.3 Verstrekkingenvertaling

6.3.3.1 Use case: verzamelen

6.3.3.1.1 DVP

Transactie: raadplegen

6.3.3.1.2 DVZA

Transactie: beschikbaarstellen

6.4 AllergieIntolerantie

6.4.1 AllergieIntolerantie gegevens

6.4.1.1 Use case: verzamelen

6.4.1.1.1 DVP

Transactie: raadplegen

6.4.1.1.2 DVZA

Transactie: beschikbaarstellen

6.4.2 Medicatiegerelateerde allergie- en intolerantiegegevensvertaling

6.4.2.1 Use case: verzamelen

6.4.2.1.1 DVP

Transactie: raadplegen

6.4.2.1.2 DVZA

Transactie: beschikbaarstellen

6.5 eAfspraak

6.5.1 eAfspraak

6.5.1.1 Use case: verzamelen

6.5.1.1.1 DVP

Transactie: raadplegen

6.5.1.1.2 DVZA

Transactie: beschikbaarstellen

6.6 Zelfmetingen

6.6.1 Meetwaarden vitale functies

6.6.1.1 Use case: delen & verzamelen

6.6.1.1.1 DVP

Transactie: raadplegen & sturen

6.6.1.1.2 DVZA

Transactie: beschikbaarstellen & ontvangen

6.7 PDF/A

6.7.1 Documenten

6.7.1.1 Use case: verzamelen & delen

6.7.1.1.1 DVP

Transactie: raadplegen & sturen

6.7.1.1.2 DVZA

Transactie: beschikbaarstellen & ontvangen

6.8 Huisartsgegevens

6.8.1 Huisartsgegevens

6.8.1.1 Use case: verzamelen

6.8.1.1.1 DVP

Transactie: raadplegen

6.8.1.1.2 DVZA

Transactie: beschikbaarstellen

6.9 Basisgegevens GGZ

6.9.1 GGZ

6.9.1.1 Use case: verzamelen

6.9.1.1.1 DVP

Transactie: raadplegen

6.9.1.1.2 DVZA

Transactie: beschikbaarstellen

6.10 Beelden

6.10.1 Beelden

6.10.1.1 Use case: delen

6.10.1.1.1 DVP

Transactie: sturen

6.10.1.1.2 DVZA

Transactie: ontvangen

6.11 Basisgegevens Langdurige Zorg

6.11.1 Basisgegevens Langdurige Zorg

6.11.1.1 Use case: verzamelen

6.11.1.1.1 DVP

Transactie: raadplegen

6.11.1.1.2 DVZA

Transactie: beschikbaarstellen

6.12 Vragenlijsten

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

6.12.1.1 Use case: verzamelen & use case: delen

6.12.1.1.1 DVP

Transactie: raadplegen & sturen

6.12.1.1.2 DVZA

Transactie: beschikbaarstellen & ontvangen




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