FD Sundhed — 16.838 ansatte, uden CPR forlader huset
16.838 kommunalt ansatte. Personnumre der aldrig må forlade huset. En booking der skal lande i et system vi ikke ejer. FD Sundhed er den sværeste slags software: den skriver sig ind mellem systemer der allerede findes, og den håndterer den mest følsomme datatype der eksisterer.
Aalborg Kommune har en sundhedsordning. Har du ondt i ryggen, betaler din arbejdsplads for at du kommer til fysioterapeut. Ordningen har eksisteret længe. Problemet var aldrig ordningen — det var vejen ind i den.
Se platformen live: fdsundhed.dk
Før: en ordning ingen brugte
En ordning bliver kun brugt hvis den er lettere end at lade være. Den gamle vej var det modsatte: find ud af om du er omfattet, ring til din leder, få et ja på en eller anden måde, ring til klinikken, find en tid, håb på at fakturaen lander det rigtige sted.
Fem led, fire ventetider, og et sted undervejs opgiver de fleste. Den dyreste sygemelding er den der starter som en lille skulder, ingen fik gjort noget ved.
Efter: fire trin, og ingen af dem er et telefonopkald
Medarbejderen åbner appen — eller browseren, det er samme løsning — og peger på hvor det gør ondt. Lederen får besked og siger ja eller nej, typisk inden for et døgn. I samme sekund godkendelsen falder, får medarbejderen adgang til klinikkens rigtige kalender og booker sin tid. Ikke en anmodning om en tid. Tiden.
Fra «av» til en booket behandling, uden at nogen har løftet et rør.
Det svære var ikke appen
Det var at få den til at tale med verden som den er.
Booking mod et system vi ikke ejer. Klinikkerne kører på Complimenta — et etableret patientsystem fra CGM. Vi skiftede det ikke ud. FD Sundhed taler med det via dets eget API: henter behandlere, ydelser og ledige tider, opretter bookingen, annullerer den igen hvis medarbejderen fortryder. Appens kalender er ikke en kopi af klinikkens. Den er klinikkens.
Det stiller et krav de færreste integrationer skal opfylde: en medarbejder der aldrig har været på klinikken før, findes ikke som patient. Løsningen skal derfor kunne oprette hende — på klinikkens vegne — med CPR som identifikation, uden at oprette en dublet af en person der tilfældigvis var der for tre år siden.
Et personnummer der bliver hvor det er. Medarbejderen indtaster sit CPR én gang. Det gemmes krypteret hos os og bruges til at finde hende i klinikkens system. Da faktureringsleddet senere skulle vide hvem behandlingen gjaldt, tilbød det tre måder at identificere en person på — og CPR var den eneste vi kunne levere. Så byggede vi den fjerde: vi henter patientnummeret ud af klinikkens system i samme øjeblik bookingen oprettes, og sender det. Et personnummer forlader aldrig huset.
En leder med flere arbejdspladser. En kommunal leder kan have ansvar for tre afdelinger med hver sin konto der skal betale. Hun vælger kassen når hun godkender, og valget står i revisionssporet bagefter. Ikke fordi nogen bad om det — men fordi alternativet er en faktura ingen kan forklare et halvt år senere.
Helbredsdata er ikke almindelige data
Hvad en medarbejder fejler er en særlig kategori under GDPR. Det er ikke et felt man beskytter lidt bedre end de andre; det er et felt der kræver udtrykkeligt samtykke, dokumenteret adgang, og et klart svar på hvem der ser hvad.
Så det spørgsmål blev stillet direkte til kunden i stedet for at blive gættet: ser lederen hvad medarbejderen fejler? Svaret var ja — lederen ser hele indberetningen. Det står nu i produktet, i den tekst medarbejderen læser inden hun sender, og det er skrevet ind i koden som en regel der ikke kan brydes ved et uheld. Et løfte om fortrolighed man ikke kan holde, er værre end ingen løfte.
Rækkeadgang i databasen, krypteret CPR, revisionsspor på hver godkendelse. Ikke som en liste over ting vi huskede — som forudsætningen for overhovedet at tage den første rigtige indberetning.
Én kodebase, tre flader
Løsningen findes som webapp, som installerbar app på telefonen, og som rigtige apps i App Store og Google Play. Det er ikke tre produkter. Det er én kodebase, pakket ind i en native skal — så appen kan det en app skal kunne: Face ID i stedet for et kodeord, en notifikation når lederen har svaret, og dine tider i lommen også når der ikke er net.
Og fordi det er samme kodebase, findes der ikke en «app-version» der halter tre uger efter hjemmesiden.
Guiderne er en del af produktet
Sundhedsordninger fejler sjældent på teknikken. De fejler på at ingen tør trykke.
Derfor viser løsningen hele forløbet frem, skærm for skærm, før man logger ind — 16 skærmbilleder for medarbejderen, 11 for lederen. Ægte skærmbilleder fra det ægte produkt. Man kan se præcis hvad der kommer til at ske, inden man beslutter sig for om man tør.
Hvor det står
16.838 medarbejdere er importeret fra kommunens kartotek. Ordningen er live, appen er i Google Play, og iOS-udgaven er på vej gennem Apples review. 125 dokumenterede features ligger bag.
Det er ikke et pilotprojekt der venter på at blive rigtigt.
Hvorfor det gik så hurtigt
FD Sundhed er ikke bygget fra bunden. Det er bygget på broberg.ai — det samme fundament af genbrugelige byggeklodser som resten af universet: mail, autentificering, fejlovervågning, visuel afprøvning, AI-adgang. Hver gang en af dem bliver bedre, bliver FD Sundhed det også.
Det er forskellen på at bygge et produkt og at bygge på en platform. Bygget lynhurtigt. Bygget rigtigt.