Complete Guide to the PDP Law for Hospitals: Compliance and Technical Implementation of SIMRS

In the era of healthcare digitalization, hospitals and other healthcare facilities face significant challenges in managing sensitive patient data. With the enactment of Law Number 27 of 2022 on Personal Data Protection (PDP Law), compliance is no longer an option, but an absolute obligation. Violations of the PDP Law can result in severe administrative sanctions, financial fines of up to billions of rupiah, even imprisonment, not to mention invaluable reputational damage. Imagine a scenario of a medical data breach of 10,000 patients that includes chronic disease history, laboratory results, and genetic information—the impact would be highly damaging to public trust and hospital operations. This article serves as a practical and in-depth guide for Hospital IT Managers, clinic owners, operations managers, and decision-makers who need technology solutions. We will thoroughly examine everything from the basic concepts of the PDP Law, how to implement it technically in your Hospital Management Information System (SIMRS), to concrete examples of code and best practices that you can immediately apply. The goal is to help you build a system that is not only efficient, but also resilient and compliant with personal data protection regulations.

Basic Concepts of the PDP Law and Their Relevance for Healthcare Facilities

Law Number 27 of 2022 on Personal Data Protection (PDP Law) is the main legal umbrella in Indonesia that regulates rights and obligations related to personal data processing. For healthcare facilities (fasyankes) such as hospitals and clinics, this law has very high relevance given that the nature of the data processed is specific personal data, namely health data. Specific personal data, as stipulated in Article 4 Paragraph (2) of the PDP Law, requires a stricter level of protection because of its great potential impact if misused. For example, information about a patient's history of infectious diseases, mental condition, or genetic data can have serious social, economic, and discriminatory consequences if its confidentiality is not maintained.

In the context of the PDP Law, hospitals act as Personal Data Controllers, namely any person, public body, and other entity that determines the purpose and exercises control over personal data processing. This means the hospital is fully responsible for the entire life cycle of patient data, from collection, storage, processing, to deletion. Meanwhile, the Personal Data Subject is the individual who owns the data, in this case the patient, who has fundamental rights over their data, including the right to obtain information, correction, postponement, restriction, even deletion of data. Articles 5 through 15 of the PDP Law explicitly regulate these data subject rights.

In addition, hospitals also often cooperate with third parties, such as SIMRS vendors, cloud service providers, or referral laboratories. These third parties can act as Personal Data Processors, namely parties that process personal data on behalf of the Personal Data Controller. The PDP Law requires a clear written agreement between the Controller and the Personal Data Processor, which regulates responsibilities, processing purposes, and data security measures. For example, if a hospital uses cloud services for storing electronic medical record data, the cloud provider must comply with the security standards set by the hospital and the PDP Law.

One crucial point is the obligation to obtain consent (consent) from the data subject before processing their personal data, unless there is another legal basis that permits it (Article 20 of the PDP Law). For health data, consent must be explicit and specific. For example, when a patient registers, the hospital must transparently explain what data will be collected, for what purpose, how long it will be stored, and who has access. By understanding these roles and responsibilities, hospitals can begin to design a holistic compliance strategy, not only from a technical standpoint but also administrative and procedural, in accordance with the spirit of the PDP Law.

Technical Implementation of PDP Compliance in SIMRS and Related Systems

Compliance with the PDP Law is not only about policy, but also solid technical implementation in the Hospital Management Information System (SIMRS) and its supporting infrastructure. The first step is to ensure data security at the infrastructure level. For databases, for example, the use of PostgreSQL 16 with at rest encryption features such as pg_crypto or filesystem-level encryption is highly recommended. Data in transit (data in transit) between SIMRS modules, mobile applications, or external systems (such as BPJS Kesehatan or SatuSehat) must always be encrypted using strong protocols, at minimum TLS 1.2, but TLS 1.3 is much better for ensuring data confidentiality and integrity.

Access to patient data must be managed with strict Role-Based Access Control (RBAC) principles. Every SIMRS user, from doctors, nurses, medical records staff, to administrative staff, must have minimal access rights (least privilege) in accordance with their duties and responsibilities. For example, a doctor may only access the medical records of patients under their responsibility, and finance staff must not access patient diagnosis details. Good RBAC implementation in applications based on Laravel 11.x can be done using well-defined middleware and policy, ensuring every data request passes through proper authorization.

Integration with external systems such as SatuSehat and Bridging BPJS requires special attention. Data standardization using FHIR R4 (Fast Healthcare Interoperability Resources Release 4) is crucial for secure and structured data exchange. When sending patient data to the SatuSehat platform, ensure that only relevant and required data is sent, and always use strong authentication tokens (for example OAuth 2.0) and SSL/TLS certificate validation. An example implementation can use the HAPI FHIR 6.8 library for Java or an equivalent FHIR client library on other platforms, ensuring that FHIR data serialization and deserialization are performed securely and in accordance with standards.

Audit logging is a vital component of PDP compliance. Every activity involving access, modification, or deletion of patients' personal data must be recorded in detail, including who performed it, when, from where, and what was done. These logs must be stored in a secure location separate from the main system, and protected from unauthorized modification. For applications based on Node.js 20 LTS, using Winston or Pino as a logger can be configured to send logs to a SIEM (Security Information and Event Management) system such as the ELK Stack (Elasticsearch, Logstash, Kibana) for real-time analysis and monitoring. This enables hospitals to detect anomalies or potential data security incidents early and provide strong audit evidence when needed.

Finally, consider data anonymization or pseudonymization techniques for research, statistical, or system testing purposes. Data that has been anonymized cannot be re-identified back to the data subject, so it falls outside the scope of the PDP Law. However, ensure that the anonymization process is carried out with a strong method and cannot be re-identified. For pseudonymized data, direct identifying information is replaced with artificial identifiers, but there is still a way to link it back to the original identity if the pseudonymization key is available. Both techniques are important for balancing the need for data with patients' privacy rights.

Example Code and Data Security Configuration

To ensure PDP Law compliance in SIMRS, the technical implementation must include strong mechanisms for authentication, authorization, and auditing. The following is an example of a simple database configuration and API endpoint that illustrates these principles. This code is not pseudocode, but a representative example that can be adapted in a real development environment.

Code Block 1: Database Schema with Encryption and Audit Log

In the patient database schema, several specific personal data columns must be encrypted. We also need to add columns to record when the data was last accessed or modified for audit purposes. This example uses PostgreSQL 16 syntax.

-- Patient table with encrypted data and audit columns-- Use of bytea type to store encrypted dataCREATE TABLE patients (    id BIGSERIAL PRIMARY KEY,    medical_record_number VARCHAR(50) UNIQUE NOT NULL,    full_name_encrypted BYTEAT NOT NULL, -- Patient full name, encrypted    dob_encrypted BYTEA NOT NULL, -- Date of birth, encrypted    gender VARCHAR(10) NOT NULL,    address_encrypted BYTEA NOT NULL, -- Address, encrypted    phone_number_encrypted BYTEA, -- Phone number, encrypted    email_encrypted BYTEA, -- Email, encrypted    diagnosis_history_encrypted BYTEA, -- Diagnosis history, encrypted    created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP,    updated_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP,    last_accessed_by VARCHAR(100), -- User who last accessed    last_accessed_at TIMESTAMP WITH TIME ZONE -- Last accessed time);-- Function to update updated_at and last_accessed_at columnsCREATE OR REPLACE FUNCTION update_patient_audit_columns()RETURNS TRIGGER AS $$BEGIN    NEW.updated_at = NOW();    IF TG_OP = 'UPDATE' THEN        NEW.last_accessed_by = CURRENT_USER; -- Or user from the application        NEW.last_accessed_at = NOW();    END IF;    RETURN NEW;END;$$ LANGUAGE plpgsql;-- Trigger to automatically update audit columnsCREATE TRIGGER patient_audit_triggerBEFORE UPDATE ON patientsFOR EACH ROWEXECUTE FUNCTION update_patient_audit_columns();

Code Explanation 1: The patients table schema is designed to store sensitive data such as name, date of birth, address, and diagnosis history in encrypted form (BYTEA). The last_accessed_by and last_accessed_at columns are added to track who and when the patient data was last accessed or modified, which is very important for PDP Law compliance audits. The patient_audit_trigger trigger automatically updates these audit columns whenever there is a change to patient data. Encryption and decryption functions must be handled at the application layer using secure encryption keys that are properly managed.

Code Block 2: Authorization Middleware and API Access Log (Laravel 11.x)

In a SIMRS application based on Laravel 11.x, we can use middleware to manage authorization for access to patient data and record every access attempt.

// app/Http/Middleware/LogPatientAccess.php<?phpnamespace App\Http\Middleware;use Closure;use Illuminate\Http\Request;use Illuminate\Support\Facades\Log;use Symfony\Component\HttpFoundation\Response;class LogPatientAccess{    public function handle(Request $request, Closure $next): Response    {        $patientId = $request->route('patientId'); // Get patient ID from route        $userId = auth()->id(); // ID of the currently logged-in user        $userRole = auth()->user()->role; // User role (e.g., doctor, nurse)        // Log every access to patient data        Log::channel('patient_access')->info('Patient Data Access Attempt', [            'user_id' => $userId,            'user_role' => $userRole,            'patient_id' => $patientId,            'action' => $request->method() . ' ' . $request->fullUrl(),            'ip_address' => $request->ip(),            'timestamp' => now()->toDateTimeString(),            'status' => 'attempted' // Initially attempted, can be updated after request completes        ]);        $response = $next($request);        // If request succeeds, update log status        Log::channel('patient_access')->info('Patient Data Access Success', [            'user_id' => $userId,            'user_role' => $userRole,            'patient_id' => $patientId,            'action' => $request->method() . ' ' . $request->fullUrl(),            'ip_address' => $request->ip(),            'timestamp' => now()->toDateTimeString(),            'status' => 'success',            'response_status' => $response->getStatusCode()        ]);        return $response;    }}// app/Http/Kernel.php (Add middleware to 'api' or 'web' group)protected $middlewareGroups = [    'api' => [        // ... other middleware        \App\Http\Middleware\LogPatientAccess::class,    ],];// routes/api.php (Example usage on route)Route::middleware(['auth:sanctum', 'can:view,patient'])->group(function () {    Route::get('/patients/{patientId}', [PatientController::class, 'show']);    // ... other routes that access patient data});// app/Policies/PatientPolicy.php (Example policy for authorization)<?phpnamespace App\Policies;use App\Models\User;use App\Models\Patient;use Illuminate\Auth\Access\Response;class PatientPolicy{    public function view(User $user, Patient $patient): bool    {        // Example: Doctor can only view patients they handle        return $user->role === 'doctor' && $user->id === $patient->assigned_doctor_id;        // Or: Medical records staff can view all patients        // return $user->role === 'medical_records';    }}

Code Explanation 2: The LogPatientAccess middleware logs every attempt to access patient data before and after the API request is processed. This ensures every interaction with sensitive data is recorded. These logs are directed to a separate channel (patient_access) to facilitate monitoring and analysis. At the same time, PatientPolicy is used to enforce strict authorization, for example only assigned doctors or medical records staff with certain roles are allowed to view patient data. This combination of logging middleware and authorization policy is an important foundation for PDP Law compliance.

Secure Data Exchange Scheme and Incident Handling

The exchange of patient data between systems or with external parties, such as the SatuSehat platform, is one of the most vulnerable areas to PDP violations. The use of interoperability standards such as FHIR R4 is highly recommended because it provides a consistent data structure and well-defined APIs. However, beyond format, transport and content security are also crucial. The following example shows a simplified FHIR R4 payload for the Patient resource, highlighting sensitive data and how it should be encrypted or protected during exchange.

Example FHIR R4 Payload (JSON) for Patient Resource

This payload represents patient data that might be exchanged. Note that some sensitive fields such as name or NIK may require application-level encryption or tokenization if sent over less secure channels, even though transport using TLS is already mandatory.

Here is an example of a simplified FHIR R4 payload for the Patient resource:

{
  "resourceType": "Patient",
  "id": "RM-2024-00123",
  "identifier": [
    {"system": "https://fhir.kemkes.go.id/id/nik", "value": "3271xxxxxxxxxxxx"}
  ],
  "name": [{"use": "official", "text": "Patient Name"}],
  "telecom": [{"system": "phone", "value": "+62812xxxxxxx"}],
  "birthDate": "1985-04-12",
  "address": [{"city": "Bandung", "postalCode": "40111"}]
}

To maintain compliance, apply payload encryption at the application level (e.g., AES-GCM with keys managed via KMS), tokenization for identifiers such as NIK, and message signing (JWS) to ensure data integrity. Additionally, prepare incident handling procedures: detection of access anomalies, notification to authorities and data subjects according to PDP Law deadlines, and neat forensic documentation.

Practical Tips for Implementing PDP Law Compliance in SIMRS

Start with comprehensive data mapping. Identify all entry and exit points of patient data, including registration modules, electronic medical records, laboratory, radiology, pharmacy, and external integrations such as SatuSehat and BPJS. From this map, establish data classification (general, sensitive, highly sensitive) and determine proportional security controls for each category. Involve legal, IT, and service units from the beginning so that the policies created are not only regulatory compliant but also executable in the field.

Second, apply the principles of least privilege and need-to-know consistently. Use role-based access control (RBAC) combined with attribute-based access control (ABAC) for dynamic scenarios, such as emergency access in the ER. Require multifactor authentication (MFA) for staff accessing sensitive data, and conduct regular access rights reviews (at least every quarter) to revoke permissions that are no longer relevant. Don't forget to record every change in access rights in an immutable audit trail.

Third, build a privacy culture through regular training and incident simulations. Train staff to recognize phishing, understand the importance of patient identity verification, and know the reporting flow if a data breach occurs. Provide a secure and anonymous internal reporting channel, then follow up on every report with a documented investigation. With a combination of aligned technology, processes, and people, PDP Law compliance is not merely an administrative burden, but part of improving hospital service quality.

FAQ

What sanctions can be imposed if a hospital violates the PDP Law?

The PDP Law provides for administrative sanctions in the form of written warnings, temporary suspension of data processing activities, deletion or destruction of data, up to administrative fines whose amount is determined by the supervisory agency. In addition, there is the potential for criminal sanctions for certain violations, for example unlawfully disclosing personal data that does not belong to one, with the threat of imprisonment and/or fines. Therefore, compliance must be built systemically, not reactively.

May patient data be stored in the cloud?

Yes, as long as it meets the requirements of the PDP Law, including having a lawful basis for processing, adequate consent where required, and guarantees of equivalent data protection. Choose a cloud provider that has relevant security certifications, provides encryption in transit and at rest, and offers data storage in Indonesian territory if required. Also ensure there is a clear data processing agreement (DPA) between the hospital and the service provider.

How should requests for access to or deletion of patient data be handled?

Prepare standard procedures that include verification of the requester's identity, recording of the request, response deadlines in accordance with regulations, and a lawful refusal mechanism if there is another legal basis requiring the data to be retained (for example, medical record retention obligations). For deletion requests, ensure they do not conflict with legal obligations in the health sector, and document every decision transparently to the patient.

Does an existing SIMRS need a total overhaul?

Not always. The first step is to conduct a gap assessment of existing controls. Often improvements can be made gradually, for example by adding encryption to sensitive columns, tightening authorization, improving logging, and integrating a digital consent module. A total overhaul is only necessary if the existing architecture does not allow the safe implementation of basic controls such as audit trails and encryption.

Compliance with the PDP Law is a continuous journey that demands commitment from all elements of the hospital. With clear governance, appropriate technology, and trained human resources, hospitals can protect patient data while increasing public trust. Don't wait until an incident occurs—start with small steps today, evaluate regularly, and ensure every decision is risk-based. Need assistance to develop a compliance roadmap and secure SIMRS technical implementation? Consult your needs with our expert team now to get an assessment, architecture recommendations, and implementation assistance tailored to the scale and complexity of your hospital.

This article is part of the knowledge base of Nugroho Setiawan, an IT consultant in Jogja (Yogyakarta). Related solutions: SIMRS (Hospital Information System) BPJS & SatuSehat Integration. Need a free consultation?