Privasi Data Kesehatan dan UU PDP: Yang Perlu Dipahami Developer

Kalau kamu pernah membangun sistem yang menyentuh data pasien — SIMRS, aplikasi klinik, atau sekadar modul rekam medis kecil di dalam produk yang lebih besar — cepat atau lambat kamu akan bertemu dengan UU Perlindungan Data Pribadi (UU PDP). Banyak developer menganggap ini urusan legal semata dan baru mikir soal compliance setelah fitur jadi. Padahal sebagian besar kewajiban di UU PDP itu sebenarnya keputusan arsitektur, bukan keputusan hukum — dan jauh lebih murah dipikirkan dari awal daripada ditambal belakangan.

Kenapa Data Kesehatan Diperlakukan Khusus

UU PDP membedakan data pribadi umum dari data pribadi yang bersifat spesifik, dan data kesehatan masuk kategori spesifik itu — sejajar dengan data biometrik, data genetik, dan catatan kriminal. Konsekuensinya, kewajiban perlindungannya lebih ketat dibanding, katakanlah, alamat email atau nomor telepon. Sebagai developer, ini artinya kita tidak bisa memperlakukan tabel diagnoses atau medical_records sama seperti tabel users biasa. Setiap kolom yang berisi diagnosis, hasil lab, riwayat pengobatan, atau catatan dokter perlu dipikirkan jalur aksesnya sendiri: siapa yang boleh baca, dari endpoint mana, dan tercatat ke mana.

Prinsip yang Relevan untuk Kode yang Kita Tulis

Beberapa prinsip UU PDP yang paling sering bersinggungan langsung dengan implementasi teknis:

• Minimalisasi data — jangan simpan lebih banyak dari yang benar-benar dipakai fitur. Kolom "catatan tambahan" bebas teks yang jarang dibaca ulang biasanya lebih baik tidak ada daripada dibiarkan menumpuk data sensitif tanpa tujuan jelas.
• Pembatasan tujuan — data yang dikumpulkan untuk pelayanan medis idealnya tidak dipakai ulang untuk keperluan lain (misalnya analitik marketing) tanpa dasar yang jelas.
• Kontrol akses berbasis kebutuhan — bukan semua staf perlu bisa melihat semua rekam medis; ini soal desain otorisasi, bukan sekadar login.
• Hak subjek data — pasien berhak tahu datanya dipakai untuk apa, dan dalam banyak kasus berhak meminta koreksi atau penghapusan sejauh tidak bertentangan dengan kewajiban rekam medis lain (misalnya retensi untuk keperluan audit BPJS).

Implementasi Teknis: Dari Enkripsi sampai Audit Log

Di level aplikasi, ada beberapa lapisan yang menurut saya wajib ada sebelum fitur menyentuh data kesehatan sungguhan:

Enkripsi at-rest untuk kolom sensitif. Di Laravel misalnya, ini semudah memakai encrypted cast pada atribut model:

protected $casts = [
    'diagnosis_notes' => 'encrypted',
];

Enkripsi di level kolom ini bukan solusi ajaib, tapi setidaknya memastikan dump database mentah atau backup yang bocor tidak langsung menampilkan catatan medis dalam bentuk plain text.

Otorisasi eksplisit, bukan asumsi. Setiap endpoint yang mengembalikan data pasien sebaiknya lewat policy atau gate yang jelas — jangan mengandalkan "toh frontend sudah menyembunyikan tombolnya". Serangan paling umum ke sistem kesehatan bukan enkripsi yang dibobol, tapi endpoint API yang lupa dicek otorisasinya.

Audit trail. Siapa membuka rekam medis siapa, kapan, dari mana — log ini penting bukan cuma untuk investigasi insiden, tapi juga karena banyak kerangka kepatuhan data kesehatan mensyaratkan jejak akses yang bisa ditelusuri. Package audit log generik untuk Laravel atau tabel access_logs buatan sendiri sama-sama valid, yang penting konsisten dipakai di semua jalur akses, termasuk query manual lewat tinker atau admin panel.

Retensi dan Anonimisasi

Satu hal yang sering terlewat: UU PDP juga menyinggung soal berapa lama data boleh disimpan. Untuk data kesehatan, retensi biasanya mengikuti aturan sektor kesehatan yang lebih spesifik (jauh lebih lama dari data pribadi umum), jadi "hapus otomatis setelah 90 hari" yang lazim dipakai untuk log aplikasi biasa jelas tidak cocok di sini. Untuk kebutuhan seperti analitik atau training model AI internal, anonimisasi atau pseudonimisasi — misalnya mengganti identitas pasien dengan ID acak sebelum data dipakai untuk analisis agregat — adalah pendekatan yang jauh lebih aman daripada bekerja langsung di atas data identitatif.

Takeaway

UU PDP untuk data kesehatan pada akhirnya bukan daftar checklist hukum yang ditempel di akhir proyek, melainkan serangkaian keputusan desain: kolom mana yang dienkripsi, siapa yang boleh mengakses apa, apa yang dicatat di audit log, dan berapa lama data disimpan. Kalau prinsip-prinsip ini masuk ke tahap desain skema database dan arsitektur API sejak awal, kepatuhan terhadap UU PDP jadi konsekuensi alami dari sistem yang memang dibangun dengan hati-hati — bukan proyek tambal sulam terpisah.