Tillbaka till bloggen

Beställningsportal för företagshälsovård — vad ska den klara?

Kravlista för en beställningsportal inom företagshälsovård: avtalsstyrd tjänstekatalog, roller och behörighet, statusflöde, fakturaunderlag, inloggning för sällananvändare och gränsen mot journalen.

FöretagshälsaPortwayUppdaterad 8 min readbeställningsportal, företagshälsovård, digitalisering, guide

Kort svar: En beställningsportal för företagshälsovård ska visa varje kundföretag exakt de tjänster som ingår i deras avtal, låta rätt person beställa utan att ringa, och visa var ärendet står. Det som avgör om den används är sällan funktionslistan utan två detaljer: att beställaren kommer in utan att hantera ett lösenord hen använder fyra gånger om året, och att portalen inte samlar hälsouppgifter den inte behöver. Räkna med att avtal och prislistor, inte tekniken, är det som tar tid att sätta upp.

Allt fler kundföretag kräver en digital beställningsportal, och i offentliga upphandlingar är den ofta ett skallkrav snarare än en fördel. Men "portal" betyder olika saker för olika leverantörer. Den här artikeln går igenom vad som faktiskt behöver fungera, i den ordning det brukar gå fel.

Vad en beställare faktiskt gör

Innan funktionslistan: beställaren i kundföretaget är en chef eller HR-administratör som gör det här kanske ett par gånger per kvartal. Hen är inte er dagliga användare, kommer aldrig att lära sig systemet, och har inget tålamod med en portal som kräver att hen minns något.

Det förklarar varför portaler misslyckas av skäl som inte står i kravspecifikationen. Beställningen görs inte i portalen utan i ett mejl till en handläggare som beställaren råkar känna — och då är hela investeringen förbi. Allt nedan handlar egentligen om att göra portalvägen till den enklaste vägen.

Avtalsstyrd tjänstekatalog

Grundkravet: kundföretaget ska se sina tjänster, inte era. En generisk katalog där hälften av raderna inte ingår i avtalet leder till beställningar ni måste avvisa, och en avvisad beställning är dyrare än ett telefonsamtal.

Det innebär i praktiken att tjänster kopplas per kundföretag, med det avtalets urval, benämningar och priser. Två kunder som köper "hälsoundersökning" köper sällan samma sak, och den som har förhandlat ett eget innehåll förväntar sig se det.

Detsamma gäller åt andra hållet: om ett kundföretag har en egen blankett eller en extra fråga som ska ställas vid varje beställning, ska den finnas i deras flöde och ingen annanstans.

Roller och behörighet

Alla i kundföretaget ska inte kunna beställa allt. Den uppdelning som fungerar i praktiken är tre nivåer:

  • HR-administratör — ser hela organisationen, avtalet, fakturaunderlag och statistik
  • Chef — beställer för sin egen avdelning och ser bara den
  • Medarbetare — bokar i förekommande fall sin egen tid, ser inget annat

Den mittersta nivån är den som brukar saknas. Utan avdelningsavgränsning ser varje chef alla beställningar i hela företaget, och eftersom en beställning innehåller namn på medarbetare som ska på hälsoundersökning är det en integritetsfråga, inte en bekvämlighetsfråga. Hos oss löses det med grupper: en chef kopplas till sin avdelning och ser det som hör dit.

Statusflödet — och vad kunden får se

En beställning behöver ett fåtal begripliga lägen. Vi använder fyra: mottagen, pågår, klar, avbruten. Fler lägen låter mer informativt och blir mindre — ingen beställare vet vad skillnaden mellan "under beredning" och "under handläggning" innebär för dem.

Det som gör statusen värd något är att den uppdateras automatiskt när ni gör något, inte när någon kommer ihåg att uppdatera den.

En detalj som är lätt att missa i kravställningen: interna anteckningar och kundsynliga meddelanden måste vara två skilda saker på samma ärende. Handläggare behöver kunna skriva "ring Anna innan vi bokar, förra gången blev det fel" utan att det syns hos kunden, och kunden behöver kunna ställa en fråga i ärendet i stället för att mejla. Portaler som bara har ett kommentarsfält får antingen tomma anteckningar eller ett obehagligt läckage.

Inloggning för sällananvändare

Det här är den punkt där flest portaler tappar sina användare. En beställare som loggar in fyra gånger om året har glömt lösenordet varje gång, och en glömd inloggning i ett akutläge blir ett telefonsamtal — precis det portalen skulle ta bort.

Alternativen som fungerar:

  • Magisk länk — beställaren fyller i sin mejladress och får en engångslänk. Inget lösenord att glömma, och åtkomsten hänger på mejlkontot, som redan är den kanal ni kommunicerar i. Det här är vår standard.
  • BankID — vanligt när portalen också ger medarbetaren åtkomst till egna uppgifter, och ofta ett krav i offentlig sektor.
  • SSO mot kundföretagets katalog — bäst för stora kunder, men kräver en insats per kund och lönar sig sällan under en viss storlek.

Vanliga lösenord är det sämsta alternativet för just den här användaren, oavsett hur bra återställningsflödet är.

Fakturaunderlag och avtalsdokument

Två saker som beställare frågar efter och som ofta glöms i portalbygget:

  • Fakturaunderlag — vad har beställts, av vem, på vilken avdelning, under perioden. HR ska kunna svara på "vad har vi använt hittills i år" utan att höra av sig till er. Det är också den vanligaste orsaken till att någon över huvud taget loggar in mellan beställningarna.
  • Avtalet självt — vilka tjänster som ingår, till vilka priser, och vad som gäller vid avbokning. Ligger det i portalen slutar ni svara på frågan i mejl.

Gränsen mot journalen

Det viktigaste arkitektoniska beslutet, och det som sällan står i en kravspecifikation: en beställningsportal ska inte bli en journal.

En beställning säger att en namngiven medarbetare ska på en hälsoundersökning ett visst datum. Den ska inte innehålla anledningen, tidigare besvär eller resultat. Det som är vårddokumentation hör hemma i journalsystemet under patientdatalagen, med de bevarandekrav och den åtkomststyrning som följer där — samma uppdelning som vi går igenom i checklistan för systembyte.

Blandas de ihop uppstår två problem samtidigt. Kundföretagets chefer får åtkomst till uppgifter en arbetsgivare inte ska ha, och ni får journaluppgifter i ett system som inte är byggt för att bevara dem i tio år.

Det betyder inte att portalen är okänslig. Redan uppgiften att en viss person ska på ett samtalsstöd är en känslig personuppgift enligt GDPR, och kraven på kryptering, åtkomststyrning, lagring inom EU och personuppgiftsbiträdesavtal gäller fullt ut. Vi går igenom dem i GDPR och säkerhet inom företagshälsovård.

Portalen är kundföretagets, inte er

Ett kundföretag som loggar in i en portal med er logotyp uppfattar det som ert system. Ett kundföretag som loggar in i en portal med sin egen logotyp uppfattar det som sitt. Skillnaden märks i hur ofta den används och hur den beskrivs internt hos kunden — och den är gratis att bygga in från början och besvärlig att lägga till efteråt.

Detsamma gäller ordernummer: en beställning som heter något kunden känner igen är lättare att hänvisa till i ett mejl än ett löpnummer ur er databas.

Vanliga fallgropar

  • Onboarding som tar veckor. Om det krävs en utvecklarinsats för att lägga upp ett nytt kundföretag kommer säljaren att sluta lova portalen. Avtal och prislistor ska gå att lägga in av er egen personal.
  • Ingen mobil. Chefer beställer från telefonen, ofta stående i en korridor.
  • Notifieringar som bara går ut. En bekräftelse räcker inte; det som minskar samtal är uppdatering vid schemaläggning och påminnelse före besök.
  • Ingen spårbarhet. När en kund undrar vem som beställde vad i mars behöver ni kunna svara utan att gissa.
  • Statistik som ingen bad om. Ett fåtal siffror kunden faktiskt använder slår en instrumentpanel som ser imponerande ut i en demo.

Så gör vi i Portway

Beställningsportalen är avtalsstyrd per kundföretag, med kundens egen profil och egna tjänster. Beställare loggar in med magisk länk, chefer avgränsas till sin avdelning via grupper, och varje ärende har både interna anteckningar och en kundsynlig tråd. Statusändringar går ut som e-post eller SMS, och beställningen delar tjänstekatalog med tidbokningen, så ingenting skrivs om.

Vill ni se hur flödet ser ut med era egna tjänster och avtal går det att boka en genomgång.

Vanliga frågor

Vad är skillnaden mellan en beställningsportal och ett journalsystem? Beställningsportalen hanterar vad kunden har beställt, av vem och när, samt fakturaunderlaget. Journalsystemet hanterar vårddokumentationen och lyder under patientdatalagen. De ska hållas isär: kundföretagets chefer ska ha åtkomst till det första och aldrig till det andra.

Måste kundföretaget ha BankID för att beställa? Nej. För en beställning räcker normalt en verifierad mejladress, till exempel via en engångslänk. BankID blir aktuellt när enskilda medarbetare ska se uppgifter om sig själva, och krävs ibland i offentliga upphandlingar.

Hur lång tid tar det att lägga upp ett nytt kundföretag? Själva uppsättningen är en administrativ uppgift på under en timme när avtalet är klart. Det som tar tid är att bestämma vilka tjänster som ska ingå och till vilka priser — alltså avtalsarbetet, inte systemet.

Kan varje kundföretag ha egna tjänster och priser? Ja, och det är hela poängen. En portal som bara klarar en gemensam prislista tvingar er att hantera undantagen manuellt, vilket är den administration portalen skulle ta bort. Vi går igenom den effekten i minska administrationen inom företagshälsovård.