Publiceren
Binnen het modulair ontwerp van VIPP Babyconnect zijn er verschillende implementatievarianten van het proces publiceren mogelijk. Hierin onderscheiden we de rollen Registrator (module A in het module model), Extractor (module B0 in het module model) en Convertor (module B1 in het module model). Zorgaanbieders moeten gegevens correct kunnen publiceren, dat wil niet zeggen dat het gebruikte bronsysteem zelf FHIR-resources moet kunnen leveren. (beschikbare output mag ook geconverteerd worden). Zie het Afsprakenstelsel voor meer informatie over dit proces en deze rollen.
Bronsystemen kunnen incrementeel ontsloten worden aan de hand van een groeipad. Bijvoorbeeld:
Prio1: minimale set aan gegevens die relevant is tijdens een acute situatie
Huidige afspraak (2023) voor verloskunde: kernset +
Prio2: gegevens in PDF/A, bijvoorbeeld een bevalverslag.
Het relevante deel van de Integrale zwangerschapskaart
De rest van het relevante deel van PWD 3.2
Uitgangspunten
Deze testen vinden plaats in de productieomgeving van de leverancier gekoppeld aan de testomgeving InteropLab.
Bij een SaaS-systeem (verloskunde, kraam) wordt per bronsysteem getest. (Niet de zorgverlener of de zorgaanbieder.) Dit testwerk gebeurt door een kartrekker-regio tijdens de eerste implementatie.
Reden hiervoor is, dat alle gebruikers van een SaaS systeem, gebruik maken van dezelfde omgeving. Als een SaaS systeem eenmaal getest en goed bevonden is, geldt dat voor alle gebruikers van dat systeem. (SaaS = Software as a Service)
Bij on-premise-oplossingen (echo, ziekenhuis) wordt per bronsysteem én zorgaanbieder getest, niet de zorgverlener. Dit testwerk zal dus door alle zorgaanbieders die gebruikmaken van dit systeem moeten worden uitgevoerd.
Reden hiervoor is, dat gebruikers van een on premise systeem, gebruik maken van hetzelfde systeem bij die zorgaanbieder. Dat systeem kan echter volledig afwijken van een systeem bij een andere zorgaanbieder, terwijl het van dezelfde leverancier afkomstig is en dezelfde naam draagt.
Afwijkend hiervan zijn systemen die wel on-premise draaien, maar toch dezelfde uitvoering zijn. Voorbeeld hiervan is HIX standaard content.
Er hoeft niet gewacht te worden met testen totdat het bronsysteem het relevante deel van het volledige PWD kan publiceren. Er kan begonnen worden met het testen van bijv. Prio1, afhankelijk van het beoogde groeipad.
Aanpak bij publiceren FHIR
Een zorgverlener legt samen met een informatieanalist van Nictiz, een applicatiespecialist en eventueel de CMIO van VIPP Babyconnect, vastgestelde sets van gegevens (use-cases) vast in unieke velden van het bronsysteem.
De set van gegevens wordt vanuit het bronsysteem volgens één van de implementatievarianten gepubliceerd naar de testomgeving als FHIR-resources.
Bij variant “direct FHIR” ga naar stap 3
Bij variant “via een convertor”
De XML output van het XIS, wordt vergeleken met de vastgestelde testset
Hiervoor wordt een XML test tool gebruikt van ZW Connect
Als de vergelijking ok is, ga dan door naar volgende stap, Als niet ok, dan terug naar het XIS, voor reparaties uit en start de test opnieuw
De XML output van het XIS wordt ook door de convertor gehaald, en verder naar stap 3
De gepubliceerde FHIR-resources worden vergeleken met de fixtures.
De FHIR resources worden zowel semantisch, als syntactisch gevalideerd.
Hiervoor InteropLab gebruikt
Er wordt gecontroleerd of logging correct heeft plaatsgevonden: is er inzichtelijk wie er wat wanneer heeft gepubliceerd?
De resultaten van de test worden gerapporteerd.
Om dit geheel te monitoren wordt het gereedschap InteropLab toegepast. Binnen InteropLab worden de testen uitgevoerd en de resultaten gerapporteerd.
Aanpak bij publiceren PDF/A
Een zorgverlener legt samen met een informatieanalist van Nictiz en eventueel de CMIO van VIPP Babyconnect een vastgestelde set van gegevens vast in unieke velden van het bronsysteem. (use cases)
De set van gegevens wordt vanuit de bronsysteem volgens één van de implementatievarianten gepubliceerd naar de testomgeving als PDF/A.
De inhoud van de PDF/A worden vergeleken met de patiënt journeys.
De resultaten van de test worden gerapporteerd.
Resultaten
SaaS oplossing: bij akkoord is het bronsysteem gekwalificeerd voor het publiceren van de geteste dataset.
On-premise oplossing: bij akkoord is de combinatie zorgaanbieder-bronsysteem gekwalificeerd voor publiceren van de geteste dataset.
De resultaten van de test zijn gepubliceerd in InteropLab, en zijn inzichtelijk voor de deelnemers, de overige regio’s, het landelijk programmabureau, Nictiz en ministerie VWS.
Specifiek voor het testen van publiceren is er een testomgeving: InteropLab. Dit is een testsysteem voor het uitvoeren van conformiteits- en interoperabiliteitstesten tegen gepubliceerde projectspecificaties en standaarden, zoals FHIR. Hiermee kunnen zowel de transacties als de content van de transacties gevalideerd worden.
Het is binnen InteropLab tevens mogelijk om de implementatie van generieke functies zoals lokalisatie en adressering te testen. Bij de eerste implementatie wordt door alle regio’s gebruik gemaakt van HINQ. Omdat HINQ een ingebouwde techniek heeft voor lokalisatie en adressering hoeft deze niet extern getest te worden. Daarnaast zijn de normen voor de generieke functies nog niet gereed (gepland gereed 2025)
De uit te voeren testen worden uitgewerkt in testscripts en de behaalde testresultaten zijn inzichtelijk in rapportages, beide vormen het testprotocol. Het is binnen InteropLab mogelijk om verschillende gescheiden omgevingen te creëren, bijv. eigen omgevingen per regio, per leverancier, etc.
0 Comments