Backend Lead

Key Responsibilities

  • Own the backend of the platform end to end — the clinical record, orders, laboratory and radiology, billing and insurance, pharmacy and stock, and the services that hold them together
  • Set the service and data design for these modules, and review every change that touches a clinical record, a price, a ledger or a claim
  • Lead the backend engineers: set the standard, review their work in progress rather than only at the end, and keep the codebase something a new engineer can be productive in within a fortnight
  • Turn what a hospital actually does into a model the software can hold, working from real documents — a tariff sheet, a rate contract, a scheme circular — which will be inconsistent, hand-maintained and full of exceptions
  • Own the Application Programming Interface (API) contracts the web and mobile applications consume, and keep them stable enough to be relied on

Correctness You Can Prove

  • Make every write auditable and attributable: who did it, when, and what it replaced — corrections by reversal, never by silent overwrite
  • Hold the line on money and stock, where a rounding error is a real rupee in a real hospital's accounts and a stock count that drifts is medicine that cannot be found — Decimal for every amount, never a float
  • Make clinical safety checks real: allergy and interaction checks, dose limits by age and weight, critical values that must reach a human, and alerts a doctor cannot silently lose
  • Build multi-tenancy in from the first table — one platform serving many hospitals, with no path by which one can see another's data
  • Own the reconciliation story: what the cashier counted, what the system says and what the day-end report shows must agree, and any difference must be explainable

Interoperability and Standards

  • Own the interoperability strategy: Fast Healthcare Interoperability Resources (FHIR) R4 as the façade the outside world reads and writes, over an internal model designed for how hospitals actually run
  • Deliver Ayushman Bharat Digital Mission (ABDM) compliance — Ayushman Bharat Health Account (ABHA) creation and linking, consent, and health information exchange
  • Make sure the platform speaks to the equipment that already exists in the hospital: Health Level Seven (HL7) version 2 messages from laboratory analysers, and Digital Imaging and Communications in Medicine (DICOM) worklists for imaging
  • Use standard terminologies where they earn their place — Logical Observation Identifiers Names and Codes (LOINC), Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT), International Classification of Diseases (ICD-10) — and map to them rather than making clinicians work in them
  • Treat integration failure as normal: retries, dead letters, replay, and a system that keeps working when the hospital's internet does not

Delivery Oversight

  • Keep the backlog for the backend sequenced and estimated honestly, and flag slippage the week it becomes likely
  • Review pull requests with an eye on the data as much as the code — a migration that silently rounds is worse than a bug that crashes
  • Own the automated tests around money, stock and clinical safety; these are the paths where tests are mandatory rather than encouraged
  • Own the operational side too: what happens at three in the morning when something fails, and how anyone finds out

Key Skills and Technical Knowledge

Our stack — what you will work in day to day

  • Language — Python 3.12 with type hints everywhere, and Structured Query Language (SQL)
  • Framework — FastAPI, with Pydantic v2 for validation and serialisation
  • Database access — SQLAlchemy 2.0 in async mode, with Alembic for migrations
  • Typing, enforced — mypy or Pyright in strict mode, failing the build. Python's type hints are optional at runtime, so we make them non-optional in continuous integration
  • Database — PostgreSQL 16, with migrations, indexes and query plans. Managed Postgres on whichever cloud a hospital requires: Amazon Relational Database Service (RDS) or Aurora, Google Cloud SQL or AlloyDB, or Azure Database for PostgreSQL
  • Caching — Redis (Amazon ElastiCache, Google Memorystore or Azure Cache for Redis)
  • Background work and events — a task queue with idempotent consumers, dead-letter handling and replay: Celery, Dramatiq, arq or a PostgreSQL-backed queue, on a broker we can run ourselves rather than one that ties us to a single cloud
  • Object storage — behind one interface, with a driver per provider: Amazon Simple Storage Service (S3), Google Cloud Storage or Azure Blob Storage
  • Containers and cloud — Docker everywhere, which is what makes the platform portable across Amazon Web Services (AWS), Google Cloud Platform (GCP) and Microsoft Azure: Amazon Elastic Container Service (ECS) Fargate, Google Cloud Run, Azure Container Apps, or Kubernetes where a customer requires it
  • Infrastructure as code — Terraform, with a module per cloud and one pipeline
  • Delivery — GitHub Actions, trunk-based development, migrations only through version control
  • Testing — pytest and pytest-asyncio, and Playwright for Application Programming Interface (API) and end-to-end journeys
  • API contract — FastAPI generates the OpenAPI schema, and the TypeScript client the web and mobile applications use is generated from it, so the contract cannot quietly drift
  • Healthcare standards — Fast Healthcare Interoperability Resources (FHIR) R4, Health Level Seven (HL7) version 2 over Minimal Lower Layer Protocol (MLLP), Logical Observation Identifiers Names and Codes (LOINC), Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT), International Classification of Diseases (ICD-10), Digital Imaging and Communications in Medicine (DICOM), Ayushman Bharat Digital Mission (ABDM) and Ayushman Bharat Health Account (ABHA)

Valuable to have as well

  • The Python healthcare libraries: fhir.resources for FHIR R4 models, hl7apy or python-hl7 for version 2 messaging, pydicom for imaging
  • Machine learning and Artificial Intelligence (AI) work in Python — the AI services share this language, which is one of the reasons we chose it
  • Experience writing code that runs on more than one cloud, and a view on where an abstraction is worth it and where it is not
  • Open-source FHIR servers such as HAPI FHIR or Medplum
  • Indian Goods and Services Tax (GST), Third Party Administrator (TPA) and insurance claims, or Pradhan Mantri Jan Arogya Yojana (PMJAY)
  • On-premise or hybrid deployment inside a hospital's own network
  • Multi-tenant Software as a Service (SaaS) architecture, and data residency across countries

If your background is Java, .NET, Node or Go

  • We build in Python on FastAPI, and that is what you would write here
  • If you come from Django or Flask, FastAPI will feel immediately familiar — the difference is async, Pydantic and generated OpenAPI documentation
  • Java, Spring Boot, Kotlin, C#, .NET, Go, Scala, Ruby on Rails or Node.js and TypeScript with strong service, API and relational database experience transfers directly. What does not transfer is loose typing habits and an aversion to SQL
  • We expect you productive in Python within the first month, and we will give you that month

What You'll Bring

  • Six or more years building backend services in production, with at least two setting direction for other engineers
  • Strong Python, used with type hints and tested — or another typed backend language with the willingness to work in Python from day one
  • Deep relational database skill: schema design, transactions and isolation levels, indexes, and the ability to read a query plan and act on it
  • Have owned a system where correctness is auditable after the fact — healthcare, billing, payments, accounting, insurance, lending or similar
  • Have modelled a domain that resisted simple modelling, and can explain the trade-offs you took and the ones you regret
  • Comfortable with event-driven work: queues, at-least-once delivery, idempotency, ordering and replay
  • Able to design an API another team consumes, and hold its contract stable
  • Able to explain a technical constraint to a hospital accountant, and a hospital's billing rule to an engineer who has never seen a hospital bill
  • Willing to sit at a billing counter or beside a doctor for a day and come back with the questions the specification missed
  • Preferred experience with healthcare interoperability — FHIR, HL7 version 2, LOINC, SNOMED CT, ABDM or another national health data exchange
  • Preferred experience with Indian Goods and Services Tax (GST), insurance and Third Party Administrator (TPA) claims, pharmacy or retail inventory with batch and expiry, or a system migrated off a legacy database