...
Nøkkelressurser fra leverandør
Norsk helsenett (kjernejournal):
Produkteier
Helsefaglig rådgiver
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.
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 |
F.11 | |
4 | 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.
F.12 | |
5 | Ved kall til KJ: Samtykke: |
|
|
Dialogbokser presenteres sluttbruker som forventet
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:
| Melding til sluttbruker vises. | T.23 |
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.
7 | Ved kall til KJ: Innbygger har reservert seg mot KJ:
| Melding til sluttbruker vises. | T.23 |
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.
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:
| F.9 |
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
10 | 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
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. |
Leverandør skal beskrive dette i løsningsbeskrivelse for integrasjon.
21
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. |
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
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. |
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.T.34 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