The brief: a clinic and diagnostic-lab manager

You have learnt Django module by module — models, the ORM in depth, views, auth, APIs, concurrency, testing, architecture, deployment. The capstone is where it stops being a list of features and becomes the way you build one real thing, end to end. Over five lessons you will pull the whole course together into Nidaan, a clinic and diagnostic-lab management system — the application the examples have been building towards — and finish it to a standard you could actually put in front of a clinic. This lesson is the brief: what Nidaan is, what it must do, and the standard it is built to.

What we are building

Nidaan is the software a small clinic or diagnostic lab runs its day on. Real, unglamorous, and exactly the kind of database-backed application Django exists for:

• Patients — records: name, contact, city, date of birth, history.
• Doctors — the clinicians, their specialisations.
• Appointments — a patient booked with a doctor at a time, with a status (booked → done → cancelled) and a fee.
• Test reports — diagnostic results belonging to a patient (and often an appointment), including uploaded scans.
• Billing — fees and payments.

Around that data, Nidaan needs the things every real clinic system needs: staff manage it through the admin and custom views; patients can be given a read-only API for their own records; sensitive data is protected so one patient never sees another's reports; reminders go out for tomorrow's appointments; and the whole thing is tested, hardened against concurrency, and deployed over HTTPS.

Why a clinic system is the right capstone

A clinic system exercises Django's whole surface in a way a toy project cannot, and it does so with real stakes that make the lessons land:

• Rich relational data — patients, doctors, appointments, reports, payments, all related — so the ORM, relationships, and query optimisation matter.
• The admin as a real operational tool — clinic staff genuinely run the back office through it, which is Django's headline strength.
• Sensitive data — medical and financial records — so authentication, permissions and object-level access are not academic; a leak is a real harm.
• Reporting — fees collected, appointments per doctor, tests pending — so aggregation and annotation earn their place.
• An API — a patient-facing app wants their own appointments and reports, so DRF, filtering and API auth apply.
• Background and scheduled work — appointment reminders, nightly report generation — so the concurrency module is used, not just read.

Every module of the course has a job in Nidaan, which is the point of a capstone: to build something whole enough that the pieces have to fit together.

The requirements — the standard it is built to

This is not "make it work". It is "build it the way the whole course said to". The requirements encode that, and each traces to a module:

1. The data model is correct and honest — right field types, right relationships, right on_delete choices, and database constraints enforcing invariants (a fee is never negative; no double-booking).
2. Business logic lives in the right layer — on models and services, not crammed in views; queries named on managers; views thin.
3. Queries are efficient — no N+1 on any list; reports use aggregation, not Python loops; indexes where the data is filtered.
4. Access is properly controlled — staff roles via groups and permissions; patients see only their own records (object-level access); sensitive uploads are not at public URLs.
5. Concurrency is handled — money and status changes use atomic transactions and avoid the lost-update race; slow and scheduled work runs in background tasks.
6. It is tested — the risky paths (money, permissions, failures) have tests; the API's contract is pinned.
7. It is deployable — DEBUG=False, HTTPS, PostgreSQL, static/media handled, check --deploy clean.

The test for "done" is the same one the whole course has used: could this be handed to a real clinic, and would it hold up?

How the five lessons go

We build in the order a careful engineer works — model first, then the core, then the API and access, then hardening and launch:

• Design (next lesson): model the whole clinic domain in types and relationships before writing feature code — the entities, their relationships, the constraints that keep the data honest. Get the foundation right, because everything sits on it.
• Build: the core flows — booking and completing appointments, recording test reports — with the business logic in the right layer and the queries efficient.
• API and access: expose a patient-facing DRF API, and enforce the layered access control (authenticated → permitted → own-records-only) that sensitive medical data demands.
• Hardening: make it concurrency-safe (atomic money, no lost updates), test the risky paths, and take it through the deployment checklist to a live, HTTPS, PostgreSQL deployment.

Model-first is not ceremony — in a database-backed app the data model is the foundation, and getting it right makes the features follow. That is the lesson the whole capstone is meant to land.

Before you start

You have the Nidaan project from following the course — the patients (and related) apps, the models, views, admin and API built lesson by lesson. If you have been building along, you are most of the way there; the capstone assembles the remaining pieces and raises the whole thing to the finished standard. If you have only read, now is the time to build: create the project, and over these five lessons construct Nidaan for real, running each part as you go (the course's whole discipline is that code is run, not just written). The next lesson starts where every good Django project starts — the data model.

Check your work

What Nidaan is. A clinic and diagnostic-lab manager: patients, doctors, appointments, test reports, billing — plus admin, a patient API, protected sensitive data, reminders, tests, and a real deployment.

Why a clinic system. It exercises Django's whole surface with real stakes — rich relational data, the admin as an ops tool, sensitive data (permissions matter), reporting (aggregation), an API, and background work.

The seven requirements. Correct/honest data model with constraints; logic in the right layer; efficient queries; proper (including object-level) access control; concurrency handled; tested risky paths; deployable (check --deploy clean). Each traces to a module.

Why model-first. In a database-backed app the data model is the foundation — getting it right makes the features follow.

The build order. Design → build → API and access → hardening/deploy.

Practice

1. List Nidaan's core entities and, for each, one sentence on what it holds and which module its handling comes from.
2. For each of the seven requirements, name the course module it comes from — a map of what the capstone exercises.
3. Sketch on paper the entities and their relationships (patient-appointment-doctor-report-payment) before reading the design lesson; you will compare.
4. Decide which parts of Nidaan belong in the admin (staff) versus custom views/API (patients) — and why.
5. Write down, for Nidaan, one concrete example each of: a place N+1 could hide, a place the lost-update race could occur, and a piece of sensitive data needing object-level access.
6. If you have built along, list what you already have versus what the capstone still needs to assemble.

Official documentation

• Django — Writing your first app (tutorial) — A refresher on assembling a Django project end to end.
• Django — Full documentation index — The reference for every piece Nidaan uses.
• Open-source Django projects — Real Django applications to learn structure from.

Next: designing the domain model.