Healthcare · US hospitals
Synzi
Adding a new patient language became a content edit instead of a code release.
- Role
- Backend lead
- Duration
- 14 months
- Team
- 2 from our side
- Sector
- US hospitals
The situation
Synzi connects US hospitals with patients through video, secure messaging, and live human translators. A large share of those patients do not speak English, and the clinical message templates — appointment reminders, discharge instructions, medication follow-ups — only existed in two.
We joined as backend lead on the microservices behind messaging and translation.
The problem
Languages were compiled into the templates. Every new one meant a code change, a QA pass, and a release — so a hospital branch asking for Haitian Creole waited on an engineering roadmap it had no visibility into.
Worse, branches within the same hospital network needed different wording for the same message. The data model had nowhere to put that.
What we built
- 01
Translations became data, not code
A translation record keyed by template, branch, and locale, with a fallback chain up to the network default. Unlimited languages, no deploy.
- 02
An editor the clinical team could use
Side-by-side source and target with variable validation, so a missing merge field is caught before a patient sees an empty bracket.
- 03
Flask microservices, isolated per concern
Messaging, translation, and scheduling deploy independently. A translation change cannot take down a video call.
- 04
An audit trail on every clinical string
Who changed which wording, when, and what the patient actually received. Non-negotiable in a regulated environment.
The outcome
Message templates went from 2 fixed languages to unlimited per-branch translations.
Adding a patient language stopped being an engineering ticket and became a content edit a clinical operations lead could make the same afternoon.