Page Comparison

...

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å httphttps://nhn.no/nasjonale-e-helselosninger/kjernejournal :

Demoversjon og veiviser for kjernejournal
Hjelpesider for kjernejournal - Hjelpesidene oppdateres for hver leveranse av kjernejournal

...

Type krav
Gjeldende for type integrasjon
Type API
Må-/bør-krav

Note
Ved filtrering på kolonnen “API” må denne kombineres med filtrering på kolonnen “Gjelder type integrasjon” da en kravliste kun filtrert på “API” ikke vil gi en komplett liste over aktuelle krav.

Kravene testes av ulike test cases i demomøte, og i avbrudds- og ved integrasjonstest. Ved oppdatering av krav legges dette inn i tabell for endringshistorikk nederst på siden.

Demomøte (Akseptansetest del 1)

Komplett i denne sammenheng betyr at det kliniske innholdet må fremkomme komplett og korrekt, Metadata som ikke endrer betydningen av klinisk innhold kan

Table filter

tabs

fixedCols
totalrow
hidelabels	false
ddSeparator	,\u0020‚‚‚,\u0020‚
sparkName	Sparkline
tabs	false
hidePane	Filtration panel		false
limitHeight
sparkline	false
macroMarker	16192645361201632119732041_242839
isFirstTimeEnterddSeparators	falsetrue
default	,,,,
isFirstTimeEnter	false
hideColumns	false
cell-width	150,150,150,150,150
totalRowName
totalColName
disabled	false
globalFilter	false
formatVersion	2
iconfilter
order	0,1,2,3,4
hideControls	false	numbering
inverse	false,false,false,false,false
numbering
datefilter
column	Gjelder for type integrasjon(Portal / API),Må-/bør-krav,Type krav,API,Gjelder for type integrasjon(Portal / API/ WebEPJ)
totalcol
sort
disableSave	false
rowsPerPage
separator	Comma (,)
labels	Gjelder for type integrasjon(Portal / API)‚Må-/bør-krav‚Type krav‚API	thousandSeparator	ignoreFirstNrows	krav‚API‚Gjelder for type integrasjon(Portal / API/ WebEPJ)
thousandSeparator
ignoreFirstNrows
ddOperator	OR,OR,OR,OR,
userfilter
datepattern	dd.M.yy
numberfilter
hideFilters
heightValue
updateSelectOptions	false
worklog	365\|5\|8\|y w d h m\|y w d h m
isOR	AND
showNRowsifNotFiltered

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

2a

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å

Helsepersonell må alltid angi samtykke for oppslag i KJ.

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.

Tekst

Forslag til tekst som

skal

kan 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

til sluttbruker ved akuttsituasjon:

"Det er en akuttsituasjon der pasienten ikke er i stand til å samtykke, og det er fare for liv

og

eller alvorlig helseskade. Jeg

får

har tjenstlig behov for tilgang til sperret informasjon, denne hentes fra

kjernejournal

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

11

Funksjonelt

API

Legemiddel

API, FHIR Kritisk info

API	Det kliniske fagsystemet

må

bør vise resultatet av spørring etter informasjon

i KJ på en brukervennlig måte.

Må

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å

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

at KJ er kilden til informasjonen

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

tydlig

tydelig for bruker hvilke felter som kun er lokale og hvilke som synkroniseres mot KJ.

Demomøte (Akseptansetest del 1)

F

T.

13

1

Funksjonelt

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

Teknisk

API

FHIR Kritisk info API

Ved opplasting av informasjon til KJ skal det fremkomme i dialog 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

Må

Ved manglende informasjon ved opplasting bør det presenteres en dialog til sluttbruker hvor manglende informasjon kan registreres.

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, Legemiddel 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å	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)

F

T.

20

7

Funksjonelt

Teknisk

Portal, legemiddel API, WebEPJ

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.

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)

F

T.

21

8

Funksjonelt

Teknisk

Portal, legemiddel API

FHIR Kritisk info API

Lokal kritisk info som er samstemt med kjernejournal skal ikke kunne oppdateres i

, WebEPJ

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.

må det være mulig å konfigurere hvilken brukergruppe eller enkeltpersoner som skal ha tilgang til KJ	Må		Demomøte (Akseptansetest del 1)
T.

1

10

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>

	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.

2

13

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å

		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.

4

16

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

, 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, legemiddel 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å		Demomøte (Akseptansetest del 1)
T.

9

21

Teknisk

Portal

, APIKall til helseindikatortjenesten (både Webservice og REST) må implementeres slik at det kliniske fagsystemet ikke blir hengende dersom det ikke oppnås kontakt med

Det kliniske fagsystemet må kunne hente ticket fra JSON-respons og bruke dette som URL-parameter ved åpning av KJ.

Må

Som et kall i egen tråd.

Akseptansetest del

2b

2:

Avbruddstest portalintegrasjon

Integrasjonstest

T.

10

22

Teknisk

Portal

Innebygd nettleser må skjule adressefelt

Må

Demomøte (Akseptansetest del 1)

T.11

Teknisk

Portal

Innebygd nettleser må skjule knapperad

, legemiddel 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, legemiddel 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.

12

24

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.

, legemiddel legemiddel 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, legemiddel legemiddel 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.28	Teknisk	legemiddel 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.

16

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,

30

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)

legemiddel 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 /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

legemiddel API

FHIR Kritisk info 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)

Dato	ID	Krav	Endring
04.08.2022	S.1-S.4	Sertifikater	Endret testbetingelser
22 Nov 2021	T.33		Utgår, dekkes av T.25
28 Sep 2021	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.
22 Sep 2021	F.1		Utvidet til å også gjelde for API-integrasjon
22 Sep 2021	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
02 Sep 2021	F16-F21 T31-T34	Nye krav for FHIR Kritisk Info API og Legemiddel API integrasjon
11 Jun 2021	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"
25 Oct 2022	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

Versions Compared

Old Version 5

New Version Current

Key

Endringshistorikk for krav

Endringshistorikk for krav