Building a medical tourism platform on one backend, with patient consent enforced in code
MedCare360 is a medical tourism platform for patients travelling to India for serious treatment, carrying them from researching a condition and comparing hospitals through to appointments, prescriptions and the handover back home.
Digital Back Office did not just build what we asked for, they built the product we actually needed. Their team took a very broad idea and turned it into four working surfaces, and what impressed us most was the discipline around patient data: every access rule, every consent boundary, every AI answer was designed to be safe first and clever second. It has been a genuine partnership, not a hand-off.
Problem
A patient weighing treatment abroad researches the condition on one site, checks hospital reviews on another, gets a cost estimate in a messaging thread and asks about insurance somewhere else again. Nothing carries over and nobody owns the whole picture. MedCare360 came to us with no existing system to extend and no separate vendor for any layer, so the platform had to be designed and built end to end.
Solution
We designed and built a single platform with four surfaces on one API and one database, so the data is shared but the experience is not: reassuring on the public site, calm on the patient portal, dense and fast on the doctor portal, and operational in the internal CRM. One token system with three density presets keeps them recognisably siblings without making the clinical tool feel like a consumer app.
Results
MedCare360 now holds the full patient journey in one place, from researching a condition to reading a prescription after treatment, running on production cloud infrastructure the client can reproduce from code.
Research, trust, cost, insurance and visa logistics each lived in a different tool, and most platforms in the space cover one or two of those stages and then drop the patient, so the whole journey had to be held in a single product.
Patients arrived carrying prescriptions, scans and discharge summaries with no reliable way to share them ahead of time with a doctor they had not met, or to take them home afterwards in a form their own GP could use.
Handing a doctor a patient's scans could not be governed by a written policy; it had to be checked by the system on every request, including every AI retrieval, and revocable by the patient instantly.
Patients wanted plain answers about their own health and doctors wanted summaries instead of a file to read, but an AI that leaks one patient's data into another's answer is a liability rather than a feature.
We mapped the real patient journey, discover, decide, plan, travel, treat and recover, and identified where the existing experience broke. That map is what produced a four-surface architecture rather than one monolithic application.
A single design brief set colour, type, spacing, radius and motion tokens along with the reasoning for three density presets, written as a source of truth so engineers could build new screens consistently without a designer in the loop for every variation.
The database schema, migration discipline, API structure and authentication model for three separate principals, internal staff, patients and doctors, were built before any feature work, so nothing later had to be retrofitted onto the wrong foundation.
The public site and CMS came first because they define the catalog everything else depends on, then the patient portal, then the doctor portal, then the consent model connecting them, then the AI layer on top of the data all of that produced.
Environments were provisioned with Terraform and shipped by automated pipelines from the beginning, so production was never a hand-configured artefact that only one person understood.
A single authorization resolver decides what any doctor may see for any patient, and every read passes through it. Patients can also share records through a read-only link scoped to chosen document types and set to expire, and revoke either grant in one action.
Retrieval is hybrid, filtered to a single patient inside the database query itself, and every generated answer is fully buffered and validated for citation integrity and scope leakage before a word reaches the screen.
Approved content is rendered once into a snapshot stored alongside the record, so public listings read that snapshot with no joins, and cache invalidation is triggered by the approval itself.
An AI-assisted scraper builds and updates hundreds of hospitals and thousands of doctors through the same API the CRM uses, so acquired records still pass editorial approval before they go live.
Migrations run as a gated step inside the deployment; if one fails the new container never starts and the platform rolls back on its own, and production changes require a human to review a plan and apply that exact plan.
From AI strategy and automation to custom machine learning applications, we create solutions that help organizations innovate faster, operate smarter, and scale with confidence.
Complete the form below, and we'll respond within 24 hours.
We are based in UK, but we can support your business in any time zone, we work 24x7.
Difficult is done at once, the impossible takes a bit longer. If it is possible, consider it done. The impossible, it will be done!
We provide full spectrum of enterprise data services.
We understand that every business is different. We work on both fixed cost and time and material basis. We can also provide consultants, who can work alongside your existing team.
