FD Sundhed — 16,838 employees, one national ID that never leaves the building
16,838 municipal employees. One national ID number that must never leave the building. A booking that has to land in a system we don't own. FD Sundhed is the hard kind of software: it writes itself into the space between systems that already exist, and it handles the most sensitive category of data there is.
The City of Aalborg runs an employee health scheme. Hurt your back, and your workplace pays for the physiotherapy. The scheme had existed for years. The scheme was never the problem — the way in was.
See the platform live: fdsundhed.dk
Before: a benefit nobody used
A benefit only gets used if it is easier than not using it. The old route was the opposite: work out whether you're covered, call your manager, get a yes somehow, call the clinic, find a slot, hope the invoice reaches the right place.
Five steps, four waits, and somewhere along the way most people give up. The most expensive sick leave is the one that started as a minor shoulder nobody dealt with.
After: four steps, and none of them is a phone call
The employee opens the app — or the browser, it's the same product — and points at where it hurts. The manager is notified and says yes or no, typically within a day. The moment approval lands, the employee gets access to the clinic's actual calendar and books a slot. Not a request for a slot. The slot.
From "ouch" to a booked treatment, without anyone picking up a phone.
The app was not the hard part
Making it talk to the world as it actually is — that was.
Booking into a system we don't own. The clinics run on Complimenta, an established patient system from CGM. We didn't replace it. FD Sundhed speaks to it through its own API: pulls therapists, services and open slots, creates the booking, cancels it again if the employee changes their mind. The calendar in the app isn't a copy of the clinic's. It is the clinic's.
That imposes a requirement few integrations ever face: an employee who has never visited the clinic doesn't exist as a patient. So the solution has to be able to create her — on the clinic's behalf, with a national ID as identification — without creating a duplicate of someone who happened to visit three years ago.
A national ID that stays put. The employee enters her CPR number once. We store it encrypted and use it to find her in the clinic's system. When the billing step later needed to know who a treatment was for, it offered three ways to identify a person — and the national ID was the only one we could supply. So we built a fourth: we pull the patient number out of the clinic's system at the moment the booking is created, and send that instead. A national ID never leaves the building.
A manager with more than one workplace. A municipal manager may be responsible for three departments, each with its own account to be billed. She picks which one when she approves, and the choice is recorded in the audit trail. Not because anyone asked for it — but because the alternative is an invoice nobody can explain six months later.
Health data is not ordinary data
What an employee is suffering from is a special category under GDPR. It isn't a field you protect slightly better than the others; it's a field that requires explicit consent, documented access, and a straight answer about who sees what.
So that question was put to the customer directly rather than guessed at: does the manager see what the employee is suffering from? The answer was yes — the manager sees the whole report. That now appears in the product, in the text the employee reads before submitting, and it is written into the code as a rule that can't be broken by accident. A confidentiality promise you cannot keep is worse than no promise at all.
Row-level access in the database, encrypted national IDs, an audit trail on every approval. Not as a list of things we remembered — as the precondition for accepting the first real report at all.
One codebase, three surfaces
The solution exists as a web app, as an installable app on the phone, and as real apps in the App Store and on Google Play. These are not three products. It is one codebase wrapped in a native shell — so the app can do what an app should: Face ID instead of a password, a notification the moment the manager answers, and your appointments in your pocket even with no signal.
And because it is the same codebase, there is no "app version" trailing three weeks behind the website.
The guides are part of the product
Health schemes rarely fail on the technology. They fail because nobody dares to press the button.
So the solution shows the whole journey, screen by screen, before you log in — 16 screens for the employee, 11 for the manager. Real screenshots from the real product. You can see exactly what is about to happen before deciding whether you dare.
Where it stands
16,838 employees have been imported from the municipal register. The scheme is live, the app is on Google Play, and the iOS build is working its way through Apple's review. 125 documented features sit behind it.
This is not a pilot waiting to become real.
Why it went so fast
FD Sundhed was not built from scratch. It was built on broberg.ai — the same foundation of reusable building blocks as the rest of the universe: mail, authentication, error monitoring, visual verification, AI access. Every time one of them improves, FD Sundhed improves with it.
That is the difference between building a product and building on a platform. Built lightning-fast. Built right.