MERK: dette er mal for tester som gjennomføres, testene kan derfor endres noe når leverandør oversender løsningsbeskrivelse for API-integrasjonen til NHN.
Det forventes at følgende fagmiljøer kjenner innholdet i testene:
Kjernejournal (KJ) test-, teknisk team og driftsteam
Leverandørenes prosjekt- og testledere
Integrasjonstest gjennomføres for å sikre at det kliniske fagsystemet har implementert tilstrekkelig teknisk validering av kommunikasjonen mot KJ. Mer informasjon om bakgrunn for testene kan leses her.
Oppfyllelse av integrasjonskrav
Det som testes er:
at det kliniske fagsystemer bruker TLSv1.2* i kontakten med KJ
at det kliniske fagsystemet sender med
X-EPJ-System
-header med korrekt informasjon
ID | Teststeg | Forventet resultat | Faktisk resultat |
---|---|---|---|
1 | Logg inn i det kliniske fagsystemet, søk opp en pasient og trigg API-kall mot KJ. | Det kliniske fagsystemet:
Dette verifiseres i logger av NHN. |
*Transport Layer Security (TLS) er kryptografiske protokoller som gir kommunikasjonssikkerhet over et datanettverk.
Håndtering av feil fra KJ
Det som testes er:
at det kliniske fagsystemet viser feilmeldinger fra KJ til bruker
at det kliniske fagsystemet logger feilmeldinger fra KJ, for feilsøking
ID | Teststeg | Forventet resultat | Faktisk resultat |
---|---|---|---|
1 | Deaktiver virksomheten i KJ, slik at den ikke har tilgang (utføres av NHN). | ||
2 | Søk frem en pasient i det kliniske fagsystemet. Trigg API-kall mot KJ. |
| |
3 | Aktiver virksomheten igjen, men legg inn sperring mot aktuell sluttbruker på aktuell pasient (utføres av NHN). | ||
4 | Søk frem en pasient i det kliniske fagsystemet. Trigg API-kall mot KJ. |
|
TLS-sertifikat
Det som testes er:
at det kliniske fagsystemet håndterer sertifikatbytte på KJ
at det kliniske fagsystemet validerer sertifikatene i koblingen mot KJ
at sluttbruker får feilmelding når API-kall til KJ ikke lar seg utføre
ID | Teststeg | Forventet resultat | Faktisk resultat |
---|---|---|---|
Scenario 1 | Bytte av TLS-sertifikat på API. | ||
1 | NHN bytter ut TLS-sertifikatet på API-et med et nytt gyldig TLS-sertifikat. | ||
2 | Trigg API-kall mot KJ i det kliniske fagsystemet. |
| |
Scenario 2 | Negativ test: TLS–sertifikat for feil server på API. | ||
1 | NHN bytter ut TLS-sertifikatet på API-et med et sertifikat som er utstedt til feil adresse. | ||
2 | Trigg API-kall mot KJ i det kliniske fagsystemet. |
| |
Scenario 3 | Negativ test: TLS–sertifikat utstedt av ugyldig utsteder på API. | ||
1 | NHN bytter ut TLS-sertifikatet på API-et med et sertifikat som er utstedt av en ugyldig utsteder. | ||
2 | Trigg API-kall mot KJ i det kliniske fagsystemet. |
| |
Scenario 4 | Negativ test: Revokert TLS-sertifikat på API. | ||
1 | NHN bytter ut TLS-sertifikatet på API-et med et sertifikat som er revokert. | ||
2 | Trigg API-kall mot KJ i det kliniske fagsystemet. |
|
Pålogging av sluttbruker i det kliniske fagsystemet
Det kliniske fagsystemets funksjonalitet for bytte av bruker avgjør hvilke deler av testen som er aktuell
Det som testes er:
at det kliniske fagsystemet håndterer bytte av bruker ved API-kall til KJ
at det kliniske fagsystemet håndterer API-oppslag mot KJ korrekt ved flere innloggede brukere samtidig
Scenario 1 går på sluttbrukerbytte med utlogging, mens scenario 2 går på flere samtidige innloggede sluttbrukere og byttet mellom disse. Hvilke(t) scenario(er) som er nødvendige, vil variere basert på funksjonaliteten til det kliniske fagsystemet.
ID | Teststeg | Forventet resultat | Faktisk resultat |
---|---|---|---|
Scenario 1 | |||
1 | Logg inn i det kliniske fagsystemet med sluttbruker A, søk opp en pasient og trigg API-kall til KJ. Evt. autentiser vha. HelseID (ikke aktuelt ved single sign on). |
| |
2 | Logg sluttbruker A ut av det kliniske fagsystemet. | ||
3 | Logg inn i det kliniske fagsystemet med sluttbruker B, søk opp en pasient og trigg API-kall til KJ. |
| |
Scenario 2 | |||
1 | Logg inn i det kliniske fagsystemet med sluttbruker B, søk opp en pasient og trigg API-kall til KJ. Evt. autentiser vha. HelseID som sluttbruker B (ikke aktuelt ved SSO). | ||
2 | Lås det kliniske fagsystemet som sluttbruker B. | ||
3 | Logg inn i det kliniske fagsystemet med sluttbruker A, søk opp en pasient og trigg API-kall til KJ. Evt. autentiser vha. HelseID som sluttbruker A (ikke aktuelt ved SSO). |
| |
4 | Lås det kliniske fagsystemet som sluttbruker A. | ||
5 | La sluttbruker B åpne det kliniske fagsystemet igjen. | ||
6 | Søk opp en pasient og trigg API-kall til KJ. | To gyldige utfall:
Feilet utfall:
|
Pålogging av bruker ved bytte av virksomhet i det kliniske fagsystemet
Det kliniske fagsystemets funksjonalitet for bytte av bruker avgjør om testen bortfaller
Det som testes er:
at det kliniske fagsystemet håndterer bytte av virksomhet ved API-kall til KJ.
Forutsetning:
Det kliniske fagsystemet har støtte for flere virksomheter, og ut/innlogging uten re-start.
ID | Teststeg | Forventet resultat | Faktisk resultat |
---|---|---|---|
1 | Logg inn i det kliniske fagsystemet med sluttbruker som tilhører virksomhet A, søk opp en pasient og trigg API-kall. Evt. autentiser vha. HelseID (ikke aktuelt ved single sign on). |
| |
2 | Logg sluttbruker ut av det kliniske fagsystemet. | ||
3 | Logg inn i det kliniske fagsystemet med samme sluttbruker, på virksomhet B, søk opp en pasient og trigg API-kall. Evt. autentiser vha. HelseID (ikke aktuelt ved single sign on). |
|
Test av asynkron håndtering av responser
Kun aktuell for web-baserte fagsystemer
På den moderne weben er mange operasjoner asynkrone, og det er ikke gitt at ting alltid skjer i samme rekkefølge som de vanligvis gjør. Tregheter på nettverk kan medføre at ett kall plutselig tar mye lenger tid enn normalt, mens det neste kallet kanskje går raskt. Det er derfor viktig at applikasjonen håndterer at responser kommer i en unaturlig rekkefølge, og validerer at en respons hører til den aktuelle konteksten, evt. avbryter pågående operasjoner når svaret ikke lenger er aktuelt.
Det som testes er:
at et web-basert klinisk fagsystem ikke blander responser tilhørende forskjellige pasienter
Forutsetning:
To pasienter, pasient A har data i KJ, pasient B har ikke data i KJ
Developer tools åpen i nettleser
ID | Teststeg | Forventet resultat | Faktisk resultat |
---|---|---|---|
1 | NHN legger inn en kunstig treghet på oppslag mot pasient A. |
|
|
2 | Trigg API-kall for pasient A. |
|
|
3 | Trigg API-kall for pasient B. |
|
|
4 | La vinduet med informasjonen til pasient B være åpen til svaret på pasient A returneres. |
|
|