...
at det oppnås ingen kontakt med KJ (SYN timeout)
at forsøkene på kontakt med KJ avvises aktivt (TCP RST)at det oppnås kontakt med KJ, men er KJ er unaturlig treig til å svare
At KJ er utilgjengelig når man åpner en pasient
AT KJ er utilgjengelig når man er inne på en pasient
Mer informasjon om bakgrunn for testene kan leses her.
| Table of Contents |
|---|
SYN timeout ved åpning (avbrudd)
Det som testes er: T9(utgått) - Testen er ikke obligatorisk, men anbefales.
at det kliniske fagsystemet ikke påvirkes av at KJ er utilgjengelig, slik at sluttbruker kan utføre operasjoner i det kliniske fagsystemet som normalt
at det kliniske fagsystemet korrekt indikerer feil i kontakten med KJ
at sluttbruker får feilmelding når KJ ikke er tilgjengelig
Instruksjon til drift: Her forventes det at trafikken droppes mot ST2.
Forutsetning: To pasienter, pasient A
...
og pasient B
...
ID | Teststeg | Forventet resultat | Faktisk resultat |
|---|
Scenario 1
Instruksjon:
| |||
1 | Åpne pasient A | ||
2 | KJ blir utilgjengelig. |
ID
Teststeg
Forventet resultat
Faktisk resultat
Scenario 1
1
KJ blir utilgjengelig.
2
Trigg indikatorkall.
3 | Trigg indikatorkall i det kliniske fagsystemet. EPJ forsøker å gjøre en endring som de forsøker å laste opp |
Det er forventet at det tar litt tid før det kliniske fagsystemet mottar melding om at KJ er utilgjengelig, men det skal ikke være heng i det kliniske fagsystemet mens det pågår. |
Scenario 2
1
Åpne pasient A i det kliniske fagsystemet mens KJ er tilgjengelig.
2
Trigg API-kall til KJ.
3
Åpne pasient B i det kliniske fagsystemet.
4
KJ blir utilgjengelig.
5
Trigg API-kall til KJ.
Det feiler på en naturlig måte, etter en fornuftig tidsperiode.
Det skal ikke være tvil for sluttbruker at KJ er utilgjengelig.
Brukeren skal til enhver tid kunne avbryte operasjonen.
Informasjon fra KJ til pasient A skal ikke vises.
Aktiv avvisning ved åpning
Det som testes er:
at det kliniske fagsystemet ikke påvirkes av at KJ er utilgjengelig, slik at sluttbruker kan utføre operasjoner i det kliniske fagsystemet som normalt
at det kliniske fagsystemet korrekt indikerer feil i kontakten med KJ
at det kliniske fagsystemet korrekt håndterer feilet indikatorkall, og ikke forsøker videre API-kall
at sluttbruker får feilmelding når KJ ikke er tilgjengelig
4 | Bytt til pasient B |
|
Scenario 2
1
ID
Teststeg
Forventet resultat
Faktisk resultat
Scenario 1
1
Helseindikator-API-et til KJ blir utilgjengelig.
2
Trigg API-kall til KJ.
Ny pasient åpnes i det kliniske fagsystemet som normalt.
Det kliniske fagsystemet informerer sluttbruker om Ingen kontakt med kjernejournal.
Ingen heng i det kliniske fagsystemet.
Bruker kan navigere og utføre normale operasjoner.
Det blir ikke gjort videre API-kall mot KJ, evt. sluttbruker får ikke mulighet til dette, på denne pasienten.
Scenario 2
2
Ikke-helseindikator-API-ene til KJ blir utilgjengelig (hvilke(t) API(er) avhenger av leverandørs integrasjon).
3
Trigg API-kall til KJ.
Det feiler på en naturlig måte, etter en fornuftig tidsperiode.
Det skal ikke være tvil for sluttbruker at KJ er utilgjengelig.
|
2
KJ blir utilgjengelig.
3
Trigg videre API-kall.
Det feiler på en naturlig måte, etter en fornuftig tidsperiode.
Det skal ikke være tvil for sluttbruker at KJ er utilgjengelig.
Det er ingen heng i det kliniske fagsystemet. Sluttbruker kan navigere og utføre normale operasjoner.
Tregt svar ved åpning
Det som testes er:
at det kliniske fagsystemet ikke påvirkes av at KJ er utilgjengelig, slik at sluttbruker kan utføre operasjoner i det kliniske fagsystemet som normalt
at det kliniske fagsystemet korrekt indikerer feil i kontakten med KJ
at det kliniske fagsystemet korrekt håndterer feilet indikatorkall, og ikke forsøker videre API-kall
at sluttbruker får feilmelding når KJ ikke er tilgjengelig
Det er forventet at det tar litt tid før det kliniske fagsystemet mottar melding om at KJ er utilgjengelig, men det skal ikke være heng i det kliniske fagsystemet mens det pågår. | |||
5 | Aktiver trafikk som normalt | Alt blir tilgjengelig som før testen |