kwalificatie:Vissue-MM-3700 Handleiding Touchstone: verschil tussen versies
(Schrijf "Bearer token" op uniforme wijze) |
k (→Mock-authenticatie met vaste tokens: MM-3700: Kleine tekstuele wijzigingen.) |
||
Regel 59: | Regel 59: | ||
Het gebruik hiervan verschilt per rol die wil testen of kwalificeren: | Het gebruik hiervan verschilt per rol die wil testen of kwalificeren: | ||
* Voor clients die getest worden, is er per testpatiënt uit het scenario [https://github.com/Nictiz/Nictiz-testscripts/blob/main/Configuration/QualificationTokens.json een Bearer-token gedefinieerd]. De client dient deze tokens te gebruiken in elke request naar Touchstone/WildFHIR. | * Voor clients die getest worden, is er per testpatiënt uit het scenario [https://github.com/Nictiz/Nictiz-testscripts/blob/main/Configuration/QualificationTokens.json een Bearer-token gedefinieerd]. De client dient deze tokens te gebruiken in elke request naar Touchstone/WildFHIR. | ||
− | * Bij servers die getest worden, wordt er tijdens het aanmaken van de test gevraagd om een Bearer-token voor elke testpatiënt. Touchstone zal deze tokens gebruiken in de requests naar de server die getest wordt. | + | * Bij servers die getest worden, wordt er tijdens het aanmaken van de test gevraagd om een Bearer-token voor elke testpatiënt. Touchstone zal deze tokens gebruiken in de requests naar de server die getest wordt. Standaard zijn hier [https://github.com/Nictiz/Nictiz-testscripts/blob/main/Configuration/QualificationTokens.json de zelfde tokens] ingevuld die ook voor client-testen gebruikt worden, het staat gebruikers vrij om deze tokens over te nemen.<br />'''Let op''': De tokens moeten gedefinieerd worden als <q>Bearer<spatie>[token]</q>, bijvoorbeeld <q>Bearer 0aed465d-aab0-4417-9b3c-e6f635892fea</q> (zonder aanhalingstekens). |
[[Bestand:TouchstoneEnterToken.png|link=]] | [[Bestand:TouchstoneEnterToken.png|link=]] | ||
<section end="Tokens"/> | <section end="Tokens"/> | ||
<section begin="Aandachtspunten"/> | <section begin="Aandachtspunten"/> | ||
+ | |||
===Aandachtspunten=== | ===Aandachtspunten=== | ||
====USER_KEY en ORG_KEY weghalen in tickets==== | ====USER_KEY en ORG_KEY weghalen in tickets==== |
Huidige versie van 11 okt 2022 om 13:51
Dit is een tijdelijke pagina met wijzigingen voor issue MM-3700. De gepubliceerde versie vind je hier. |
Dit is een werkpagina. |
1 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.
1.1 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.
1.2 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.
2 Touchstone-account
2.1 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.
2.2 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.
3 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.
4 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.
5 Mock-authenticatie met vaste tokens
De authenticatie-stap is geen onderdeel van de Touchstone-test. Authenticatie van de FHIR-requests via een Bearer-token wordt op Touchstone nagebootst door het gebruik van vaste, niet-verlopende tokens.
Het gebruik hiervan verschilt per rol die wil testen of kwalificeren:
- Voor clients die getest worden, is er per testpatiënt uit het scenario een Bearer-token gedefinieerd. De client dient deze tokens te gebruiken in elke request naar Touchstone/WildFHIR.
- Bij servers die getest worden, wordt er tijdens het aanmaken van de test gevraagd om een Bearer-token voor elke testpatiënt. Touchstone zal deze tokens gebruiken in de requests naar de server die getest wordt. Standaard zijn hier de zelfde tokens ingevuld die ook voor client-testen gebruikt worden, het staat gebruikers vrij om deze tokens over te nemen.
Let op: De tokens moeten gedefinieerd worden alsBearer<spatie>[token]
, bijvoorbeeldBearer 0aed465d-aab0-4417-9b3c-e6f635892fea
(zonder aanhalingstekens).
6 Aandachtspunten
6.1 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.
6.2 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.
6.3 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.
6.4 Infrastructuur
Bij het gebruik van Touchstone willen we de volgende punten onder de aandacht brengen:
- Touchstone maakt geen gebruik van tweezijdige TLS-authenticatie.
6.5 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
7 Variabele T datum
Test- en kwalificatiescenario's werken vaak met relatieve datums, bijvorbeeld "de afgelopen zes weken". Om dit te vertalen naar concrete datums tijdens het uitvoeren van een test wordt er in de functionele en technische testscripts gewerkt met een zogenaamde T-datum, bijvoorbeeld "T-400D" ofwel 400 dagen vóór de T-datum.
De T-datum is altijd de maandag van de week waarin getest wordt.
Bijvoorbeeld in 2022 is de T-datum in week 3 gelijk aan 17 januari 2022. Deze T-datum is in verschillende situaties relevant:
- Wanneer er tijdens het starten van een test gevraagd wordt om een "variabele T", is dit de datum die gebruikt dient te worden.
- Leveranciers die testgegevens in hun eigen systeem invoeren, dienen deze referentiedatum aan te houden om de concrete datums te berekenen.
- Wanneer er datums in requests gebruikt worden, dienen deze berekend te worden ten opzichte van de T-datum.
Elke maandag wordt de Nictiz WildFHIR-server geschoond en opnieuw gevuld met testgegevens op basis van deze T-datum.
7.1 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.