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 klikk på KJ-ikonet. Klikk på noen faner. | 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. |
|
Sertifikathåndtering - TLS-sertifikat
Det som testes er:
at det kliniske fagsystemets håndterer sertifikatbytte på KJ
at det kliniske fagsystemet validerer sertifikatene i koblingen mot KJ
at KJ-ikonet vises korrekt i uventede feilsituasjoner
at sluttbruker får feilmelding når KJ-portalen ikke lar seg åpne
ID | Teststeg | Forventet resultat | Faktisk resultat |
---|---|---|---|
Scenario 1 | Bytte av TLS-sertifikat, både på portal og API. | ||
1 | NHN bytter ut TLS-sertifikatet både på portal og API med et nytt gyldig TLS-sertifikat. | ||
2 | Åpne ny pasient, og åpne KJ-portalen 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 | Åpne ny pasient i det kliniske fagsystemet. |
| |
Scenario 3 | Negativ test: TLS–sertifikat for feil server på portalen. | ||
1 | NHN bytter ut TLS-sertifikatet på portalen med et sertifikat som er utstedt til feil adresse. | ||
2 | Klikk på KJ-ikonet i det kliniske fagsystemet. |
| |
Scenario 4 | 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 | Åpne ny pasient i det kliniske fagsystemet. |
| |
Scenario 5 | Negativ test: TLS–sertifikat utstedt av ugyldig utsteder på portalen. | ||
1 | NHN bytter ut TLS-sertifikatet på portalen med et sertifikat som er et sertifikat utstedt av en ugyldig utsteder. | ||
2 | Klikk på KJ-ikonet i det kliniske fagsystemet. |
| |
Scenario 6 | Negativ test: Revokert TLS-sertifikat på API. | ||
1 | NHN bytter ut TLS-sertifikatet på API-et med et sertifikat som er revokert. | ||
2 | Åpne ny pasient i det kliniske fagsystemet. |
| |
Scenario 7 | Negativ test: Revokert TLS-sertifikat på portalen. | ||
1 | NHN bytter ut TLS-sertifikatet på portalen med et sertifikat som er revokert. | ||
2 | Klikk på KJ-ikonet i det kliniske fagsystemet. |
|
Sesjonshåndtering ved bytte av sluttbruker i det kliniske fagsystemet
Det som testes er:
at det kliniske fagsystemet avslutter KJ-sesjonen når det byttes bruker
at det kliniske fagsystemet håndterer forskjellige KJ-sesjoner når det er 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 klikk på KJ-ikonet. Logg inn i KJ (ikke aktuelt ved single sign on). |
| |
2 | Logg sluttbruker A ut av det kliniske fagsystemet, uten å aktivt logge ut av KJ. | ||
3 | Logg inn i det kliniske fagsystemet med sluttbruker B, søk opp en pasient og klikk på KJ-ikonet. |
| |
Scenario 2 | |||
1 | Logg inn i det kliniske fagsystemet med sluttbruker B, søk opp en pasient og klikk på KJ-ikonet. Logg inn i KJ (ikke aktuelt ved single sign on). | ||
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 klikk på KJ-ikonet. |
| |
4 | Logg inn i KJ (ikke aktuelt ved single sign on). | ||
5 | Lås det kliniske fagsystemet som sluttbruker A. | ||
6 | La sluttbruker B åpne det kliniske fagsystemet igjen. | ||
7 | Søk opp en pasient og klikk på KJ-ikonet. | To gyldige utfall:
Feilet utfall:
|
Sesjonshåndtering ved bytte av virksomhet i det kliniske fagsystemet
Det som testes er:
at det kliniske fagsystemet avslutter KJ-sesjonen ved bytte av virksomhet.
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 klikk på KJ-ikonet. Logg inn i KJ (ikke aktuelt ved single sign on). |
| |
2 | Logg sluttbruker ut av det kliniske fagsystemet, uten å aktivt logge ut av KJ. | ||
3 | Logg inn i det kliniske fagsystemet med samme sluttbruker, på virksomhet B, søk opp en pasient og klikk på KJ-ikonet. |
| |
4 | Logg inn i KJ (ikke aktuelt ved single sign on). |
|
Håndtering av pasientkontekst
Det er kritisk at pasienten som vises i KJ alltid er den samme som er åpen i det kliniske fagsystemet. Dette skal sikre at helsepersonell ikke jobber med forskjellig pasient i det kliniske fagsystemet og i KJ.
Det som testes er:
at det kliniske fagsystemet gjør nytt indikatorkall ved bytte av pasient
at det kliniske fagsystemet gjør et nytt hentpasient-kall med ny ticket når det åpnes en ny pasient
Forutsetning:
To pasienter, pasient A har kritisk info, pasient B har ikke kritisk info
ID | Teststeg | Forventet resultat | Faktisk resultat |
---|---|---|---|
1 | Logg inn i det kliniske fagsystemet, søk opp pasient A. |
| |
2 | Trykk på KJ-ikonet og evt. logg inn i KJ. |
| |
3 | Bytt til pasient B i det kliniske fagsystemet, uten å aktivt logge ut av KJ. |
| |
4 | Trykk på KJ-ikonet. |
|
Åpning av frittstående nettleser samtidig med at sluttbruker er innlogget i KJ-portal
Det som testes er:
at integrert nettleser ikke deler state (cookies, cache o.l.) med frittstående nettleser
Forutsetning:
Innlogging til KJ gjøres med ID-porten.
Det kliniske fagsystemet er ikke en web-basert løsning.
ID | Teststeg | Forventet resultat | Faktisk resultat |
---|---|---|---|
1 | Logg inn i KJ ved hjelp av ID-porten. | ||
2 | Åpne opp nettleser (frittstående). | ||
3 | Naviger til f.eks altinn.no, og velg å logge inn. |
|
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 e.l. 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 kritisk info, pasient B har ikke kritisk info
Developer tools åpen i nettleser
ID | Teststeg | Forventet resultat | Faktisk resultat |
---|---|---|---|
1 | NHN legger inn en kunstig treghet på oppslag mot pasient A. | ||
2 | Søk frem pasient A i det kliniske fagsystemet. |
| |
3 | Søk frem pasient B i det kliniske fagsystemet. |
| |
4 | La pasient B være åpen til svaret på pasient A returneres. |
| |
5 | Trykk på KJ-ikonet. |
|
Test av hold sesjon
Det som testes er:
at hold sesjon-kall er implementert i henhold til integrasjonsguide
Forutsetning:
Bruker er aktiv i det kliniske fagsystemet, slik at det kliniske fagsystemet gjør hold sesjon-kall mot KJ.
Testen må vare lenge nok til at sesjonen i KJ vil bli avsluttet uten hold sesjon (20 minutter). Har det kliniske fagsystemet mulighet til å konfigurere opp hyppigheten av hold sesjon-kallet, kan KJ justere ned inaktivitetsgrensen, slik at testen kan gjennomføres raskere.
Hold sesjon testes også under avbruddstestene (akseptansetest del 2b), så det kan være greit å samkjøre de to testene: Brudd ved hold sesjon
ID | Teststeg | Forventet resultat | Faktisk resultat |
---|---|---|---|
1 | Søk frem pasient i det kliniske fagsystemet. | ||
2 | Trykk på KJ-ikonet og logg inn i KJ. | ||
3 | Lukk KJ-vinduet, og jobb med andre ting i det kliniske fagsystemet. | ||
4 | Fagsystemet gjør hold sesjon-kall. |
| |
5 | Trykk på KJ-ikonet og logg inn i KJ. |
|