Durdans LIMS - Laboratory Information Management System

Durdans LIMS is a Laboratory Information Management System built for Durdans Hospital, one of Sri Lanka's leading private hospital networks, by a University of Moratuwa team in partnership with IFS Sri Lanka. It digitises the entire clinical-laboratory pipeline - from patient registration and billing, through sample collection, result entry, multi-level verification, and pathologist authorization, to final report dispatch - across a multi-branch hospital network. Because senior engineers and tech leads at IFS review the codebase, it is held to a real enterprise standard rather than a student-project bar.

This was a team project, built by a University of Moratuwa team under the com.uom.lims namespace. The description below covers the system as a whole.

At its heart is a faithful model of how a real hospital laboratory runs. A patient is registered, an order is created and billed, a phlebotomist collects and labels the sample, reception accessions it and verifies its quality, a medical lab technologist enters the results, a supervisor verifies them, a pathologist gives clinical authorization with an electronic signature, and the authorized report is dispatched by email or SMS. Nine roles defined in the identity provider - technologist, supervisor, receptionist, phlebotomist, billing, dispatch, pathologist, branch admin, and super admin - each see only the screens and actions their job actually requires.

The platform is multi-tenant by branch: every clinical and financial record is scoped to a hospital branch, and every query is branch-isolated on the server, so one branch's staff can never read or write another branch's data. Authorization is fail-closed - every request is denied by default and then explicitly granted per role, with the monitoring endpoints locked to super admins and the client never trusted to supply its own branch. The project went through two enterprise security reviews and a dedicated hardening pass: secrets were externalized out of the codebase, eventing was made reliable, and result flagging was moved onto clinically-correct rules rather than hard-coded guesswork.

The backend is a Spring Boot service written in Java 21, organized as a multi-module Gradle build that separates the API contract - request and response objects, enums, and custom validators for Sri Lankan NIC, passport, driving licence, and phone formats - from the implementation. It persists to PostgreSQL through JPA with Liquibase-managed schema migrations, secures every endpoint as an OAuth2 resource server that validates the identity provider's signed JWTs, and publishes domain events to Apache Kafka through a transactional outbox, so an event is delivered if and only if its database transaction committed. Patient documents are stored in object storage, reference data is cached, and health and metrics are exposed to Prometheus and Grafana. The frontend is a Next.js and React single-page application in TypeScript and Tailwind CSS, protected by layered, fail-closed route guards backed by the identity provider, with role-aware dashboards and PDF and spreadsheet report export.

A distinctive part of the system is its instrument-integration layer. Real laboratory analyzers are not physically connected, so the team built a standalone, dependency-free analyzer simulator that speaks the ASTM E1394 and LIS2-A2 protocols over TCP with checksum-validated framing, shipping hematology and chemistry workloads. The backend runs a feature-flagged TCP listener that decodes this analyzer traffic, maps each device code to a LOINC-coded parameter and each barcode to its sample, ingests results idempotently, and publishes them through the outbox. An auto-verification engine then automatically releases normal numeric results and holds abnormal or critical ones for human review, with quality-control runs evaluated against Westgard rules and result flags driven by an age- and sex-aware reference-range engine.

The system implements the healthcare messaging standards that real laboratory and hospital information systems exchange: HL7 version 2.5.1 for result, admission, and order messages, FHIR R4 for result resources, and LOINC coding with UCUM units on every catalog test and parameter. It also addresses Sri Lanka's Personal Data Protection Act directly, with patient consent capture, data-subject access and erasure requests including field-level redaction, a retention scheduler for the data lifecycle, and electronic-signature manifestation on clinical sign-out.

Testing is concentrated on the high-risk integration and correctness paths: the input validators, ASTM ingestion, auto-verification, Westgard quality control, reference-range matching, result-flag resolution, the HL7 and FHIR builders and parsers, and the data-protection request flows are all covered by automated tests. The whole stack runs locally through a single Docker Compose environment that brings up the identity provider, two databases, Kafka, object storage, and the observability tools.

The result is a realistic, enterprise-reviewed clinical system rather than a demo: multi-branch, standards-based, security-hardened, and faithful to how a real hospital laboratory actually operates, from patient registration through to a pathologist-signed report.