Skip to end of banner
Go to start of banner

Akseptansetest del 2a: Integrasjonstest

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

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:

  • benytter TLS 1.2 i koblingen mot KJ, både API og portal

  • sender med HTTP-header X-EPJ-System i alle HTTP-kall, både API og portal

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.

  • KJ-ikonet i det kliniske fagsystemet viser ikon med strek over.

  • Tooltip-en viser brukermelding fra respons: Virksomheten har ikke tilgang til kjernejournal (KJF-000227).

  • Feilkoden logges til systemlogg i det kliniske fagsystemet.

  • Øvrig bruk at det kliniske fagsystemet påvirkes ikke.

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.

  • Det kliniske fagsystemet fungerer uten noen endringer.

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.

  • KJ-ikonet i det kliniske fagsystemet viser ikon med strek over.

  • Tooltip-en viser en passende feilmelding.

  • Feilmelding logges til systemlogg i det kliniske fagsystemet.

  • Øvrig bruk at det kliniske fagsystemet påvirkes ikke.

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.

  • Integrert nettleser i det kliniske fagsystemet feiler ved åpning av portalen.

  • Sluttbruker skal ikke få noen mulighet til å gå videre med ugyldig sertifikat.

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.

  • KJ-ikonet i det kliniske fagsystemet viser ikon med strek over.

  • Tooltip-en viser en passelig feilmelding.

  • Feilmelding logges til systemlogg i det kliniske fagsystemet.

  • Øvrig bruk at det kliniske fagsystemet påvirkes ikke.

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.

  • Integrert nettleser i det kliniske fagsystemet feiler ved åpning av portalen.

  • Sluttbruker skal ikke få noen mulighet til å gå videre med ugyldig sertifikat.

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.

  • KJ-ikonet i det kliniske fagsystemet viser ikon med strek over.

  • Tooltip-en viser en passelig feilmelding.

  • Feilmelding logges til systemlogg i det kliniske fagsystemet.

  • Øvrig bruk at det kliniske fagsystemet påvirkes ikke.

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.

  • Integrert nettleser i det kliniske fagsystemet feiler ved åpning av portalen.

  • Sluttbruker skal ikke få noen mulighet til å gå videre med ugyldig sertifikat.

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).

  • Sluttbruker A er logget inn i KJ.

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.

  • Uten SSO: man er ikke innlogget i KJ.

  • Ved SSO: man er logget på som sluttbruker B i KJ.

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.

  • Uten SSO: man er ikke innlogget i KJ.

  • Ved SSO: man er logget på som sluttbruker A i KJ.

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:

  • Sluttbruker B er logget inn i KJ.

  • Sluttbruker B må logge på KJ på nytt.

Feilet utfall:

  • KJ-portal vises med sluttbruker A.

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).

  • Sluttbruker er tilknyttet virksomhet A i KJ.

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.

  • Uten SSO: man er ikke innlogget i KJ.

  • Ved SSO: sluttbrukeren er tilknyttet virksomhet B i KJ.

4

Logg inn i KJ (ikke aktuelt ved single sign on).

  • Sluttbruker blir tilknyttet virksomhet B i KJ.

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.

  • KJ-ikonet vises som normalt, og gjenspeiler pasient A.

2

Trykk på KJ-ikonet og evt. logg inn i KJ.

  • Det er pasient A som vises i KJ.

3

Bytt til pasient B i det kliniske fagsystemet, uten å aktivt logge ut av KJ.

  • KJ-ikonet vises som normalt, og gjenspeiler pasient B.

4

Trykk på KJ-ikonet.

  • Det er pasient B som vises i KJ.

Å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.

  • Bruker er ikke logget inn i ID-porten, og må logge inn som normalt.

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.

  • Forespørselen mot KJ blir hengende.

  • Indikatorikonet oppdateres ikke i henhold til innhold i KJ.

3

Søk frem pasient B i det kliniske fagsystemet.

  • Indikatorikonet oppdateres i henhold til innhold i KJ.

4

La pasient B være åpen til svaret på pasient A returneres.

  • Indikatorikonet endres ikke - indikatorikonet for pasient B vises fortsatt.

5

Trykk på KJ-ikonet.

  • KJ til pasient B åpnes.

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.

  • Hold sesjon-kallet går i bakgrunnen, ikke merkbart for bruker.

5

Trykk på KJ-ikonet og logg inn i KJ.

  • Bruker er fortsatt logget inn i KJ, så blir ikke bedt om å logge inn på nytt.

  • No labels