Skip to end of banner
Go to start of banner

Krav ved integrasjon med kjernejournal

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 20 Next »

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 :

Utover dette stilles ingen krav til utarbeidelse av opplæringsmateriell eller gjennomføring av opplæring.

 Innspill til opplæring

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.

  • Legg vekt på "Hva" og ikke så mye "Hvordan": legg vekt på hvilken informasjon som ligger i kjernejournal, og hvordan helsepersonell i den aktuelle målgruppen kan ha nytte av informasjonen.

  • Bruk hjelpesidene til kjernejournal aktivt i undervisningsmaterialet

  • Bruk demoversjonen i undervisningen, ta eventuelle skjermbilder fra demoversjonen (demoversjonen oppdateres 2 ganger per år)

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

  • 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.

Endringshistorikk for krav

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:
"Informasjonen hentes fra KJ 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 KJ og lagres i pasientjournalen"

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.“

 

  • No labels