Physician record review

A healthcare company running chronic care management programs needed a second-opinion service it could bill for. Its principal AI services architect, Frank Robles, in the role since January 2026, is building the backend himself: the clinical reviewer portal and the billing service.

Here is the model. A treating practitioner, the clinician who sees the patient, sends the patient's record to an independent consulting practitioner. The consultant is a physician outside the treating relationship.

The consulting physician reads the records and an AI clinical summary of them, decides whether they agree or disagree with the prior clinical assessment, and writes a review note. The note goes back to the treating practitioner, and the review is billable.

• The review queue. Records waiting for a consulting physician, in one place.
• The review timer. Reviews are designed around a minimum of five minutes and a target of eight.
• Notes. The physician's agreement or disagreement and the review note, captured against the record.
• The return path. The finished review goes back to the treating practitioner who sent it.
• The billing report. Every completed review lands in a report the billing team can work from.

A second-opinion service lives or dies on two numbers: how long a review takes and whether every review gets billed. A review done too fast is hard to defend. A review that never reaches the billing report is work given away.

So the platform treats both as part of the product. The timer is built into the review screen, sized to a five-minute floor and an eight-minute target. The billing report reads from the same system of record the reviews are written to, so there is no second spreadsheet to reconcile at month end.

The AI clinical summary is there to get the physician to the point faster. The judgment, agree or disagree, and the note stay with the physician.

Django was chosen over FastAPI because this portal's first-class requirements are operations and admin controls, compliance controls, operational monitoring and billing reporting. Django brings an admin, an authentication system and a mature permissions model on day one, which is where most of that work lives.

PostgreSQL is the system of record for transactional and reportable data: the reviews, the timings, the billing. A document database serves as the clinical read model. Large payloads go to object storage under a business associate agreement. Celery and Redis run the background work, and the whole thing runs on Kubernetes from container images in a registry.

Python, Django 5.2 and Django REST Framework. The front end is Django templates and Tailwind: one repository and one deploy, and designed so a front-end designer can work in it without learning a second application.

• Python
• Django 5.2
• Django REST Framework
• PostgreSQL
• Document database
• Celery
• Redis
• Kubernetes
• Tailwind

• Its own authentication. Django-native, not bolted on from a third party.
• Staff join by invitation. An emailed link that expires and works once. The user sets their own password; nobody sends one.
• Two-factor authentication by QR code and passcode. Optional at first, with a per-account override.
• A two-tier admin. A formatted Operations Admin sits in front of the real Django admin. Staff do their work in the first; the second is kept for the few who need it.
• Four groups. Superusers, normal users, admin and billing.
• Treating practitioners are kept outside. They get their own screens in phase 2 and never see the internal operations admin.

Frank is writing the backend himself, from a blank slate, rather than extending the first portal. The stack, the permission groups and the phase 2 boundary that keeps treating practitioners out of the operations admin are his decisions. In a billable clinical service the access model and the billing report are the parts that get audited.