Tutorial: Configuring Automatic Lab Result Notifications to Doctors

In many hospitals and clinics, laboratory results are often already available in the LIS (Laboratory Information System), but the treating physician only learns of them after being contacted manually by lab staff. This process is not only time-consuming but also risks causing delays in treatment, especially for critical values. Imagine an on-call physician in the ER having to call the lab repeatedly just to confirm that a patient's blood test results are out. With high patient volumes, human error and missed notifications become real problems. Automation of lab result notifications is a relatively easy solution to implement if the IT infrastructure already supports it. This article discusses concrete steps for configuring automatic notifications from the database to the physician's device, using commonly used tools such as PostgreSQL 15, Node.js 20, and nodemailer 6.9. For hospitals in Yogyakarta, DIY, and Magelang that want to implement a similar system, IT consulting and SIMRS/SIM Klinik application development can help accelerate the process without compromising data security.

Automatic Lab Result Notification Architecture

The minimal architecture consists of three components: the data source (LIS or lab result database), a message broker or trigger, and a notification service. Ideally, lab results that have been verified by a clinical pathologist are marked with the status final or verified. It is this status change that triggers the notification. If the laboratory uses an analyzer that produces HL7 v2.5.1 messages (ORU^R01), integration can be performed through an integration engine such as Mirth Connect 4.4.0 that forwards messages to the database. For a more modern environment, HL7 FHIR R4 with the Observation resource and Subscription mechanism can be used, but it requires a FHIR server such as HAPI FHIR 6.2.0.

In practice, many SIMRS in Indonesia still rely on relational databases as the data center. PostgreSQL 15 provides the LISTEN/NOTIFY feature, which is lightweight and suitable for real-time notifications without the need for an additional message broker. Alternatively, use Redis 7.2 with pub/sub or RabbitMQ 3.12 for enterprise scale. For hospitals with hundreds of lab results per hour, the LISTEN/NOTIFY approach is sufficient as long as database connections are managed with a connection pool. Most importantly, ensure that notifications are sent only after results have been validated, not while they are still in preliminary status.

The notification service can take the form of email, WhatsApp messages through gateways such as Twilio or Wablas, or notifications within the physician's mobile application. Email remains the simplest and most reliable option for sending lab result details along with PDF attachments. Use an SMTP relay with TLS 1.3, for example Postfix 3.7 or a cloud service such as SendGrid. Ensure that every notification includes encrypted patient identity and a secure link to the system to view complete details. With this architecture, physicians receive notifications within seconds after results are verified.

Configuration Steps: From Database to Physician

The first step is to prepare a lab results table with a status column. Example: lab_results (id, patient_id, doctor_id, test_name, result_value, status, verified_at). Create a PostgreSQL trigger that calls pg_notify('lab_result_channel', row_to_json(NEW)::text) whenever the status changes to 'final'. This trigger ensures that only final results trigger notifications. Also ensure that there are indexes on the status and verified_at columns to maintain performance. If data volume is high, consider partitioning the table by month.

The second step is to create a notification service using Node.js 20.11.0 with the pg 8.11.3 and nodemailer 6.9.7 packages. This service will listen to the lab_result_channel channel, format the message, and then send an email to the registered physician's address. The following is a minimal code example that can be run after installing the dependencies (npm install pg nodemailer):

const { Client } = require('pg');
const nodemailer = require('nodemailer');
const client = new Client({ connectionString: process.env.DATABASE_URL });
const transporter = nodemailer.createTransport({ host: 'smtp.example.com', port: 587, secure: false, auth: { user: 'lab@example.com', pass: 'secret' } });
client.connect();
client.query('LISTEN lab_result_channel');
client.on('notification', async (msg) => {
  const data = JSON.parse(msg.payload);
  if (data.status !== 'final') return;
  await transporter.sendMail({ from: 'lab@example.com', to: `${data.doctor_id}@rs.example.com`, subject: `Hasil Lab Pasien ${data.patient_id}`, text: `Pemeriksaan ${data.test_name}: ${data.result_value}` });
});
console.log('Menunggu notifikasi hasil lab...');

The third step is to configure SMTP or a WhatsApp gateway. For email, use application credentials that have limited send permissions. For WhatsApp, integrate with an API gateway such as Wablas or Twilio. Ensure that you handle retries if delivery fails, for example with exponential backoff. Store a log of every notification sent in the notification_logs table for auditing. Test with dummy data first, then perform monitoring using Prometheus and Grafana to monitor latency and error rate.

Patient Data Security and Compliance

Lab result notifications contain sensitive personal data. Encrypt the payload using AES-256-GCM before sending it via email or WhatsApp. Never send patient data in plain text. Use a link that points to the SIMRS login page with a one-time access token (expires in 15 minutes). Implement OAuth 2.0 authentication for the notification service so that only authorized doctors can access details. For compliance with UU PDP No. 27 of 2022, ensure there is patient consent and a complete audit trail.

Restrict access to the database and notification service using role-based access control. Use TLS 1.3 for all connections, including database connections. Store SMTP credentials in a secrets manager such as HashiCorp Vault 1.15 or AWS Secrets Manager. Perform penetration tests regularly, at least once a year. If your hospital in Yogyakarta or Magelang does not yet have a dedicated security team, IT consulting with an application development provider experienced in SIMRS/SIM Klinik can help formulate security policies that comply with regulations.

In addition, apply the principle of least privilege to the account used by the notification service. Do not use a database administrator account. Create a dedicated user with permission only for SELECT on the lab results table and INSERT on the log table. For email notifications, use a dedicated sender address (for example, no-reply@lab.rs) that is not used for other communication. Document all configurations in a runbook so they are easy to audit and replicate in the event of disaster recovery.

Best Practices

1. Validate the lab result status before sending notifications. Ensure that only the final or verified status triggers a notification, not preliminary or draft.
2. Use a message queue for scalability. If notification volume exceeds 1000 per hour, migrate from LISTEN/NOTIFY to RabbitMQ or Redis pub/sub so as not to burden the database.
3. Encrypt sensitive data and implement access tokens. Do not send lab values directly in email; use a secure link with a one-time token that expires in 15 minutes.
4. Record every notification in the audit log. Store send time, recipient, delivery status, and SMTP/WhatsApp response for forensic and compliance purposes.
5. Perform testing and continuous monitoring. Use dummy data, measure notification latency, and set up alerts if delivery failures exceed 5% within 1 hour.

FAQ

Can automatic notifications be sent to a doctor's WhatsApp?

Yes. Use a WhatsApp Business API gateway such as Twilio or Wablas. You need to register an official sender number and obtain the doctor's consent to receive messages. Ensure the message contains only a summary and a secure link, not the complete lab result details.

What if the doctor does not have an official hospital email?

Use in-app notifications in the SIMRS mobile application or send to a registered WhatsApp number. Alternatively, use an SMS gateway to send a verification code that directs to the patient/doctor portal. Ensure doctor contact data is updated regularly in the employee master data.

Is the PostgreSQL LISTEN/NOTIFY method safe for patient data?

It is safe as long as the database connection uses TLS and the payload is encrypted. However, LISTEN/NOTIFY sends the payload in plain text in the server memory. For extra security, encrypt the lab values before sending them through the channel, or use a message broker that supports end-to-end encryption.

How long does it take to implement automatic lab result notifications?

For hospitals whose SIMRS already has a structured lab module, basic configuration (database trigger + Node.js service + SMTP) can be completed in 2-3 working days. However, for integration with HL7/FHIR and security compliance testing, allow 2-4 weeks depending on infrastructure complexity.

Automatic lab result notifications are not just an additional feature but an operational necessity to accelerate clinical decisions and reduce the risk of communication errors. By following the tutorial above, a hospital or clinic IT team can build a reliable, secure, and scalable notification system. If you need technical assistance, IT consulting, or application development for SIMRS/SIM Klinik/ERP/POS/website for the Yogyakarta, DIY, and Magelang areas, our team is ready to help from planning to implementation. Contact us for an initial discussion and a readiness audit of your system.

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