What happens when a mission-critical government system handling sensitive human records and complex rehabilitation pathways still relies on fragmented paper records and inconsistent local practices?
For public-sector digital transformation, the biggest risk is rarely just technology. It is the gap between how a process is supposed to work, how it actually works on the ground, and what the software is expected to deliver.
That was the reality we faced when building the Smart Rehabilitation Facility Management System (RMS) for our client. The project involved 74 legally bound functions, a 12-person team, and a 14+ month project lifecycle with a 4-month accelerated delivery window. The pressure increased further when the client moved the release deadline from mid-September to August 31, 2026.
Project goal: Establish a unified RMS platform that connects three administrative levels, standardizes workflows, and creates a single source of truth for national oversight.
About our client
Our client operates a nationwide addiction rehabilitation management network spanning three administrative levels: treatment centers (CSCN) that manage residents and daily records, provincial authorities (PC04) that monitor operations within their regions, and a national bureau (C04) that oversees the network as a whole.
The organization was moving away from paper-based records and fragmented processes toward a connected digital way of managing rehabilitation. The goal was to give staff a consistent way to record and manage information throughout the treatment journey, while enabling higher-level authorities to monitor operations and receive standardized reports.
The RMS platform is therefore more than an internal record-keeping tool. It provides the digital foundation connecting facility-level operations with provincial and national management, while ensuring sensitive information is handled according to each user’s role and access level.
Here’s how it works in diagram:
| Industry | Government / Public Sector |
| Country | Vietnam |
| Service | Software Delivery (Website development) |
Business context & challenges
Prior to our engagement, operations across facilities were largely manual. Resident files, medical milestones and legal records were managed through physical binders.
The consequences went beyond operational inefficiency. Official administrative forms had to follow strict government formats, meaning a misplaced record or incorrect information could affect legal filings or delay court-ordered releases.
At the same time, provincial and national authorities lacked real-time visibility into facility operations. Even after an initial year of soft digitization, workflows remained inconsistent across facilities, while local staff needed an interface that felt familiar rather than disruptive.
This created three connected challenges:
| Existing issue | Business impact | At national level |
|---|---|---|
| Paper-based records | Legal and compliance exposure | Operational delays and administrative risk |
| Siloed operations | Limited real-time national visibility | poor planning -> inefficient resource allocation -> potential resource waste / higher operating costs. |
| Different local practices | Inconsistent workflows and adoption challenges | Inconsistent management across facilities |
At this scale, these were no longer isolated operational issues. It will move from facilities to provincial and national authorities. Without a unified system, it becomes harder to maintain consistent processes, monitor operations, and make timely decisions across the rehabilitation network.
Synodus therefore needed to build a unified system that could connect all three levels, standardize core workflows, and give authorities a reliable foundation for managing rehabilitation operations at scale.
Project workflow
The project followed a four-stage roadmap across its 14+ month lifecycle, from domain discovery and system design to development, deployment and ongoing evolution.
| Phase | Timeframe | Scope |
|---|---|---|
| Phase 1: Discover | Month 1-2 | Map workflows, moddel domains, build prototypes |
| Phase 2: Design | Month 3-4 | Define architecture and build the technical foundation |
| Phase 3: Build & deliver | 4-month execution | Deliver 74 core functions against the August 31 deadline |
| Phase 4: Deploy & evolve | Post-August 2026 | Roll out, optimize and expand |
The first two phases established the domain and technical foundation. The third focused on delivering the core functions within the accelerated deadline, while the fourth covers deployment, continuous optimization and future feature expansion.
Synodus designed RMS as a centralized platform covering key rehabilitation operations, from resident records and treatment progress to medical tracking, legal procedures, administrative forms and management dashboards across CSCN, PC04 and C04.
Underneath the platform is a modular microservices architecture with 11 independent services and isolated databases, connected through gRPC and Kafka. This structure keeps sensitive data separated by business domain while allowing information to move across the system. A dedicated PM5 master data layer provides standardized reference data across services.
Rather than simply digitizing existing paperwork, the solution was designed to preserve familiar frontline workflows while creating a scalable digital foundation. Existing government forms were translated into digital interfaces, while search, caching and real-time communication capabilities support faster access to operational data as the system grows.
The process of making it works
1. Let the domain shape the architecture
Before defining services, the team first broke real rehabilitation operations into entities, lifecycles, relationships, business rules, and edge cases. The BA team worked one Sprint ahead of Development, using a standardized SRS and clickable prototypes to turn evolving requirements into a shared delivery baseline.
This domain model then informed the service boundaries. Rather than building RMS around one tightly coupled application, Synodus structured it into 11 independent NestJS services, each running as a separate process with its own PostgreSQL database.
The services had no cross-imports. Each domain therefore owned its data and remained independently maintainable, reducing the risk of changes in one area cascading across the platform.
2. Separate data ownership from system communication
Once the services were isolated, the next challenge was keeping them connected.
Synodus used gRPC for synchronous operations where a service needed an immediate response, while Kafka handled asynchronous data distribution between services. The same principle was applied to master data: PM5 owns the reference data, while other services consume standardized updates through Kafka rather than accessing PM5’s database directly.
This allowed RMS to maintain clear data ownership without sacrificing the connected workflows required across CSCN, PC04, and C04.
3. Design for the way the platform would be used
RMS needed to work with thousands of resident profiles and operational records, so performance could not depend entirely on transactional database queries.
The team introduced Elasticsearch for search and Redis for caching, while Socket.IO with a Redis adapter supported real-time updates across multiple application nodes. BullMQ handled background jobs so heavier processing did not have to block frontline workflows.
These decisions helped keep the platform responsive as operational data grew, with query response times reaching under 200ms across thousands of profiles.
Outcomes
By August 31, 2026, the team had delivered remarkable results:
| Before | After |
|---|---|
| Paper-based records and fragmented workflows | 74 core functions digitized in one rehabilitation management system |
| Disconnected information across CSCN, PC04, and C04 | CSCN → PC04 → C04 connected through standardized digital workflows |
| Different local practices and manual government forms | Standardized digital forms & reports |
| Growing human records and operational data | Digital statutory forms and <200ms query response across thousands of profiles |
The impact was also reflected in our client’s experience of the delivery:
This was a complex system with many interconnected processes and strict requirements. But the team handled that complexity well because they took the time to understand our operational process and translated them into strong technical solutions while keeping the implementation focused on our real-world needs.
Mr. Q.B, Staff Officer & Digital Transformation Lead, from the Capital’s Rehabilitation Center No. 4
What’s next?
We are now standardizing on-site workflow mapping and legal document harvesting as mandatory discovery steps for public-sector initiatives before software architecture begins.
The project’s effort telemetry will also be used to establish historical estimation baselines for future complex enterprise projects, while the structured RMS data opens the way for predictive analytics around post-release reintegration and treatment-plan optimization.
For a system built around sensitive records, legally defined workflows, and multiple levels of government, the transformation required a clearer understanding of the domain, tighter control of scope, and enough delivery data to make difficult project decisions visible.
If you are looking for a partner for a complex, high-stakes project, we can help.
