Bgz:V2.0-beta.3 Validatiescript BgZ MSZ: verschil tussen versies

Uit informatiestandaarden
Ga naar: navigatie, zoeken
(Algemene voorwaarden voor valideren)
Regel 130: Regel 130:
 
#* Onder de voorwaarden vermeld in [[#Specifieke_voorwaarden_bij_controleren_van_gegevens|sectie 2.3]] wordt nagegaan of de gegevens overeenkomen met de gestuurde gegevens (fig. 1p).
 
#* Onder de voorwaarden vermeld in [[#Specifieke_voorwaarden_bij_controleren_van_gegevens|sectie 2.3]] wordt 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:
 
 
; Conditionele eisen
 
: Zib-definities bevatten conditionele eisen en een zib-definitie kan 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. Om voor deze concepten voorbeelden te maken, zijn ten minste drie instanties van dit gegevenselement nodig.
 
 
; Minimale invulling
 
: Er moet altijd een definitie van een patiënt zijn. 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.
 
 
; Laatst bekende waardes
 
: Het aantal mogelijke instanties van gegevenselementen in één transactie is beperkt doordat van sommige gegevenselementen alleen de meest recente waarde hoeft te worden uitgewisseld. Dit staat in de [[BgZ:V2.0_Ontwerp_Beta_BgZ_MSZ#Specificatie van uitgewisselde BgZ componenten|informatiestandaard]]. Zo wordt bijvoorbeeld het laatst bekende lichaamsgewicht uitgewisseld.
 
 
; Medisch plausibele gegevens
 
: Combinaties van gegevens die medisch gezien niet mogelijk zijn, zijn uit de testgegevens weggelaten om rekening te houden met de mensen en systemen die de gegevens verwerken. Bijvoorbeeld, Korotkoff-tonen passen bij het meten van de bloeddruk met een manchet (waarbij de tonen door de stethoscoop worden gehoord). Als deze methode niet wordt gebruikt, is niet duidelijk hoe er geluisterd wordt.
 
 
; Causaliteit
 
: Een gebeurtenis kan niet eindigen voordat deze begint. Een reden voor een gebeurtenis kan bijvoorbeeld niet ontstaan nadat de gebeurtenis heeft plaatsgevonden. Een startdatumtijd en einddatumtijd van een gebeurtenis kunnen hetzelfde zijn, afhankelijk van hoe nauwkeurig ze zijn vastgelegd.
 
 
; Medische terminologie
 
: Bij het maken van dit script zijn de SNOMED CT-conceptcodes en de Nederlandse voorkeurstermen gebruikt die toen up-to-date waren. Het omgaan met verouderde codes die in een dossier kunnen voorkomen door het gebruik van codestelsels, is geen onderdeel van een testscript. Maar bij kwalificatie moet een leverancier wél kunnen werken met oude codes.
 
 
; Fictieve informatie
 
: De inhoudelijke gegevens zijn volledig fictief en kunnen niet teruggeleid worden naar mensen, zorgverleners of 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.
 
 
; Reden voor screenshots
 
: Een dossier bevat meer gegevens dan wat er in de BgZ-MSZ wordt uitgewisseld. Bijvoorbeeld, er kan één laatst bekende meting worden uitgewisseld, terwijl een XIS voor dezelfde patiënt meerdere metingen van hetzelfde type bevat. Dit is waarom er alleen screenshots van een XIS worden doorgestuurd. Het is niet nodig om het hele dossier uit te wisselen via FHIR-resource-instanties.
 
 
; Kardinaliteit
 
: De inhoudelijke gegevens zijn ontwikkeld op basis van de transacties in de BgZ-MSZ. In transacties kunnen de kardinaliteiten verschillen van de conceptuele zibs. In de BgZ-MSZ wordt bijvoorbeeld geen privénummer van een zorgverlener gedeeld. Bovendien kan een kardinaliteit niet altijd op zichzelf worden geïnterpreteerd, omdat er verbanden bestaan tussen data-elementen. Een tussenvoegsel is bijvoorbeeld niet optioneel wanneer het onderdeel is van een familienaam.
 
 
; Aanpassingen op zibs
 
: In transacties kunnen extra elementen worden toegevoegd of kunnen elementen van de zibs worden weggelaten. Er wordt bijvoorbeeld voor labresultaten geen monsterinformatie uitgewisseld.
 
 
== Identificatiegegevens van de kwalificatie-patiënten ==
 
 
In dit kwalificatiescript komen onderstaande fictieve patiënten voor.
 
{| class="wikitable" 
 
!style="text-align:left; | Patiënt Identifier
 
!style="text-align:left; | Voornamen
 
!style="text-align:left; | Achternaam
 
!style="text-align:left; | Initialen
 
!style="text-align:left; | Identificatienummer
 
!style="text-align:left; | Geboortedatum (DD-MM-YYYY)
 
|-
 
| style="background-color: white;"| A
 
| style="background-color: white;"| Jan Adrianus
 
| style="background-color: white;"| van Houten
 
| style="background-color: white;"| J.A.H.
 
| style="background-color: white;"| 999909587 (BSN)
 
| style="background-color: white;"| 25-07-1954
 
|-
 
| style="background-color: white;"| B
 
| style="background-color: white;"| Michelle
 
| style="background-color: white;"| Bergzoon
 
| style="background-color: white;"| M.B.
 
| style="background-color: white;"| 999911259 (BSN)
 
| style="background-color: white;"| 01-08-1964
 
|}
 
 
== Achtergrond bij use case patiënt A ==
 
 
De use case beschrijft een man, dhr J.A.H. geb. 25 juli 1954. 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.H. 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 Stitswerd, 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-v3.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 mevr M.B. geb. 01 augustus 1964. 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.B. 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-v3.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>
 
 
{{#lst:BgZ:V2.0_beta_2_AddendInhoudelijkeGegevens|BgZ-msz-kwa-patA-SLB}}
 
 
{{#lst:BgZ:V2.0_beta_2_AddendInhoudelijkeGegevens|BgZ-msz-kwa-patA-DB}}
 
 
{{#lst:BgZ:V2.0_beta_2_AddendInhoudelijkeGegevens|BgZ-msz-kwa-patB-SLB}}
 
 
{{#lst:BgZ:V2.0_beta_2_AddendInhoudelijkeGegevens|BgZ-msz-kwa-patB-D1}}
 
{{#lst:BgZ:V2.0_beta_2_AddendInhoudelijkeGegevens|BgZ-msz-kwa-patB-D2}}
 
{{#lst:BgZ:V2.0_beta_2_AddendInhoudelijkeGegevens|BgZ-msz-kwa-patB-D3}}
 
  
 
= Release notes =
 
= Release notes =
 
[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-193 MSZ-193:Lichaamsgewicht is gewogen bij Lichaamslengte is onjuist]
 

Versie van 6 aug 2025 om 10:44


Voor een overzicht van relevante wiki-pagina's voor BgZ-MSZ zie Landingspagina_BgZ

1 Inleiding

Na het doorlopen van de test- en kwalificatiescripts, volgt een extra validatie-stap. Hiervoor worden validatiescripts gebruikt, die eveneens de volgende transacties in de Basisgegevensset Zorg (BgZ) voor de medisch-specialistische zorg (MSZ) bevatten.

  • Het sturen en ontvangen van de BgZ.
  • Het beschikbaar stellen en raadplegen van de BgZ. (LET OP! Deze use case is momenteel nog niet volledig uitgewerkt omdat het communicatiepatroon nog niet beschikbaar is.)

Deze validatie-stap toetst geen infrastructurele eisen.

1.1 Doelgroep (verwijzing?)

De volgende doelgroepen worden onderscheiden:

  • Leveranciers die zich willen kwalificeren.
  • Organisaties die betrokken zijn bij het validatieproces zoals VZVZ en NTV.
  • Partijen die betrokken zijn bij de doorontwikkeling van de informatiestandaard en de voorbeelddossiers zoals zorgverleners en hun vertegenwoordigers.

1.2 Algemene voorwaarden voor valideren

Een leverancier kan de validatie-stap starten als aan de volgende voorwaarden is voldaan:

  1. Kennis en begrip van de informatiestandaard BgZ-MSZ;
  2. Zowel het test- als het kwalificatiescript zijn met succes doorlopen en de leverancier kan de resultaten daarvan overleggen;
  3. De validatiedocumentatie 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 validatieproces;
  4. Inhoudelijke gegevens beschreven in dit script moeten toegankelijk zijn voor de eindgebruiker. De leverancier levert schermafdrukken aan voor controle van de toegankelijkheid van deze inhoudelijke informatie;
  5. Aansluiting op de validatieomgeving en de simulatoren (zie 1.3).

1.3 Testomgeving en Validatieproces (verwijzen?)

Aanmelden voor de validatie van de BgZ MSZ kan via het kwalificatiecentrum. Voor meer informatie, stuur een mail naar het kwalificatiecentrum.

2 Validatie

2.1 Inleiding

Een leverancier valideert voor de use case:

  1. Uitwisseling BgZ bij verwijzing of overdracht (PUSH).
  2. Opvraging BgZ bij eerdere behandelaar (PULL).

LET OP:

  • Deze laatste use case is momenteel nog niet volledig uitgewerkt omdat het communicatiepatroon nog niet beschikbaar is.
  • De queries voor de BgZ MSZ 2.0 informatiestandaard wijken af van de query voorbeelden in de TA-NP Technical Agreement [link].

2.2 Doel en verwacht resultaat (verwijzen?)

Bij een succesvolle validatie heeft een leverancier aangetoond te voldoen aan de [eisen per systeemrol.]

Systeemrol MSZ-XIS-S:

  • Vastleggen: het sturende XIS kan via de UI aantonen dat BgZ gegevens onderdeel zijn geworden van het XIS.
  • Leveren: het sturende XIS kan technische berichten genereren en leveren die identiek zijn aan de FHIR instanties van Nictiz.

Systeemrol MSZ-XIS-O:

  • Inzien: het ontvangende XIS kan de BgZ gegevens tonen zoals in de addenda zonder dat deze deel zijn geworden van het XIS.
  • Overnemen: het ontvangende XIS kan via de UI aantonen dat overgenomen gegevens onderdeel zijn geworden van het XIS.

2.3 Specifieke voorwaarden bij controleren van gegevens (verwijzen?)

FHIR resource-instanties

  1. Units moeten exact worden uitgewisseld zoals deze zijn gedefinieerd in de sectie inhoudelijke gegevens.
  2. De precisie van gegevens moet identiek blijven bij uitwisseling. Bijvoorbeeld 3,00 wordt niet 3,0 en februari 2015 wordt niet 2015.
  3. De FHIR narrative kan per configuratie afwijken. Deze hoeft niet identiek te zijn aan de narrative in de FHIR resource-instanties uit de testomgeving. De waarde in elementen moeten wel terugkomen in de narrative.
  4. De ordening van elementen als onderdeel van een uitgewisseld FHIR bericht is niet relevant. Denk bijvoorbeeld aan twee SNOMED CT codes.
  5. Het FHIR resource instance ID is niet relevant.

Gecodeerde concepten waarbij "anders" deel uitmaakt van de waardenlijst
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.

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

Labels van gegevens
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. Bij schermafdrukken moet een vertaaltabel van UI-label naar zib-label worden aangeleverd.

Waarde van gegevens
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.

2.4 Reconciliëren en ontdubbelen

Buiten deze kwalificatie vallen het kunnen reconciliëren en het kunnen ontdubbelen.

  • Reconciliëren: het samenvoegen van gegevens uit verschillende bronnen.
  • Ontdubbelen: het omgaan met dubbele gegevens uit verschillende bronnen.

Uitsluitend wordt het overnemen getoetst. Met overnemen bedoelen we het ongewijzigd kunnen opslaan van gegevens en onderlinge relaties.

2.5 Uit te voeren stappen en op te leveren materialen

Stappen-kwa-BgZ-msz-v2.0.1.png

Figuur 1. Samenvatting van de stappen die worden doorlopen om aan te tonen dat een systeem de BgZ kan sturen en kan ontvangen.

(PULL) LET OP! De use case met Raadplegen/Beschikbaarstellen is momenteel nog niet van toepassing, omdat het communicatiepatroon nog niet beschikbaar is.

Vastleggen

  1. Maak een nieuw dossier aan in uw XIS voor de fictieve patiënten A en B.
  2. 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.
  3. Maak schermafdrukken van de vastgelegde gegevens als integraal onderdeel van het dossier in uw XIS (fig 1c).
    • Onder de voorwaarden zoals vermeld in sectie 2.3 wordt er nagegaan of de gegevens overeenkomen met de gegevens uit de addenda (fig. 1d).

Leveren

  1. Stel FHIR resource-instanties samen voor gegevens uit alle BgZ-hoofdstukken. Hiervoor zijn deelkwalificaties mogelijk. Maak hierbij gebruik van:
  2. Lever de FHIR-resource-instanties aan zoals afgesproken bij de intake (fig. 1e).
    • Onder de voorwaarden vermeld in sectie 2.3 wordt nagegaan of de gegevens overeenkomen met de FHIR instanties in de testomgeving (fig. 1f).
    • Dit is naar voorbeeld van de gegevens zoals beschreven in de addenda inhoudelijke gegevens (fig. 1g), beginnend bij Patient A.

Inzien

  1. De simulator stuurt FHIR resource-instanties (fig. 1j).
    • De test server bevat de transactie gegevens zoals beschreven in de sectie inhoudelijke gegevens (fig. 1h).
  2. 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.
  3. Maak schermafdrukken van de ontvangen BgZ hoofdstukken (fig. 1k).
    • Onder de voorwaarden vermeld in sectie 2.3 wordt nagegaan of de gegevens overeenkomen met de gegevens uit de addenda (fig. 1m).

Overnemen

  1. Het ontvangende/ raadplegende system neemt de gegevens in de BgZ hoofdstukken ongewijzigd over (fig. n).
  2. Maak schermafdrukken van de overgenomen BgZ hoofdstukken als integraal onderdeel van het Dossier in het XIS (fig. 1o).
  3. Voeg de schermafdrukken toe aan het Kwalificatiemateriaal document.
    • Onder de voorwaarden vermeld in sectie 2.3 wordt nagegaan of de gegevens overeenkomen met de gestuurde gegevens (fig. 1p).


3 Release notes