Software Engineer

Overview

From November 2020 to July 2023, I worked as a software engineer at Bioforge Health Systems Ltd, building hospital management systems for multiple hospitals including Jalalabad Ragib-Rabeya Medical College and Bangladesh Medical College (BMC).

As a senior member of the team, my role went beyond writing code for individual features. I was involved in system-level design across all modules, participated in architectural decisions, reviewed code, and provided feedback to other engineers. The product was a full suite of modules—discharge, lab, appointment scheduling, inpatient, statistics, and more—built on a microservices architecture where each module operated as its own service with clear boundaries.

Our long-term goal was to evolve from per-hospital deployments into a single SaaS platform where hospitals could sign up and start using the system without custom infrastructure. We chose microservices early because we knew hospitals operate very differently—policies, workflows, and terminology varied enough that a monolith would have been painful to maintain and customize per client.

Tech stack: React.js, Node.js, Express, MongoDB, PostgreSQL, Material UI, Socket.IO

Project: Discharge Module

I had direct ownership of the discharge module. A big part of my work was frequent visits to hospitals to observe how staff actually used their current (paper-based) processes: how discharge paperwork moved between wards and admin, where forms got stuck, and where communication broke down.

The goal wasn't to digitize the paper forms—it was to understand the real workflow and design something better. That meant:

• Reducing handoffs and duplicate entry. Paper discharge required nurses to fill out forms, walk them to admin, wait for signatures, and repeat. We consolidated this into a single flow where each role saw only what they needed to act on.
• Making status visible. Staff could see where a discharge was in the process without chasing people down the hall.
• Keeping it simple for non-technical users. Nurses, clerks, and admin staff aren't developers. The UI had to use familiar language, minimal steps, and mirror their mental model of the process.

Project: Lab Module

I also owned the lab module, applying the same approach: observe the existing workflow, identify bottlenecks, and design a digital system that fits how people actually work.

In the paper-based system, lab requests and results were siloed. Doctors would write requests on paper, runners would carry them to the lab, and results would come back the same way—sometimes hours later, sometimes lost.

The lab module addressed this by:

• Real-time request and result tracking. Doctors could submit requests digitally; lab staff could update status and results; everyone could see progress without phone calls or runners.
• Integration with patient records. Results flowed directly into the patient's file, reducing transcription errors and making history accessible.
• Role-based visibility. Lab staff saw their queue; doctors saw their patients' pending and completed tests; admin saw throughput and bottlenecks.

Project: Vital Signs Monitor (IoT)

This was an R&D project that resulted in a published IEEE paper: "A Cost-Effective Solution for Real Time Remote Monitoring of Vital Signs in Patients" (2021). I'm a co-author on the paper.

The goal was to build a low-cost IoT system for real-time remote monitoring of patients' vital signs—specifically heart rate and SpO2—designed for resource-limited settings in developing countries. The system used a four-layer architecture:

1. Sensing layer — Wearable wrist unit with sensors
2. Data processing layer — Signal processing and validation
3. Networking layer — Socket-based communication to transmit data
4. Applications layer — Web-based GUI for healthcare providers

My role

I worked primarily on the software side, but I also wrote the firmware code on the hardware that established the socket connection between the IoT device and the software layer. This was the critical bridge—without reliable socket communication, the system couldn't function.

On the software side, I owned everything:

• Web-based GUI for nurses and physicians to monitor patients remotely
• Real-time data processing and display of vital signs
• Alert systems for abnormal readings
• Integration with the HMS so vital signs flowed into the broader patient record

Tech: Arduino, C++, React.js, Node.js, MongoDB, Socket.IO

Outcome

The system worked as a prototype and successfully integrated with our HMS. However, it was never deployed in a clinical setting because the hardware wasn't approved for hospital use—it remained in the research phase. The outcome was the published paper and a working proof-of-concept, not a production deployment.

This is a common reality in healthcare R&D: technical feasibility doesn't guarantee regulatory or institutional acceptance. The project demonstrated that low-cost remote monitoring was achievable; turning it into a clinical product would have required a different kind of effort (certifications, partnerships, trials) that was outside our scope at the time.

Learnings

Hospital visits changed everything. Designing from assumptions or generic "hospital workflows" would have missed how different each place was. Watching paper-based processes in action—seeing where forms got stuck, where people improvised, where communication broke down—directly shaped the discharge and lab modules.

Simplicity for non-technical users is non-negotiable. The system had to be usable by staff who weren't technical. That meant clear labels, minimal steps, and workflows that mirrored their mental model. The difference between adoption and workaround is often just a few clicks.

Microservices gave us flexibility, but required discipline. Splitting into services let us customize per hospital and evolve modules independently. But it also meant more coordination overhead—clear ownership, well-defined APIs, and careful thinking about where data lived.

R&D and production are different games. The vital signs monitor was technically successful but never deployed. Building something that works in a lab is one challenge; getting it approved, trusted, and adopted in a hospital is another. Both are valuable experiences, but they require different skills and timelines.

Related

• Hospital Management System — Overview of the full HMS
• Discharge Module — More detail on the discharge workflow
• Vital Sign Monitor — Project page with tech stack
• IEEE Paper — "A Cost-Effective Solution for Real Time Remote Monitoring of Vital Signs in Patients"