Let's talk about
your project
your project
Fill out the form. We'll get back to you within 24 hours with a proposal.
This was a system for a network of medical facilities: booking, patient records, online and on-site visits, and full e-health integration with the national hub, the insurance institution and the medical chamber. We show how it looked from the inside: from cutting the system off an external platform, through building an own data model, to a multi-week fight with electronic sick notes. The project covered around 150 facilities, close to 100 consulting rooms and 40 doctors. We closed 457 tickets in Jira and the whole thing took roughly a year and a half, of which the development phase alone was close to a year and the UX/UI project 3 to 4 months. This was not an ordinary "booking system": the hardest part turned out to be the integrations with state systems, where the outcome is decided by specification details and error handling.
The system works as a standalone product: a doctor runs facilities, rooms, services, visits, patient records and documentation on our side, and e-health documents go where they should. We deliberately do not quote percentage figures here, because the project did not measure them in a way we could honestly cite. What we can show is the scope and the decisions.
This case covers the integrations with state systems: P1, ZUS and NIL, and what came out of them in practice. If you are looking instead for how we rebuilt the foundation and made the system independent of an external platform, we covered that separately: migration and building an own data model.
At the start the system was not self-contained. Booking and the work of the consulting room rested on an external platform, which supplied the data on doctors, availability, visits and slots. The search, the calendar, the admin panel and the reports all reached into someone else’s source.
The biggest surprise sat in the data: services and consulting rooms were identified by identifiers from that external platform rather than by our own records. As long as that held, every new feature, whether a prescription, a sick note or a medical event, would have to defer to a foreign system. So the first real design decision was simple: bring the logic in-house. We unpacked that as a separate thread: cutting off the external platform and building an own data model.
We built our own data model: tables and a panel to manage a doctor’s facilities, rooms and services, with add, edit and delete, and with visit statuses carried across. The doctor search, the calendar and appointment booking started reading from our tables rather than from the external portal. A service can be tied to a specific room and marked as online or on-site. The result of this layer: a doctor manages their facilities, rooms and services in the system’s own panel, free of the external platform. That was the precondition for adding anything on top.
Rezultat tej warstwy: a doctor manages their facilities, rooms and services in the system’s own panel, free of the external platform. That was the precondition for adding anything on top.
On that core sit the modules that make up the daily work of a facility: Schedule (doctor availability and assigning patients to slots), Facility (locations, rooms, services), Records, split between the visit record and the patient record, plus support for doctors working online and on-site. The schedule turned out to be less obvious than it looks: availability is not one calendar but a crossing of doctor, room and service, where any of the three can disappear independently of the others.
On that foundation we added integrations with three e-health systems. Each one needs its own contract or application, its own technical test and, importantly, a contract held by the healthcare provider, not by the IT company:
The whole thing is signed using WS-Security, with a certificate tied to an individual doctor, on infrastructure that meets hard requirements: a static public IP address (for the allowlists of the e-health, social insurance and medical chamber systems), database and disk encryption, access logs, documentation backups kept for the required retention period, hosting inside the European Union and a data protection impact assessment. It is the layer you only notice when it is missing.
Integrations are easy to describe in one sentence: "we connected to the social insurance system". In practice electronic sick notes took about three weeks longer than planned, and most of the work went not into sending the document but into handling what happens when something goes wrong. A few examples straight from the backlog:
A doctor could issue a sick note and cancel it, but cancellation surfaced two real problems. The descriptions of cancellation reasons in our portal did not match the social insurance dictionary word for word, so the document was sometimes rejected. The second: a cancellation reached the institution as a document with no data in it. The fix was to pull the current dictionary of cancellation reasons straight from the source and show live values in the cancellation dialog, rather than keeping our own copy that quietly drifts out of date.
It looks trivial and it is the heart of the convenience: once the patient’s national ID number is entered, the system pulls the payer’s tax ID and name from the social insurance portal. A patient can have several employers, in which case the doctor ticks a checkbox to choose who receives the note, instead of retyping tax IDs from memory. Patient data, the ID number and address, is pulled from the patient record.
We also added a signal that many systems lack: if the payer has no active account in the insurance portal, the institution will not deliver the note electronically, so we show a note that a copy has to be printed and handed to the patient.
"Sick leave after the end of employment" is not a cosmetic checkbox. It is a distinct case where the patient has finished work but is still on leave that started while employed. In that situation the document goes only to the insurance institution, not to the payer. Backdated leave justification only appears once the calendar actually moves the period back by more than three days. And the place of issue, for a doctor working across several facilities, can be picked on the form instead of being hard-coded. We removed fields that were never used in practice and laid the form out vertically, in the order a doctor actually works.
Separately we fixed a small thing that can spoil the whole impression: printing a sick note or a prescription from a visit on the patient’s account produced a "no permission" message. Today a patient prints their own sick notes, prescriptions and referrals without friction.
In a medical project, security is not the last stage to be "closed before handover". It is a separate layer that grows alongside the features, and in our backlog it had its own numbered place next to the integrations:
| Task | What it covered |
|---|---|
| Encryption | patient data in the database and on disk |
| Logs | an access register for documentation: who, when, to what |
| CSRF | protection for forms in the doctor and patient panels |
| Electronic signature | standaryzacja WS-Security, certificate per doctor |
| GDPR / DPIA | security policy and impact assessment, delivered as a document for the client |
On top of that came two-factor authentication for doctor accounts and Consent Mode on the public side. We watched retention separately, because in healthcare it is not a matter of preference: documentation has to be kept for at least 20 years, and access logs for at least 5. That feeds straight into backup architecture and running costs, and into the choice of hosting, which has to stay inside the European Union.
The most underrated detail in this whole layer is converting the certificate from p12 to pem. It sounds like a footnote and it is the condition for the signature working at all in communication with state services, alongside a separate TLS certificate for the integrator portal.
This is the part that surprises people most, because it is not about programming. Before the system sends its first electronic prescription, things have to happen that an IT company has no control over and that money cannot speed up:
The practical lesson from this delivery: start the paperwork in parallel with the project, not after it. Code is often ready before paper is, and then a finished system sits idle waiting for an application.
The system works as a standalone product: a doctor runs facilities, rooms, services, visits, patient records and documentation on our side, and e-health documents go where they should. We deliberately do not quote percentage figures here, because the project did not measure them in a way we could honestly cite. What we can show is the scope and the decisions.
The happy path, send the document, is a fraction of the work. The value shows up where the institution answers with an error: in the queue, the retries and the visibility of what failed.
The three-week slip on electronic sick notes did not come from hard programming. It came from a tangled specification and conformance testing of the XML template.
As long as services and rooms were described by foreign identifiers, every feature was a hostage of the external system. Moving that in-house was the precondition for everything that followed.
We closed the project the way we think every bespoke delivery should be closed: with a formal handover of the code to the client, after refactoring. The client is not a hostage of the contractor. They get what they paid for, in a state they can take forward. It is worth asking every company you talk to about a medical system, before you sign.
We learned the most not from the days when everything worked, but from the ones when the institution sent back an empty document or a validation error. You recognise a good medical system by how it behaves in exactly those moments.
Are you planning a system for a facility or a network of clinics, with integration into national e-health, insurance or licensing systems? We are happy to point out where to start and where the biggest traps are. Book a free consultation or see our systems for healthcare.