Krav til dokumentasjon
Krav til dokumentasjon som skal oversendes Norsk helsenett følger godkjenningsprosessen og er beskrevet i de ulike fasene i godkjenningsprosessen. Leverandørkoordinator gir informasjon om hvilken informasjon som skal leveres til hvilket tidspunkt.
Krav til opplæring
Norsk helsenett stiller krav til at leverandør informerer sine kunder om følgende informasjon som ligger på https://nhn.no/nasjonale-e-helselosninger/kjernejournal :
Hjelpesider for kjernejournal - Hjelpesidene oppdateres for hver leveranse av kjernejournal
Utover dette stilles ingen krav til utarbeidelse av opplæringsmateriell eller gjennomføring av opplæring.
| Expand | ||
|---|---|---|
| ||
Opplæringen bør spisses til den aktuelle brukergruppen. Eksempelvis vil bruken av kjernejournal være annerledes for sykepleiere og leger i pleie- og omsorgsektoren, enn i spesialisthelsetjenesten og for fastleger.
|
Krav til pilotering/utprøving
Ved portalintegrasjon kreves det ikke pilotering/utprøving, og det er opp til den enkelte leverandør om de selv ønsker å rulle ut portalintegrasjon til et lite antall kunder først og deretter øke i antall.
Ved integrasjon med KJ-API vil det i hvert tilfelle vurderes om det er nødvendig med en pilotering/utprøving. I de tilfellene hvor det er aktuelt med pilotering/utprøving av KJ-integrasjonen vil planen for dette legges i et samarbeid mellom leverandør og Norsk helsenett. Kravene til pilotering/utprøving vil kunne variere, avhengig av type integrasjon.
Funksjonelle-, tekniske- og sikkerhetskrav
Tabellen kan filtreres på:
Type krav
Gjeldende for type integrasjon
Type API
Må-/bør-krav
Kravene testes av ulike test cases i demomøte, og ved integrasjonstest. Ved oppdatering av krav legges dette inn i tabell for endringshistorikk nederst på siden.
...
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:
/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:
oppslag i KJ
...
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:
åpne sperret fane
...
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:
låse opp låste resepter
...
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:
innslag ikke kan lastes opp - årsak skal fremkommedet er manglende påkrevd informasjon - hvilken informasjon som mangler skal fremkommeopplasting er mislykketopplasting er vellykketendring er mislykketendring er vellykketsletting er mislykketsletting er vellykketavkreft er mislykketavkreft er vellykket
...
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:
/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å
...
Krav til dokumentasjon
Krav til dokumentasjon som skal oversendes Norsk helsenett følger godkjenningsprosessen og er beskrevet i de ulike fasene i godkjenningsprosessen. Leverandørkoordinator gir informasjon om hvilken informasjon som skal leveres til hvilket tidspunkt. Integrasjon til Kritisk informasjon API følger en annen prosess. Se https://utviklerportal.nhn.no/informasjonstjenester/kritisk-informasjon/ for mer informasjon.
Krav til opplæring
Norsk helsenett stiller krav til at leverandør informerer sine kunder om følgende informasjon som ligger på https://nhn.no/nasjonale-e-helselosninger/kjernejournal :
Hjelpesider for kjernejournal - Hjelpesidene oppdateres for hver leveranse av kjernejournal
Utover dette stilles ingen krav til utarbeidelse av opplæringsmateriell eller gjennomføring av opplæring.
| Expand | ||
|---|---|---|
| ||
Opplæringen bør spisses til den aktuelle brukergruppen. Eksempelvis vil bruken av kjernejournal være annerledes for sykepleiere og leger i pleie- og omsorgsektoren, enn i spesialisthelsetjenesten og for fastleger.
|
Krav til pilotering/utprøving
Ved portalintegrasjon kreves det ikke pilotering/utprøving, og det er opp til den enkelte leverandør om de selv ønsker å rulle ut portalintegrasjon til et lite antall kunder først og deretter øke i antall.
Ved integrasjon med KJ-API vil det i hvert tilfelle vurderes om det er nødvendig med en pilotering/utprøving. I de tilfellene hvor det er aktuelt med pilotering/utprøving av KJ-integrasjonen vil planen for dette legges i et samarbeid mellom leverandør og Norsk helsenett. Kravene til pilotering/utprøving vil kunne variere, avhengig av type integrasjon.
Funksjonelle-, tekniske- og sikkerhetskrav
Tabellen kan filtreres på:
Type krav
Gjeldende for type integrasjon
Type API
Må-/bør-krav
Kravene testes av ulike test cases i demomøte, og ved integrasjonstest. Ved oppdatering av krav legges dette inn i tabell for endringshistorikk nederst på siden.
| Table filter | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
...
Dato | ID | Krav | Endring |
|---|---|---|---|
04.08.2022 | S.1-S.4 | Sertifikater | Endret testbetingelser |
| T.33 | Utgår, dekkes av T.25 | |
| F.10 T.29 T.30 | Utgår, dekkes av F.11 Utgår da dette er en forutsetning for integrasjonen. Endret ordlyd - kravets innhold er det samme. | |
| F.1 | Utvidet til å også gjelde for API-integrasjon | |
| F.16 | Ved blokkering av enkelte helsepersonell i KJ skal det vises en feilmelding. Feilmeldingen bør henvise til at informasjon er tilgjengelig i KJ Portal. | Utgår - dekkes av T.23 |
| F16-F21 T31-T34 | Nye krav for FHIR Kritisk Info API og Legemiddel API integrasjon | |
F.8 | 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. | Følgende lagt til tidligere ordlyd: Tekst som skal vises sluttbruker: Ved pasientens samtykke: Ved akuttsituasjon: | |
| F.1 F.7 F.8 F.11 F.12 F.13, F.14, F.17 F.20 T.2 T.8 T.9 T.18 T.19 T.22 T.23 T.26 T.27 S.2 S.4, S.5, S.6 S.7 | F.1 Utgår som API krav. F.7 Endret ordlyd på krav: Det kliniske fagsystemet må utvikle dialog med funksjonalitet for å angi samtykke for oppslag i KJ F.8 Endret kommentarfelt F.11 Utgår som “Må” krav F.12 Forenklet ordlyden i kravet slik at det tydeligere kommer frem at det ikke pålegges design-føringer for fagsystemet F.13, F.14, F.17 utgår- erstattes av F.21 F.20 Endret ordlyd på krav slik at klinisk fagsystem har handlingsrom til å sende data uten at det påvirker lokal lagring. Tidligere krav lød: “Lokal kritisk info som er samstemt med KJ skal ikke kunne oppdateres i det kliniske fagsystemet uten at det synkront oppdateres med KJ.“ T.2 Tatt vek engelsk tekst i kommentarfelt og erstattet det med setningen "Kan sendes som http-header eller URL" i selveste kravet T.8 Krav endret fra "BØR" krav til "MÅ" krav. Setningen "gjennom et brukergrensesnitt” ble tatt vekk. T.9 Utgår T.18 Utgår som API krav T.19 Ordlyd på krav endret fra “Det kliniske fagsystemet må kunne kalle KJs REST-API med access-token fra HelseID for henting av pasientens helseindikator“ T.22 Utgår som “Må” krav T.23 Ordlyd endret fra “Det kliniske fagsystemet må kunne tolke feilmeldinger fra KJs APIer. Brukermeldingen skal presenteres for brukeren, og feilkoden skal logges.“ T.26 Utgår T.27 Utgår S.2 Utgår som “Må” krav S.4, S.5, S.6 Utgår og erstattes med S.8 S.7 Ordlyd på krav endret fra “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.“ | |
04.10.2024 | Kritisk informasjon API krav | Kravene til kritisk informasjon API er tatt vekk. Informasjon om ny prosess finnes nå på utviklerportalen.nhn.no |