Building a KVKK-Compliant Patient Management System: Zero to Production

Building software for a clinic is a different job from building software for an online store. When an e-commerce site goes down, customers get annoyed and a few sales are lost. When a patient management system is set up wrong, the consequences are heavier: the wrong person can see a patient file, the clinic can be fined under KVKK (Turkey's GDPR analogue), and worst of all, patients can lose trust in their clinic.

Before we wrote a single line of code for Koru Klinik, the clinic director said something that stuck with us: "We need this fast — but we can't afford to get it wrong." This post is about the foundations we built under that constraint, the traps we fell into along the way, and the questions that come up most often in real-world conversations.

A Reminder First: Health Data Is Not Ordinary Data

KVKK puts health information into a separate "special-category personal data" bucket. In practice, this means the safeguards that are enough for ordinary personal data — say, a name and address on an e-commerce site — are not considered enough for medical data. Explicit consent, additional technical safeguards, immutable audit logs — every one of these has to be in place, individually.

When we took on our first healthcare client, we thought this was just "slightly stricter e-commerce security." We were wrong. It's a different mental model from day one.

Four Core Principles

When we started building Koru Klinik, we wrote four rules into stone. They were non-negotiable — even when a feature request came up, we didn't trade these away.

1. Data Minimization — No "We Might Need It Someday"

In our first meeting, the clinic wanted to collect everything: marital status, profession, number of children, and on. "We might need it later." We said no. We don't store fields that aren't medically necessary. If a real need shows up later, we can always add the field then. But data we don't store can't leak, can't be misused, and can't trip us up in an audit.

2. Encryption Everywhere

Data is encrypted in transit and at rest, separately. Sensitive fields — national IDs, diagnoses, lab results — get an extra layer of encryption applied before they ever reach the database. The result: even if someone gained physical access to the server, all they'd hold in their hand is a pile of meaningless bytes.

3. Access Control — A Doctor Sees Only Their Own Patients

The risk most clinics underestimate is the insider one. Threats don't always come from outside; a doctor might idly look up a colleague's patient file out of curiosity. In our system, that simply isn't possible — a user cannot "accidentally" see anything outside their authorized scope. And the moment they try, the next mechanism kicks in.

4. A Full Audit Trail

Every read and write — who, when, on which record — is logged automatically. Those logs cannot be deleted or edited. Not even by us; the technical permission to do so does not exist.

"My Patient Wants All Their Data" — The 30-Day Rule

Under KVKK, if a patient asks "give me everything you have on me," the clinic has 30 days to comply. In most clinical software, this is still a manual ordeal: someone opens different modules, gathers reports one by one, dumps them into a spreadsheet, sends them by email. An hour of work, plus the risk of copy-paste mistakes and missing entries.

We collapsed this entire process into a single click. An authorized user picks the patient, hits "create data request," and the system collects every related record, generates a signed download link, and logs the whole event. Human involvement is minimal; the margin for error is near zero.

Why "Append-Only" Audit Logs Matter

Imagine a clinic staff member made a mistake on a diagnosis and tries to "delete" rather than "amend" the record. In a regular system, that's allowed — gone, forgotten. Then an audit comes and the inspector asks, "What were the prior diagnoses for this patient?" The answer is "no record." That makes negligence impossible to prove and puts the clinic in a bad spot.

In our system, that maneuver isn't possible. A record is never deleted, only marked as superseded. The corrected version is added as a new entry. The full history — including who changed what and when — stays around forever.

The practical consequence: in a KVKK inspection, "our records have not been tampered with" stops being an aspiration and becomes a technically verifiable fact. If a dispute ever arises, the clinic has a defensible chain of evidence — every action linked back to a person and a moment in time.

A Few Lessons from the Field

The software is one half of the story. The other half — the part that actually makes a clinic KVKK-compliant — is people. A few things we learned at Koru Klinik:

• Software without training isn't enough. If staff are sharing logins or whispering passwords across the desk, no software can save you. Our first deliverable was a half-day training session.
• Don't kill the speed. A "secure but slow" system gets quietly sabotaged by its users — they'll find a workaround. The system has to be both safe and fast. Anything else is wishful thinking.
• Don't forget backups. KVKK isn't only about protecting data; it's also about retaining it for a reasonable period. Without a backup strategy, a single hardware failure can become a full-blown KVKK incident.

Wrapping Up

The race in healthcare software isn't won by who ships the most features — it's won by who got the controls right the first time. Speed matters, but there's no luxury of getting it wrong. Retrofitting a misbuilt patient management system is harder than building it right from scratch, and the risk in the meantime is always yours to carry.

If you'd like a closer look at how the system is put together, the Koru Klinik page is a good place to start.