bgz:V2.0 Kwalificatie beta 2: verschil tussen versies

Uit informatiestandaarden
Ga naar: navigatie, zoeken
imported>Iwo Serlie
(kwalificatiescript BgZ MSZ beta 2)
 
imported>Iwo Serlie
(Tekst vervangen door "LEEG")
 
Regel 1: Regel 1:
<!-- BACK TO TOP BUTTON -->
+
LEEG
<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:Kwalificatie script BgZ MSZ 2.0.0-beta.2}}
 
__NUMBEREDHEADINGS__
 
= Inleiding =
 
 
 
Dit kwalificatiescript 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 kwalificatie 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 kwalificatie ==
 
 
 
Een leverancier kan een kwalificatie starten als aan de volgende voorwaarden is voldaan:
 
# Kennis en begrip van de informatiestandaard BgZ-MSZ;
 
# De pre-validatie (test scripts) zijn met succes doorlopen en de leverancier kan daarvan de resultaten overleggen;
 
# De kwalificatiedocumentatie bevat dossier gegevens die de kwalificerende partij zelf invoert. Het is van belang dat de gegevens juist ingevoerd worden. Onjuist ingevoerde gegevens (bijvoorbeeld tijd/datum) leiden tot vertraging en kunnen blokkerend zijn voor het kwalificatieproces;
 
# 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 kwalificatieomgeving en de simulatoren (zie 1.3).
 
 
 
== Testomgeving en Kwalificatieproces ==
 
 
 
Aanmelden voor de kwalificatie van de BgZ MSZ kan via het kwalificatiecentrum. Voor meer informatie, stuur een mail naar [mailto:kwalificatie@nictiz.nl het kwalificatiecentrum].
 
 
 
= Kwalificatie =
 
 
 
== Inleiding ==
 
 
 
Een leverancier kwalificeert 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).
 
 
 
Bij de kwalificatie worden voor beide use cases dezelfde hoofdstukken van de BgZ gestuurd als beschikbaar gesteld. 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 kwalificatie heeft een leverancier aangetoond te voldoen aan de eisen in de volgende scenario’s:
 
# 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.
 
# Het ontvangende XIS kan de BgZ inzien. Het toont de BgZ-MSZ correct.
 
# Het ontvangende XIS kan de BgZ overnemen. Het toont de overgenomen gegevens correct.
 
 
 
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. In de kwalificatie wordt getoetst of het invoerveld van deze beschrijving zichtbaar is op de schermprints en of het tekstveld in het resource is gevuld.
 
 
 
<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.
 
 
 
<b>Labels van gegevens</b>
 
De naamgeving van een data-element op een user interface mag niet zodanig zijn dat het op enig moment in het proces als een ander data-element kan worden geïnterpreteerd. Als een label afwijkt van het label van de zib (voorbij hoofdletter en spatiegebruik) moet bij schermafdrukken een vertaaltabel van label naar zib-element naam worden bijgevoegd.
 
 
 
<b>Waarde van gegevens</b>
 
De waarde van een data-element op de user interface moet zonder informatie verlies worden afgebeeld. Als er sprake is van een unit transformatie moet de transformatie bij de schermafdruk worden bijgesloten. Een SNOMED-CT code mag als een DT of VT naam worden afgebeeld.
 
 
 
== Reconciliëren en ontdubbelen ==
 
 
Het kunnen samenvoegen van de BgZ uit verschillende bronnen (reconciliëren) valt buiten deze kwalificatie. Ook het kunnen om gaan met dubbelingen uit verschillende bronnen (ontdubbelen) valt buiten deze kwalificatie. Uitsluitend het ongewijzigd kunnen overnemen van BgZ hoofdstukken en onderlinge relaties wordt getoetst. Dit wordt aangeduid met ‘overnemen’.
 
 
 
== Uit te voeren stappen en op te leveren materialen ==
 
 
 
<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
 
[[Bestand:Stappen-kwa-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 en kan ontvangen.
 
 
 
<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). Dit is relevant in verband met de schermafdrukken en het testen van de metagegevens. Leg ook de relaties vast tussen de elementen in de verrichtingenlijst en de elementen in de probleemlijst.
 
# Maak schermafdrukken van de vastgelegde gegevens als integraal onderdeel van het dossier in uw XIS (fig 1c). Er wordt onder de voorwaarden zoals vermeld in sectie 2.3 nagegaan of de gegevens overeenkomen met de gegevens uit de addenda (fig. 1d).
 
 
 
<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).
 
 
 
<b>Inzien</b>
 
# De simulator stuurt FHIR resource-instanties (fig. 1j). De test server bevat de transactie gegevens zoals beschreven in de sectie inhoudelijke gegevens (fig. 1h).
 
# Het ontvangende systeem toont alle BgZ hoofdstukken in een user interface, deze gegevens zijn geen integraal onderdeel van het dossier in uw XIS. Hiervoor zijn geen deelkwalificaties mogelijk.
 
# Maak schermafdrukken van de ontvangen BgZ hoofdstukken (fig. 1k). Er wordt onder de voorwaarden zoals vermeld in sectie 2.3 nagegaan of de gegevens overeenkomen met de gegevens uit de addenda (fig. 1m).
 
 
 
<b>Overnemen</b>
 
# Het ontvangende/ raadplegende system neemt de gegevens in de BgZ hoofdstukken ongewijzigd over (fig. n).
 
# Maak schermafdrukken van de overgenomen BgZ hoofdstukken als integraal onderdeel van het Dossier in het XIS (fig. 1o).
 
# Voeg de schermafdrukken toe aan het Kwalificatiemateriaal document. Er wordt onder de voorwaarden zoals vermeld in sectie 2.3 nagegaan of de gegevens overeenkomen met de gestuurde gegevens (fig. 1p).
 
 
 
= Inhoudelijke gegevens =
 
 
 
== 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 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 A ==
 
 
 
De use case beschrijft een (74 jarige) man, dhr J.A. Kooyman geb. 4 maart 1950. Ondanks zijn wat hogere leeftijd is hij nog steeds een fervent motorrijder. Tijdens een touring tocht door Zuid Holland werd hij aangereden door een auto en kwam ter val. Hij brak zijn linker onderbeen op meerdere plekken, gecompliceerd door een grote wond.  Daarnaast brak hij zijn linker pols. J.A.K. werd nog diezelfde avond in Rotterdam aan zijn been geopereerd door de dienstdoende orthopeed. Hij kreeg een fixateur externe en de pols werd behandeld d.m.v. aanleggen van gips.
 
 
 
Jan is woonachtig in Rotterdam, maar vraagt om overplaatsing naar Nijmegen op te worden opgevangen door een goede relatie. Jan wordt 1 dag na de OK ontslagen uit het ziekenhuis in Rotterdam en overgenomen door het ziekenhuis in Nijmegen.
 
 
 
 
 
<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
 
[[Bestand:Tijdlijn-bgz-msz-v2-patA-tijdlijn-v2.png|850px]]
 
</div>
 
Figuur 2. tijdlijn bij use case A
 
 
 
 
 
<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
 
[[Bestand:Relaties-bgz-msz-v2-patA-v1.png|900px]]
 
</div>
 
Figuur 3. relaties bij use case A.
 
 
 
 
 
Overzicht 1. Probleemlijst.
 
<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
 
[[Bestand:PatientA_Probleemlijst v1.png|1000px]]
 
</div>
 
 
 
Overzicht 2. Verrichtingen.
 
<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
 
[[Bestand:PatientA_VerrichtingenLijst v2.png|1000px]]
 
</div>
 
 
 
Overzicht 3. Allergieën.
 
<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
 
[[Bestand:PatientA_Allergieen v1.png|1000px]]
 
</div>
 
 
 
Overzicht 4. Behandelaanwijzingen.
 
<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
 
[[Bestand:PatientA_Behandelaanwijzing v2.png|1000px]]
 
</div>
 
 
 
Overzicht 5. Medicatie.
 
<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
 
[[Bestand:PatientA_Medicatie v2.png|1000px]]
 
</div>
 
 
 
== Achtergrond bij use case patiënt B ==
 
 
 
De usecase beschrijft een (61 jarige) mevr M.D. geb. 30 juni 1963. Binnen de familie van patiënte werd bij twee van haar zussen en haar moeder borstkanker gediagnosticeerd. Bij allen werd het BRCA1 gen gevonden, zo ook bij mevr M.D. Daarom staat ze onder frequente controle. Bij een laatste controle werd een palpabele massa aangetroffen in de linker borst. Binnen twee weken werd patiënte geopereerd en vond een mastectomie L plaats. Helaas werd dit gecompliceerd door een wondinfectie waarvoor antibiotica en drainage van de wond. Patiënte heeft een uitgebreide medische voorgeschiedenis waaronder een CVA enkele jaren geleden met nog steeds een spierzwakte aan haar rechter arm.
 
 
 
 
 
<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
 
[[Bestand:Tijdlijn-bgz-msz-v2-patB-tijdlijn-v2.png|850px]]
 
</div>
 
Figuur 4. tijdlijn bij use case B
 
 
 
 
 
<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
 
[[Bestand:Relaties-bgz-msz-v2-patB-v1.png|900px]]
 
</div>
 
Figuur 5. relaties bij use case B. De meest recente items vindt u bovenaan.
 
 
 
 
 
Overzicht 6. Probleemlijst.
 
<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
 
[[Bestand:PatB_Probleemlijst_v1.png|1000px]]
 
</div>
 
 
 
Overzicht 7. Verrichtingen.
 
<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
 
[[Bestand:PatB_Verrichtingenlijst_v1.png|1000px]]
 
</div>
 
 
 
Overzicht 8. Allergieën.
 
<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
 
[[Bestand:PatB_Allergieen_v1.png|1000px]]
 
</div>
 
 
 
Overzicht 9. Behandelaanwijzingen.
 
<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
 
[[Bestand:PatB_Behandelaanwijzing_v1.png|1000px]]
 
</div>
 
 
 
Overzicht 10. Medicatie.
 
<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
 
[[Bestand:PatB_Medicatie_v1.png|1000px]]
 
</div>
 
 
 
== Patiënt A, uitgewisselde gegevens bij sturen/ ontvangen  ==
 
 
 
{{#lst:BgZ:V2.0_beta_AddendInhoudelijkeGegevens|BgZ-msz-kwa-patA-SLB}}
 
 
 
== Patiënt A, uitgewisselde gegevens bij beschikbaar stellen/ raadplegen ==
 
 
 
PM
 
 
 
== Patiënt A, dossier ==
 
 
 
{{#lst:BgZ:V2.0_beta_AddendInhoudelijkeGegevens|BgZ-msz-kwa-patA-DB}}
 
 
 
== Patiënt B, uitgewisselde gegevens bij sturen/ ontvangen  ==
 
 
 
{{#lst:BgZ:V2.0_beta_AddendInhoudelijkeGegevens|BgZ-msz-kwa-patB-SLB}}
 
 
 
== Patiënt B, uitgewisselde gegevens bij beschikbaar stellen/ raadplegen ==
 
 
 
PM
 
 
 
== Patiënt B, dossier ==
 
 
 
{{#lst:BgZ:V2.0_beta_AddendInhoudelijkeGegevens|BgZ-msz-kwa-patB-D1}}
 
{{#lst:BgZ:V2.0_beta_AddendInhoudelijkeGegevens|BgZ-msz-kwa-patB-D2}}
 
{{#lst:BgZ:V2.0_beta_AddendInhoudelijkeGegevens|BgZ-msz-kwa-patB-D3}}
 

Huidige versie van 5 mrt 2025 om 14:09

LEEG