Akseptansetest del 1: Demomøte <navn>-API-integrasjon

MERK: dette er mal for tester som gjennomføres, testene kan endres etter behov etter mottatt løsningsbeskrivelse for API integrasjonen.

Formål:

Leverandør holder demo av kjernejournalintegrasjon i det kliniske fagsystemet, teststegene nedenfor benyttes som mal for demo. Resultatet av gjennomgang av test stegene avgjør om leverandør er klar for akseptansetest del 2 (integrasjons- og avbruddstest).

Ressurser:

Nøkkelressurser fra leverandør
Norsk helsenett (kjernejournal):
- Produkteier
- Løsningsarkitekt
- Sikkerhetsarkitekt
- Testleder
- Prosessleder/prosjektleder

ID	Teststeg	Forventet resultat	Kommentar
1	Gjennomgang av tilgangsstyring	I det kliniske fagsystemet kan det konfigureres (ved utrulling) hvilken brukergruppe eller enkeltpersoner som skal ta i bruk KJ-integrasjonen
2	Visning av hvordan konfigurering av tilgang til informasjon hentet fra KJ ved API gjøres i det kliniske fagsystemet	Det er en sentral konfigurerbar verdi som (de)aktiverer KJ-integrasjonen i det kliniske fagsystemet.
3	Autentisering av bruker ved API-kall
4	Demonstrer et API-kall til KJ	KJ svarer og data presenteres korrekt og brukervennlig for sluttbruker
5	Det skal komme tydelig frem at KJ er kilde til informasjonen som lastes ned
6	Informasjonen som lastes ned fra KJ til det kliniske fagsystemet presenteres komplett, oversiktlig og brukervennlig.
7	Ved kall til KJ: Samtykke: Dialogboks for angivelse av samtykke for oppslag i KJ Dialogboks for angivelse av samtykke for åpning av sperret informasjon	Dialogbokser presenteres sluttbruker som forventet
8	Ved kall til KJ: Blokkering mot helsepersonell: dersom pålogget bruker eller flere helsepersonell er blokkert mot aktuell pasientens KJ skal informasjon om dette presenteres i det kliniske fagsystemet ved hjelp av en forståelig melding.	Melding til sluttbruker vises.
9	Ved kall til KJ: Innbygger har reservert seg mot KJ: dersom pasienten ikke har KJ skal dette presenteres for helsepersonellet i det kliniske fagsystemet	Melding til sluttbruker vises.
10	Feilmeldinger fra KJ presenteres brukervennlig og forståelig til sluttbruker i det kliniske fagsystemet		Det er ikke garantert at en feilsituasjon oppstår under demo, dette testes også i akseptansetest del 2.
11	Det kliniske fagsystemet skal teknisk legge til rette for nedlasting av informasjon fra kjernejournal via API automatisk		Resultat avhenger av leverandørs implementasjon. Leverandør skal beskrive dette i løsningsbeskrivelse for integrasjon.
12	Det kliniske fagsystemet skal teknisk legge til rette for nedlasting av informasjon fra kjernejournal via API ved manuell handling		Resultat avhenger av leverandørs implementasjon. Leverandør skal beskrive dette i løsningsbeskrivelse for integrasjon.
13	Ved legemiddel-API: Låste resepter: dialogboks for angivelse av samtykke dersom en pasient har låste resepter samtykke sendes i ny forespørsel til KJ
14	Ved kritisk info-API Ved opplasting av informasjon til KJ skal det fremkomme i dialogboks til sluttbruker dersom: innslag ikke kan lastes opp - årsak skal fremkomme det er manglende påkrevd informasjon - hvilken informasjon som mangler skal fremkomme opplasting er mislykket opplasting er vellykket endring er mislykket endring er vellykket sletting er mislykket sletting er vellykket avkreft er mislykket avkreft er vellykket	Brukervennlig informasjon til sluttbruker. Ved manglende informasjon ved opplasting bør det presenteres en dialogboks til sluttbruker hvor manglende informasjon kan registreres. Dersom opplasting til KJ av en endring eller nyregistrering feiler skal bruker varsles (jfr krav F14) og få anledning til manuelt å forsøke på nytt eller å la registreringen bli liggende kun lagret lokalt. Registreringen må da tydelig markeres som ikke lastet opp til KJ. Bruker bør få en oppgave om å laste kritisk info opp til KJ i sin oppgaveliste.	Leverandør skal beskrive dette i løsningsbeskrivelse for integrasjon.
15	Ved kritisk info-API Ved endringer eller nyregistreringer i felter som synkroniseres med KJ skal oppdatering sendes til KJ samtidig med at registreringen/endringen lagres lokalt.		Leverandør skal beskrive dette i løsningsbeskrivelse for integrasjon.
16	Ved kritisk info-API Det kliniske fagsystemet bør vise hjelpetekst for kodeverket for KI (Eks: Kritisk medisinsk tilstand: "Skal bare benyttes unntaksvis").		Leverandør skal beskrive dette i løsningsbeskrivelse for integrasjon. Dette er et bør krav
17	Ved kritisk info-API Lokal kritisk info som har blitt samstemt med kjernejournal skal ikke kunne oppdateres i det kliniske fagsystemet uten at det synkront oppdateres med kjernejournal.		Leverandør skal beskrive dette i løsningsbeskrivelse for integrasjon.
18	Ved kritisk info-API For hver opprett/oppdater/slett-operasjon er det nødvendig at det kliniske fagsystemet kaller lese-API. Dette er viktig for å unngå duplisering av data og å forbedre kvaliteten på kritisk informasjon.		Leverandør skal beskrive dette i løsningsbeskrivelse for integrasjon.
19	Ved kritisk info-API Det kliniske fagsystemet må kunne benytte timestampene i helseindikator-responsen for å avgjøre om de skal lese KI i KJ eller ikke.		Leverandør skal beskrive dette i løsningsbeskrivelse for integrasjon.
20	Ved kritisk info-API Når det kliniske fagsystemet viser KI for sluttbruker, bør det markeres om de obligatoriske feltene ("S" felter i FHIR profil) er samstemt med kjernejournal eller ikke.		Leverandør skal beskrive dette i løsningsbeskrivelse for integrasjon. Dette er et bør krav
21	Ved kritisk info-API Dersom det kliniske fagsystemet benytter et annet kodeverk i det kliniske fagsystemet enn det som er gyldig på kritisk info-elementet, må man sikre 1-1 mapping mellom 2 kodeverk.		Leverandør skal beskrive dette i løsningsbeskrivelse for integrasjon.
22	Ved kritisk info-API Dersom kontakten mellom det kliniske fagsystemet og KJ er brutt (og KI synkroniseres) ved bruk av API, må dette kommuniseres ved hjelp avmelding til sluttbruker av det kliniske fagsystemet.		Leverandør skal beskrive dette i løsningsbeskrivelse for integrasjon.
23	Ved kritisk info-API Det kliniske fagsystemet må kunne benytte timestampene i helseindikator-responsen for å avgjøre om de skal lese KI i KJ eller ikke.		Leverandør skal beskrive dette i løsningsbeskrivelse for integrasjon.
24	Ved kritisk info-API KJ fungerer som et nasjonalt sentralt arkiv for kritisk informasjon og det kliniske fagsystemet opprettholder en lokal kopi av denne informasjonen. Kritisk informasjon i det kliniske fagsystemet kan være utdatert på grunn av at pasient har vært på andre steder og har fått oppdatert kritisk informasjonen sin. For det kliniske fagsystemet er det nødvendig å lese fersk informasjon fra KJ ved hjelp av API før pasientbesøk.		Leverandør skal beskrive dette i løsningsbeskrivelse for integrasjon. Bør krav