Akseptansetest del 2a: Integrasjonstest av <navn API> API-integrasjon

Owned by Kjernejournal systembruker
Last updated: 22 Nov, 2021
5 min read

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

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:

  • benytter TLS 1.2 i koblingen mot KJ

  • sender med HTTP-header X-EPJ-System i alle HTTP-kall

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

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.

  • Det kliniske fagsystemet presenterer brukermelding fra respons til sluttbruker: 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.

  • Det blir ikke gjort videre API-kall mot KJ, evt. sluttbruker får ikke mulighet til dette, på denne pasienten, før nytt indikatorkall er forsøkt.

 

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.

  • Det kliniske fagsystemet presenterer brukermelding fra respons til sluttbruker: Du er blokkert fra innsyn i denne pasientens kjernejournal.

  • Feilkoden logges til systemlogg i det kliniske fagsystemet.

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

 

 

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

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.

  • 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

Trigg API-kall mot KJ i det kliniske fagsystemet.

  • Ved forsøk på API-kall til KJ vises en passende feilmelding til sluttbruker.

  • Feilmelding logges til systemlogg i det kliniske fagsystemet.

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

 

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.

  • Ved forsøk på API kall til KJ vises en passende feilmelding til sluttbruker.

  • Feilmelding logges til systemlogg i det kliniske fagsystemet.

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

 

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.

  • Ved forsøk på API-kall til KJ vises en passende feilmelding til sluttbruker.

  • Feilmelding logges til systemlogg i det kliniske fagsystemet.

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

 

 

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

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

  • Oppslagene i KJ gjøres som sluttbruker A.

 

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.

  • Uten SSO: sluttbruker må autentisere seg. Oppslagene i KJ gjøres som sluttbruker B.

  • Ved SSO: Ingen autentisering nødvendig. Oppslagene i KJ gjøres som sluttbruker B.

 

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

  • Uten SSO: sluttbruker må autentisere seg. Oppslagene i KJ gjøres som sluttbruker A.

  • Ved SSO: Ingen autentisering nødvendig. Oppslagene i KJ gjøres som sluttbruker A.

 

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:

  • Sluttbruker B trenger ikke autentisere seg på nytt for å gjøre API-kall.

  • Sluttbruker B må autentisere seg på nytt for å gjøre et API-kall.

Feilet utfall:

  • Oppslagene i KJ gjøres som bruker A.

 

 

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

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

  • Oppslaget er tilknyttet virksomhet A i KJ.

 

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

  • Oppslaget er tilknyttet virksomhet B i KJ.

 

 

Test av asynkron håndtering av responser

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

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.

  • Forespørselen mot KJ blir hengende.

 

3

Trigg API-kall for pasient B.

  • Det kommer tilbake tom informasjon.

 

4

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

  • Informasjonen endres ikke.

 

 

© Norsk helsenett - kjernejournal