ID | Kravtittel | Kravbeskrivelse | Støttes i | Kravet gjelder | Godkjennes av | Kommentar |
2.1.1 | 2.1. Opprettelse, forvaltning og migrering | EPJ skal kunne opprette en ny virksomhet i SFM. | Alle | Alle | NHN | Virksomhet opprettes ved bruk av ressursen sfm-Organization. Brukeren som er oppgitt i Helse-id token registreres som admin bruker i SFM og benyttes i videre prosess med å opprette andre brukere/migrere informasjon til SFM. |
2.1.1.1 | 2.1. Opprettelse, forvaltning og migrering | EPJ skal tilrettelegge funksjonalitet for opprettelse av ny virksomhet, slik at superbruker intuitivt forstår forskjellen på å opprette en ny virksomhet i ny SFM-instans vs. det å opprette en ny virksomhet i en allerede etablert instans (der den nye virksomheten deler data med annen virksomhet). | Alle | Alle | NHN | Før ny virksomhet opprettes skal det av sikkerhetsgrunner gjøres en GET på Organization: Når hensikten er å opprette ny instans (nytt skjema) i SFM skal det sjekkes at token med "journal-id" og orgnr_parent/orgnr_child ikke returnerer http status 200 OK. Når hensikten er å opprette ny virksomhet i eksisterende instans skal det sjekkes at åpent søk med eksistende "journal-id" gir http 200 OK Operasjon CreateOrganization benyttes videre i begge tilfelle. Ny virksomhet opprettes i ny journalinstans dersom Journal-id er ukjent Ny virksomhet opprettes i eksisterende journalinstans dersom Journal-id finnes fra før (gitt token med org som allerede eksiserer i samme instans).
|
2.1.1.2 | 2.1. Opprettelse, forvaltning og migrering | EPJ skal vise fornuftig feilmelding når HelseID ikke kan utstede gyldig token. | Alle | Alle | NHN | HelseID sjekker at gyldig delegering foreligger. HelseID vil returnere feilkoder dersom dette ikke er oppfylt. Se HelseID dokumentasjon for spesifikke feilkoder som må håndteres. |
2.1.1.3 | 2.1. Opprettelse, forvaltning og migrering | EPJ som benytter SFM skal presentere HelseID-token med identifikator til SFM instans. | Fra versjon 4 | Alle | NHN | Begge disse tilsvarer SFM-id i sfm-organization profilen. |
2.1.1.4 | 2.1. Opprettelse, forvaltning og migrering | EPJ skal kunne tilby sine virksomheter et valg ifht om driftsleverandør skal ha en superbruker i deres organisasjon eller ikke. | Fra versjon 4 | Alle | EPJ | Det skal være støtte for at bruker i virksomheten kan logge inn og gjøre operasjonen for å opprette organisasjon på vegne av sin virksomhet, og at dette ikke nødvendigvis MÅ gjøres av en ansatt hos driftsleverandør. |
2.1.1.5 | 2.1. Opprettelse, forvaltning og migrering | EPJ skal ha funksjonalitet for å forvalte sine "tenants" og skal generere Journal-ID. | Fra versjon 4 | Multitenant | NHN | Eier av Multitenant HelseID-klienten (orgnr_supplier) er ansvarlig for å forvalte sine "tenants" og generere Journal-ID for aktuelle instanser i SFM. Journal-ID skal alltid være en UUID. |
2.1.1.6 | 2.1. Opprettelse, forvaltning og migrering | Eier av Multitenant HelseID-klienten må formidle korrekt Journal-id ved forespørsel om token for aktuell tenant. | Fra versjon 4 | Multitenant | NHN | |
2.1.1.7 | 2.1. Opprettelse, forvaltning og migrering | EPJ/driftsleverandør skal enkelt tilgjengeliggjøre informasjon om relasjon mellom virksomheter/kunder, og SFM journalinstanser | Fra versjon 4 | Multitenant | EPJ | Liste over kunder (inkl Navn, Organisasjonsnummer og Journal-id) skal kunne produseres fra EPJ/driftsleverandør. Hensikten med kravet er at EPJ skal ha denne oversikten/koblingen hos seg, og skal kunne være i stand til å fremskaffe denne informasjonen ved forespørsel fra NHN, f. eks til bruk ifbm. support/feilsøking. Gjelder også historikk. |
2.1.1.8 | 2.1. Opprettelse, forvaltning og migrering | System skal støtte manuell endring av Journal-id. Historikk skal ivaretas. | Fra versjon 4 | Multitenant | EPJ | a) System som støtter multi tenant HelseID skal støtte å ta i bruk "journal-id" for kunde som tidligere har single tenant klient, ved å gjenbruke eksisterende SFM-id. b) System som støtter single tenant skal støtte å konfigurere single tenant klient med SFM-id lik "journal-id" fra multi tenant system. |
2.1.2 | 2.1. Opprettelse, forvaltning og migrering | EPJ skal benytte SFM sitt oppgitte migreringsformat for overføring av relevante journalopplysninger | Alle | Alle med funksjon | EPJ | Det benyttes eget migreringstoken som alle leverandører må støtte. For leverandører som benytter FM så løses selve migreringen av FM, men migreringstoken må gjøres tilgjengelig av EPJ. |
2.1.3 | 2.1. Opprettelse, forvaltning og migrering | EPJ skal sikre at virksomheter som tar i bruk SFM overholder dokumentasjonskrav. | Alle | Alle | EPJ | Historikk må enten migreres til SFM eller være tilgjengelig i EPJ. |
2.1.4 | 2.1. Opprettelse, forvaltning og migrering | EPJ skal sikre at valgt migreringsmåte ivaretar behovene til de brukergrupper de leverer til. | Alle | Alle | EPJ | Når det finnes relevant data om kritiske legemiddelreaksjoner som er strukturert så skal det migreres. For fastleger og avtalespesialister skal LIB migreres slik at brukerne kan finne igjen samme liste før og etter migrering. |
2.2.1 | 2.2. Opprette systembrukere i SFM | Helsepersonell skal kunne skrives til SFM. Gyldig identifikator skal være oppgitt. | Alle | Alle | NHN | sfm-Practitioner skal benyttes. Gyldig identifikator er PID og/eller HPR. |
2.2.2 | 2.2. Opprette systembrukere i SFM | Det skal være mulig å endre informasjon på helseperson i EPJ. Endringene skal overføres til SFM. | Alle | Alle | NHN | SFM henter opplysninger fra HPR registeret og benytter informasjon derfra til å gi rettigheter i SFM og knyttet til kommunikasjon mot RF og KJ. I API returnerer SFM HPR opplysninger (når det er konflikt mellom opplysninger som EPJ har skrevet til SFM og opplysninger fra HPR så returneres HPR opplysninger i API). |
2.2.3 | 2.2. Opprette systembrukere i SFM | Det skal være mulig å sette helseperson til inaktiv i EPJ. Endringene skal overføres til SFM. | Alle | Alle | NHN | Inaktive brukere vil ikke ha tilgang til SFM. |
2.2.4 | 2.2. Opprette systembrukere i SFM | Administrative brukere skal kunne skrives til SFM. PID skal være oppgitt. | Alle | Alle | NHN | sfm-Person skal benyttes. Helsepersonell som skal ha administrative rettigheter må skrives både som sfm-Practitioner og sfm-Person. |
2.2.5 | 2.2. Opprette systembrukere i SFM | Det skal være mulig å endre informasjon på administrativ bruker i EPJ. Endringene skal overføres til SFM. | Alle | Alle | NHN | |
2.2.6 | 2.2. Opprette systembrukere i SFM | Det skal være mulig å sette administrativ bruker til inaktiv i EPJ. Endringene skal overføres til SFM | Alle | Alle | NHN | Inaktive brukere vil ikke ha tilgang til SFM. |
2.3.1 | 2.3. Opprette og oppdatere pasienter i EPJ og overføre pasienten til SFM | Ved opprettelse av pasient med PID i EPJ skal PID overføres til SFM. | Alle | Alle | NHN | Ref. rekvirentkrav 2.7.3.17. EPJ skal benytte Persontjenesten for å sjekke PID, navn og adresse. |
2.3.2 | 2.3. Opprette og oppdatere pasienter i EPJ og overføre pasienten til SFM | Ved opprettelse av pasient med d-nummer så skal i tillegg fødselsdato overføres til SFM. | Alle | Alle | NHN | |
2.3.3 | 2.3. Opprette og oppdatere pasienter i EPJ og overføre pasienten til SFM | Ved opprettelse av pasient uten PID i EPJ, så skal fødselsdato, kjønn og xxx-id overføres til SFM. | Alle | Alle | NHN | |
2.3.4 | 2.3. Opprette og oppdatere pasienter i EPJ og overføre pasienten til SFM | Fornavn, etternavn, gateadresse, postnummer og poststed skal angis for alle pasienter som overføres til SFM | Alle | Alle | NHN | Gateadresse registreres hvis det er tilgjengelig (enkelte husstander i Norge mangler gateadresse). |
2.3.5 | 2.3. Opprette og oppdatere pasienter i EPJ og overføre pasienten til SFM | Dersom det er funksjonalitet i EPJ for å opprette EØS trygdeopplysninger på en (utenlandsk) pasient i EPJ skal informasjonen overføres til SFM. | Alle | Alle med funksjon | EPJ | Hvis det ikke er støtte i EPJ for å registrere EØS-informasjon er ikke kravet relevant. |
2.3.6 | 2.3. Opprette og oppdatere pasienter i EPJ og overføre pasienten til SFM | Når opplysninger i pasient endres i EPJ skal oppdaterte opplysninger overføres til SFM. | Alle | Alle | NHN | Gjelder alle opplysninger i Patient ressursen bl.a: Uten PID-> PID, Bytte PID, Endre fornavn, etternavn, kjønn, fødselsdato, adresse.
|
2.3.7 | 2.3. Opprette og oppdatere pasienter i EPJ og overføre pasienten til SFM | Dersom det er funksjonalitet i EPJ for å slå sammen to pasientjournaler i EPJ. Informasjon om sammenslåingen skal overføres til SFM slik at SFM kan utføre tilsvarende sammenslåing. | TBD | Alle med funksjon | EPJ | |
2.4.1 | 2.4. Åpne SFM-pasientbehandlingsportal fra EPJ | Når SFM pasientbehandlingsportal åpnes i EPJ så skal den vises som en integrert del av pasientens journal slik at det ikke er mulig å forveksle pasienter. | Alle | Alle | NHN | Åpning i multimodalt vindu/frittstående browser er ikke akseptabelt. Det må fremkomme tydelig hvilken pasient bruker jobber med, og ikke være mulig å gjøre feil. |
2.4.2 | 2.4. Åpne SFM-pasientbehandlingsportal fra EPJ | SFM pasientbehandlingsportal skal ha fokus når løsningen åpnes i EPJ | Alle | Alle | NHN | Eks: Slik at kortkommandoer i SFM kan benyttes. |
2.4.3 | 2.4. Åpne SFM-pasientbehandlingsportal fra EPJ | Når pasient lukkes i EPJ så skal SFM pasientbehandlingsportal (browser) alltid lukkes og pasientbillett skal forkastes. | Alle | Alle | NHN | Pasientbillett skal ikke brukes på tvers av brukere i EPJ (selv om billetten som utleveres fra SFM er den samme). Dette er knyttet til at SFM har funksjonalitet knyttet til henting av billett. |
2.4.4 | 2.4. Åpne SFM-pasientbehandlingsportal fra EPJ | EPJ skal sikre at pasientnavn og PID til en hver tid vises tydelig for helsepersonell når SFM pasientbehandlingsportal er åpnet, slik at helseperson alltid har kontroll på hvilken pasient den jobber med. | Alle | Alle | NHN | |
2.4.5 | 2.4. Åpne SFM-pasientbehandlingsportal fra EPJ | EPJ skal sørge for at SFM har tilgang til aktivt accesstoken så lenge bruker er logget inn i EPJ. | Alle | Alle | NHN | EPJ holder kontroll på refresh token og oppdaterer access token for pålogget bruker. EPJ må forholde seg til oppgitt varighet i access token. |
2.4.6 | 2.4. Åpne SFM-pasientbehandlingsportal fra EPJ | EPJ skal logge ut bruker fra SFM når brukersesjon i EPJ avsluttes. | Alle | Alle | NHN | Omfatter terminering av alle browsersesjoner mot SFM og Helfo og kall til datadelings API for å terminere aktivt access token. Inkluderer når det byttes bruker i kjørende journalsystemklient. |
2.4.7 | 2.4. Åpne SFM-pasientbehandlingsportal fra EPJ | EPJ skal fungere for bruk hvis SFM ikke er tilgjengelig. Bruker skal informeres om at SFM ikke er tilgjengelig. | Alle | Alle | EPJ | |
2.5.1 | 2.5. Ordingering og rekvirering - SFM | SFM skal være den primære lokale kilden til pasientens legemidler i bruk. | Alle | Alle | NHN | Se egne krav når SFM benyttes i kombinasjon med kurveløsning. Administreringsmodul skal forholde seg til SFM som kilde. Dette gjelder både oppretting, endringer og seponering av legemiddelbehandlinger/resepter. Gjelder både legemidler, kosttilskudd, næringsmidler og forbruksmateriell. |
2.6.1 | 2.6. Visning av LIB og legemiddelreaksjoner i EPJ | Hvis EPJ har funksjonalitet for å vise LIB andre steder enn i SFM pasientbehandlingsportal, så skal SFM LIB Widget benyttes | Alle | Alle med funksjon | EPJ | SFM LIB Widget viser oppdatert liste over pasientens legemidler. |
2.6.2 | 2.6. Visning av LIB og legemiddelreaksjoner i EPJ | Hvis EPJ har funksjonalitet for å vise liste over legemiddelreaksjoner andre steder enn i SFM pasientbehandlingsportal, så skal SFM LMR Widget benyttes. | Alle | Alle med funksjon | EPJ | SFM LMR Widget viser oppdatert liste over pasientens legemiddelreaksjoner. |
2.7.1 | 2.7. Håndtering av oppgaver | EPJ skal kunne spørre om oppgaver som må håndteres og presentere svaret i oppgavelister til brukere av EPJ. | Alle | Alle | NHN | EPJ skal ikke spørre automatisk etter oppgaver for medhjelpere (legesekretærer, sykepleier osv). EPJ skal automatisk spørre etter oppgaver for rekvirent som skal se egne oppgaver. |
2.7.2 | 2.7. Håndtering av oppgaver | Oppgaver knyttet til svar til MD apotek skal kunne skilles ut i prioritert/filtrert liste. | Alle | Multidoselege | NHN | Hensikten med kravet er at oppgaven skal være prioritert å løse og at bruker får nødvendige støtte. Kan også løses ved at disse oppgavene alltid legges øverst i oppgaveliste eller er default filtrert.
Dette gjelder følgende sfm-task-types: |
2.7.3 | 2.7. Håndtering av oppgaver | Det skal være mulig å spørre SFM om oppgaver på et utvalg av pasienter. Spørringen skal være manuell slik at den bare gjøres når helsepersonell med tjenstlig behov initierer det. | Ikke avklart | Pleie og omsorg | NHN | Må løses av EPJ som benyttes i pleie og omsorg. Funksjonaliteten er nødvendig for at hjemmetjeneste skal holde oversikt over endringer i pasientens legemiddelbehandlinger. Spørring bør begrenses til oppgaveløsning for relevante enheter og de pasienter enheten har ansvar for. SFM vil hente opplysninger fra Kjernejournal for oppgitte pasienter. Dette gjelder sfm-task-types 10 Endring på pasient. Spørringen vil kunne ta lang tid på grunn av spørring mot KJ og oppdateringer i SFM. |
2.7.4 | 2.7. Håndtering av oppgaver | EPJ skal sikre at bruker blir informert om at det finnes uløste oppgaver når pasientens journal lukkes og når epj lukkes. | Alle | Alle | NHN | |
2.7.5 | 2.7. Håndtering av oppgaver | Hvis EPJ viser oppgaveliste knyttet til enkeltpasient når bruker har åpnet en pasientjournal så skal EPJ spørre om oppgaver på enkeltpasient. | Alle | Alle | NHN | |
2.7.6 | 2.7. Håndtering av oppgaver | Det skal være mulig å spørre om oppgaver på enkeltbrukere. | Alle | Alle | NHN | Funksjonen skal også brukes når helsepersonell velger å se oppgaver på annen helseperson. |
2.8.1 | 2.8. Krav ved opprettelse av korrespondanse | EPJ skal støtte at oppdatert LIB legges til i utgående korrespondanse. | Alle | Alle | NHN | LIB leses fra SFM |
2.8.2 | 2.8. Krav ved opprettelse av korrespondanse | Dersom LIB oppdateres etter at korrespondanse er klargjort skal bruker varsles om dette. | Alle | Alle | NHN | Bruker skal varsles når korrespondansemodul åpnes. Kravet gjelder utgående korrespondanse hvor legemiddelinformasjon er lagt til. |
2.8.3 | 2.8. Krav ved opprettelse av korrespondanse | Hvis LIB ikke er signert skal bruker varsles. | Alle | Alle | NHN | Kravet gjelder utgående korrespondanse hvor legemiddelinformasjon legges til. Hensikten med kravet er at bruker gjøres oppmerksom på at det finnes oppgaver knyttet til LIB og som ha oppstått etter at LIB sist ble signert. Det er ønskelig at signert LIB blir formidlet i korrespondanse. |
2.8.4 | 2.8. Krav ved opprettelse av korrespondanse | EPJ skal støtte at oppdatert liste over legemiddelreaksjoner legges til i utgående korrespondanse | Alle | Alle | NHN | Liste over legemiddelreaksjoner leses fra SFM. |
2.8.5 | 2.8. Krav ved opprettelse av korrespondanse | Dersom liste over legemiddelreaksjoner oppdateres etter at korrespondanse er klargjort skal bruker varsles om dette. | Alle | Alle | NHN | Bruker skal varsles når korrespondansemodul åpnes. Kravet gjelder utgående korrespondanse hvor liste over legemiddelreaksjoner er lagt til. |
2.9.1 | 2.9. Krav til visning ved administrering av legemidler | Det skal være mulig å dokumentere administrering av legemidler når listen er signert og det foreligger kladdoppføring i SFM. | Alle | Alle med funksjon | EPJ | Kravet gjelder EPJ som tilbyr elektronisk dokumentasjon av administrering av legemidler. Kravet gjelder for virksomheter der det er behov for å kunne administrere legemidler basert på kladd (f.eks. aktuelt i PLO installasjoner). Kravet er relevant der for eksempel en sykepleier/vernepleier er alene på vakt og skal kunne dokumentere administrering av et legemiddel som ikke er dobbeltsignert av annen sykepleier/vernepleier eller signert av lege. Sykepleier/vernepleier skal da sjekke relevante kilder for å hente inn opplysninger om hvilke legemidler pasienten skal stå på og merke "legemiddelliste klar til administrering" i SFM slik at denne kan overføres til administrasjonsmodul i EPJ. |
2.9.2 | 2.9. Krav til visning ved administrering av legemidler | Ved administrering av legemiddelbehandlinger som ikke er godkjent/dobbeltsignert, skal bruker varsles om at det administrerers på grunnlag av kladd. | Alle | Alle med funksjon | EPJ | Kravet gjelder EPJ som tilbyr elektronisk dokumentasjon av administrering av legemidler. |
2.9.3 | 2.9. Krav til visning ved administrering av legemidler | Detaljer knyttet til legemiddelbehandling skal kunne presenteres til bruker | Alle | Alle med funksjon | EPJ | Kravet gjelder EPJ som tilbyr elektronisk dokumentasjon av administrering av legemidler. Detaljer som skal kunne presenteres til bruker: Brukskodene Fast/Behov/Kur, Legemiddelets Navn, Form, Styrke, Bruksområde, kortdose (hvis kortdose mangler skal Dssn benyttes), og "skal ikke kombineres med andre legemidler"(ingen kombinasjon) når dette er satt av rekvirent i SFM For magistrelt legemiddel anbefales det i tillegg å vise bestanddeler i blandingen. For legemiddel med AK-journal skal det vises: Strukturert dosering, Oppstartsdato, Sluttdato, siste INR måling – dato og verdi for siste måling Sluttdato skal kalles "Siste dose tas".
|
2.9.4 | 2.9. Krav til visning ved administrering av legemidler | Det skal være mulig å se alternative merkevarer som kan administreres basert på forskrivning. | Alle | Alle med funksjon | EPJ | Kravet gjelder EPJ som tilbyr elektronisk dokumentasjon av administrering av legemidler. SFM vil tilby grensesnitt mot FEST gjennom sitt API. Dette kan benyttes for å laste ned og vise ulike alternative merkevarer basert på virkestoff. SFM vil også levere informasjon om merkevare som er utlevert på siste resept og referanse til bilde av legemiddel. |
2.10.1 | 2.10. Krav til overføring av legemiddelinformasjon mellom elektronisk legemiddelkurve og SFM | Det skal være en definert og entydig prosess for når data overføres til kurveløsning og kurveløsningen overtar databehandlingen. | Ikke avklart | Alle med funksjon | NHN | Kravet er aktuelt der hvor leverandør leser legemiddelinformasjon fra SFM til elektronisk legemiddelkurve. |
2.10.2 | 2.10. Krav til overføring av legemiddelinformasjon mellom elektronisk legemiddelkurve og SFM | Det skal være en definert og entydig prosess for når data overføres fra kurveløsning og SFM overtar databehandlingen. | Ikke avklart | Alle med funksjon | NHN | |
2.10.3 | 2.10. Krav til overføring av legemiddelinformasjon mellom elektronisk legemiddelkurve og SFM | Legemiddelopplysninger som eksporteres fra kurve til SFM skal følge FEST sin innholdsstandard og bruke FEST-ID på legemidlene der disse finnes i FEST. | Ikke avklart | Alle med funksjon | NHN | Målet er å sikre at kurve ikke eksporterer interne og lokale ID'er til SFM dersom legemiddelet finnes i FEST. Da skal kurve/EPJ bruke FEST-ID på legemiddelet slik at SFM enkelt kan sammenlikne med andre legemidler i pasientens LIB. |
2.10.4 | 2.10. Krav til overføring av legemiddelinformasjon mellom elektronisk legemiddelkurve og SFM | Dersom virkestofforskrivning er importert til kurve og legemiddelet har blitt brukt gjennomgående til utskrivning, skal virkestofforskrivningen eksporteres til SFM med samme format og ID. | Ikke avklart | Alle med funksjon | NHN | Kravet skal sikre en enhetlig legemiddelopplysningsflyt mellom SFM og kurve. Målet er å sikre at opplysninger som har kommet fra SFM som virkestoff, og deretter har blitt konvertert til intern merkevare/produkt, konverteres tilbake til opprinnelig virkestoff ved tilbakeføring til SFM før utskrivning. Dette vil gjøre samstemming for brukere mye enklere da de da kan automatisk matches og settes som lik. Dette gjelder kun virkestoff-forskrivninger. For merkevarer og pakninger, skal bruker samstemme og dermed få støtte til å konvertere til virkestoff- forskrivning. Kravet gjelder når legemiddelet har dosering hver dag i løpet av perioden legemiddelet blir ført i kurve" (obs 0 er også en dosering). Kravet gjelder ikke når et legemiddel er seponert og ny legemiddelbehandling er opprettet. |
2.10.5 | 2.10. Krav til overføring av legemiddelinformasjon mellom elektronisk legemiddelkurve og SFM | Overføring av informasjon fra elektronisk legemiddelkurve til SFM skal følge e-resepts krav til innhold, og dosering skal følge e- resepts informasjonsstandard for strukturert dosering. | Ikke avklart | Alle med funksjon | NHN | Når legemidler overføres fra elektronisk legemiddelkurve i EPJ til SFM skal som minimum følgende detaljer pr legemiddel overføres:
Brukskodene Fast/Behov/Kur, Legemiddelets Navn, Form, Styrke, Bruksområde, strukturert
dosering/kortdose, Dssn, Seponeringsdato (dersom det foreligger). |
2.11.1 | 2.11. Skriving og lesing av medisinske data fra EPJ til SFM | Diagnoser skal kunne skrives fra EPJ til SFM. | Alle | Alle med funksjon | NHN | Gjelder i første omgang Marevan-behandling |
2.11.2 | 2.11. Skriving og lesing av medisinske data fra EPJ til SFM | Laboratorieverdier skal kunne skrives fra EPJ til SFM. | Alle | Alle med funksjon | NHN | Gjelder i første omgang INR på relevante pasienter. Det er opp til hver leverandør om den tar i bruk funksjonen. |
2.11.3 | 2.11. Skriving og lesing av medisinske data fra EPJ til SFM | Det skal være mulig å benytte statistikkrelaterte API metoder som SFM tilbyr. | Ikke avklart | Alle med funksjon | EPJ | Gjelder de leverandørene som tilbyr bruk av funksjonalitet knyttet til statistisk analyse og rapportering som omfatter legemiddelinformasjon. Det er opp til hver leverandør om de tar i bruk funksjonen. |
2.12.1 | 2.12. Tilgang til Helsepersonell -og virksomhetsportal | Det skal være mulig for helseperson å åpne helsepersonellportal i SFM for å kunne få tilgang til funksjonalitet som ikke er pasientrettet. | Alle | Alle | NHN | Åpning av portal skal kunne gjøres i EPJ uten at pasient er valgt. |
2.12.2 | 2.12. Tilgang til Helsepersonell -og virksomhetsportal | Det skal være mulig for brukere med administrasjonsrettigheter i EPJ å åpne virksomhetsportalen i SFM. | Alle | Alle | NHN | Åpning av portalen skal kunne gjøres i EPJ uten at pasient er valgt. Virksomhetsportalen gir mulighet for å konfigurere virksomheten og administrere brukere. |
2.13.1 | 2.13. Tekniske krav for API | System som kaller SFM endepunkt skal inkludere http header User-Agent på standardformen:
User-Agent: <product> / <product-version> <comment> | Alle | Alle | NHN | Merk at kravet ikke gjelder navigasjon til SFM-klientene i IFRAME |
2.13.2 | 2.13. Tekniske krav for API | System som kaller SFM endepunkt skal inkludere http header X-point-of-care på formen:
X-point-of-care: <orgnum> | Alle | Alle | NHN | Spesielt for store organisasjonsnummer er det viktig at <orgnum> er virksomhet og ikke etat eller toppnivå Merk at kravet ikke gjelder navigasjon til SFM-klientene i IFRAME |
2.13.3 | 2.13. Tekniske krav for API | Avsendersystem kan legge til en pseudo-id for sluttbruker eller arbeidsplass/pc, f.eks. intern id i systemet.
Det er ikke tillatt å benytte HPR-nummer eller fødselsnummer/d-nummer:
X-practitioner-pseudo: <pseudo-id for bruker> | Alle | Alle med funksjon | NHN | Anbefalt:
Fordelen med å oppgi denne er muligheten til å identifisere eventuell feilsituasjon til enkelt bruker, som igjen kan hindre at hele virksomheten blir stengt ute ved ytelsesutfordringer. Merk at kravet ikke gjelder navigasjon til SFM-klientene i IFRAME |