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.

Detaljer og funksjonalitet som ikke direkte er dekket av kravene i dette dokumentet, men som utvikles i sammenheng med SFM-integrasjonen, vil også kunne inngå som del av test - og godkjenningsløpet. Leverandører må sørge for at dette blir avklart før oppstart utvikling. Godkjenningsprosessen planlegges sammen med hver enkelt leverandør (se egen side for mer informasjon).

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

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:

  1. I SFM stilles det krav om at EPJ etterspør en pasientbillett før det kan kommuniseres om pasienten.

  2. 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, skal SFM være den primære lokale kilden («master») til pasienters aktuelle LIB. Dvs. at EPJ skal bruke SFM som kilde og ikke vedlikeholde en egen lokal LIB. I tillegg skal andre historiske legemiddelopplysninger slik som tidligere legemiddelbehandlinger, resepthistorikk, utleveringshistorikk, m.m. kun eksistere i SFM. Der EPJ ønsker å bruke informasjonen, skal 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. Krav ved opprettelse av korrespondanse

Ettersom SFM skal være den primære lokale kilden for legemiddelopplysninger og kritiske legemiddelreaksjoner (LMR), vil SFM også være kilde der denne typen informasjon skal 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. Krav 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.



Endringshistorikk for krav

Beskrivelse av endring utført og sist endret dato