...
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 :
Hjelpesider for kjernejournal - Hjelpesidene oppdateres for hver leveranse av kjernejournal
...
Type krav
Gjeldende for type integrasjon
Type API
Må-/bør-krav
| Info |
|---|
Ved filtrering på kolonnen “Gjelder for type integrasjon”, må filtrering på “API” eller “Portal” alltid kombineres med “Portal, API” for å få komplett liste. 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 integrasjonstest. Ved oppdatering av krav legges dette inn i tabell for endringshistorikk nederst på siden.
...
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 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
"Det er en akuttsituasjon der pasienten ikke er i stand til å samtykke,
Det kliniske fagsystemet må vise resultatet av spørring etter informasjon i KJ komplett og korrekt. | 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 brukerMå
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. | 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.Må
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.
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.16 Funksjonelt API Legemiddel API, FHIR Kritisk info API Ved blokkering av enkelte helsepersonell i kjernejournal skal det vises en feilmelding. Feilmeldingen bør henvise til at informasjon er tilgjengelig i KJ Portal. | Siden vi ikke har kontroll på data etter at de er lastet ned, må vi blokkere nedlasting av data fra de personene som har blokkert et helsepersonell. Feilmeldingen bør henvise til at informasjon er tilgjengelig i KJ Portal. På denne måten et annet helsepersonell som er ikke blokkert kan fortsatt se og endre helseopplysninger om gitt pasientMå
| 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 Legemiddel API, FHIR Kritisk info API
Å 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.
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 | BørDet kliniske fagsystemet bør vise hjelpetekst for kodeverket for KI
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. | Skal vise konflikter mellom det kliniske fagsystemet og kjernejournal. Dette bidrar til effektivisering av synk jobben mellom det kliniske fagsystemet og kjernejournal.Må
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. | 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 kjernejournalMå
Når bruker klikker på KJ-ikonet skal det åpnes en intern nettleser som åpner URL-adressen til hentpasient med 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. | 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 insteadMå
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 | Det kliniske fagsystemet må benytte tjenesten ”Logg av” som tilbys fra KJ når bruker logger av Portal
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å
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 Demomøte (Akseptansetest del 1)
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å
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å 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
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, presentere dette for brukeren og logge feilkoden til teknisk logg.
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. 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. 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) |
Endringshistorikk for krav
...
Dato
...
ID
...
Krav
...
Endring
...
...
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 kjernejournal og lagres i pasientjournalen med pasientens samtykke. Pasienten har gitt sitt samtykke til at jeg kan få tilgang til informasjonen. "
...
|
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: 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 |