Backend Lead

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 contrac