In 2025, patients in Poland's public system did not show up and did not cancel 6.74% of planned visits¹. 2 in 3 Polish primary care patients still book by phone, and only 8% online². All of that lands on reception, which in many clinics runs on rules nobody wrote down.
Off-the-shelf clinic management software handles the standard flow well. The private clinic in this story needed custom clinic management software, with its own rules built in: how a patient moves from the first call to a finished visit, who may do what, and what must never happen. We wrote those rules down as a contract first, and we build the app from it on EHOS, our platform for software made for a company, to its own rules.
Contract-first means we write down how the clinic works before any code is written: a written description of the clinic's processes, its rules and the actions the software must refuse, in the language of the people who run the clinic. This is a report from the build, written by the engineer building it.
Why doesn't off-the-shelf clinic management software fit every clinic?
The pressure on clinic staff is measurable. In a 2025 survey of 499 Polish doctors, 54% named bureaucracy as the biggest burden in their work³. Across 5 European countries, 65% of clinicians spend more than 1 hour a day on admin, and 4 in 5 say this reduces time with patients, according to a 2025 survey by Tandem Health, a vendor of AI tools for clinicians⁴. A rule that lives only in someone's head is one more thing to check by hand.
In this clinic, the current reception software follows a generic patient flow, and the clinic's own rules did not fit it. So the team worked around the system:
- Vouchers bought in the mobile app. They didn't show up at the front desk, so someone matched them by hand.
- A free slot without the machine. The calendar showed a free slot even when the machine needed for that treatment was already in use.
- The late-cancellation fee. Whether a patient paid it depended on whether someone at reception remembered to mark it.
- 1 visit, 2 payers. When the patient paid for part of a visit and an insurer for the rest, the system couldn't split it, so staff worked around it.
Each workaround cost reception time and left numbers the team could not fully trust, because payments, bookings and fees depended on who was at the desk that day.
Configurable clinic systems work well when a clinic's workflow fits their model. This one did not, so the clinic chose to have its own rules built in.
What does a clinic get from custom clinic management software?
- Its rules written down once, in its own words. Booking, a medical certificate, a fee for a missed visit, who pays for what: each process is described the way the clinic runs it.
- The documented scenarios run as tests. If a change breaks one of those rules, the test fails.
- Missing rules show up early. When a screen needs a rule nobody wrote down, the gap shows up while building, and the clinic decides it, instead of the code deciding by accident.
- New staff follow the clinic's rules from day 1. The rules sit in the system, not only in the heads of the people who have worked there longest.
- A change starts with a rule written in the clinic's own words. The clinic sets the priority itself, instead of waiting for a generic product's roadmap.
The app is built for this clinic. We are building it for 1 clinic; other clinics with a process their software keeps working around could gain something similar, and we will know more once this clinic works in the app.
1 rule, from the front desk to the app
Take the late-cancellation fee. Once it is written down, the rule works the same way whoever is at the desk:
| Part of the rule | Example: a missed visit |
|---|---|
| Event | A patient does not come to a confirmed visit |
| Who decides | The reception manager, under the clinic's own policy |
| Rule | A fee can be proposed only when the visit meets the clinic's agreed criteria |
| Exception | An authorised person can waive the fee and record why |
| What the system must refuse | Charging a patient automatically outside that policy |
| Test | When a waiver is approved, no fee is issued and the decision is recorded |
Illustrative: how a rule is structured. The wording is an example and does not quote the clinic's contract.
The same parts can describe the clinic's other processes: booking, certificates, who pays for what.
Why is the clinic app built on EHOS?
EHOS is the platform Empowered House builds for software made for a company, to its own rules. A process that makes a company different can get its own app, built from how its team actually works. For this clinic, that shapes the work:
- 1 contract per process. Booking, visits and payments each have their own written rules, in 1 place instead of across screens.
- Rules the system keeps. Rules and deadlines are kept by the system, so they don't depend on someone remembering; it refuses steps nobody agreed to.
- A record of who did what. You can see who did what and when.
- More time for the clinic's rules. Each next app starts with access rules and an audit trail already in place, so the engineer does not build them again for every app.
- Faster, in the engineer's view. The recorded workshops turned into a contract quickly. Writing it forces the questions early, so what the clinic agreed is what the app does.
How do you map a clinic's processes before building software?
We started with an event storming workshop with the clinic team. Every session was recorded and transcribed, and the path after that had 3 steps: transcript, then a write-up and a mockup, then the contract and the app. This project began before EHOS existed, so treat its steps as one example, not a benchmark. How we map a process with the people who run it is described in our method.
We did not try to settle every exception in the workshop. There was a lot to take in, and the point was to get the shape of the processes right. The details come while building.
How does contract-first development work day to day?
"For me, the contract is the documentation I build the app on," says Filip, the engineer on the project. "The app checks the scenarios from the contract as tests."
Each process the clinic runs gets its own contract, and the app is built process by process: the schedule, visit booking and patient records came first, and the clinic's other processes follow. The contract also covers the outside systems the clinic needs, such as SMS reminders.
The contract grows with the app. When a screen needs a rule nobody has written down yet, the rule goes into the contract first, and open questions go back to the clinic. That is the day-to-day work: small, frequent additions to the contract.
What did the contract change for the engineer?
- Less explaining. The clinic's knowledge sits in 1 structured place, so neither Filip nor the AI agent writing code with him has to rediscover it for every screen.
- Tests and documentation say the same thing. Both come from the same written rules, so they do not drift apart. Someone still checks that the tests cover enough.
- More control over the rules. The contract is the documentation and part of the code, so the app follows what the clinic confirmed; whether that means fewer rounds of fixes, the project will show.
What is still hard?
Reviewing the contract itself. Filip works with it mostly through the AI agent, and a careful read-through by people is part of the plan before the clinic goes live. Now and then a rule needs something EHOS cannot express yet, and that goes back to the EHOS team. EHOS is still in alpha, and this project is one of the ways it gets better.
What is built so far?
Build status, November 2026:
- Done: the schedule, the visit calendar and booking, the patient record, and the settings those views need, such as services, staff and rooms.
- Next: the clinic's other processes, 1 at a time.
- Test data only: the test environment uses synthetic data generated by AI, with fake identifiers, invalid phone numbers and example email addresses. Real patient records move over later, through a migration that imports as much as possible from the clinic's current system.
There are no business results to report yet, and we will not invent any. When the clinic starts working in the app, we will write part 2.
FAQ
What is custom clinic management software?
Software built for one clinic's bookings, visits, certificates and payments, following that clinic's own rules instead of a generic patient flow.
When should a clinic build its own software?
When a process it runs every day does not fit the configuration its current system allows, and the workarounds cost more than building and maintaining its own.
How do you handle no-show fees in clinic software?
Write the no-show fee down as its own rule: when it applies, who decides and who can waive it. The app is then tested against that rule.
Can we keep our current clinic system during the build?
In this project, yes. The clinic keeps its current system while the new app is built and tested on synthetic data; real data moves over later, through a migration.
What is event storming?
A workshop where the people who run a process map it step by step as events on a wall. For this clinic it took about 10 hours with the clinic team over 2 days, plus time afterwards to work through the material.
How long does it take to build custom clinic software?
It depends on how many rules the process has and how many exceptions the team works around today. The scope is agreed after a workshop with the people who run the process, and the app is built in stages, process by process.
What is contract-first development?
You write down how a process works first, then build and test the software against that description. Here the contract covers the clinic's processes, its rules and the actions the software must refuse.
If your clinic depends on rules your current software cannot follow, start with 1 process. We map it with your team in a fixed-price workshop and help you decide whether to configure what you have, extend it or build your own. Book a 30-minute fit call.
Sources
- Ministry of Health, Poland, reply to parliamentary question 16235 (2026), data for 2025, centrally managed waiting lists: api.sejm.gov.pl
- Maison & Partners for CM CMP, survey of 2,396 patients in Poland, September to October 2025, reported by Medycyna Praktyczna: www.mp.pl
- Zymetria for Polpharma, survey of 499 doctors in Poland, October to December 2025, published 2026: polpharma.pl
- Tandem Health, Time to Care, more than 1,000 clinicians in the UK, France, Germany, Spain and Sweden, 17 November 2025: tandemhealth.ai
