Blog Details

KVKK (Türkiye's Personal Data Protection Law) compliance is often treated as paperwork — a policy document, a consent form, a checkbox at the end of a project. In health software specifically, that approach falls apart quickly, because the data itself (patient records, clinical assessments, expense receipts tied to named individuals) is sensitive by definition. The more useful approach is to treat KVKK requirements as default architectural decisions made at the start, not a compliance layer bolted on afterward.

Role-Based Access as the Default, Not the Exception

In systems like ClinOps and AlcoaNexus, every role — CRA, CRC, project manager, researcher, supervisor, data scientist — sees only what its function requires. This isn't primarily a security feature; it's a data-minimization one. A finance reviewer approving an expense report doesn't need to see clinical assessment data, and a data scientist running aggregate analysis doesn't need to see which specific patient a record belongs to when a de-identified view will do.

Audit Logging as Infrastructure, Not an Afterthought

Every meaningful action — a record created, a section approved, a document submitted — needs to be logged with who did it and when, not because a regulator might ask (though they might), but because it's the only way to answer "what happened to this data" months later. Retrofitting audit logging onto an existing system is possible but painful; building it as a cross-cutting concern from day one is far cheaper.

Locking and Data Minimization

Once a clinical record is finalized, it should be locked against further edits — both to protect data integrity and to create a clear boundary of when changes stopped being legitimate. And wherever a workflow can operate on less personal data — an aggregate instead of a row, a de-identified export instead of a full record — it should default to that, rather than exposing the full dataset "just in case" a future feature needs it.

None of this is exotic. It's a short list of defaults — least-privilege access, structured audit trails, record locking, and minimizing what any single role can see — applied consistently from the first schema design, rather than a KVKK review squeezed in before launch.