Skip to main content

Linnoedge

Linnoedge
Back to Works

Works — System Development

It ran on Salesforce for years.
Then came the day to build
something they actually owned.

Patient & Physician Management System — Full Rebuild for a Pharmaceutical Company

  • Healthcare & Pharma
  • React.js
  • Nest.js
  • Salesforce Migration
  • FAX API Integration
Salesforce-dependent (licensing costs, customization ceiling)
Fully owned, on-premises system

5 yrs

On-premises Server
Registration Staff
Back Office
FAX Operations

5 yrs

of patient data
migrated from Salesforce

4 core

functions rebuilt
in-house, Salesforce-free

4 mo

from requirements
to production release

Change

Before → After, in numbers

BeforeAfter
Patient data managementSalesforce-dependent (licensing costs, customization ceiling)→Fully owned, on-premises system
Master data syncManual CSV operations by staff→Automated SFTP transfer on schedule
FAX operationsManual receipt confirmation in a separate system→API-integrated, handled within the system
Report generationDependent on Salesforce reporting module→In-house implementation, fully customizable
UI consistencyDifferent visual treatment per feature→Unified design system (MUI) across all screens

"We thought the floor would stop without Salesforce. It was the opposite — once it was gone, we could finally see all the places where our workflows had been bending around its constraints. The moment FAX confirmation came inside the system, we realized: this is what we'd needed all along."

IT Lead

Pharmaceutical company, Japan — patient management operations

Context

The system ran the workflow.
Or was it the other way around?

Salesforce is a common choice for patient registration and management in the pharmaceutical and healthcare industry. It's marketed on its flexibility. But at one company I worked with, something had quietly reversed: instead of the system adapting to the clinical workflow, the clinical workflow had been bending around the system's constraints for years.

Licensing costs that climbed with every new user. A UI that couldn't match the company's brand guidelines. Customization ceilings that kept getting hit. The gap between how the floor actually worked and how the system expected it to work had been widening for years — and everyone had just accepted it.

And then there was FAX. In healthcare in Japan, paper and digital systems run in parallel. Manual bridging between the two — receiving a fax, confirming receipt, logging it somewhere — was still being done by hand. That wasn't unusual. But it was fixable.

Challenge

Features not in the spec
were running in production

The project started with requirements gathering. That's when we found something unexpected.

"There were features the team used every day that weren't documented anywhere."

The existing Salesforce environment had a FAX receipt confirmation flow that appeared in no official requirements document. It had grown organically over years of live operation — someone needed it, someone built a workaround, and then the workaround became the process. Not a single line of documentation, but people were using it every day to get their work done.

The new system had to replicate what was visible. It also had to replicate what wasn't.

Fig. 1 Bringing FAX receipt confirmation into the system
An undocumented FAX receipt confirmation flowGrew out of live operation; people used it every day
Connect an external FAX API serviceFAX send and receive is wired into the system
Build the confirmation flow into the systemStaff confirm faxes without switching screens

Craft

The engineering decisions behind the rebuild

The direction was simple: get out of Salesforce entirely. No external cloud dependencies either.

Patient data would live on the client's own on-premises server, fully under their control. We'd rebuild from scratch in React.js and Nest.js.

But the hardest problem came before any of the technology. It was figuring out how to encode workflows that existed nowhere in writing.

Full rebuild vs. Salesforce extension

There was a version of this project where we went deeper into Salesforce customization instead. We considered it. But working through the requirements, that path would have meant staying inside exactly the constraints the client wanted to escape. The whole point was to remove the ceiling. So we built from scratch.

AI-accelerated development for a high screen-count project

This project had a lot of screens. We used AI tools to generate UI scaffolding — producing base layouts that we then refined and tailored to the actual workflows. There was a second AI application too: a colleague at our partner firm built a custom RAG tool (officebrain) that made the project's spec documents searchable by AI. The time previously spent hunting through documentation disappeared.

FAX + API: bridging paper culture and digital systems

We integrated FAX send/receive with an external API service and built the receipt confirmation flow directly into the system. Fitting an entire paper-based communication culture inside a digital product — while accounting for the specific compliance constraints of the healthcare industry — was the most technically complex part of the project. Honestly, this is where most of the clock time went.

Fig. 2 How the new system is put together
Patient data held in Salesforce5 years of data migrated
New system (React.js + Nest.js)Built from scratch; one design system (MUI) across all screens
The client's on-premises serverPatient data fully under their control, no external cloud
Connections to the outsideMaster data syncs over SFTP on a schedule; FAX runs through an external API
Registration Staff

Screens designed around
how the floor actually works

The entire input interface was rebuilt from scratch. Rather than mirroring what Salesforce had shown, we mapped the actual workflow on the floor and designed around that. Patient registration, physician assignment, and contact management all flow sequentially in one continuous process — no switching between screens or systems.

Back Office

Manual CSV transfers
replaced with scheduled automation

Master data sync via CSV had been a manual task. We automated it over SFTP on a schedule — send, receive, confirm, done. Report generation also moved out of Salesforce's reporting module and into our own implementation, giving the system administrators direct control over format and layout without needing developer involvement.

FAX Operations

The undocumented workflow
is finally visible in the system

FAX send/receive is now connected to an external API, and the receipt confirmation flow lives inside the system. Staff no longer toggle between the main system and a separate Salesforce screen to confirm faxes. The workflow that existed nowhere in the documentation is now — for the first time — visible, trackable, and part of the official process.

Tech Stack

Technologies used

  • React.js
  • Nest.js
  • Material UI (MUI)
  • SFTP Integration
  • FAX External API
  • On-premises Server
  • AI Dev Support (RAG tool + UI generation)

Built something similar to what you need?

Let's talk about your version of this.

30 minutes. No cost. Comes with a written next-step summary.