Penarikan Persetujuan dan Konflik Retensi pada Aplikasi Kesehatan

Ketiga permintaan harus dijawab dalam satu respons tertulis, tetapi hasilnya berbeda per item.

1. Penarikan persetujuan riset dan pemasaran - dikabulkan. Penarikan berlaku ke depan; pemrosesan sebelumnya tetap sah. Konsekuensinya operasional, bukan sekadar administratif: hentikan kiriman pemasaran, keluarkan Rani dari kumpulan data riset, dan pastikan penarikan tersinkron ke sistem downstream (CRM, platform iklan, alat analitik). Jangan menuntut alasan sebagai syarat penarikan.

2. Penghapusan seluruh data - dikabulkan sebagian. Menolak seluruhnya adalah kelebihan penolakan; menghapus seluruhnya melanggar kewajiban retensi. Pisahkan:

• Log makanan, preferensi, data personalisasi, riwayat interaksi: hapus.
• Riwayat pembayaran: tidak dihapus, disimpan 10 tahun untuk kewajiban perpajakan, dengan akses dibatasi dan dipisahkan dari sistem analitik.
• Rekam medis yang diunggah: tidak dihapus selama periode retensi 25 tahun; alihkan ke penyimpanan arsip terkunci, bukan dihapus, dan hentikan penggunaan untuk tujuan lain.

Sampaikan kepada Rani data mana yang dihapus, mana yang disimpan, dasar hukum penyimpanan, dan berapa lama. Ini memenuhi prinsip transparansi sekaligus hak pembatasan pemrosesan.

3. Salinan CSV - dikabulkan dengan pengamanan. Verifikasi identitas lebih dahulu, kirim melalui kanal terautentikasi (bukan lampiran surel biasa), dan pastikan hanya data Rani yang disertakan (hati-hati data pihak ketiga seperti kontak atau nama tenaga medis). Format terstruktur dan dapat dibaca mesin sesuai hak portabilitas.

Tetapkan tenggat internal, dokumentasikan setiap keputusan, dan sediakan jalur keberatan. Permintaan akses dan salinan memiliki tenggat 3x24 jam menurut UU PDP; untuk penghapusan dan penarikan, tetapkan SLA internal yang setara dan komunikasikan.

Keabsahan desain. Satu centang untuk tiga tujuan berbeda melanggar prinsip persetujuan yang spesifik dan eksplisit. Tiga cacat utamanya: (a) penggabungan (bundling) membuat persetujuan pemasaran tidak dapat dipisahkan dari penerimaan layanan; (b) 'penawaran mitra' tidak menjelaskan penerima, jenis data, dan kanal; (c) tidak ada bukti versi teks, waktu, dan tujuan yang disetujui. Desain ini juga rawan dianggap sebagai pola gelap (dark pattern) bila pilihan menolak lebih sulit daripada menerima.

108.000 akun tanpa bukti. Migrasi sistem bukan dasar pemrosesan. Beban pembuktian ada pada pengendali, sehingga secara hukum SehatKu berada pada posisi tidak dapat menunjukkan dasar pemrosesan untuk personalisasi dan iklan. Tiga opsi yang dapat dipertahankan:

1. Re-consent terkontrol: minta persetujuan ulang per tujuan dengan pemberitahuan jelas; selama belum diperoleh, hentikan iklan personalisasi dan turunkan ke iklan kontekstual.
2. Ganti dasar: bila ingin memakai kepentingan yang sah, lakukan dan dokumentasikan uji kepentingan yang sah, sediakan opt-out yang mudah, dan pastikan data benar-benar minimal.
3. Hentikan dan hapus bila tidak ada dasar yang dapat dibangun.

Perbaikan sistemik: terapkan platform manajemen persetujuan dengan pencatatan versi, timestamp, tujuan granular, dan sinkronisasi penarikan; larang penggunaan data untuk tujuan baru sebelum persetujuan tercatat; audit tahunan atas cakupan bukti persetujuan.

Yang harus dihindari: melanjutkan pemrosesan sambil menunggu perbaikan sistem, atau menganggap pengguna lama otomatis setuju karena tetap menggunakan aplikasi.

Ya. Data kesehatan termasuk kategori data pribadi yang bersifat spesifik menurut UU PDP, sehingga seluruh rantai pemrosesan hasil laboratorium tunduk pada pengamanan yang lebih ketat.

Implikasi desain:

• Dasar pemrosesan harus persetujuan eksplisit yang terpisah dari syarat layanan umum, atau dasar lain yang benar-benar tepat (misalnya pelayanan kesehatan). Persetujuan generik pada kotak centang tunggal tidak memadai.
• Penilaian dampak (DPIA) wajib sebelum fitur dijalankan penuh, karena melibatkan data sensitif dalam skala besar dan integrasi antarlembaga.
• Peran dengan rumah sakit mitra harus jelas: bila RS menentukan tujuan pengobatan dan SehatKu hanya menyalurkan, RS adalah pengendali dan SehatKu prosesor; bila SehatKu memakai data itu untuk analitik produk, ia menjadi pengendali dan memerlukan dasar sendiri.
• Pembatasan akses dan enkripsi: akses berbasis peran, enkripsi saat disimpan dan dikirim, pencatatan audit akses, serta larangan menarik data ke lingkungan analitik umum.
• Minimalisasi: jangan meminta seluruh riwayat medis bila hanya satu parameter laboratorium yang dibutuhkan.
• Penghapusan dan retensi harus mengikuti ketentuan retensi rekam medis, tetapi tautan ke akun pemasaran harus diputus.

Kesalahan yang sering muncul di ujian: menyamakan 'data sensitif' dengan 'data terenkripsi', atau berargumen bahwa persetujuan syarat layanan sudah mencakup semuanya. Kekhususan tujuan dan sifat eksplisit persetujuan adalah uji yang sebenarnya.