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

1

Gjennomgang av tilgangsstyring

I det kliniske fagsystemet kan det konfigureres (ved utrulling) hvilken brukergruppe eller enkeltpersoner som skal ta i bruk KJ-integrasjonen

T.8

2

Autentisering av bruker ved API-kall

T.8, S.7

3

Demonstrer et API-kall til KJ

KJ svarer og data presenteres korrekt og brukervennlig for sluttbruker

F.11

4

Det skal komme tydelig frem at KJ er kilde til informasjonen som lastes ned

F.12

5

Ved kall til KJ:

Samtykke:

• Gis ved oppslag i KJ

• For åpning av sperret informasjon

Dialog for samtykke hvis fanen er sperret.

NHN sjekker i brukslogg at riktig samtykke er gitt

F.7, F.8

6

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.

T.23

7

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.

T.23

8

Når sluttbruker går inn i EPJ så skal det ikke være automatisk nedlastning fra KI-apiet. Sluttbruker MÅ gjøre en aktiv handling (eks. navigere til KI-fanen) for å initiere nedlastning. Dette dekkes av KJ-forskriften, men som et kontrollpunkt ønsker vi at dette vises i demo.

T.26 (utgått, men ønsker en stikkprøve på at EPJ følger KJ-forskriften)

9

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

F.9

10

Ved kritisk info-API

Mislykket opplastning/synkronisering med KJ via API

Dersom kommunikasjonen mellom KJ og fagsystemet er brutt skal dette varsles til bruker med feilmelding. Dersom bruddet har ført til at opplasting av data til KJ er mislykket skal fagsystemet tilby lokal lagring slik at nytt forsøk på opplasting kan gjøres senere. Slik lokalt lagret info må tydelig merkes som ikke opplastet til KJ.

Dersom opplasting til KJ mislykkes pga manglende påkrevet informasjon eller endring mislykkes pga samtidighetskonflikt skal bruker varsles og få anledning til ny opplasting etter at nødvendige endringer er gjort.

Kan også tas i del 2.

11

Ved kritisk info-API (funksjonelt)

Lokal kritisk info som har blitt samstemt med kjernejournal skal ikke kunne oppdateres i det kliniske fagsystemet uten at det synkront oppdateres med kjernejournal.

Ved oppdatering av lokal kritisk info som er samstemt med KJ i det klinisk fagsystem skal oppdatert informasjon sendes til KJ raskest mulig.

Informasjon som ikke er synket med KJ i det kliniske fagsystemet skal markeres som ikke synket med KJ frem til det er utført.

F.20

12

Ved kritisk info-API (teknisk)

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.

For hver opprett/oppdater/slett-operasjon skal det kliniske fagsystemet hente oppdatert data før det utfører skriveoperasjonen

Data regnes som oppdatert hvis nylig hentet timestamp fra Helseindikator-apiet fra KJ tilsier at lokale data allerede samsvarer med data i kjernejournal

T.30

NHN gjør endringer på pasienten under møtet.

13

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.

T.34

Leverandør skal beskrive dette i løsningsbeskrivelse for integrasjon.