/
Krav til integrasjon med SFM Fullversjon

Krav til integrasjon med SFM Fullversjon

Denne siden er under oppdatering.
Vær oppmerksom på at det kan forekomme endringer i kravene (se endringslogg). Vi anbefaler derfor at denne siden besøkes ofte for å holde seg oppdatert på gjeldende integrasjonskrav.

Denne siden gir oversikt over gjeldende krav til integrasjon med SFM Fullversjon. Ved oppdatering av krav legges dette inn i tabell for endringshistorikk nederst på siden, samt i kravtabell ved nye krav og større endringer.

Godkjenningsprosess SFM Fullversjon

Leverandører som skal integrere med SFM Fullversjon må verifisere at integrasjonskravene blir innfridd. Kravene danner utgangspunkt for utarbeidelse av testcase som skal benyttes i akseptansetesten.

Det gjøres kontinuerlige endringer og presiseringer i kravspesifikasjonen. Det er forventet at EPJ leverandører som er integrert med, eller som har påbegynt dette arbeidet, gjør en vurdering av endringene inkludert plan for å sørge for at nye integrasjonskrav ivaretas i egen løsning.

Besvar SFM integrasjonskrav

Leverandør skal besvare alle integrasjonskrav ved innsending. Fjern eventuelle filtreringer på krav og eksporter tabellen i sin helhet til CSV-fil ved å klikke på tannhjulet i høyre hjørne. Kravene skal leveres i Excel-format og fylles ut med besvarelse fra leverandør i ny kolonne. Sørg for at den eksporterte tabellen er lesbar for mottaker og at leverandørens besvarelse fremkommer tydelig i en egen kolonne.

Besvarte integrasjonskrav skal ha filnavn på formen: <yyyy.mm.dd> <produktnavn> SFM Integrasjonskrav <revisjon>.docx

Forklaring av kravtabellen

Alle krav er i utgangspunktet obligatoriske krav som må innfris for å kunne bestå akseptansetesten og dermed får godkjent integrasjonen mot SFM. Der annet gjelder er dette spesifisert i kravtabellen.

Tabellen i neste avsnitt kan filtreres på:

  • Krav ID

  • Kravtittel

  • Kravbeskrivelse

  • Støttes i

  • Kravet gjelder

  • Godkjennes av

  • Kommentar

Du kan også benytte scrollbaren til høyre og fritekstfeltet i tabellen (kommentar) for å navigere deg frem til ønsket krav.

ID

Kravtittel

Kravbeskrivelse

Støttes i

Kravet gjelder

Godkjennes av

Kommentar

ID

Kravtittel

Kravbeskrivelse

Støttes i

Kravet gjelder

Godkjennes av

Kommentar

Unik ID på krav. Inneholder dot notasjon hvor tallet foran dot angir område og tallet etter dot angir løpenummer

Tittel for angitt kravområde

Tekstlig beskrivelse av krav som stilles.

Angir hvilken versjon kravet blir stilt til leverandørene.

 

Alle - Alle leverandører som integrerer med SFM skal oppfylle kravet.

Alle med funksjon - Leverandører som støtter funksjonen skal oppfylle kravet

Annet spesifisert - Multidoselege, Multitenant, Pleie og omsorg

NHN eller EPJ

Hvorvidt NHN gjennomfører akseptansetest (NHN), eller om kravet kun skal verifiseres/selvdeklareres av leverandør (EPJ) gjennom egen systemtest

Kommentarfeltet til å opplyse om relevant tilleggsinformasjon eller henvisninger som kan være til hjelp når kravet skal tolkes og implementeres.

Krav til integrasjon med SFM Fullversjon

Leverandører kan finne teknisk dokumentasjon for utvikling av integrasjon i Utviklerportalen: https://utviklerportal.nhn.no/informasjonstjenester/sentral-forskrivningsmodul/
Trykk på den utvidbare boksen for beskrivelse av hvert enkelt kravområde:

 

2.1. Opprettelse, forvaltning og migrering SFM er en separat applikasjon som har sin egen funksjonalitet, datamodell og sentral database. For at virksomheten som starter å bruke SFM skal få fullverdig konvertering av data fra gammel EPJ-løsning eller FM til SFM kreves det en effektiv løsning hvor datakvalitet blir bevart. 2.2. Opprette systembrukere i SFM SFM skiller mellom helsepersonellbrukere og administrative brukere Informasjonen lagres i forskjellige tabeller og det kreves at EPJ skriver til både sfm-Practitioner og sfm-Person hvis person skal ha rettighet som administrator og helseperson som en ekstra sikkerhetsmekanisme og for å håndtere rettigheter. Det er påkrevd at administratorbruker skriver brukerinformasjon til SFM før brukeren kan logge seg inn i SFM. Når det opprettes og endres brukerinformasjon i EPJ så skal endringene speiles til SFM. 2.3. Opprette og oppdatere pasienter i EPJ og overføre pasienten til SFM I SFM-løsningen er det valgt en tilnærming som krever at pasienten må være opprettet i SFM før EPJ kan åpne den. Det medfører at EPJ må skrive pasient til SFM før pasienten kan åpnes i SFM-GUI, eller informasjon om pasienten kan leses tilbake til EPJ via API. Grunnen til at en pasient må være skrevet til SFM før den tas i bruk er todelt: I SFM stilles det krav om at EPJ etterspør en pasientbillett før det kan kommuniseres om pasienten. SFM ser det som en sikkerhetsmekanisme at pasient må opprettes i egen prosess før det kan registreres annen informasjon på pasienten. SFM vil tilby funksjonalitet for overføring av legemiddelopplysninger mellom virksomheter som benytter ulike instanser av SFM når pasient bytter fastlege eller fastlege bytter virksomhet. 2.4. Åpne SFM-pasientbehandlingsportal fra EPJ For å kommunisere med SFM er det krav om at EPJ benytter Helse-ID og at bruker er logget inn med høyt sikkerhetsnivå. Dette vil si at hvis EPJ tilbyr pålogging uten bruk av Helse-ID med høyt sikkerhetsnivå så vil brukerne ikke få tilgang til SFM i en slik sesjon. Pasientbillett benyttes av SFM Pasientbehandlingsportal og SFM Datadeling API for å kunne kommunisere informasjon om enkeltpasienter. Merk at EPJ systemet må be om pasientbillett for hver kombinasjon av bruker og pasient. 2.5. Ordinering og rekvirering - SFM Når EPJ tar i bruk SFM som legemiddelmodul, er det anbefalt at SFM er den primære lokale kilden («master») til pasienters aktuelle LIB. Dvs. at EPJ bruker SFM som kilde og ikke vedlikeholder en egen lokal LIB. I tillegg er det anbefalt at andre historiske legemiddelopplysninger, slik som tidligere legemiddelbehandlinger, resepthistorikk, utleveringshistorikk, m.m. kun eksisterer i SFM. Der EPJ ønsker å bruke informasjonen, bør det sikres at kilden er SFM, og at eventuelle endringer utføres i SFM for å sikre at opplysningene der alltid er oppdatert. SFM vil ikke tilby administrasjonsfunksjonalitet for oppfølging av inntak og administrasjon av legemidler, som vil si at dette må utvikles av EPJ eller tilbys av andre løsninger slik som kurvesystem. 2.6. Visning av LIB og legemiddelreaksjoner i EPJ SFM er den primære lokale kilden for pasientens aktuelle (og historiske) LIB, men EPJ skal kunne tilby denne i ulike visninger og til bruk i andre deler av EPJ. Der dette gjøres, er det viktig at opplysningene fra SFM vises på et entydig format og med samme innhold og oppsett, slik at brukere opplever dette som samme informasjon og en sømløs integrasjon. For visning av legemidler i bruk (LIB) og legemiddelreaksjoner (LMR) i EPJ tilbyr SFM visningskomponenter (widgets) for å forenkle visning i EPJ. SFM LIB Widget for visning av oppdatert liste over pasientens legemidler. SFM LMR Widget for visning av oppdatert liste over pasientens legemiddelreaksjoner. SFM LIB Widget og SFM LMR Widget skal normalt alltid vises samlet. 2.7. Håndtering av oppgaver For å understøtte samhandling internt i virksomheten og med eksterne aktører, samt ivareta pasientsikkerheten, genererer SFM oppgaver som må løses av relevant helsepersonell. Oppgavene kan være adressert til enkeltpersoner eller til en rolle som skal ivareta oppgaven. Eksempler på dette er at multidoseansvarlig lege må svare ut spørsmål fra apotek som er kommet i en M25.2 melding fra RF, eller at medhjelper har vært inne og opprettet en reseptkladd som fastlegen må inn og godkjenne/signere før den sendes til RF. Oppgavene må tilgjengeliggjøres for relevant helseperson i en arbeidsliste/oppgaveliste eller liknende. SFM eier oppgavelisten og holder orden på oppgaver som løses basert på aksjoner som bruker gjør i SFM og i noen tilfeller når EPJ registrerer at en oppgave er utført. 2.8. Anbefalinger ved opprettelse av korrespondanse Ettersom SFM er anbefalt å være den primære lokale kilden for legemiddelopplysninger og kritiske legemiddelreaksjoner (LMR), vil SFM også være kilde der denne typen informasjon brukes i korrespondanse. For å forenkle formidlingen av riktig liste i korrespondanse tilbyr SFM informasjonen som skal sendes både som html tabell som kan brukes direkte inn i tekstlig informasjon og som xml som følger standard for struktur som ligger i PLO meldingene.  2.9. Anbefalinger til visning ved administrering av legemidler SFM understøtter ikke dokumentasjon knyttet til administrering av legemidler. SFM er imidlertid kilde til hva som skal administreres og leverer derfor legemiddeldata tilpasset administrering slik at EPJ på en enkel måte kan presentere informasjon til bruker og dokumentere hva som ble administrert. 2.11. Skriving og lesing av medisinske data fra EPJ til SFM I forbindelse med forskrivning, medisinske varsler og søknad til Helfo er det behov for at SFM skal ha tilgang til diagnoser og spesifikke LAB verdier fra EPJ. For å forenkle løsningen og redusere kostnader vil SFM tilby ressurser slik at EPJ kan skrive disse dataene til SFM når de endres i EPJ, eller knyttet til åpning av pasienten. SFM tilbyr ressurser for lesing av medisinske data til bruk for rapportering, oppfølging av grupper av pasienter og kvalitetsforbedring av virksomhet. Disse dataene kan leses fra SFM via tilgjengelige ressurser. 2.12. Tilgang til Helsepersonell -og virksomhetsportal SFM inneholder to portaler som ikke er knyttet til behandling av enkeltpasienter. Helsepersonell-portalen inneholder funksjonalitet som ikke kan knyttes til enkeltpasienter. Dette gjelder blant annet funksjoner for rapportering, opprettelse av maler og lokale legemidler, m.m. Portalen skal kunne åpnes av helsepersonell når det ikke er valgt pasient i EPJ. Virksomhetsportalen inneholder funksjonalitet for å administrere brukere og for å konfigurere oppsett av virksomheten. Portalen skal kunne åpnes av brukere med administrasjonsrettigheter fra EPJ sitt administrasjonsgrensesnitt. 2.13. Tekniske krav for API Kravene i denne hovedkategorien gjelder overordnet teknisk integrasjon, og har ikke funksjonelt med SFM å gjøre. For innhold i HTTP header gjelder kravene kun for API endepunkt, men det er ikke til hinder for at de benyttes også i portal-integrasjonen der det er mulig (iframe URL). 2.14. Krav til feilsøking/support Krav i denne kategorien er krav som stilles til EPJ for å sikre effektiv feilsøking og support.

Last ned kravene her:


Endringshistorikk for krav

Beskrivelse av endring utført og sist endret dato

Dato

ID

Krav

Beskrivelse av endring utført

Dato

ID

Krav

Beskrivelse av endring utført

Sep 11, 2026

2.3.3

2.3. Opprette og oppdatere pasienter i EPJ og overføre pasienten til SFM

Presisert at xxx-id skal være en GUID.

Sep 11, 2026

2.3.1

2.3. Opprette og oppdatere pasienter i EPJ og overføre pasienten til SFM

Presisert at kravet kun gjelder for patient.

Jun 10, 2026

2.3.3

2.3. Opprette og oppdatere pasienter i EPJ og overføre pasienten til SFM

Krav er endret fra å være “Obligatorisk for alle” til “Obligatorisk for de med funksjon”.

Jun 2, 2026

 

 

Samtlige krav som var merket som “Anbefalt” er nå merket med “EPJ/Virksomhetens ansvar“.

Jun 2, 2026

2.1.1b

2.1. Opprettelse, forvaltning og migrering

Presisering av at dette gjelder for leverandører med behov for å støtte komplekse organisasjonsoppsett.

Jun 2, 2026

2.3.1a

2.3. Opprette og oppdatere pasienter i EPJ og overføre pasienten til SFM

Presisering av kommentar. Lagt til følgende avsnitt: “Merk at fortrolig og strengt fortrolig adresse fra Persontjenesten ikke skal skrives til SFM. Fordi Reseptformidleren krever adresse kan en annen nøytral adresse, som for eksempel Legekontorets adresse, benyttes.”

Jun 2, 2026

2.4.8

2.4. Åpne SFM-pasientbehandlingsportal fra EPJ

Endring fra anbefalt til at dette kravet er obligatorisk for de med funksjon

Apr 9, 2026

2.6.4

2.6. Visning av LIB og legemiddelreaksjoner i EPJ

Fjernet kommentar angående Widget da den er faset ut

Mar 4, 2026

Se beskrivelse

2.4. Åpne SFM-pasientbehandlingsportal fra EPJ

Lagt til nytt krav 2.4.9

Oct 20, 2025

Se beskrivelse

2.1. Opprettelse, forvaltning og migrering
2.4. Åpne SFM-pasientbehandlingsportal fra EPJ
2.5.1. Ordinering og rekvirering - SFM
2.6. Visning av LIB og legemiddelreaksjoner i EPJ
2.7. Håndtering av oppgaver
2.8. Krav ved opprettelse av korrespondanse
2.9. Krav til visning ved administrering av legemidler

Endret ordlyd i de nye anbefalingene, slik at det fremkommer at disse områdene kan/bør ivaretas, men ikke er absolutte krav. Se oppdatering Oct 15, 2025 for oversikt over hvilke anbefalinger dette gjelder.

I tillegg er følgende endringer utført:
2.4.1. Endret fra godkjennes av “NHN” til godkjennes av “EPJ”
2.4.2. Endret fra godkjennes av “NHN” til godkjennes av “EPJ”
2.7.6. Endret fra godkjennes av “NHN” til godkjennes av “EPJ”
Kravområde 2.8. er gitt ny tittel “Anbefalinger ved opprettelse av korrespondanse”
Kravområde 2.9. er gitt ny tittel “Anbefalinger ved administrering av legemidler”

Oct 16, 2025

Se beskrivelse

2.1. Opprettelse, forvaltning og migrering
2.4. Åpne SFM-pasientbehandlingsportal fra EPJ
2.5.1. Ordinering og rekvirering - SFM
2.6. Visning av LIB og legemiddelreaksjoner i EPJ
2.7. Håndtering av oppgaver
2.8. Krav ved opprettelse av korrespondanse
2.9. Krav til visning ved administrering av legemidler

Utført revisjon av kravlisten der alle krav er markert som enten obligatorisk eller anbefalt.

Følgende krav er fom. Oktober 2025 anbefalte krav til integrasjon med SFM Fullversjon:
2.1.1.4.
2.1.3., 2.1.4
2.4.1., 2.4.2., 2.4.7., 2.4.8.
2.5.1.
2.6.3., 2.6.4.
2.7.6.
2.8.1.-2.8.5.
2.9.1.-2.9.5.

Følgende krav utgår fra kravlisten fom. Oktober 2025:
2.7.4.
2.7.5.

Krav 2.7.3. er fjernet fra kravlisten. Dette utgikk September 2024.
Kravbeskrivelse endret for krav 2.1.2.

Jun 4, 2025

2.1.1c.

2.1. Opprettelse, forvaltning og migrering

2.1.1c. Nytt krav til å sende med oppdatert informasjon om EPJ (epjinfo) i organization-ressursen.  

May 23, 2025

2.1.1.1c
2.2.7
2.3.1a
2.3.1b
2.3.1c
2.3.1d
2.3.3
2.3.7
2.4.8

2.1. Opprettelse, forvaltning og migrering
2.2. Opprette systembrukere i SFM
2.3. Opprette og oppdatere pasienter i EPJ og overføre pasienten til SFM
2.4. Åpne SFM-pasientbehandlingsportal fra EPJ

2.1.1.1c. Nytt krav til inaktivering av virksomhet
2.2.7. Nytt krav til resetting av PIN kode
2.3.1a-2.3.1d. Oppdatert krav og nye krav til opprettelse, oppdatering og endring av Patient/Practitioner/Person slik at personopplysninger samsvarer med Persontjenesten
2.3.3. Krav oppdatert med kommentar til xxx-id
2.3.7. Nytt krav til inaktivering av pasient
2.4.8. Nytt krav til tilgangsstyring av pasienter i EPJ

Apr 30, 2025

2.11.1.

2.11. Skriving og lesing av medisinske data fra EPJ til SFM

2.11.1. Krav om å skrive diagnoser gjelder også H-resept

Apr 10, 2025

2.1.1a.
2.1.1b.
2.1.1.1a.
2.1.1.1b.

2.1. Opprettelse, forvaltning og migrering

2.1.1a. Ny kravID. Presiseringer i kravbeskrivelse og kommentarfelt
2.1.1b. Nytt krav opprettet. Krav lagt til for å presisere at EPJ må støtte opprettelse av virksomhet i eksisterende instans.
2.1.1.1a. Kommentar til krav om hvordan operasjon CreateOrganization benyttes er slettet da dette inngår som del av kommentar til krav 2.1.1a. og 2.1.1b.
2.1.1.1b. Kravbeskrivelse endret for å presisere at begrepet underorganisasjon er knyttet til Enhetregisteret (Brreg). Lagt ved kommentar om kunderrelevans.

Apr 4, 2025

2.2.4.
2.2.6.
2.6.1.
2.6.2.
2.6.3.
2.6.4.

2.2. Opprette systembrukere i SFM
2.6. Visning av LIB og legemiddelreaksjoner i EPJ

2.2.4. Følgende kommentar lagt til kravet: “Brukere kan aktiveres i SFM i forkant av oppstart. EPJ er ansvarlig for tilgangsstyring slik at brukeren kun får tilgang til EPJ (inkludert SFM) på riktig tidspunkt.”
2.2.6. Følgende kommentar lagt til kravet: “Brukere som ikke lenger skal ha tilgang til EPJ (inkludert SFM) skal deaktiveres i SFM innen rimelig tid.”
2.6.1. Kravet fjernet fra listen da SFM LIB Widget og SFM LMR Widget er planlagt å fases ut fra 01.01.26
2.6.2. Kravet fjernet fra listen da SFM LIB Widget og SFM LMR Widget er planlagt å fases ut fra 01.01.26
2.6.3. Ordlyd i krav endret. Dette kravet gjelder ikke bruk av SFM Widgets
2.6.4. Ordlyd i krav endret. Dette kravet gjelder ikke bruk av SFM Widgets

Apr 2, 2025

2.1.2.
2.2.1.
2.2.3.

2.1. Opprettelse, forvaltning og migrering
2.2. Opprette systembrukere i SFM

2.1.2. Endret kravtekst fra EPJ skal benytte SFM sitt oppgitte migreringsformat, til at EPJ kan benytte dette
2.2.1. Følgende kommentar lagt til kravet: “Brukere kan aktiveres i SFM i forkant av oppstart. EPJ er ansvarlig for tilgangsstyring slik at brukeren kun får tilgang til EPJ (inkludert SFM) på riktig tidspunkt.”
2.2.3. Følgende kommentar lagt til kravet: “Brukere som ikke lenger skal ha tilgang til EPJ (inkludert SFM) skal deaktiveres i SFM innen rimelig tid.”

Mar 6, 2025

2.3.7.
2.11.3.

2.3. Opprette og oppdatere pasienter i EPJ og overføre pasienten til SFM
2.11. Skriving og lesing av medisinske data fra EPJ til SFM

2.3.7. Krav fjernet fra listen da SFM ikke har funksjonalitet for å støtte sammenslåing av pasienter
2.11.3. Krav fjernet da SFM ikke har funksjonalitet for å hente ut statistikkrelaterte API metoder til bruk i EPJ til statistisk analyse og rapporteringsformål

Mar 4, 2025

2.1.1.1b.

2.1. Opprettelse, forvaltning og migrering

2.1.1.1b. Presisering av krav. Med underorganisasjon menes her hvordan underorganisasjonen er representert i Brønnøysundregistrene (BRREG)

Mar 3, 2025

2.6.3.
2.6.4.

2.6. Visning av LIB og legemiddelreaksjoner i EPJ

2.6.3. Oppdatert krav (deler av dette kravet er skrevet til krav 2.6.4)
2.6.4. Nytt krav til visning LIB og LMR for EPJ som enten har egen visning, eller bruker SFM Widgets

Feb 14, 2025

2.1.1.1a.
2.1.1.1b.
2.13.2.

2.1. Opprettelse, forvaltning og migrering
2.13. Tekniske krav til API

2.1.1.1a. Ny kravID
2.1.1.1b. Nytt krav til opprettelse av underorganisasjon.
2.13.2. Endret fra godkjennes av “EPJ” til godkjennes av “NHN”

Nov 27, 2024

2.1.1.9

2.1. Opprettelse, forvaltning og migrering

2.1.1.9. Nytt krav til Multitenant

Nov 12, 2024

2.13.4.
2.1.4.
2.6.3.

2.13. Tekniske krav til API
2.1. Opprettelse, forvaltning og migrering
2.6. Visning av LIB og legemiddelreaksjoner i EPJ

2.13.4. Nytt krav til API bruk. Leverandør vises til Utviklerportalen for retningslinjer.
2.13.1. Endret fra godkjennes av “NHN” til godkjennes av “EPJ”
2.13.2. Endret fra godkjennes av “NHN” til godkjennes av “EPJ”
2.1.4. Endret krav til migrering av data. Se ny kommentarer i krav. Leverandør vises til Utviklerportalen for ytterligere beskrivelse av migreringsstrategier.
2.6.3. Nytt krav til visning av LIB andre steder i EPJ.

Nov 5, 2024

2.7.5.

2.7. Håndtering av oppgaver

2.7.5. Kravet endret fra å gjelde “alle” til “alle med funksjon” for å samsvare med kravbeskrivelsen

Oct 17, 2024

2.6.1-2.6.2.
2.10.1-2.10.5.

2.6. Visning av LIB og legemiddelreaksjoner i EPJ
2.10. Krav til overføring av legemiddelinformasjon mellom elektronisk legemiddelkurve og SFM

2.6. Kravene endret ordlyd for å presisere at SFM ikke kravstiller at SFM LIB og LMR Widget må benyttes, men at dette frivillig funksjonalitet

  • 2.6.1. Ordlyd endret fra “skal” til “kan”

  • 2.6.2. Ordlyd endret fra “skal” til kan”

2.10. Slettet i sin helhet. Det er ikke i scope for SFM å tilpasse for overføring mellom SFM Fullversjon og kurveløsning.

Oct 10, 2024
Oct 14, 2024

2.1.1.3.
2.1.1.5.
2.1.1.6.
2.4.6.
2.8.3.
2.14.1-2.14.3.

2.1. Opprettelse, forvaltning og migrering
2.4. Åpne SFM-pasientbehandlingsportal fra EPJ
2.8. Krav ved opprettelse av korrespondanse
2.14. Krav til feilsøking/support

2.1.1.3. Endret fra godkjennes av “NHN” til godkjennes av “EPJ”
2.1.1.5. Endret fra godkjennes av “NHN” til godkjennes av “EPJ”
2.1.1.6. Endret fra godkjennes av “NHN” til godkjennes av “EPJ”
2.4.6. Følgende krav til kommentar lagt: “End Session kall til sesjons-API for å terminere aktivt access token.”
2.8.3. Fremkommer nå av krav at dette gjelder kladd/utkast. Følgende kommentar til krav lagt til: “Hvis en oppføring/liste ikke er signert, og det er utkast i listen, må dette fremkomme.”
2.14.1-2.14.3. Ordlyd i krav endret

  • Endret ordlyd i kravbeskrivelse fra “ved behov” til “på forespørsel fra NHN”

  • Lagt ved følgende kommentar: “det er ikke et krav å fremskaffe slik logging tilbake i tid”

Sep 11, 2024

2.1.1
2.3.1
2.3.6
2.4.4
2.7.3
2.14.1 - 2.14.3

2.1. Opprettelse, forvaltning og migrering
2.3. Opprette og oppdatere pasienter i EPJ og overføre pasienten til SFM
2.4. Åpne SFM-pasientbehandlingsportal fra EPJ
2.7. Håndtering av oppgaver
2.14. Krav til feilsøking/support

2.1.1. Kravbeskrivelse endret til at EPJ også skal kunne oppdatere virksomheten i SFM.
2.3.1. Utførte endringer:

  • Kravbeskrivelse endret til at EPJ også skal kunne oppdatere pasient i EPJ.

  • Presisert i kommentarfelt at EPJ benytte Persontjenesten for å være synkronisert med PID, navn og adresse.

  • Følgende kommentar til krav lagt til: “Merk at man også kan få en oppgave fra SFM som skal trigge en oppdatering av pasientens personalia.”

2.3.6. Kommentar til krav oppdatert. Følgende tekst lagt til: “inkludert aktivering/deaktivering av FNR/DNR. Pasient skal ha maks 1 aktiv PID (FNR/DNR) av gangen.”
2.4.4. Rettelse i tekst. Endret fra “åpnet” til “åpen”
2.7.3. Krav markert som utgått da funksjonalitet ikke er implementert i SFM. Vil støttes på annen måte i SFM.
2.14.1-2.14.3. Nye krav til support/feilsøking
Kolonne “Sist endret” lagt til. Nyere krav og endringer f.o.m. dagens dato er markert i denne kolonnen.

Sep 9, 2024

2.5.1
2.8.1 - 2.8.5

2.5. Ordinering og rekvirering - SFM
2.8. Krav ved opprettelse av korrespondanse

2.5.1. Endret fra godkjennes av “NHN” til godkjennes av “EPJ”
2.8.1. Endret fra godkjennes av “NHN” til godkjennes av “EPJ”
2.8.2. Endret fra godkjennes av “NHN” til godkjennes av “EPJ”
2.8.3. Endret fra godkjennes av “NHN” til godkjennes av “EPJ”
2.8.4. Endret fra godkjennes av “NHN” til godkjennes av “EPJ”
2.8.5. Endret fra godkjennes av “NHN” til godkjennes av “EPJ”

Aug 26, 2024

 

Alle

Kravtabell og endringslogg publisert. Tabellen erstatter tidligere versjoner.

Aug 26, 2024

2.1
2.7

 

2.1.1.2. Kravbeskrivelse revidert. Endret kolonne “støttet i” fra “TBD” til “Alle versjoner”.
2.1.1.4. Endret fra godkjennes av “NHN” til “EPJ”. Endret ordlyd i kravbeskrivelse til “skal kunne tilby”
2.1.1.7. Endret fra godkjennes av “NHN” til “EPJ”
2.1.1.8. Endret fra godkjennes av “NHN” til “EPJ”

Aug 13, 2024

2.1
2.3
2.7

 

2.1.1. Brutt lenke fjernet
2.1.1.3. Presisering av kommentar til krav: “blir default generert automatisk i HelseID selvbetjening”
2.1.1.4. Presisering av kommentar til krav
2.1.1.6. Kommentar til krav fjernet i sin helhet (død lenke)
2.1.1.7. Ny kommentar til krav lagt til: “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.”
2.3.1. Kommentar til krav endret fra “Det er ønskelig at EPJ benytter PREG/MF HELSE for å sjekke PID, navn og adresse“ til “Ref. rekvirentkrav 2.7.3.17. EPJ skal benytte Persontjenesten for å sjekke PID, navn og adresse”
2.7.1. Kommentar til krav endret (død lenke)
2.7.6. Kommentar til krav endret. Følgende setning fjernet fra kommentarfelt: “Funksjonen skal benyttes i alle automatiske oppslag. “

Jul 1, 2024

 

Alle

Kravtabell utkast.

May 27, 2024