ID | Type krav | Gjelder for type integrasjon (Portal / API) | API | Krav | Må-/bør-krav | Kommentar | Akseptansetest |
|---|
F.1 | Funksjonelt | Portal | | KJ-ikon (helseindikatorikon) presenteres synlig for brukeren i det kliniske fagsystemet. | Må | Ikoner lastes ned fra vedlegg i integrasjonsguide: Integration Guide Kjernejournal Portal | Demomøte (Akseptansetest del 1) |
F.2
| Funksjonelt | Portal | | KJ-ikon har en tooltip som gir bruker informasjon om personens KJ status. | Må |
| Demomøte (Akseptansetest del 1) |
F.3 | Funksjonelt | Portal | | Det kliniske fagsystemet skal tilby helsepersonell tilgang til KJ enten som en ny fane i det kliniske fagsystemet eller som et separat vindu som åpnes etter trykk på ”KJ-ikonet”. *minimumsstørrelse 960x640 | Må |
| Demomøte (Akseptansetest del 1) |
F.4 | Funksjonelt | Portal | | Brukeren skal enkelt kunne klippe og lime fra KJ til det kliniske fagsystemet ved hjelp av KJs kopier til utklipp-funksjonalitet. | Må |
| Demomøte (Akseptansetest del 1) |
F.5 | Funksjonelt | Portal | | PDF generert i KJ-portal må kunne lastes ned til lokal klient og bruker må ha tilgang til PDF-leser og ha mulighet for utskrift av PDF-filer. | Må |
| Demomøte (Akseptansetest del 1) |
F.6 | Funksjonelt | Portal | | For å ivareta pasientsikkerheten skal KJ portalen være tett knyttet til den åpne pasienten i EPJ-systemet, slik at det ikke oppstår forvirring om hvilken pasient som er åpen i KJ. | Må | For web-baserte kliniske fagsystemer vil ikke dette være fullstendig kontrollerbart, men ved å bruke windows.open og parameteret windowName kan det sørges for at den samme fanen benyttes hver gang man trykker på KJ-ikonet, gitt normale innstillinger i Chrome. Et alternativ kan være å benytte det returnerte objektet til å lukke eksisterende fane og så benytte windows.open på nytt.
Dette vil ikke garantere at det kliniske fagsystemet har full kontroll på faner med KJ, ettersom brukeren kan styre en del innstillinger i nettleser, eller klone flere faner manuelt. Det er likevel bedre enn at det åpnes nye faner fortløpende. | Akseptansetest del 2a: Integrasjonstest |
F.7 | Funksjonelt | API | Legemiddel API, FHIR Kritisk info API | Det kliniske fagsystemet må utvikle dialog med funksjonalitet for å angi samtykke for: | Må | Helsepersonell må alltid angi samtykke for oppslag i KJ.
| Demomøte API (Akseptansetest del 1) |
F.8 | Funksjonelt | API | Legemiddel API, FHIR Kritisk info API | Det kliniske fagsystemet må utvikle dialog med funksjonalitet for å angi samtykke for: | Må | Dersom responsen fra KJ opplyser om at det finnes sperret fane (eksempelvis legemiddelfane eller kritisk informasjonsfane) må sluttbruker kunne angi samtykke for åpning av fane og sende ny forespørsel til KJ med samtykke for åpning av sperret fane. I respons fra KJ vil informasjon i den sperrede fane fremkomme. Tekst som skal vises sluttbruker: Ved pasientens samtykke:
"Informasjonen hentes fra kjernejournal og lagres i pasientjournalen med pasientens samtykke. Pasienten har gitt sitt samtykke til at jeg kan få tilgang til informasjonen. " Ved akuttsituasjon:
"Det er en akuttsituasjon der pasienten ikke er i stand til å samtykke, og det er fare for liv og alvorlig helseskade. Jeg får tilgang til sperret informasjon, denne hentes fra kjernejournal og lagres i pasientjournalen" | Demomøte API (Akseptansetest del 1) |
F.9 | Funksjonelt | API | Legemiddel API | Det kliniske fagsystemet må utvikle dialog med funksjonalitet for å angi samtykke for: | Må | Dersom responsen fra KJ opplyser om at det finnes låste resepter må sluttbruker kunne angi samtykke for å låse opp låste resepter. I nytt kall mot KJ sendes det da samtykke for å åpne låste resepter. I responsen fra KJ vil låste resepter inkluderes. | Demomøte API (Akseptansetest del 1) |
F.10 | Funksjonelt | API | Legemiddel API, FHIR Kritisk info API | Det kliniske fagsystemet må vise resultatet av spørring etter informasjon i KJ på en brukervennlig måte. | Må |
| Demomøte (Akseptansetest del 1) |
F.11 | Funksjonelt | API | Legemiddel API, FHIR Kritisk info API | Det kliniske fagsystemet må vise resultatet av spørring etter informasjon i KJ komplett og korrekt. | Må | Komplett i denne sammenheng betyr at det kliniske innholdet må fremkomme komplett og korrekt, Metadata som ikke endrer betydningen av klinisk innhold kan håndteres i bakgrunnen og må ikke vises til bruker. | Demomøte (Akseptansetest del 1) |
F.12 | Funksjonelt | API | Legemiddel API, FHIR Kritisk info API | Når det gjøres oppslag mot KJ, og informasjon fra KJ hentes inn i det kliniske fagsystemet, skal det komme tydelig frem at KJ er kilden til informasjonen. | Må | Dersom informasjon fra KJ presenteres sammen med lokale felter skal det være tydlig for bruker hvilke felter som kun er lokale og hvilke som synkroniseres mot KJ. | Demomøte (Akseptansetest del 1) |
F.13 | Funksjonelt | API | FHIR Kritisk info API | Ved opplasting av informasjon til KJ skal det fremkomme i dialog til sluttbruker dersom: | Må | Ved manglende informasjon ved opplasting bør det presenteres en dialog til sluttbruker hvor manglende informasjon kan registreres. | Demomøte (Akseptansetest del 1) |
F.14 | Funksjonelt | API | FHIR Kritisk info API | 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. | Må | Når det ligger lokale registreringer som ikke er blitt lastet opp til KJ bør neste bruker som åpner samme informasjon få anledning til å forsøke en ny opplasting. Dette bør da være en manuelt styrt opplasting i tilfelle denne brukeren må rådføre seg eller kontrollere opplysningene før de lastes opp. | Demomøte (Akseptansetest del 1) |
F.15 | Funksjonelt | API | FHIR Kritisk info API | Når bruker gjør endringer eller nyregistreringer i felter som synkroniseres med KJ skal oppdatering sendes til KJ samtidig med at registreringen/endringen lagres lokalt. | Må | Opplasting til KJ skal skje automatisk og ikke være avhengig av en aktiv handling fra bruker. (For å hindre at endringer kun lagres lokalt og ikke opplastes til KJ) | Demomøte (Akseptansetest del 1) |
F.17 | Funksjonelt | API | Legemiddel API, FHIR 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. | Må | Å vise status ved symbol/ikon for ingen kontakt med API-el. feil i synkronisering skal sikre at brukeren er oppdatert om status mot kjernejournal. Samtidig bør det ikke hindre at informasjon kan fortsatt oppdateres lokalt i EPJ, dersom det er ønskelig. | Demomøte (Akseptansetest del 1) |
F.18 | Funksjonelt | API | FHIR Kritisk info API | Det kliniske fagsystemet bør sikre at helsepersonell ikke fører viktig informasjon som kritisk informasjon. | Bør | Det kliniske fagsystemet har en del viktig informasjon som man ønsker å ikke blande sammen med kritisk informasjon. Særlig relevant for fritekstfelt under verdien "kritisk medisinsk tilstand". | Ikke testbart |
F.19 | Funksjonelt | API | FHIR Kritisk info API | Det kliniske fagsystemet bør vise hjelpetekst for kodeverket for KI
(Eks: Kritisk medisinsk tilstand: "Skal bare benyttes unntaksvis"). | Bør | | Demomøte (Akseptansetest del 1) |
F.20 | Funksjonelt | API | FHIR Kritisk info API | Det kliniske fagsystemet må indikere for sluttbruker hvilke av de obligatoriske feltene (S-dataelementene/feltene i FHIR profil) som ikke er samstemt med kjernejournal. | Må | Skal vise konflikter mellom det kliniske fagsystemet og kjernejournal. Dette bidrar til effektivisering av synk jobben mellom det kliniske fagsystemet og kjernejournal. | Demomøte (Akseptansetest del 1) |
F.21 | Funksjonelt | API | FHIR Kritisk info API | Lokal kritisk info som er samstemt med kjernejournal skal ikke kunne oppdateres i det kliniske fagsystemet uten at det synkront oppdateres med kjernejournal. | Må | Det bidrar til å sikre en god datakvalitet i begge systemer, hvis det kliniske fagsystemet opererer med flere felter som dekker eldre data og nye informasjonen som er samstemt med kjernejournal. | Demomøte (Akseptansetest del 1) |
T.1 | Teknisk | Portal | | Når bruker klikker på KJ-ikonet skal det åpnes en intern nettleser som åpner URL-adressen til hentpasient med ticket:
https://kjernejournal.no/hpp-webapp/ hentpasient.html?ticket=<URL-enkodet ticket> | Må |
| Demomøte (Akseptansetest del 1) |
T.2 | Teknisk | Portal, API | | I kommunikasjonen med KJ skal det kliniske fagsystemet inkludere en "X-EPJ-System"-header som indikerer hvilket klinisk fagsystem, og hvilken versjon, det er som utfører kallet. | Må | As web based EHR systems isn’t able to add HTTP headers to the portal requests, they MAY send the X-EPJ-System parameter in the URL instead
| Akseptansetest del 2a: Integrasjonstest portalintegrasjon |
T.3 | Teknisk | Portal, API | | Pasienten skal være registrert i det lokale kliniske fagsystemets pasientregister med fødsels- eller D-nummer for å kunne åpne pasientens KJ (portal) eller lese/skrive informasjon fra/til pasientens KJ (API). | Må |
| Demomøte (Akseptansetest del 1) |
T.4 | Teknisk | Portal | | Det kliniske fagsystemet må benytte tjenesten hold sesjon som tilbys fra KJ. | Må |
| Akseptansetest del 2b: Avbruddstest portalintegrasjon |
T.5 | Teknisk | Portal | | Det kliniske fagsystemet må benytte tjenesten ”Logg av” som tilbys fra KJ når bruker logger av det kliniske fagsystemet. | Må |
| Akseptansetest del 2b: Avbruddstest portalintegrasjon |
T.6 | Teknisk | Portal | | Det kliniske fagsystemet må støtte at det lastes ned krypterte PDF-er fra KJ-nettleseren i det kliniske fagsystemet. PDF-en skal lagres i minnet og ikke til disk (alternativt slette PDF fra temp-mapper ved lukking/utlogging fra kliniske fagsystem) for å forhindre at informasjon blir tilgjengelig for andre brukere The EHR must support downloads of PDF's from the the KJ browser. The EHR must ensure that the PDF files are not stored longer than necessary since the files contains sensitive data. | Må |
| Demomøte (Akseptansetest del 1) |
T.7 | Teknisk | Portal, API | | Det kliniske fagsystemet skal ha en sentral konfigurerbar verdi som (de)aktiverer KJ-integrasjon i det kliniske fagsystemet. | Må |
| Demomøte (Akseptansetest del 1) KJEKSTERN-148 - Demomøte (Akseptansetest del 1) |
T.8 | Teknisk | Portal, API | | I det kliniske fagsystemet bør det være mulig, gjennom et grafisk brukergrensesnitt (ved utrulling) , å konfigurere hvilken brukergruppe eller enkeltpersoner som skal ha tilgang til KJ. | Bør | Da det er tilfeller hvor det er helsepersonellroller ved virksomheter som ikke har tjenstlig behov for kjernejournal bør disse heller ikke få tilgang på KJ portal eller API.
| Demomøte (Akseptansetest del 1) |
T.9 | Teknisk | Portal, API | | Kall til helseindikatortjenesten (både Webservice og REST) må implementeres slik at det kliniske fagsystemet ikke blir hengende dersom det ikke oppnås kontakt med KJ. | Må | Som et kall i egen tråd. | Akseptansetest del 2b: Avbruddstest portalintegrasjon |
T.10 | Teknisk | Portal | | Innebygd nettleser må skjule adressefelt | Må |
| Demomøte (Akseptansetest del 1) |
T.11 | Teknisk | Portal | | Innebygd nettleser må skjule knapperad | Må |
| Demomøte (Akseptansetest del 1) |
T.12 | Teknisk | Portal | | Innebygd nettleser må ha skrudd av mulighet for høyreklikk-funksjonalitet | Må |
| Demomøte (Akseptansetest del 1) |
T.13 | Teknisk | Portal | | Innebygd nettleser må støtte Ctrl + A, Ctrl + C og Ctrl + V | Må |
| Demomøte (Akseptansetest del 1) |
T.14 | Teknisk | Portal | | Når en pasientjournal lukkes i det kliniske fagsystemet må den tilhørende åpne KJ-portalen også lukkes. | Må |
| Demomøte (Akseptansetest del 1) |
T.15 | Teknisk | Portal | | Det må benyttes en nettleser som støttes av KJ. | Må | KJ støtter kun inntil to år gamle versjoner av Chrome og Edge. | Demomøte (Akseptansetest del 1) |
T.16 | Teknisk | Portal | | En oppgradering av nettleseren benyttet til KJ-portal bør ikke være avhengig av oppgradering av det kliniske fagsystemet. | Bør | Nettleseren som benyttes til KJ bør ikke være avhengig av oppgradering av selve det kliniske fagsystemet. Dersom oppdatering av nettleser krever en oppgradering av det kliniske fagsystemet forventes det hyppige oppdateringer slik at det tilstrebes at nettleser til enhver tid ikke er eldre enn 2 år. | Demomøte (Akseptansetest del 1) |
T.17 | Teknisk | Portal | | Integrert nettleser i EPJ skal ikke dele state (cookies, cache o.l.) med frittstående nettleser. Innlogging i KJ i EPJ skal ikke medføre at man blir logget inn i noen frittstående nettleser.
| Må | | Akseptansetest del 2a: Integrasjonstest portalintegrasjon |
T.18 | Teknisk | Portal, API | | Det kliniske fagsystemet må kunne benytte HelseID sitt API for å hente et access-token som brukes på KJs REST-API for henting av pasientens helseindikator. | Må | Se integrasjonsguide for detaljer om scope, audience og security_level | Akseptansetest del 2a: Integrasjonstest |
T.19 | Teknisk | Portal, API | | Det kliniske fagsystemet må kunne kalle KJs REST-API med access-token fra HelseID for henting av pasientens helseindikator. | Må |
| Akseptansetest del 2a: Integrasjonstest |
T.20 | Teknisk | Portal | | Det kliniske fagsystemet må kunne tolke alle 5 indikatorverdiene i JSON-respons og vise korrekt KJ-ikon i det kliniske fagsystemet. | Må | Se også GF1 | Demomøte (Akseptansetest del 1) |
T.21 | Teknisk | Portal | | Det kliniske fagsystemet må kunne hente ticket fra JSON-respons og bruke dette som URL-parameter ved åpning av KJ. | Må |
| Akseptansetest del 2a: Integrasjonstest |
T.22 | Teknisk | Portal, API | | Dersom det kliniske fagsystemet har både portal- og API-integrasjon skal det kliniske fagsystemet støtte at ticketen med samtykket fra API-oppslaget gjenbrukes ved senere portaloppslag på samme pasient. | Må | | Akseptansetest del 2a: Integrasjonstest |
T.23 | Teknisk | Portal, API | | Det kliniske fagsystemet må kunne tolke feilmeldinger fra KJs REST-API. Brukermeldingen skal presenteres for brukeren, og feilkoden skal logges. | Må | | Demomøte (Akseptansetest del 1) |
T.24 | Teknisk | Portal, API | | Det kliniske fagsystemet kan teste tilkobling mot KJ ved å kalle KJs ping-tjeneste med access-token fra HelseID. | Bør | For å teste at kommunikasjon fungerer, uten å faktisk hente helseinformasjon | - |
T.25 | Teknisk | Portal, API | | Det kliniske fagsystemet må bruke helsepersonellets aktuelle arbeidssted når det henter access-token fra HelseID, slik at oppslaget i KJ blir knyttet opp mot korrekt virksomhet. | Må | KJ knytter oppslaget opp mot virksomheten i tokenet fra HelseID. | Akseptansetest del 2a: Integrasjonstest |
T.26 | Teknisk | API | Legemiddel API, FHIR Kritisk info API | Det kliniske fagsystemet skal teknisk legge til rette for nedlasting av informasjon fra KJ via API automatisk | Må | Avhenger av sluttbrukers ønske om bruk av API, må kravet kan derfor falle bort.
| Demomøte (Akseptansetest del 1) |
T.27 | Teknisk | API | Legemiddel API, FHIR Kritisk info API | Det kliniske fagsystemet skal teknisk legge til rette for nedlasting av informasjon fra KJ via API ved manuell handling | Må | Sluttbruker skal i det kliniske fagsystemet manuelt kunne velge å laste ned informasjon fra KJ | Demomøte (Akseptansetest del 1) |
T.28 | Teknisk | API | FHIR Kritisk info API | API-integrasjonen må utvikles i tråd med den tekniske dokumentasjon/dokumentasjon av FHIR-API | Må | Integrasjonen skal være i tråd med FHIR-profiler beskrevet på Simplifier - https://simplifier.net/kjernejournalr4 | Demomøte (Akseptansetest del 1) |
T.29 | Teknisk | API | FHIR 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. | Bør | Integrasjonen skal være i tråd med FHIR-profiler beskrevet på Simplifier - https://simplifier.net/kjernejournalr4 Les Alert information FHIR profiles for Kritisk info-profiler. | Demomøte (Akseptansetest del 1) |
T.30 | Teknisk | API | FHIR 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. | Må | Integrasjonen skal være i tråd med FHIR-profiler beskrevet på Simplifier - https://simplifier.net/kjernejournalr4 Les Alert information FHIR profiles for Kritisk info-profiler. | Demomøte (Akseptansetest del 1) |
T.31 | Teknisk | API | FHIR 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. | Må | Hver gang helsepersonell åpner KI til en pasient skal det gå et kall til KJ for å sjekke om det er KI i KJ på pasienten.
Det kliniske fagsystemet bør kunne benytte timestampene i helseindikator-responsen for å avgjøre om de skal lese KI i KJ eller ikke. Dette skal sikre at man ikke kaller APIet mer enn det er nødvendig. | Demomøte (Akseptansetest del 1) |
T.32 | Teknisk | API | FHIR Kritisk info API | Når det kliniske fagsystemet viser KI, bør det også vise om de obligatoriske felter(altså "S" felter) er samstemt med kjernejournal eller ikke. | Bør | Dette er for å vise at man jobber med en eldre versjon av KI som kan skape utfordringer ved synkronisering med kjernejournal på et senere tidspunkt. Alle obligatoriske felt per profil finnes under følgende linken : https://simplifier.net/kjernejournalr4/~resources?category=Profile&sortBy=RankScore_desc Les Alert information FHIR profiles for Kritisk info-profiler. | Demomøte (Akseptansetest del 1) |
T.33 | Teknisk | API | Legemiddel API, FHIR Kritisk info API | Hvis en helsepersonell bytter virksomhet i det kliniske fagsystemet, må det gjøres virksomhet autentisering på nytt. | Må | Se også T.25. | Akseptansetest del 2a: Integrasjonstest |
T.34 | Teknisk | API | FHIR Kritisk info API | Dersom man 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. | Må | Dette kravet skal sikre at man har en mapping mellom 2 kodeverk og skal begrense mulighet for å få feil fra Kritisk info API. Kodeverk som er i bruk per felt per profil finnes under følgende linken : https://simplifier.net/kjernejournalr4/~resources?category=Profile&sortBy=RankScore_desc | Demomøte (Akseptansetest del 1) |
S.1 | Sikkerhet | Portal, API | | Det kliniske fagsystemet må benytte TLSv1.2 eller høyere. | Må |
| Akseptansetest del 2a: Integrasjonstest portalintegrasjon |
S.2 | Sikkerhet | Portal, API | | Det kliniske fagsystemet skal validere at sertifikatene i TLS-koblingene mot KJ er gyldige til formålet (godkjent utsteder, gyldig for korrekt hostnavn og gyldig dato). | Må | Dette håndteres normalt sett av underliggende biblioteker, men det må ikke deaktiveres av fagsystemet. | Akseptansetest del 2a: Integrasjonstest portalintegrasjon |
S.3 | Sikkerhet | Portal, API | | Det kliniske fagsystemet bør ikke godta revokerte sertifikater (hverken TLS eller virksomhetsertifikater). | Bør | Dette for å beskytte det kliniske fagsystemet i en eventuell feilsituasjon der sertifikatene til KJ mot formodning skulle bli kompromittert. | Akseptansetest del 2a: Integrasjonstest portalintegrasjon |
S.4 | Sikkerhet | Portal, API | | Nøkkel som benyttes i forbindelse med S.5 må oppbevares sikkert og med samme sikkerhetstiltak som ved oppbevaring av virksomhetssertifikater i virksomheten. | Må | Dette er i praksis et HelseID-krav, men KJ velger å peke på dette da det påvirker KJ-integrasjon. | - |
S.5 | Sikkerhet | Portal, API | | Det bør være enkelt å importere RSA-nøkler fra HelseID inn i det kliniske fagsystemet. | Bør | Dette er i praksis et HelseID-krav, men KJ velger å peke på dette da det påvirker KJ-integrasjon. | - |
S.6 | Sikkerhet | Portal, API | | Det bør være enkelt å oppdatere RSA-nøkler fra HelseID i det kliniske fagsystemet. | Bør | Dette er i praksis et HelseID-krav, men KJ velger å peke på dette da det påvirker KJ-integrasjon. | - |
S.7 | Sikkerhet | Portal, API | | Ved SSO for portalintegrasjon, og ved API-integrasjon, må det kliniske fagsystemet sørge for at sluttbruker autentiserer seg med høyeste sikkerhetsnivå herunder: Buypass, Commfides eller BankID. | Må |
| Demomøte (Akseptansetest del 1) |
