Klinik Management — Web application (Laravel) with electronic medical records
This system stores health data — the most sensitive category there is. It is installed and run by a clinic, which is the data controller and is bound by healthcare confidentiality rules. This page documents what the software stores, who can see it, and how it is protected.
Klinik Management is software that an organization installs and runs on its own infrastructure. The clinic operating a given installation decides what data is entered into it and is the data controller for that installation. This page documents what the application itself collects and processes by design; it is the reference policy for the software, and an operator may publish additional terms on top of it. As the developer, I have no access to any production database unless an operator explicitly grants it for maintenance.
| Data | Why |
|---|---|
| Patient identity | Name, date of birth, gender, address, phone number, and where required an identity or insurance number — to create and correctly match a medical record. |
| Medical records (EMR) | Complaints, examination findings, diagnosis, treatments, and doctor notes — the clinical record of your visit. |
| Prescriptions and dispensing | Medicines prescribed, dosage, and stock movement. |
| Appointments and queue | Chosen doctor, schedule slot, queue number, and visit status. |
| Payment records | Service fees, totals, Midtrans order ID and status. No card or bank credentials. |
| Staff accounts | Name, role (admin, doctor, cashier), and hashed password. |
| Audit logs | Who opened or changed which record and when — required to keep medical records accountable. |
Medical records are treated as confidential health information. Within the system they are reachable only by the clinic staff whose role requires it, and every access is written to an audit log.
The developer of this software does not hold, mirror, or have standing access to any clinic’s patient data. Where an operator requests maintenance support, access is granted by them, limited in time, and should be performed on anonymised or test data wherever possible.
Medical data is never used for advertising, never sold, and never shared with insurers or employers by the software itself.
| Service | What it does |
|---|---|
| Midtrans (PT Midtrans) Privacy policy ↗ | Processes payments (QRIS, virtual account, e-wallet, card). Card and banking details are entered on Midtrans’ own page — this application never sees or stores them. |
Roles are enforced with a permission layer (Spatie Permissions): a cashier sees billing but not clinical notes; a doctor sees the records of patients in their care; an administrator manages accounts and schedules. Assigning roles correctly is the clinic’s responsibility.
The application uses cookies only for functionality:
There are no advertising cookies, no third-party analytics or tracking pixels, and no cross-site profiling. Clearing cookies simply logs you out.
Records are shared only inside the clinic, with the patient themselves on request, and with third parties where the patient consents or the law requires (for example a referral, or a lawful request from an authority).
Medical records are retained for the period required by applicable healthcare regulations and the clinic’s own record-keeping policy — typically far longer than ordinary business data. A patient may ask for corrections to inaccurate data; a request to erase a clinical record can be refused where retaining it is a legal obligation.
The application applies standard protections: passwords are stored as one-way hashes (never in plain text), access is limited by role, and all traffic between client and server is expected to run over HTTPS/TLS.
Sensitive fields are protected by role-based access, audit logging, and hashed credentials. Encryption at rest, backups, network isolation, and physical security of the server are configured by the clinic operating the installation.
No system is perfectly secure. Server hardening, backups, and access management for a live installation are the responsibility of the organization operating it.
Paediatric patients are registered by a parent or guardian at the clinic, and the guardian exercises the patient’s rights. The system never allows a child to self-register.
You have the right to ask for access to, correction of, or deletion of your personal data, and to object to certain processing.
Because your data lives in the installation run by the organization you deal with, address those requests to that organization first — they hold the data and can act on it. If you cannot reach them, or you believe the application itself is at fault, contact the developer at mhdlutfidev@gmail.com and I will assist technically.
If this policy changes, the “Last updated” date at the top of this page will be revised. Material changes will be reflected in the application release notes.
Questions, complaints, or privacy requests about this application:
I aim to respond within 7 business days.