Brontekst bekijken van BgZ:BgZ MSZ TestScript 2 0 0 beta 2

<!-- BACK TO TOP BUTTON -->
<span id="BackToTop"></span>
<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>
<!-- EINDE BACK TO TOP BUTTON -->

{{DISPLAYTITLE:Test script BgZ MSZ 2.0.0-beta.2 DRAFT}}
__NUMBEREDHEADINGS__
= Inleiding =

Dit testscript is bedoeld voor pre-validatie of testen van het uitwisselen van de Basisgegevensset Zorg (BgZ) in de medisch specialistische zorg (MSZ). 

Dit testscript bevat de te doorlopen scenario’s voor de volgende transacties in de Basisgegevensset Zorg (BgZ) voor de medisch-specialistische zorg (MSZ).
* Het sturen en ontvangen van de BgZ.
* Het beschikbaar stellen en raadplegen van de BgZ.
Deze test toetst geen infrastructurele eisen. 

== Doelgroep == 

De volgende doelgroepen worden onderscheiden:
* Leveranciers die zich willen kwalificeren.
* Betrokken organisaties bij het validatieproces, zoals VZVZ, NTV.
* Partijen die betrokken zijn bij de doorontwikkeling van de informatiestandaard en de voorbeelddossiers.

== Algemene voorwaarden voor pre-validatie ==

Een leverancier kan een test starten als aan de volgende voorwaarden is voldaan:
# Kennis en begrip van de informatiestandaard BgZ-MSZ;
# Inhoudelijke informatie, beschreven in de informatiestandaard, moet altijd toegankelijk zijn voor de eindgebruiker. De leverancier levert schermafdrukken aan voor controle van de toegankelijkheid van deze inhoudelijke informatie;
# Aansluiting op de test- en kwalificatieomgeving en de simulatoren (zie 1.3).

== Testomgeving en Kwalificatieproces ==

Aanmelden voor de test van de BgZ MSZ kan via het kwalificatiecentrum. Voor meer informatie, stuur een mail naar [mailto:kwalificatie@nictiz.nl het kwalificatiecentrum].

= Test =

== Inleiding ==

Een leverancier test de uitwisseling voor de use cases (zie NEN 7540):
# Uitwisseling BgZ bij verwijzing of overdracht. Door middel van sturen en ontvangen van de BgZ-MSZ (PUSH).
# Opvraging BgZ bij eerdere behandelaar. Door middel van beschikbaar stellen en raadplegen voor de BGZ-MSZ (PULL).

Voor beide use cases worden dezelfde hoofdstukken van de BgZ uitgewisseld. Let op: de queries voor de BgZ MSZ 2.0 informatiestandaard wijken af van de query voorbeelden in de TA-NP Technical Agreement (2024-03-05, v1.0.0_0).

== Doel en verwacht resultaat ==

Bij een succesvolle test heeft een leverancier voor zichzelf aangetoond:
# Het sturende XIS kan BgZ gegevens vastleggen. Het toont de vastgelegde gegevens correct.
# Het sturende XIS kan de BgZ leveren. Het genereert de technisch correcte berichten.

Voor deze kwalificatie zijn de onderstaande systeemrollen van toepassing (zie FO). 
* BgZ MSZ Sturend [MSZ-XIS-S] systeem
* BgZ MSZ Ontvangend [MSZ-XIS-O] systeem
* BgZ MSZ Beschikbaarstellend [MSZ-XIS-B] systeem
* BgZ MSZ Raadplegend [MSZ-XIS-R] systeem

== Specifieke voorwaarden bij controleren van gegevens ==

<b>FHIR resource-instanties</b>
# Units moeten exact worden uitgewisseld zoals deze zijn gedefinieerd in de sectie inhoudelijke gegevens.
# De precisie van gegevens moet identiek blijven bij uitwisseling.
# De FHIR narrative kan per configuratie afwijken. Deze hoeft niet identiek te zijn aan de narrative zoals in de FHIR resource-instanties uit de testomgeving. De waarde in elementen moeten wel terugkomen in de narrative.
# De ordening van elementen als onderdeel van een uitgewisseld FHIR bericht is niet relevant. Denk bijvoorbeeld aan twee SNOMEC CT codes.
# Het FHIR resource instance ID is niet relevant.

<b>Gecodeerde concepten waarbij "anders" deel uitmaakt van de waardenlijst.</b> Het is verplicht om voor de voorbeelden met waarde "anders", van de gecodeerde concepten waar "anders" deel uitmaakt van de waardenlijst, tekstuele beschrijving op te nemen. 

<b>Meta gegevens</b>
Tijdstippen van uitgewisselde Metagegevens hoeven niet exact te zijn zoals in de addenda. De chronologische volgorde is wel van belang. Zo kunnen metagegevens bij oudere probleemlijst elementen een tijdstempel hebben die ouder is dan de tijdstempel van metagegevens bij een huidig probleemlijst element.

== Uit te voeren stappen en op te leveren materialen ==

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand:Stappen-tst-BgZ-msz-v2.0.1.png|800px]]
</div>
<b>Figuur 1.</b> Samenvatting van de stappen die worden doorlopen om aan te tonen dat een systeem de BgZ kan sturen of beschikbaar kan stellen.

<b>Vastleggen</b>
# Maak een nieuw dossier aan in uw XIS voor de fictieve patiënten A en B.
# Leg de dossiergegevens van de fictieve patiënten A en B vast in het XIS (fig. 1b). Gebruik hiervoor de gegevens zoals beschreven in de addenda (fig. 1a). Leg eerst de probleemlijst en vervolgens de verrichtingenlijst in chronologische volgorde vast (fig. 3). Leg ook de relaties vast tussen de elementen in de verrichtingenlijst en de elementen in de probleemlijst.

<b>Leveren</b>
# Gegeven het dossier zoals vastgelegd in uw XIS DB, en gegeven de definitie van de queries en profielen zoals in de FHIR implementation guide van de BgZ-MSZ 2.0, stel FHIR resource-instanties samen voor alle hoofdstukken van de BgZ. Hiervoor zijn deelkwalificaties mogelijk.
# Lever de FHIR-resource-instanties aan zoals afgesproken bij de intake (fig. 1e). Er wordt onder de voorwaarden zoals vermeld in sectie 2.3 nagegaan of de gegevens overeenkomen met de FHIR instanties in de testomgeving (fig. 1f) op basis van de gegevens zoals beschreven in de addenda inhoudelijke gegevens (fig. 1g).

= Inhoudelijke gegevens =

Gegevenselementen in de BgZ msz voor test patiënt C zijn minimaal gevuld volgens de definities van de informatiestandaard. 
Gegevenselementen in de BgZ msz voor test patiënt D zijn maximaal gevuld volgens de informatiestandaard. 
Er is uitgegaan van het uitwisselen van minimaal één gegevenselement en één zib-instantiatie met correcte vulling volgens de informatiestandaard.

== Aspecten van inhoudelijke gegevens ==

Bij het samenstellen van de inhoudelijke gegevens is rekening gehouden met de volgende aspecten
* Zib-definities bevatten conditionele eisen. Een zib-definitie kan bijvoorbeeld een container bevatten waarin precies één type gegevenselement kan worden gekozen. Een voorbeeld is de zib contact, waarbij de RedenContact container precies één concept mag bevatten uit de keuzelijst: probleem, verrichting, of afwijkende uitslag. Voor dit specifieke voorbeeld zijn ten minste drie instanties nodig van dit gegevenselement om een voorbeeld te hebben van een probleem, verrichting, of afwijkende uitslag. 
* Er is altijd een definitie van een patiënt. Lege zib-instanties worden niet vastgelegd of uitgewisseld. Er is vanuit iedere zib-instantiatie minimaal de referentie naar de betreffende patiënt en per zib-instantiatie is minimaal één veld gevuld.
* De informatiestandaard definieert dat van sommige gegevenselementen alleen de meest recente waarde wordt uitgewisseld. Dit beperkt het aantal mogelijke instanties van gegevenselementen in één transactie. Zo wordt bijvoorbeeld het meest recente lichaamsgewicht uitgewisseld.
* Combinaties van gegevens die vanuit medisch oogpunt onmogelijk zijn, zijn vermeden in de test data ten einde rekening te houden met de mensen en systemen die de data verwerken. Bijvoorbeeld, Korotkoff-tonen passen bij het gebruik van een manchet bij het meten van de bloeddruk. Als geen gebruik wordt gemaakt van een manchet wordt niet gespecificeerd hoe wordt geluisterd.
* Causaliteit. Een gebeurtenis kan niet eindigen voordat deze begint. Ook kan bijvoorbeeld de reden voor een interventie niet ontstaan na de interventie in kwestie. Een startdatum en einddatum van een gebeurtenis kunnen echter exact hetzelfde zijn, rekening houdend met de nauwkeurigheid van een datum.
* Medische terminologie. Voor SNOMED CT concepten zijn de actuele codes en waar beschikbaar de Nederlandse voorkeurstermen gebruikt op het moment dat dit script is gemaakt. Verouderde codes zijn niet gebruikt. Het kunnen omgaan met verouderde codes, die in een dossier zullen voorkomen als gevolg van het gebruik van codestelsels, is geen onderdeel van een test script. In een kwalificatie moet een leverancier wel kunnen omgaan met verouderde codes.
* Informatie is geheel fictief en niet te herleiden tot personen, zorgverleners en organisaties.

* T-datum. T is een datum die we tijdens de test en kwalificatie nader invullen / afspreken (betreft over het algemeen de huidige datum). Als ergens staat T – 100D betekent dit: 100 dagen eerder dan die afgesproken datum.

* Een dossier bevat meer gegevens dan er via de BgZ-MSZ worden uitgewisseld. Er kan bijvoorbeeld één meest recente meting worden uitgewisseld terwijl een XIS voor dezelfde patiënt meer metingen van hetzelfde type bevat. Dit is de reden dat er bij de kwalificatie alleen screenshots worden overgedragen van een XIS. Het is niet vereist om het gehele dossier via FHIR-resource-instanties te kunnen uitwisselen.

* Kardinaliteit. De inhoudelijke gegevens zijn ontwikkeld op basis van de transacties in de BgZ-MSZ. In transacties kan de kardinaliteit afwijken van de conceptuele zibs. Bijvoorbeeld, wordt er in de BgZ MSZ geen privé nummer uitgewisseld van een zorgverlener. Verder kan een kardinaliteit kan niet altijd in isolement worden geïnterpreteerd. Er is een samenhang. Bijvoorbeeld, een tussenvoegsel is niet optioneel als deze deel is van een familienaam.

* Aanvullingen op zibs. In transacties kunnen extra elementen worden toegevoegd of kunnen delen van de zibs worden uitgesloten. Bijvoorbeeld, wordt er voor labresultaten geen monster informatie uitgewisseld.

== Achtergrond bij use case patiënt C ==

De usecase beschrijft een man, dhr de Boer geb. 16 december 1984. Ondanks zijn wat hogere leeftijd is hij nog steeds actief bij de lokale trimvereniging en is zeer actief. De man kwam met een pols van 30 bij de huisarts en is opgenomen in een streekziekenhuis op de hartbewaking. Dezelfde dag is de hij doorverwezen naar het meest dichtbij zijnde Hart- en Vaatcentrum voor een RR pacemaker.

Het dossier is zodanig opgezet dat per BgZ hoofdstuk een minimum van informatie elementen is gespecificeerd. Het doel is voornamelijk om te voorkomen dat tijdens de implementatie van een uitwisseling aannames ontstaan in berichten. Uitwisseling moet zonder informatieverlies plaatsvinden. 

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand:Tijdlijn-bgz-msz-patC-v122a.png|800px]]
</div>
Figuur 2. tijdlijn bij use case C

== Achtergrond bij use case patiënt D ==

[De usecase beschrijft een mevr F.S.K. Çelik - Al Ksar el Kebir. Ze heeft een aangeboren hartafwijking, de tetralogie van Fallot. In de eerste maanden heeft ze een volledige correctie ondergaan. Na klachten is later de pulmonalisklep vervangen.
Ze kwam met een elleboogfractuur binnen. Daarnaast wist ze niet meer wat er was gebeurd. Voor de zekerheid is ze doorverwezen naar een hartcentrum voor verdere observatie.]

Het dossier is zodanig opgezet dat per BgZ hoofdstuk een maximum van informatie elementen is gespecificeerd. Het doel is voornamelijk garanderen dat alle elementen kunnen worden uitgewisseld.

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand:Tijdlijn-bgz-msz-patD-v122a.png|800px]]
</div>
Figuur 4. tijdlijn bij use case D

== Patiënt C, uitgewisselde gegevens ==

{{#lst:BgZ:V2.0_beta_AddendInhoudelijkeGegevens|BgZ-msz-tst-patC-SLB}}

== Patiënt C, dossier ==

{{#lst:BgZ:V2.0_beta_AddendInhoudelijkeGegevens|BgZ-msz-tst-patC-DB}}


== Patiënt B, uitgewisselde gegevens  ==

{{#lst:BgZ:V2.0_beta_AddendInhoudelijkeGegevens|BgZ-msz-tst-patD-SLB}} 

== Patiënt B, dossier ==

{{#lst:BgZ:V2.0_beta_AddendInhoudelijkeGegevens|BgZ-msz-tst-patB-D1}} 
{{#lst:BgZ:V2.0_beta_AddendInhoudelijkeGegevens|BgZ-msz-tst-patB-D2}} 
{{#lst:BgZ:V2.0_beta_AddendInhoudelijkeGegevens|BgZ-msz-tst-patB-D3}}

= Release notes =

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-209 Testscripts refereert naar screenshots |Tekst over aanleveren bij testscripts verwijderd (niet van toepassing)]