Complete Guide: Integrating BSrE-Certified Electronic Signatures for Your SIMRS & E-Office

In today's digital era, operational efficiency and document legality are the main pillars of every organization's success, especially in the healthcare sector with hospital management information systems (SIMRS) and E-Office systems. The manual document signing process not only consumes time and resources but is also vulnerable to forgery and complicates audits and compliance. Imagine stacks of medical records, medical procedure consent forms, or internal HRD documents that must be signed one by one every day. This creates a significant bottleneck that hampers workflows and triggers high operational costs. In Indonesia, the National Cyber and Crypto Agency (BSSN) through the Electronic Certification Center (BSrE) provides a certified Electronic Signature (TTE) solution that has legal force equivalent to a wet signature, in accordance with Law Number 11 of 2008 concerning Electronic Information and Transactions (UU ITE) and Government Regulation Number 71 of 2019. This article is specifically designed for IT Managers, clinic owners, operations managers, and decision-makers seeking technology solutions. We will guide you through practical, in-depth, and actionable steps to implement BSrE-certified TTE, from basic concepts to real code examples, error handling, and best practices to ensure your SIMRS or E-Office system is not only efficient but also secure and legally compliant.

Understanding BSrE-Certified Electronic Signatures and Their Urgency

A BSrE-certified Electronic Signature (TTE) is a form of digital signature that uses public key infrastructure (PKI) and electronic certificates issued by an Electronic Certification Provider (PSrE) registered with the Ministry of Communication and Informatics. In the Indonesian context, BSrE is one of the PSrEs recognized and mandated by the government to provide electronic certification services for government agencies and the general public. The legality of this TTE is guaranteed by UU ITE No. 11 of 2008 as amended by No. 19 of 2016, and reinforced by PP No. 71 of 2019 concerning the Implementation of Electronic Systems and Transactions, which explicitly states that a certified TTE has valid legal force and legal consequences. This means that electronic documents signed with BSrE TTE have the same validity as physical documents with wet signatures, guaranteeing authenticity, integrity, and non-repudiation.

The urgency of using BSrE TTE, especially in SIMRS and E-Office environments, is crucial. Modern healthcare systems such as SIMRS and Clinic MIS generate a massive volume of documents, ranging from patient medical records that must be kept confidential, work orders, to medical procedure consents. Manual processes will slow down services, increase the risk of human error, and complicate the audit process. With BSrE TTE, the entire signing process can be done digitally, paperless, and in seconds. This significantly reduces operational costs related to printing, physical storage, and document delivery. Furthermore, BSrE TTE helps hospitals and clinics meet accreditation standards and increasingly demanding regulations on digitalization and data security, such as standards from the Ministry of Health and the international FHIR R4 standard for medical data exchange.

The main benefits of BSrE-certified TTE for your organization include increasing operational efficiency by up to 70% in document handling, improving data security through encryption and guaranteed document integrity, and indisputable legal compliance. For example, in a hospital with 500 beds, an average of 1,500 documents require signatures every day. If each manual signature takes 5 minutes including document retrieval and distribution, then 125 work hours are wasted every day. With TTE, that time can be cut down to seconds per document, saving hundreds of work hours per month. Use cases for BSrE TTE in SIMRS include signing electronic medical records by doctors, patient consent, health certificates, and verification of BPJS Kesehatan claims. Meanwhile, in E-Office, TTE can be applied to decrees, internal memos, employee work contracts, and financial reports.

It should be understood that BSrE TTE differs from an ordinary digital signature that may only be an image. BSrE TTE uses an X.509 digital certificate issued by a trusted authority (BSrE), which binds the signer's identity to a cryptographic key. This ensures that the signature cannot be forged and that any change to the document after signing will be detected. This process involves hashing the document, signing that hash with the signer's private key, and attaching the public certificate for verification. Thus, BSrE TTE is not merely validation, but also a strong security mechanism to maintain the integrity and authenticity of your digital information.

Technical Preparation and Integration Architecture with BSrE

Integrating the BSrE Electronic Signature (TTE) into existing systems such as SIMRS, SIM Klinik, or E-Office requires careful technical planning. The first step is to register and verify identity (KYC) with BSrE to gain access to their API services. This process typically involves submitting the company's or individual's legal documents, biometric verification, and approval from BSrE. After gaining access, you will be provided with credentials such as an API Key, Client ID, or other authentication mechanisms needed to interact with the BSrE API endpoints. Understanding the BSrE API documentation in detail is key, as it will explain the required parameters, request format, and response structure for each service.

A common integration architecture involves several components. On your application side (for example, a SIMRS based on Laravel 11.x or an E-Office based on Node.js with Express.js), there will be a special module or service responsible for managing interactions with the BSrE API. The workflow is as follows: first, the user initiates the document signing process in your system. The document is then hashed using a cryptographic algorithm (generally SHA256) to produce a unique representation of the document's contents. This hash is then sent to BSrE, not the entire document contents, to maintain confidentiality. BSrE will request confirmation from the user (for example via an OTP or PIN entered in the BSrE mobile app), then sign the hash using the user's electronic certificate stored in the BSrE system. Once successful, BSrE will return the signing result (signed hash) along with the relevant certificate chain to your system.

Security aspects are the top priority in this integration. Ensure all communication between your system and the BSrE API uses the HTTPS/TLS 1.2 or newer protocol to secure data transmission. API Keys or other authentication tokens must be stored securely, for example in environment variables or a Key Vault, and not hardcoded in the source code. Implement a rate limiting mechanism if necessary to prevent API abuse. During development, it is recommended to use the sandbox or staging environment provided by BSrE for extensive testing before moving to the production environment. This will help identify and resolve potential issues without affecting the live system.

The choice of backend technology for integration is very flexible. You can use PHP with the Laravel 11.x framework, Node.js with Express 4.x or NestJS, Java with Spring Boot 3.x, or Python with Django 5.x/Flask 3.x. For the database, PostgreSQL 16 or MySQL 8.x are solid choices for storing document metadata and signing status. Also consider using a message queue (for example RabbitMQ or Apache Kafka) to handle signing requests that may take time or require asynchronous processing, especially in systems with high transaction volumes such as SIMRS integrated with FHIR R4 or HL7 v2.5.1. This will ensure application responsiveness is maintained and prevent timeouts on slow API requests.

BSrE generally provides two types of signing services: signPDF for PDF documents, and signHash for generic data. For maximum flexibility in a SIMRS or E-Office that may handle various data formats (HTML, JSON, XML, or custom), focus on integrating signHash. This allows you to create a hash of any data you want to sign, then store the original hash together with the signed_hash returned by BSrE. Verification can then be done by comparing the current document hash with the stored original hash, and verifying the signed_hash using the certificate chain from BSrE. This approach gives you full control over the document creation process and is more adaptable to various business needs.

Implementing Electronic Signature Integration (Laravel & Node.js Example)

This section will present a concrete implementation example for integrating the BSrE signHash service using PHP with Laravel 11.x and Node.js. We will focus on the core logic for generating the document hash, sending it to BSrE to be signed, and receiving the response. Assume you have obtained the API credentials from BSrE and configured them in your application environment (for example, a .env file).

Backend Implementation with Laravel 11.x (PHP)

In a Laravel application, we will create a Service Class responsible for interacting with the BSrE API. We will use the Guzzle HTTP Client, which is already integrated with Laravel, to make API requests. First, make sure Guzzle is installed:

composer require guzzlehttp/guzzle

Next, create the service file at app/Services/BSRService.php:

<?phpnamespace App\'Services;use GuzzleHttp\Client;use GuzzleHttp\Exception\ClientException;use GuzzleHttp\Exception\ServerException;use Illuminate\Support\Facades\Log;class BSRService{protected $client;protected $apiUrl;protected $apiKey;public function __construct(){$this->apiUrl = config('services.bsre.api_url');$this->apiKey = config('services.bsre.api_key');$this->client = new Client(['base_uri' => $this->apiUrl,'headers' => ['Authorization' => 'Bearer ' . $this->apiKey,'Content-Type' => 'application/json','Accept' => 'application/json',],'verify' => true, // Ensure SSL verification is active]);}/**** Generates a SHA256 hash from the input data.* @param string $data* @return string*/public function generateHash(string $data): string{return hash('sha256', $data);}/**** Sends a hash signing request to BSrE.* @param string $nik NIK of the user who will sign* @param string $passphrase User's passphrase (PIN/OTP)* @param string $documentHash Hash of the document to be signed* @param string $reason Reason for signing* @param string $location Signing location (optional)* @return array Response from BSrE* @throws \Exception*/public function signHash(string $nik, string $passphrase, string $documentHash, string $reason, string $location = null): array{try {$payload = ['nik' => $nik,'passphrase' => $passphrase,'hash' => $documentHash,'reason' => $reason,'location' => $location,'client_id' => config('services.bsre.client_id'), // Add client_id if needed];$response = $this->client->post('sign-hash', ['json' => $payload,]);$body = json_decode($response->getBody()->getContents(), true);Log::info('BSrE Sign Hash Response:', $body);return $body;} catch (ClientException $e) {$responseBody = $e->getResponse()->getBody()->getContents();Log::error('BSrE Sign Hash Client Error:', ['message' => $e->getMessage(), 'response' => $responseBody]);throw new \Exception("BSrE Client Error: " . $responseBody);} catch (ServerException $e) {$responseBody = $e->getResponse()->getBody()->getContents();Log::error('BSrE Sign Hash Server Error:', ['message' => $e->getMessage(), 'response' => $responseBody]);throw new \Exception("BSrE Server Error: " . $responseBody);} catch (\Exception $e) {Log::error('BSrE Sign Hash General Error:', ['message' => $e->getMessage()]);throw $e;}}}/**** Verifies an electronic signature.* @param string $signedHash Signature generated by BSrE* @param string $originalHash Original document hash* @param string $certificateChain Certificate chain from BSrE* @return array Verification response from BSrE* @throws \Exception*/public function verifySignature(string $signedHash, string $originalHash, string $certificateChain): array{try {$payload = ['signed_hash' => $signedHash,'original_hash' => $originalHash,'certificate_chain' => $certificateChain,];$response = $this->client->post('verify-signature', ['json' => $payload,]);$body = json_decode($response->getBody()->getContents(), true);Log::info('BSrE Verify Signature Response:', $body);return $body;} catch (ClientException $e) {$responseBody = $e->getResponse()->getBody()->getContents();Log::error('BSrE Verify Signature Client Error:', ['message' => $e->getMessage(), 'response' => $responseBody]);throw new \Exception("BSrE Client Error: " . $responseBody);} catch (\Exception $e) {Log::error('BSrE Verify Signature General Error:', ['message' => $e->getMessage()]);throw $e;}}}

In the code above, generateHash generates a SHA256 hash of the data to be signed. The signHash function sends a signing request to the BSrE /sign-hash endpoint with the NIK, passphrase, document hash, and reason. The verifySignature function is an example for verifying a signature that has been created. You need to configure BSRE_API_URL, BSRE_API_KEY, and BSRE_CLIENT_ID in your .env file.

Backend Implementation with Node.js (Express 4.x)

For Node.js, we will use the axios library for the HTTP client and Node.js's built-in crypto module for hashing. First, install axios:

npm install axios

Create a service file at services/bsre.service.js:

const axios = require('axios');const crypto = require('crypto');class BSRService {constructor() {this.apiUrl = process.env.BSRE_API_URL;this.apiKey = process.env.BSRE_API_KEY;this.axiosInstance = axios.create({baseURL: this.apiUrl,headers: {'Authorization': `Bearer ${this.apiKey}`,'Content-Type': 'application/json','Accept': 'application/json',},});}/**** Generates a SHA256 hash from the input data.* @param {string} data* @returns {string}*/generateHash(data) {return crypto.createHash('sha256').update(data).digest('hex');}/**** Sends a hash signing request to BSrE.* @param {string} nik NIK of the user signing* @param {string} passphrase User's passphrase (PIN/OTP)* @param {string} documentHash Hash of the document to be signed* @param {string} reason Reason for signing* @param {string} [location] Location of signing (optional)* @returns {Promise<object>} Response from BSrE*/async signHash(nik, passphrase, documentHash, reason, location = null) {try {const payload = {nik,passphrase,hash: documentHash,reason,location,client_id: process.env.BSRE_CLIENT_ID, // Add client_id if needed};const response = await this.axiosInstance.post('/sign-hash', payload);console.log('BSrE Sign Hash Response:', response.data);return response.data;} catch (error) {if (error.response) {console.error('BSrE Sign Hash Error:', error.response.data);throw new Error(`BSrE API Error: ${JSON.stringify(error.response.data)}`);} else {console.error('BSrE Sign Hash General Error:', error.message);throw error;}}}/**** Verifies an electronic signature.* @param {string} signedHash The signature generated by BSrE* @param {string} originalHash The hash of the original document* @param {string} certificateChain The certificate chain from BSrE* @returns {Promise<object>} Verification response from BSrE*/async verifySignature(signedHash, originalHash, certificateChain) {try {const payload = {signed_hash: signedHash,original_hash: originalHash,certificate_chain: certificateChain,};const response = await this.axiosInstance.post('/verify-signature', payload);console.log('BSrE Verify Signature Response:', response.data);return response.data;} catch (error) {if (error.response) {console.error('BSrE Verify Signature Error:', error.response.data);throw new Error(`BSrE API Error: ${JSON.stringify(error.response.data)}`);} else {console.error('BSrE Verify Signature General Error:', error.message);throw error;}}}}module.exports = BSRService;

Just like the PHP example, this Node.js code provides the functions generateHash, signHash, and verifySignature. Make sure environment variables such as BSRE_API_URL, BSRE_API_KEY, and BSRE_CLIENT_ID have been defined. Both code examples are modular and can be integrated into your application's controller or router to handle signing requests from the frontend.

Response Handling, Verification, and Errors in BSrE Integration

After sending a signing request to BSrE, your system will receive a response that needs to be interpreted. A successful response from BSrE for the signHash service will usually contain important information such as signed_hash, the signing timestamp, and certificate_chain. This data is crucial for the verification process later on. An example of a successful payload from BSrE might look like this:

{  "status": "success",  "message": "Hash successfully signed.",  "data": {    "signed_hash": "MIIB...", // Base64 encoded signed hash    "original_hash": "a1b2c3d4e5f6...", // Original SHA256 hash provided    "timestamp": "2023-10-27T10:00:00Z",    "signer_nik": "327501...",    "certificate_chain": ["MIIF...", "MIIE..."], // Base64 encoded certificate chain    "signature_id": "BSRE-SIG-1234567890"  }}

signed_hash is the result of the cryptographic signing that binds original_hash to the signer's certificate. certificate_chain contains the signer's digital certificate and the certificate of the authority that issued it, which is needed to verify the authenticity of the signature. All of this information must be stored together with the document in your database, for example in a document_signatures table that includes document_id, original_hash, signed_hash, signer_nik, timestamp, and certificate_chain. When a document needs to be verified, you can retrieve this data and use the BSrE API verify-signature or a third-party cryptographic library to ensure that the signed_hash is indeed valid and matches the original_hash and the provided certificate.

However, not all responses will be successful. API integration will certainly encounter various error scenarios. It is important to identify and handle these errors properly so that the application remains robust and provides a good user experience. Examples of error messages from BSrE can vary, for example:

{  "status": "error",  "code": 400,  "message": "Invalid NIK or passphrase.",  "details": "The provided NIK does not match the passphrase, or the passphrase is incorrect."}

Effective error handling involves several strategies. First, use try-catch blocks to catch HTTP exceptions thrown by the HTTP client library (such as Guzzle or Axios) when BSrE returns an error status code (for example, 4xx or 5xx). Second, log all error details, including the status code, the error message from BSrE, and the request payload that caused the error. This is very helpful in the debugging process. Third, provide informative feedback to the user. For example, if the NIK or passphrase is wrong, tell the user specifically. If an internal system error occurs at BSrE (5xx status), provide a message that the service is currently unavailable and to try again later. Finally, for temporary errors (such as timeouts or network disruptions), implement a retry mechanism with exponential backoff to retry the request after a certain delay, up to a maximum number of attempts, before marking the transaction as failed.

It is also important to distinguish between input validation errors (for example, invalid hash, unregistered NIK) that must be handled on your application side before sending to BSrE, and errors from BSrE itself. For validation errors, ensure that the data sent to BSrE is clean and in the correct format. For example, the NIK must be 16 digits, the hash must be SHA256, and the passphrase must comply with BSrE policy. With comprehensive response and error handling, your system will be more reliable and ready to face various operational conditions.

Best Practices in BSrE TTE Implementation

1. User Passphrase/PIN Security: Never store the user's passphrase or PIN in your database or system logs. The passphrase must always be entered directly by the user during the signing process and sent directly to the BSrE API over a secure HTTPS connection. Consider using a One-Time Password (OTP) mechanism sent to the user's registered device for additional authentication, in accordance with BSrE security standards.
2. Comprehensive Logging and Audit Trail: Every signing transaction must be recorded in detail. The log must at minimum include who signed (NIK), when (timestamp), what document was signed (document ID, original hash), the signing status (success/failure), and the details of the response from BSrE. This audit trail is crucial for compliance, dispute resolution, and forensic analysis if problems occur. Ensure that logs do not leak or become accessible to unauthorized parties.
3. Integrity of the Original Document and Hash: Ensure that the hash you send to BSrE truly represents the original document viewed and approved by the user. Use a strong hashing algorithm such as SHA256. Store this original hash together with the document and the signed_hash returned by BSrE. Any small change to the document after it has been hashed will produce a different hash, so the signature's validity will fail. Implement a checksum to verify the document's integrity before and after signing.
4. System Scalability and Availability: Design an integration architecture capable of handling a high volume of signing requests. Use load balancers, message queues for asynchronous processes, and ensure that your application servers have adequate capacity. Also consider the availability of the BSrE API; have a fallback strategy or notification if the BSrE service experiences disruptions.
5. Extensive Testing in a Sandbox Environment: Before launching to production, perform thorough testing in the BSrE sandbox environment. Test various scenarios: success, failure due to wrong NIK/passphrase, invalid document, timeout, and high volume. Ensure that all workflows, including error handling and verification, function correctly in accordance with the BSrE documentation version 2.0 or the latest.
6. Electronic Certificate Lifecycle Management: Understand that electronic certificates have a validity period. Ensure that your system can manage certificate renewal automatically or semi-automatically, and provide notifications to users before their certificates expire. Users must also understand the procedure for renewing or revoking their certificates in the event of compromise.
7. Ongoing Regulatory Compliance: The regulatory environment related to electronic signatures and data privacy (such as the PDP Law) continues to evolve. Always monitor updates from the Ministry of Communication and Informatics, BSSN, and other relevant institutions. Ensure that your implementation always complies with the latest regulations, such as Permenkominfo No. 11 of 2018 concerning the Implementation of Electronic Certification, to maintain the legality and legal force of TTE.

FAQ (Frequently Asked Questions)

What is the difference between a BSrE-certified TTE and an ordinary digital signature?

The main difference lies in legal force and validation. A BSrE-certified TTE is issued by an Electronic Certification Provider (PSrE) recognized by the government (BSrE), which means it has legal force equivalent to a wet signature and its authenticity is guaranteed. An ordinary digital signature, such as an image of a signature pasted onto a document, may not have the same guarantee of non-repudiation or legal validity because it is not bound to a digital certificate issued by a trusted authority.

How do I register to obtain a BSrE TTE?

To register for BSrE TTE, you need to visit the official BSrE website or through an application that partners with BSrE. The registration process generally involves strict identity verification (KYC), including filling in personal data, uploading identity documents (ID card), and often biometric verification such as face or fingerprint recording. After successful verification, your electronic certificate will be issued and you will be given credentials to start using the TTE service.

Is BSrE TTE legally valid?

Yes, BSrE TTE is legally valid in Indonesia. Its legal force is regulated in Law Number 11 of 2008 concerning Electronic Information and Transactions (UU ITE) as amended, as well as Government Regulation Number 71 of 2019 concerning the Implementation of Electronic Systems and Transactions. This regulation confirms that a certified TTE has the same standing as a wet signature, guaranteeing the authenticity, integrity, and non-repudiation of electronic documents.

What documents can be signed using BSrE TTE?

Almost all types of electronic documents can be signed using BSrE TTE. In the context of SIMRS, this includes electronic medical records, medical action consent forms, electronic prescriptions, health certificates, and medical reports. For E-Office, TTE can be used for decision letters, internal memos, employment contracts, financial reports, invoices, and various other administrative documents that require authentication and legality. This flexibility makes BSrE TTE highly relevant for various organizational needs.

What if I forget my passphrase or my certificate expires?

If you forget your passphrase, you need to follow the passphrase reset procedure established by BSrE, which usually involves re-verifying your identity to ensure security. If your electronic certificate expires, you can no longer use TTE until the certificate is renewed. BSrE generally provides a mechanism for certificate renewal before its validity period ends. It is important to proactively monitor your certificate's validity period and carry out renewal according to existing procedures.

How much does it cost to use the BSrE TTE service?

The cost of using the BSrE TTE service can vary depending on the type of service (individual, corporate, or government agency) and the volume of transactions required. BSrE may offer pricing schemes based on subscription packages or per transaction. For the most accurate and up-to-date cost information, it is recommended to contact BSrE directly or visit their official website. Generally, the investment in BSrE TTE will be much smaller compared to the costs and risks arising from an inefficient and vulnerable manual signing process.

The integration of BSrE-certified Electronic Signatures is no longer an option, but a necessity for organizations that want to operate efficiently, securely, and in compliance with regulations in the digital era. From crucial electronic medical records in SIMRS to important administrative documents in E-Office, BSrE TTE provides unmatched guarantees of legality and integrity. By following the in-depth technical guide, runnable code examples, and best practices we have provided, you can build a robust system ready to face the challenges of digitalization. This process will cut operational costs, accelerate document workflows by up to 80%, and significantly mitigate the risk of forgery. If you need professional assistance in designing, developing, and implementing a BSrE TTE integration solution tailored to the specific needs of your SIMRS, Clinic SIM, E-Office, or other system, the Nugroho Setiawan team with extensive experience in health system and enterprise integration is ready to be your strategic partner. Contact us today for further discussion and discover how we can help you achieve a successful digital transformation.

Related solutions by PT Pilar Inovasi Informatika (Pilar Inovasi IT products): SIMRS (Hospital Information System) Clinic Management System E-Office. Need a free consultation?