Securing Patient Data: A Complete Guide to PDP Law Compliance for Healthcare Facilities

In the era of digitalization of healthcare services, patient data leaks are no longer just a risk, but a real threat that can lead to severe sanctions and loss of public trust. Law Number 27 of 2022 concerning Personal Data Protection (UU PDP) has been fully in force, requiring every healthcare facility (Fasyankes) such as hospitals and clinics to significantly improve data security standards. Administrative fines reaching billions of rupiah to criminal threats for violators are consequences that must be avoided. For SIMRS managers, clinic owners, or IT Managers responsible for this sensitive data, in-depth understanding and proper technical implementation are key. This article will guide you through the basic concepts of the UU PDP, concrete technical implementation strategies using current industry tools and standards, runnable code examples, handling FHIR payloads, and best practices for building a secure and regulation-compliant health information system. We will focus on practical solutions relevant to the SIMRS ecosystem, SIM Klinik, and vital integrations such as BPJS or SatuSehat.

Basic Concepts and Obligations of the UU PDP for Healthcare Facilities

Patient data is one of the specific categories of personal data strictly regulated in the UU PDP. Article 4 paragraph (2) of the UU PDP explicitly mentions health data as part of specific personal data, the handling of which requires explicit consent and extra protection. As a Personal Data Controller, a Healthcare Facility has full responsibility to ensure the security, confidentiality, and availability of patient data. This covers the entire data lifecycle, from collection, storage, processing, to deletion. The main principles of the UU PDP that must be complied with include: limited and specific data collection, purpose-based data processing, data accuracy, data security, and accountability and transparency.

Violations of these principles can result in administrative sanctions in the form of written warnings, temporary suspension of data processing activities, administrative fines of up to 50 billion rupiah, and compensation (Articles 57-60 of the UU PDP). In addition, there are also criminal sanctions for individuals who misuse personal data. Concrete examples of patient data that must be protected include: complete identity (name, NIK, address), electronic medical records (RME) covering diagnosis, disease history, laboratory results, drug prescriptions, and biometric information. Every Healthcare Facility must appoint a Personal Data Protection Officer (DPO) if data processing carries high risks or is large-scale, in accordance with Article 43 of the UU PDP. This is not merely a formality, but a crucial role in overseeing compliance and data risk management.

Another no less important obligation is notification if a personal data protection failure occurs. Article 46 of the UU PDP requires Personal Data Controllers to notify in writing to the Personal Data Subject and the Supervisory Agency no later than 3x24 hours after becoming aware of the failure. The notification must include detailed information about the incident, possible impacts, and handling efforts that have been or will be made. Compliance with the UU PDP is not only about avoiding sanctions, but also about building patient trust, which ultimately will improve the reputation and sustainability of your healthcare services. Therefore, investment in data security infrastructure and competent human resources is a necessity.

Technical Implementation of Data Security in SIMRS and SIM Klinik

Securing patient data requires a layered approach and appropriate technology. The following are some essential technical implementation details:

1. Data Encryption: Data must be protected both when stored (data at rest) and when moving (data in transit). For data at rest, use full disk encryption such as LUKS on Linux servers or BitLocker on Windows Server. For databases, consider Transparent Data Encryption (TDE) available in PostgreSQL 16 Enterprise or SQL Server Enterprise, which automatically encrypts the entire database. If using cloud such as AWS S3, ensure server-side encryption (SSE-S3 or KMS) is enabled with AES-256. For data in transit, all API communication between SIMRS, SIM Klinik, or external systems such as SatuSehat/BPJS must use TLS 1.2 or TLS 1.3 with valid SSL/TLS certificates. Older protocols such as TLS 1.0 or 1.1 must be disabled due to their vulnerabilities.

2. Granular Access Control: Implement strict Role-Based Access Control (RBAC). For example, a doctor can only access patient data under their care or data relevant to their work. IT admins must not have direct access to patient medical record data without layered authorization and clear audit logging. Use the Least Privilege Principle, namely granting the minimum access rights necessary to perform duties. For example, for Laravel 11.x-based applications, you can utilize a package such as spatie/laravel-permission to manage roles and permissions effectively.

3. Comprehensive Audit Trail: Every activity involving patient data must be recorded. This includes login, access, modification, deletion, and data export. The log must include who (user ID), what (type of activity), when (timestamp), and from where (IP address) the activity was performed. For PostgreSQL 16 databases, the pgaudit module can provide audit logs according to standards. In applications, a package such as spatie/laravel-activitylog can be easily integrated to record user activity. This log is crucial for digital forensics in the event of a security incident.

4. Data Masking and Anonymization: For development or testing environments, original patient data should not be used. Implement data masking or anonymization to create realistic test data that cannot be directly identified. Libraries such as FakerPHP in PHP or Faker in Python can help generate dummy data. For research data, ensure that the data has undergone pseudonymization or anonymization processes that cannot be re-identified.

5. Data Backup and Recovery: Implement a 3-2-1 backup strategy: three copies of data, stored on two different types of media, with one copy stored offsite. Perform regular data recovery testing to ensure backups work properly. Use automatic backup features from cloud services such as AWS RDS or Azure SQL Database. For on-premise databases, use pg_dump for PostgreSQL or enterprise backup solutions. Ensure backups are also encrypted.

6. Secure Integration with FHIR Standards: For integration with SatuSehat or BPJS, use the FHIR R4 standard. Ensure all FHIR payloads are encrypted in transit using TLS 1.2/1.3. Authentication must use OAuth 2.0 (Client Credentials Grant or PKCE) and short-lived access tokens. Validate FHIR payloads using libraries such as HAPI FHIR 6.8 (for Java) or fhir-client (for Node.js) to ensure integrity and standards compliance. Implement strict FHIR schema validation to prevent invalid data injection.

Example of Data Security Implementation Code

Data security implementation is not just about configuration, but also involves well-written code. The following is an example of implementing sensitive data encryption and simple access control in the context of a web application that might be used in SIMRS or SIM Klinik, written in PHP with the Laravel 11.x framework.

Example 1: Encryption of Sensitive Data Columns in Laravel 11.x

We can encrypt data such as ID card numbers or patient phone numbers before storing them in the database and decrypt them when displaying. Laravel provides strong encryption facilities using OpenSSL with AES-256 cipher.

// app/Models/Patient.php (Model Eloquent)namespace AppModels;use IlluminateDatabaseEloquentFactoriesHasFactory;use IlluminateDatabaseEloquentModel;use IlluminateSupportFacadesCrypt;class Patient extends Model{
    use HasFactory;
    protected $fillable = ['name', 'nik', 'phone_number', 'address'];
    // Mutator untuk mengenkripsi NIK sebelum disimpan
    public function setNikAttribute($value)
    {
        $this->attributes['nik'] = Crypt::encryptString($value);
    }
    // Accessor untuk mendekripsi NIK saat diakses
    public function getNikAttribute($value)
    {
        try {
            return Crypt::decryptString($value);
        } catch (DecryptException $e) {
            // Handle error jika dekripsi gagal, misal log atau return null
            Log::error('Failed to decrypt NIK: ' . $e->getMessage());
            return null;
        }
    }
    // Mutator untuk mengenkripsi nomor telepon
    public function setPhoneNumberAttribute($value)
    {
        $this->attributes['phone_number'] = Crypt::encryptString($value);
    }
    // Accessor untuk mendekripsi nomor telepon
    public function getPhoneNumberAttribute($value)
    {
        try {
            return Crypt::decryptString($value);
        } catch (DecryptException $e) {
            Log::error('Failed to decrypt phone number: ' . $e->getMessage());
            return null;
        }
    }
}

The code above shows how Mutator (setNikAttribute, setPhoneNumberAttribute) is used to encrypt data before storing it in the database, and Accessor (getNikAttribute, getPhoneNumberAttribute) to decrypt data when retrieved. Ensure your application key (APP_KEY) in the .env file is secure and never shared. This is an important security layer for sensitive data in the database.

Example 2: Simple Access Control Implementation (RBAC) with Middleware in Laravel 11.x

To ensure that only users with certain roles can access specific features or data, we can use middleware. The following is an example of a simple middleware to check user roles.

// app/Http/Middleware/CheckRole.php (Middleware)namespace AppHttpMiddleware;use Closure;use IlluminateHttpRequest;use SymfonyComponentHttpFoundationResponse;class CheckRole{    /**     * Handle an incoming request.     *     * @param  Closure(HttpRequest): (Response) $next     */    public function handle(HttpRequest $request, Closure $next, string $role): Response    {        if (!auth()->check() || !auth()->user()->hasRole($role)) {            abort(403, 'Unauthorized action.');        }        return $next($request);    }}// app/Http/Kernel.php (Register Middleware)protected $middlewareAliases = [    // ...    'role' => AppHttpMiddlewareCheckRole::class,];// app/Models/User.php (Tambahkan method hasRole)use AppModelsPatient; // Contoh relasi jika perluuse IlluminateDatabaseEloquentFactoriesHasFactory;use IlluminateFoundationAuthUser as Authenticatable;use IlluminateNotificationsNotifiable;class User extends Authenticatable{    use HasFactory, Notifiable;    // ... fillable, hidden, casts properties    public function hasRole($role)    {        // Asumsi ada kolom 'role' di tabel users        // Atau gunakan package seperti spatie/laravel-permission        return $this->role === $role;    }}// routes/web.php (Contoh penggunaan)use AppHttpControllersPatientController;use IlluminateSupportFacadesRoute;Route::middleware(['auth', 'role:doctor'])->group(function () {    Route::get('/patients/{patient}', [PatientController::class, 'show'])->name('patients.show');});Route::middleware(['auth', 'role:admin'])->group(function () {    Route::get('/patients/{patient}/edit', [PatientController::class, 'edit'])->name('patients.edit');    Route::put('/patients/{patient}', [PatientController::class, 'update'])->name('patients.update');});

The CheckRole middleware will ensure that only logged-in users with the specified role (for example 'doctor' or 'admin') can access certain routes. If they do not meet the requirements, the system will return a 403 Forbidden response. More complex role management can be handled with a package such as spatie/laravel-permission, which provides more granular permission features. This implementation is very important to ensure that patient information can only be accessed and modified by authorized personnel, in accordance with the need-to-know principle.

Example FHIR Payload, Error Handling, and Mitigation

Integration with platforms such as SatuSehat Kemenkes RI requires an understanding of the FHIR (Fast Healthcare Interoperability Resources) standard. Patient data is often exchanged in the FHIR R4 format. The following is an example of a realistic FHIR payload for the Patient resource that will be sent to SatuSehat, along with an example of error handling.

Example FHIR R4 Payload - Patient Resource:

{
  "resourceType": "Patient",
  "identifier": [
    {
      "use": "official",
      "system": "https://fasyankes.example.id/nik",
      "value": "3273xxxxxxxxxxxx"
    }
  ],
  "active": true,
  "name": [
    {
      "use": "official",
      "family": "Santoso",
      "given": ["Budi"]
    }
  ],
  "gender": "male",
  "birthDate": "1985-07-12",
  "address": [
    {
      "use": "home",
      "city": "Bandung",
      "postalCode": "40115",
      "country": "ID"
    }
  ]
}

The above payload must be sent over a TLS connection and accompanied by appropriate authorization headers (for example, an OAuth 2.0 bearer token). Before sending, ensure that the data has gone through a de-identification process if not required, and is encrypted when stored. The following is an example of error handling when integration fails:

try {
    $response = Http::withToken($token)
        ->timeout(10)
        ->post($satuSehatUrl.'/Patient', $payload);

    if ($response->failed()) {
        Log::warning('SatuSehat error', [
            'status' => $response->status(),
            'body' => $response->body(),
        ]);
        return response()->json([
            'message' => 'Gagal mengirim data pasien ke SatuSehat.'
        ], 502);
    }
} catch (\Illuminate\Http\Client\ConnectionException $e) {
    Log::error('Koneksi SatuSehat terputus', ['error' => $e->getMessage()]);
    return response()->json([
        'message' => 'Layanan SatuSehat tidak dapat dihubungi.'
    ], 503);
}

Ensure that logs do not contain patients' personal data in raw form. Use masking or hashing on sensitive fields before recording them, and store logs on a server with limited access.

Practical Tips for Implementing the PDP Law in Healthcare Facilities

First, conduct a thorough data mapping. Identify all entry and exit points of patient data, from registration, electronic medical records, laboratory, to external integrations such as SatuSehat or BPJS. With a clear data map, you can determine the data classification (general, specific, or sensitive) and establish proportional security controls. Don't forget to document the legal basis for processing each activity, for example patient consent, legal obligation, or vital interests.

Second, consistently apply the principles of least privilege and need-to-know. Use role-based access control (RBAC) like the middleware example earlier, and review access rights regularly—for example every three months or when there is a staff change. Enable multi-factor authentication (MFA) for accounts that access patient data, and restrict access from untrusted devices or networks. For stored data, use at-rest encryption (for example AES-256) and in-transit encryption (TLS 1.2+).

Third, prepare incident response and audit trail procedures. UU PDP requires notification of data breaches to data subjects and authorities within 3x24 hours if it has a significant impact. Create a runbook that covers detection, containment, eradication, recovery, and reporting steps. Retain access logs for at least 6 years or in accordance with healthcare sector regulations, and conduct internal and external audits regularly. Educating staff about phishing, use of personal devices, and incident reporting is key to a strong security culture.

FAQ

What are the sanctions if a healthcare facility violates the UU PDP?

UU PDP stipulates administrative sanctions in the form of written warnings, temporary suspension of data processing activities, deletion or destruction of data, up to administrative fines of a maximum of 2% of annual revenue. In addition, there are criminal sanctions for certain violations, such as illegally collecting data, which can be punishable by imprisonment of up to 6 years and/or a fine of up to IDR 6 billion. Compliance is not just about avoiding sanctions, but also maintaining patient trust.

Can patient data be stored on overseas cloud servers?

UU PDP opens opportunities for data transfer abroad provided that the destination country has an equivalent or higher level of protection, or there is adequate protection guarantee. For healthcare facilities, it is better to prioritize storage within the country or cloud providers that have clear certification and data protection clauses. Ensure there is a data processing agreement (DPA) and an adequate audit mechanism.

How to handle requests for access to or deletion of patient data?

UU PDP gives data subjects the right to access, update, and under certain conditions request deletion of data. Prepare official channels (email, form, or portal) to receive requests, verify the identity of the requester, and respond within a reasonable time limit (ideally 14-30 days). Record every request and action taken. Keep in mind that for medical records, there is a retention obligation under health regulations that may override deletion requests.

Is encryption alone enough to protect patient data?

Encryption is an important foundation, but it is not enough. You also need access control, secure key management, anomaly monitoring, staff training, and documented policies and procedures. A layered approach (defense in depth) is far more effective than relying on a single technology. Conduct regular risk assessments and test system resilience through penetration testing.

Conclusion

Securing patient data in accordance with the UU PDP is not a one-time project, but a continuous commitment involving technology, processes, and people. From RBAC, encryption, secure FHIR integration, to incident response and fulfillment of data subject rights—all these elements complement each other to protect patient privacy and maintain public trust in healthcare facilities. With structured steps, you not only meet legal obligations but also improve service quality and institutional reputation.

Need assistance to assess your healthcare facility's readiness for the UU PDP, draft a privacy policy, or implement appropriate technical controls? Consult your needs with our expert team to get an audit, recommendations, and a compliance roadmap tailored to the scale and type of services of your healthcare facility. Don't wait until an incident occurs—start patient data security measures today.

This article is part of the education by Nugroho Setiawan, an IT consultant in Jogja. Related solutions: SIMRS SIM Klinik Integrator Bridging SatuSehat. Need free consultation?