De funksjonelle kravene knyttet til e-resept kan deles inn i noen overordnede prosess-steg, med tilhørende administrative- og støttefunksjoner, samt tekniske krav og forutsetninger. Ettersom e-resept er en samhandlingskjede der alle behandlere og aktører må samarbeide om en felles oversikt over legemiddelopplysninger er det viktig at det etableres felles prosesser og at informasjonen forstås likt i alle systemer. Helt overordnet kan arbeidsprosessen for bruker deles i tre faser;
- Innhenting av informasjon fra andre kilder enn lokal EPJ
- Behandling av informasjon (samstemme/endre/godkjenne)
- Oppdatering av sentral informasjon og eksterne kilder
Disse hovedfasene kan brytes videre ned i ulike prosess-steg, der hvert enkelt steg har et sett med funksjonelle krav knyttet til seg. Dette er illustrert i figuren under. Figuren er nærmere forklart i tabellen under, samt illustrert i prosess-beskrivelsene i Vedlegg.
Figuren, og prosessen, er ment som et utgangspunkt for å gruppere og sortere krav. Det er ikke dermed sagt at dette er en fast prosess med separate steg for brukere, eller en beskrivelse av skjermbilder. En lege vil eksempelvis kunne samstemme og endre legemiddelbehandling samtidig i samme arbeidsflate, selv om dette er to ulike handlinger (finne ut hva pasienten faktisk bruker vs. endre behandlingsregime for pasient). Stegene og prosessen er dermed ikke å forstå som skjermbildeflyt eller en stegvis arbeidsprosess som skal følges.
Figur 1 - Overordnet modell med funksjonelle områder
Under følger en kort beskrivelse av de ulike stegene og områdene. Disse vil bli forklart nærmere i hvert krav-kapittel.
Prosess-steg | Beskrivelse |
Administrative krav og støttefunksjoner | Dekker generelle krav som går på tvers av funksjonelle områder, samt administrative opplysninger om pasient og bruker. Administrative funksjoner, slik som bruk av FEST, meldingshåndtering, oppgavelister, m.m. er og dekket i dette området. |
Innhente | Prosess-steg for å innhente og tilgjengeliggjøre oppdatert informasjon til helsepersonell. Omfatter automatiske eller manuelle oppslag i RF, samt bruk av informasjon som er tilkommet systemet via asynkrone prosesser (eksempelvis utleveringsmeldinger eller andre elektroniske meldinger). |
Samstemme | Systemet skal sammenstille elektronisk tilgjengelig informasjon (lokal informasjon og informasjon fra Oppslag) og presentere det for helsepersonell til samstemming. Helsepersonell skal ha funksjonalitet for å "rydde informasjonen" for å etablere gjeldende Legemidler i Bruk, altså en sannhet om hva pasienten faktisk bruker. Dette må om mulig gjøres sammen med pasienten for å sikre at informasjonen er oppdatert. I forbindelse med etableringen skal helsepersonell også kunne legge inn informasjon fra andre kilder, eksempelvis pasienten selv, papirlister osv. For mer informasjon, se pasientsikkerhetsprogrammet sin definisjon og informasjon om samstemming http://www.pasientsikkerhetsprogrammet.no/om-oss/innsatsomr%C3%A5der/samstemming-av-legemiddellister |
Godkjenne | Et mellomsteg for godkjenning av pasientens Legemidler i bruk. Forutsetter at informasjon fra oppslag og lokal informasjon er ferdig samstemt. Vil ofte være mest relevant for institusjoner og innleggelser der man opererer med flere lokale versjoner av LIB over tid. For poliklinikk, fastlegepraksiser, og andre virksomheter hvor pasienten ikke innlegges, vil dette ofte ikke være et eksplisitt steg, men følge av andre aksjoner (oppdatert og innsendt PLL til RF vil i praksis være en godkjenning). |
Endre legemiddelbehandling | Steget omfatter endringer av legemiddelbehandling og/eller legemiddelreaksjoner, som blir besluttet gjennomført og dokumentert. Dette er altså medisinskfaglige vurderinger og ikke "administrativ rydding" av legemiddelopplysninger til pasienten slik som samstemmingssteget. |
Oppdatere FIB/NIB | Forbruksmateriell og næringsmidler er ikke legemidler, men er relevant for en legemiddelmodul fordi produktene for mange pasientgrupper refunderes via blåreseptforskriften og i disse tilfelle må rekvireres på resept. Kravene dekker endringer og oppfølging av resepter og utleveringer på disse. |
Levere | Prosessen omfatter levering av oppdatert informasjon til RF og andre eksterne systemer. Etter innføring av Pasientens Legemiddelliste (PLL) medfører alle endringer pasientens legemiddelopplysninger at det i tillegg til resepter, skal sendes ny oppdatert PLL til RF. |
Tekniske krav | Dekker krav som dekker tekniske funksjoner slik som meldingsformater, sertifikathåndtering, m.m. |
2.1.1 Informasjonsmodell og relasjoner
Figuren under illustrerer sammenhengen i informasjonen som omhandles i kravspesifikasjonen. Det viktigste elementet som omhandles i kravspesifikasjonen er legemiddellisten til pasienten. Som nevnt i definisjoner; den lokale legemiddellisten i EPJ kalles LIB (legemidler i bruk), den sentrale i Reseptformidleren kalles PLL (Pasientens Legemiddelliste). Begge to er legemiddellister, og målet er at den lokale og den sentrale legemiddellisten er oppdatert og synkronisert dersom pasienten skrives ut eller andre aktører/virksomheter kan tenkes å få pasienten til behandling. Det er og svært viktig at legemiddelmoduler integreres godt med andre lokale systemer for å sikre at behandlere internt i en virksomhet også samhandler om felles informasjon. Krav rundt funksjonalitet ellers i EPJ er ikke dekket i denne kravspesifikasjonen.
En legemiddelliste består av en eller flere legemiddelbehandlinger og/eller kosttilskudd. Hver av disse igjen kan ha en eller flere resepter knyttet til seg, men maksimum én aktiv resept til enhver tid (noen tekniske unntak dersom resept er låst for ekspedering e.l.). Reseptene igjen vil ha en eller flere utleveringer knyttet til seg. 
Figur 2 - Konseptuell informasjonsmodell og relasjoner
For mer detaljer, se kapittel 2.3 - Oppslag og innhenting av informasjon der de ulike objektene defineres nærmere.
2.1.2 Brukertyper og roller
I kravspesifikasjonen brukes det ulike begreper om ulike brukertyper. Disse er illustrert i figuren under.
Figur 3 - Oversikt over brukertyper i kravspesifikasjonen
"Administrativ bruker" brukes generelt om en bruker som arbeider ikke-klinisk. Helsepersonell brukes om kliniske brukere, og er enten godkjent helsepersonell med HPR-nummer, eller ufaglært helsepersonell med behov for systemtilgang. Helsepersonell kan brytes videre ned i undergrupper, der noen krav gjelder kun for rekvirenter, og andre krav gjelder kun for ikke-rekvirenter. Ulike rekvirenttyper kan og ha ulike rettigheter og krav, og rekvirent-brukertypen må dermed brytes ytterligere ned i undergrupper.
Både helsepersonell og administrativ bruker kan ha administratorrettigheter. Tanken er at kravene da gjelder for det nivået som omtales, inkludert alle undergruppene. Et krav som omhandler "rekvirent" vil dermed gjelder for lege, tannlege, jordmor og helsesykepleier, men ikke for helsesekretærer f.eks. Dette kan eksempelvis være oppslag i RF der kun rekvirenter har tilgang. Rettigheter som er regulert av forskrift skal kontrolleres av systemet, mens rettigheter som kan delegeres av databehandlingsansvarlig skal være satt av administratorbruker.
Brukertypene her er ikke det samme som roller, og ulike brukertyper kan gjerne tildeles ulike roller. Roller kan eksempelvis være "medhjelper", som kan gjelder for både jordmødre og for helsesekretærer.