vpk:V4.0 Kwalificatie Touchstone

Introductie Touchstone

Om FHIR-implementaties van een informatiestandaard te beproeven en te kwalificeren is de Touchstone-simulatieomgeving beschikbaar. Dit is een online platform waarmee leveranciers zelf tests kunnen uitvoeren en validatieresultaten kunnen inzien. Nictiz stelt de hiervoor benodigde testscripts beschikbaar. Deze komen overeen met de functionele testscripts bij een informatiestandaard.

Algemene opmerkingen over het gebruik van de simulator:

De simulator is niet bedoeld voor loadtesten, maar voor inhoudelijke controles tegen informatiestandaarden;
Nictiz vraagt verantwoord gebruik van deze simulator, neem bij twijfel over gebruik contact op.

Testopzet client

Bij testen waar de FHIR-client het testobject is ziet de testopstelling er als volgt uit:

De opzet is hier als volgt:

De client is het testobject van de leverancier.
Touchstone staat in het midden en stelt testen/testscripts, logging, validatie en overzicht beschikbaar.
Daarachter staat een FHIR-server (WildFHIR) met de FHIR-profielen en testberichten passend bij de testscripts.

Testopzet server

Bij testen waar de FHIR-server het testobject is ziet de testopstelling er als volgt uit:

De opzet is hier als volgt:

Touchstone stelt testen/testscripts, logging, validatie en overzicht beschikbaar. Daarnaast is Touchstone ook een FHIR-client die interacties kan versturen volgens de testscripts.
De server is het testobject van de leverancier.

Touchstone-account

Account aanmaken

Leveranciers hebben een eigen bedrijfsaccount nodig voor hun organisatie op Touchstone. Er zijn verschillende abonnementsvormen beschikbaar, waaronder een gratis abonnement. Deze optie (Open) biedt die alle mogelijkheden om te kunnen testen en kwalificeren, maar kent wel limieten, onder meer het aantal tests dat per dag kan worden uitgevoerd.

Voor het aanmaken van een organisatie op Touchstone kunnen de stappen op https://touchstone.aegis.net/touchstone/userguide/html/registration/index.html gevolgd worden. Let er op dat de "Name" van de organisatie het liefst herkenbaar moet zijn voor Nictiz en dat er niet bijvoorbeeld de naam van een onderontwikkelaar wordt ingevuld. Dit vereenvoudigt het aanmeldproces.

Let erop dat Touchstone standaard e-mailadressen en de organisatie van geregistreerde gebruikers toont. Individuele gebruikers kunnen dit in de instellingen van hun account aanpassen.

Join Org Group

Het bedrijfsaccount moet vervolgens toegang krijgen tot de Nictiz-materialen. Dit gaat door lid te worden van de relevant "Org Group(s)". De Touchstone-handleiding beschrijft hoe een verzoek hiervoor kan worden ingediend. Nictiz zal vervolgens het verzoek voor toetreding goedkeuren. Merk op dat hierbij goedkeuring van één van onze medewerkers nodig is en er dus korte tijd overheen kan gaan. Nadat goedkeuring is verleend dient de gebruiker, als deze nog is ingelogd, uit te loggen en opnieuw in te loggen.

Om toegang te krijgen tot pre-kwalificatietesten moet de Org Group "Nictiz-Testing" worden geselecteerd.
Om toegang te krijgen tot kwalificatietesten moet de Org Group "Nictiz-Certify" worden geselecteerd.

Testsysteem aanmaken

De volgende stap is om het systeem dat getest moet worden als "Test System" te registreren in Touchstone. Volg hiervoor de stappen in de Touchstone-handleiding.

Bij het aanmaken dienen de volgende instellingen gebruikt te worden:

Specification: FHIR 3.0.2
Niet aanvinken: requires OAuth2. Voor testen en kwalificaties wordt er een fixed token gebruikt.
Can be viewed by: My organization groups
Can be executed against by: My organization groups
Supported profiles: maak de keuze tussen FHIR-server voor het verzendende XIS of FHIR-client voor het ontvangende XIS.

NB: als beide ondersteund wordt, is het aan te raden om daar twee losse Test Systems voor op te zetten.

Uitvoeren van testen

Leveranciers kunnen zelfstandig de scripts die Nictiz publiceert uitvoeren en de resultaten bekijken. Hoe dit moet, wordt uitgelegd in de Touchstone-documentatie.

De testmaterialen zijn te via de 'Test Definitions'-link, in de map 'FHIRSandbox/Nictiz/FHIR3-0-2-eOverdracht4.0'. De materialen zijn hierin als volgt georganiseerd:

Test versus Cert

De pre-kwalificatiematerialen en kwalificatiematerialen zijn onderverdeeld in twee verschillende mappen, respectievelijk genaamd 'Test' en 'Cert'. De zichtbaarheid van deze mappen is afhankelijk van de Org Group van de gebruiker (zie de uitleg hierboven).

Sending-XIS versus Receiving-XIS

De scripts om een zendend XIS te testen zijn te vinden in de submappen beginnend met 'Sending-XIS', de scripts om een ontvangend XIS te testen zijn te vinden in de submappen beginnend met 'Receiving-XIS'.

Receiving-XIS versus Receiving-XIS-NoManifest: De testscripts in de map 'Receiving-XIS' verwachten dat het ontvangende XIS de Composition-resources ophaalt met de $document-operation. Wanneer het ontvangende XIS dat niet doet, dienen de scripts in de map 'Receiving-XIS-NoManifest' gebruikt te worden. (Deze scripts missen de test op de allerlaatste update van de Task, dit houdt verband met een tekortkoming in FHIR TestScipt. Zie ticket EOVDR-201 voor details.)

-phase1-negotiation[x] versus -phase2-handoff

eOverdracht kent een aanmeldfase en een overdrachtfase. De scripts die eindigen op '-phase1-negotiation[x]' testen de aanmeldfase, de scripts die eindigen op '-phase2-handoff' testen de overdrachtfase. Deze scripts kunnen los van elkaar of na elkaar gebruikt worden.

De aanmeldfase-scripts voor het ontvangende XIS zijn bovendien opgeknipt in twee of drie delen, waarbij de 'knip' telkens zit na het ophalen van de Composition-resource en waar in de workflow typisch een handmatige actie verwacht wordt. Dit is gedaan vanwege een tekortkoming in FHIR TestScript, dat zou falen op het moment dat de resources opgehaald worden waarnaar de Composition verwijst (zie ticket EOVDR-201 voor details.) Door de scripts op te knippen, kan de tester het script starten op het moment dat de resources zijn opgehaald en de volgende stap in het proces vereist is.

1.x versus 1.xb

De scenario's eindigend op een 'b' zijn bedoeld om alleen de uitwisseling van de veertien overlappende zibs met de BgZ te testen, de scenario's zonder deze toevoeging zijn bedoeld voor de gehele eOverdracht. Dit komt terug in de namen van de scripts op Touchstone.

Bij het starten van een test op Touchstone moet aangegeven worden wat de client en server voor de RESTful-interacties zijn. Omdat de eOverdracht-transacties een notified pull-mechanisme gebruiken, is er sprake van twee clients en twee servers per test

Het zendend XIS heeft voor dataoverdracht de rol van server en voor notificaties de rol van client.
Het ontvangend XIS heeft voor notificaties de rol van client en voor dataoverdracht de rol van client.

Uitvoeren van testen voor het ontvangend XIS (receiving XIS)

Bij het starten van een test voor het ontvangend XIS moet de volgende informatie worden opgegeven:

Origin: het eigen Test System.
Destination: Kies hierbij voor "Nictiz – Nictiz WildFHIR V202001 - FHIR 3.0.2" (voor HTTP-verkeer) of "Nictiz – Nictiz WildFHIR MedMij V202001-TLS - FHIR 3.0.2" (voor HTTPS/TLS-verkeer).
NB: voor HTTPS/TLS wordt er gebruik gemaakt van Let's Encrypt certificaten.
variabele notificationEndpoint: Het endpoint voor de notificatie, als volwaardige URL (Touchstone speelt de rol van client voor de notificatie). Let op: de URL mag niet afgesloten worden met '/'.

Uitvoeren van testen voor het zendend XIS (sending XIS)

Bij het testen van een zendend XIS wordt tijdens het starten van een test om twee Origin's (client in RESTful-termen) en twee Destination's (servers in RESTful-termen) gevraagd. Hier moet de volgende informatie worden gebruikt:

Origin 1: AEGIS.net, Inc - TouchstoneFHIR.
Origin 2: Het eigen Test System.
Destination 1: Het eigen Test System.
Destination 2: Kies hierbij voor "Nictiz – Nictiz WildFHIR V202001 - FHIR 3.0.2" (voor HTTP-verkeer) of "Nictiz – Nictiz WildFHIR MedMij V202001-TLS - FHIR 3.0.2" (voor HTTPS/TLS-verkeer).
NB: voor HTTPS/TLS wordt er gebruik gemaakt van Let's Encrypt certificaten.
Variabele task-id: de Task.id van de eOverdracht-Task die is klaargezet bij het eigen Test System.

Aandachtspunten

USER_KEY en ORG_KEY weghalen in tickets

Bij het aanmaken van een ticket over Touchstone is het vaak zinvol om een deel van de (request)code mee te sturen ter verheldering van het probleem. Als deze vraag op een openbaar platform wordt gesteld (bv. een openbaar BITS/Jira-project) is het van belang dat de USER_KEYs en ORG_KEYs in deze transactie worden verwijderd (voor het opslaan van de tekst!). Deze keys zijn namelijk gebruiker/organisatie-specifiek en mogen niet voor derden zichtbaar zijn. Mocht dit toch gebeuren, laat het ons dan direct weten in het ticket. Het ticket zal dan worden verwijderd, met evt. een nieuwe clone waar de keys niet instaan zodat de vraag wel behandeld kan worden.

Volgorde van tests

Het kwalificatiescript vraagt om een vaste volgorde voor het sturen van requests, waar de informatiestandaard mogelijk meer ruimte laat om dit ook in een andere volgorde te doorlopen. Het is daarom van belang om bij het uitvoeren van testen op de kwalificatiesimulator de interacties uit te voeren in dezelfde volgorde waarin ze worden gevraagd in de testscripts.

Ophalen van references

Antwoorden uit de kwalificatiesimulator bevatten soms references naar extra informatie. Een voorbeeld uit de BGZ: <reference value="Practitioner/medmij-bgz-practitioner-ts-02"/>

Deze references zijn los op te halen bij de kwalificatiesimulator, maar omdat er een bepaalde volgorde van interacties wordt gevraagd, kan het tussendoor ophalen van references ervoor zorgen dat een test faalt. We raden in dat geval aan om: De references pas op te halen als de test op de kwalificatiesimulator is afgelopen. Het ophalen van references zal er dan niet meer voor zorgen dat testen falen.

Indien dat niet mogelijk is:

Testen 2 keer uit te voeren:

De test één keer uit te voeren zonder het ophalen van references. Het doel hierbij is om aan te tonen dat de applicatie de juiste interacties kan versturen die worden gevraagd in het testscript.
De test een tweede keer uit te voeren, maar dan zonder dat hiervoor een testexecutie is gestart op de kwalificatiesimulator. Tijdens deze test kunnen dan wel alle references tussendoor worden opgehaald. Het doel van deze test is om aan te tonen dat de applicatie goed om kan goed met de inhoud verstuurd tijdens de test, inclusief de los op te halen references.

Infrastructuur

Bij het gebruik van Touchstone willen we de volgende punten onder de aandacht brengen:

Touchstone maakt geen gebruik van tweezijdige TLS-authenticatie.

Vragen over uitvoer van testscript

Indien er vragen zijn over uitgevoerde testen is het voor ons van belang om gericht te kunnen terugvinden welke interacties er uitgewisseld zijn. Bij contact hierover vragen wij daarom om (indien mogelijk) een testexecutie uit te voeren op de kwalificatiesimulator. Stuur bij vragen daarover altijd de link mee naar de uitgevoerde testexecutie uit de History op Touchstone.

Een voorbeeld in schermprints:

Klikken naar History in Touchstone:

Ophalen van de link van de testexecutie uit de History:

De link van de testexecutie ziet er dan bijvoorbeeld zo uit: https://touchstone.aegis.net/touchstone/execution?exec=201904050520537715673006

Warnings tijdens profielvalidatie

In de testen voor Versturende XIS'en worden het Aanmeldbericht en Overdrachtbericht als FHIR document Bundle opgehaald. Op deze Bundle wordt vervolgens profielvalidatie toegepast. Op dit moment levert dat een groot aantal warnings op, het merendeel in de vorm van: Error in discriminator at Composition.section:[...]: no children, no type. Deze warnings lijken onterecht gegeven te worden en kunnen worden genegeerd.

Overige warnings moeten beschouwd worden als aanwijzing dat er een probleem is met de implementatie, maar dit hoeft niet daadwerkelijk het geval te zijn. De tester moet warnings dus kritisch bekijken en in staat zijn deze te verklaren.

Falende tests voor de "overlap BgZ"-testen

In de testen voor Versturende XIS'en worden de Composition resources voor het Aanmeldbericht en het Overdracht gevalideerd tegen de profielen voor de gehele eOverdracht. Dit betekent dat de validatie zal falen in situaties waarbij slechts de set van overlappende zibs met de BgZ wordt getest. Het resultaat van de validatiestap dient daarom kritisch geïnspecteerd te worden indien deze scenario's getest worden.

Variabele T datum

Test- en kwalificatiescenario's werken vaak met relatieve datums, die ervoor zorgen dat scenario's niet gedateerd raken. Een datum 'volgende week' blijft zodoende altijd in de toekomst. Om dit te vertalen naar concrete datums die gebruikt worden tijdens het testen en kwalificeren wordt gewerkt met de zogenaamde T-datum. De betekenis van deze T-datum en waar een deelnemer rekening mee moet houden bij het gebruik hiervan verschilt per rol. Voor iedere rol volgt hierna verdere uitleg.

Server: beschikbaarstellen (serve) en client: sturen (send)

Leveranciers die de inhoudelijke gegevens van test- en kwalificatiescenario's in hun bronsysteem invoeren ter voorbereiding op de Touchstone-tests voor beschikbaarstellen (serve) of sturen (send), bepalen een T-datum die zij hanteren bij het invoeren van alle gegevens.

Wanneer de bepaalde T-datum bijvoorbeeld '2022-01-01' is en de kwalificatiescripts spreken van 'T + 400D', berekent de leverancier de datum die 400 dagen ná de bepaalde T-datum ligt. Die datum wordt vervolgens in het bronsysteem ingevoerd bij het betreffende veld – in dit voorbeeld dus '2023-02-05'.

Mogelijke eenheden die gebruik worden bij het verrekenen van de T-datum zijn 'D' (dagen), 'M' (maanden) en 'Y' (jaren).

Wanneer er datums gebruikt worden in de testscenario's, die invloed hebben op de Touchstone-scripts, bijvoorbeeld in de zoekparameters van het scenario "Persoon 1 vraagt alle meetwaarden op in een periode ('T – 30D t/m T')", wordt ook bij het uitvoeren van het betreffende TouchStone-script gevraagd de bepaalde T-datum in te voeren. Touchstone berekent vervolgens zelf de exact benodigde datums. Als de T-datum van het Touchstone-script overeenkomt met die van de ingevoerde gegevens, worden de gevraagde resources opgeleverd.

De verwachting is dat een leverancier de gebruikte T-datum vermeldt bij het aanleveren van de materialen en dat deze datum correspondeert met de aangeleverde screenshots en Touchstone-testexecutie(s).

Server: ontvangen (receive) en client: ophalen (retrieve)

Leveranciers die gegevens ophalen of ontvangen tijdens het gebruik van Touchstone, ontvangen testberichten van WildFHIR. Elke maandag worden de gegevens op WildFHIR ververst, waarbij alle datums opnieuw worden berekend met de datum van die maandag als referentie.

Als een client gegevens ophaalt in de week van '2022-08-01', zal, indien het kwalificatiescript spreekt van een veld met als datum 'T + 400D', er een resource opgehaald worden waarin dat betreffende veld gevuld is met de datum '2023-09-05'.

Wanneer er datums gebruikt worden in de testscenario's, die invloed hebben op de Touchstone-scripts, bijvoorbeeld in de zoekparameters van het scenario "Persoon 1 vraagt alle meetwaarden op in een periode ('T – 30D t/m T')", wordt ook bij het uitvoeren van het betreffende Touchstone-script gevraagd de T-datum in te voeren. Hier dient dus de datum van de maandag uit de testweek te worden ingevuld. Touchstone berekent vervolgens zelf de exact benodigde datums. Als de T-datum van het Touchstone-script overeenkomt met de datum die gebruikt is tijdens het verversen van WildFHIR, worden de gevraagde resources opgeleverd.

De verwachting is dat een client tijdens kwalificatie in screenshots datums laat zien die corresponderen met gegevens die opgehaald zijn tijdens de aangeleverde Touchstone-testexecutie(s).

Tijdzones

In de FHIR-datatypes dateTime (indien uren en minuten worden gebruikt) en instant is het verplicht om een tijdzone in te vullen. De tijdzone kan daarom niet worden weglaten uit de testgegevens. Touchstone heeft helaas de beperking dat de Nederlandse tijdzone niet berekend kan worden aan de hand van de T-datum. De tijdzone die nu in onze testgegevens staat is daarom de Nederlandse tijdzone bij de eerste keer invullen van dit scenario met concrete datums. Dit komt niet per definitie overeen met de geldende tijdzone in Nederland voor de (in een testexecutie gebruikte, uiteindelijke) datum. In productie moet gerekend worden op een juiste tijdzone en het is dan ook juist om deze tijdzone gewoon te interpreteren, dit betekent dat de gegevens mogelijk soms een uur later of vroeger zijn dan in het addendum staat. Dit is geen reden voor afkeuren tijdens kwalificatie.