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

Uit informatiestandaarden
Ga naar: navigatie, zoeken
(Doelgroep (verwijzing?): verwijzing naar doelgroep kwalificatiepagina)
Regel 18: Regel 18:
 
Deze validatie-stap toetst geen infrastructurele eisen.  
 
Deze validatie-stap toetst geen infrastructurele eisen.  
  
== Doelgroep (verwijzing?)==  
+
== Doelgroep ==  
 
+
Zie [[BgZ:KwalificatieScript_BgZ_MSZ_2_0_0_beta_2#Doelgroep | kwalificatie pagina.]]
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.
 
  
 
== Algemene voorwaarden voor valideren ==
 
== Algemene voorwaarden voor valideren ==

Versie van 6 aug 2025 om 10:57


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

Zie kwalificatie pagina.

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