ID | Type krav | Gjelder for type integrasjon (Portal / API/ WebEPJ) | API | Krav | Må-/bør-krav | Kommentar | Akseptansetest |
|---|
F.1 | Funksjonelt | Portal, WebEPJ | | KJ-ikon (helseindikatorikon) presenteres synlig for brukeren i det kliniske fagsystemet. | Må | Ikoner lastes ned fra vedlegg i integrasjonsguide:Integration Guide Kjernejournal Portal /wiki/spaces/KJERNEJOUR/pages/595820666 | Demomøte (Akseptansetest del 1) |
F.2
| Funksjonelt | Portal, WebEPJ | | KJ-ikon har en tooltip som gir bruker informasjon om personens KJ status. | Må |
| Demomøte (Akseptansetest del 1) |
F.3 | Funksjonelt | Portal, WebEPJ | | 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, WebEPJ | | 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 2: Integrasjonstest |
F.7 | Funksjonelt | API | Legemiddel API, FHIR Kritisk info API | Det kliniske fagsystemet må utvikle dialog med funksjonalitet for å angi samtykke for: | Må | Det kliniske fagsystemet må oppgi grunnlag for åpning av kjernejournal ved oppslag i eller henting av data fra kjernejournal | Demomøte API (Akseptansetest del 1) |
F.8 | Funksjonelt | API, WebEPJ | 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. Forslag til tekst som kan vises til sluttbruker ved akuttsituasjon: "Det er en akuttsituasjon der pasienten ikke er i stand til å samtykke, og det er fare for liv eller alvorlig helseskade. Jeg har tjenstlig behov for tilgang til sperret informasjon, denne hentes fra KJ og lagres i pasientjournalen". For WebEPJ ligger dette kravet som en del av innlogging med tillitsrammeverk som er en forutsetning for denne integrasjonen. | 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 bør vise resultatet av spørring etter informasjon fra KJ slik at ikke noe viktig klinisk meningsbærende innhold utelates. | Bør | 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 hvilke felter som synkroniseres med kjernejournal og hvilke som er lokale slik at sluttbruker forstår hva som lagres lokalt og hva som lagres i KJ. | Må | Dersom informasjon fra KJ presenteres sammen med lokale felter skal det være tydelig 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 i dialog til sluttbruker tydelig fremkomme deresom:
| 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 ved endring eller nyregistrering feiler, skal bruker varsles.
Det må være funksjonalitet for å manuelt forsøke på nytt, eller lokal lagring av registreringen. Dersom registreringen kun lagres lokalt skal dette 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 bør oppdatering sendes til KJ automatisk.
| Bør
| Opplasting til KJ bør 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)
|
F16
| Funksjonelt
| API
| FHIR Kritisk info API
| Ved blokkering av enkelte helsepersonell i KJ skal det vises en feilmelding. Feilmeldingen bør henvise til at informasjon er tilgjengelig i KJ Portal.
| | | |
F.17
| Funksjonelt
| API
| FHIR Kritisk info API
| Dersom kontakten mellom det kliniske fagsystemet og KJ er brutt (og kritisk informasjon synkroniseres) ved bruk av API, må dette kommuniseres ved hjelp av feilmelding til sluttbruker.
| Må
| Å vise status ved symbol/ikon for ingen kontakt med API-el. feil i synkronisering skal sikre at brukeren er oppdatert om status mot KJ. Samtidig bør det ikke hindre at informasjon kan fortsatt oppdateres lokalt i EPJ, dersom det er ønskelig.
Leverandør må beskrive i løsningsbeskrivelse hvordan dette håndteres.
| Demomøte (Akseptansetest del 1)
|
F.18 | Funksjonelt | API | FHIR Kritisk info API | Det kliniske fagsystemet bør vise hjelpetekst (i tooltip) for kodeverket for kritisk informasjon. | Bør | Her menes kodeverket for kritisk informasjon kategoriene “Smitte” og “Kritisk medisinsk tilstand”. Sendes med i FHIR-respons, under code.coding. For flere detaljer: KjConditionCriticalMedicalCondition profile og KjConditionInfection profile /wiki/spaces/KJERNEJOUR/pages/547062040 og /wiki/spaces/KJERNEJOUR/pages/546668853 | Demomøte (Akseptansetest del 1) |
F.19 | 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 KJ. | Må | Skal vise konflikter mellom det kliniske fagsystemet og KJ. Dette bidrar til effektivisering av synkjobben mellom det kliniske fagsystemet og KJ. | Demomøte (Akseptansetest del 1) |
F.20 | Funksjonelt | API | FHIR Kritisk info API | 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. | Må | Man må være obs på at hvis noen andre endrer samme info i KJ vil opplasting feile og de må endres før de får synket | Demomøte (Akseptansetest del 1) |
F.21 | Funksjonelt | API | FHIR 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. | Må | | 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, WebEPJ | | 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. Kan sendes som http-header eller URL | Må | For WebEPJ ligger dette kravet som en del av innlogging med tillitsrammeverk som er en forutsetning for denne integrasjonen. | Akseptansetest del 2 Integrasjonstest portalintegrasjon |
T.3 | Teknisk | Portal, API, WebEPJ | | 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, WebEPJ | | Det kliniske fagsystemet må benytte tjenesten hold sesjon som tilbys fra KJ. | Må |
| Akseptansetest del 2: Integrasjonstest portalintegrasjon |
T.5 | Teknisk | Portal, WebEPJ | | Det kliniske fagsystemet må benytte tjenesten ”Logg av” som tilbys fra KJ når bruker logger av det kliniske fagsystemet. | Må | For WebEPJ ligger dette kravet som en del av innlogging med tillitsrammeverk som er en forutsetning for denne integrasjonen.
| Akseptansetest del 2b: Avbruddstest portalintegrasjon |
T.6 | Teknisk | Portal, WebEPJ | | 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 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.
| Demomøte (Akseptansetest del 1) |
T.7 | Teknisk | Portal, API, WebEPJ | | 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, WebEPJ | | I det kliniske fagsystemet må det være mulig å konfigurere hvilken brukergruppe eller enkeltpersoner som skal ha tilgang til KJ | Må |
| Demomøte (Akseptansetest del 1) |
T.9
| Teknisk
| Portal, API
| | Kall til helseindikatortjenesten 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.
| Enkelte situasjoner testes i akseptansetest del 2 Integrasjonstest, men må også testes av leverandør.
|
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, WebEPJ | | Når en pasientjournal lukkes i det kliniske fagsystemet må den tilhørende åpne KJ-portalen også lukkes. | Må | Se kommentar tilhørende F.6 for web-basert EPJ.
| Demomøte (Akseptansetest del 1) |
T.15 | Teknisk | Portal,WebEPJ | | 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, WebEPJ | | 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, WebEPJ | | 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 2 Integrasjonstest |
T.19 | Teknisk | Portal, API, WebEPJ | | Det kliniske fagsystemet må kunne kunne kalle HelseId sitt API for å hente access token | Må | For WebEPJ ligger dette kravet som en del av innlogging med tillitsrammeverk som er en forutsetning for denne integrasjonen.
| Akseptansetest del 2 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å F.1 | Må | | 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 2: Integrasjonstest |
T.22 | Teknisk | Portal, API | | Dersom det kliniske fagsystemet både har portal- og API-integrasjon skal det kliniske fagsystemet støtte at ticketen med samtykket fra API-oppslaget gjenbrukes ved senere portaloppslag på samme pasient. | Bør | | Akseptansetest del 2a: Integrasjonstest |
T.23 | Teknisk | Portal, API, WebEPJ | | Det kliniske fagsystemet må kunne tolke feilmeldinger fra KJs APIer og feilkoden skal logges. | Må | | Demomøte (Akseptansetest del 1) Akseptansetest del 2 Integrasjonstest |
T.24 | Teknisk | Portal, API, WebEPJ | | 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, WebEPJ | | 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. Dette er viktig for KJ som logger hvilken virksomhet skjer oppslaget fra. For WebEPJ ligger dette kravet som en del av innlogging med tillitsrammeverk som er en forutsetning for denne integrasjonen. | Akseptansetest del 2 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 for 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/wiki/spaces/KJERNEJOUR/pages/547061989 for Kritisk info-profiler.
| Demomøte (Akseptansetest del 1)
|
T.30 | Teknisk | API | FHIR Kritisk info API | For hver opprett/oppdater/slett-operasjon skal det kliniske fagsystemet hente oppdatert data før det utfører skriveoperasjonen. | Må | Det er viktig å jobbe med oppdatert data for å unngå duplisering og for å forbedre kvaliteten på kritisk informasjon. Integrasjonen skal være i tråd med FHIR-profiler beskrevet på Simplifier - https://simplifier.net/kjernejournalr4 Les Alert information FHIR profiles /wiki/spaces/KJERNEJOUR/pages/547061989 for Kritisk info-profiler. Data regnes som oppdatert hvis nylig hentet timestamp fra Helseindikator-apiet fra KJ tilsier at lokale data allerede samsvarer med data i kjernejournal | 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 kritisk informasjon i KJ eller ikke. | Må | Hver gang helsepersonell åpner kritisk informasjon til en pasient skal det gå et kall til KJ for å sjekke om det er kritisk informasjon i KJ på pasienten.
Det kliniske fagsystemet må kunne benytte timestampene i helseindikator-responsen for å avgjøre om de skal lese kritisk informasjon 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 | Tidspunktet for synkronisering av kritisk informasjon bør være synlig for sluttbruker i det kliniske fagsystemet. | Bør | Dette er for å tydeliggjøre at kliniker jobber med en eldre versjon av kritisk Informasjon som kan skape utfordringer ved synkronisering med KJ på et senere tidspunkt. Ved et forsøk på synkronisering av utdaterte data vil det feile. Alle obligatoriske felt per profil står her: https://simplifier.net/kjernejournalr4/~resources?category=Profile&sortBy=RankScore_desc Les Alert information FHIR profiles /wiki/spaces/KJERNEJOUR/pages/547061989 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 virksomhetautentisering på nytt.
| Må
| Dekkes av 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 to kodeverk. | Må | Dette kravet skal sikre at man har en mapping mellom to 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) |
T.35 | Teknisk | API | FHIR Kritisk info API | Dersom det kliniske fagsystemet benytter et køsystem, må det benyttes en personlig bruker, ikke en systembruker, når data synkroniseres med KJ. | Må | Kravet gjelder både ved systembrudd og vanlige oppdateringer mot KJ da det ved opplasting til KJ skal tas stilling til data. Ved bruk av køsystem må konsument benytte personlig pålogging i alle tilfeller. Konsumenter må bygge en mekanisme som sikrer dette. | |
S.1 | Sikkerhet | Portal, API, WebEPJ | | Det kliniske fagsystemet må benytte TLSv1.2 eller høyere. | Må |
| Akseptansetest del 2, integrasjonstest. |
S.2 | Sikkerhet | Portal, API, , WebEPJ | | 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). | Bør | Dette håndteres normalt sett av underliggende biblioteker, men det må ikke deaktiveres av fagsystemet. | |
S.3
| Sikkerhet
| Portal, API
| | Det kliniske fagsystemet bør ikke godta revokerte sertifikater (verken TLS eller virksomhetsertifikater).
| Bør
| Dette for å beskytte det kliniske fagsystemet i en eventuell feilsituasjon der sertifikatene til KJ mot formodning skulle bli kompromittert.
| |
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, WebEPJ | | Ved SSO for portalintegrasjon, og ved API-integrasjon, må det kliniske fagsystemet sørge for at sluttbruker autentiseres på godkjent måte. Godkjente måter er bruk av selvdeklarerte løsninger hos NKOM på nivå høy, som inkluderer Buypass, Commfides eller BankID. I tillegg er noen sektor-spesifikke løsninger godkjent. | Må |
| Demomøte (Akseptansetest del 1) |
S.8 | Sikkerhet | Portal, API, WebEPJ | | Klienter som kaller kjernejournal informasjonstjenester må benytte HelseID. De må ha vært gjennom godkjenningsprosessen for bruk av HelseID, og oppfylle alle krav knyttet til bruk av HelseID. | Må | https://helseid.atlassian.net/wiki/spaces/HELSEID/pages/284262635/Godkjenningsprosessen+til+HelseID For WebEPJ ligger dette kravet som en del av innlogging med tillitsrammeverk som er en forutsetning for denne integrasjonen. | |
