Pyaar Dental

Pyaar Dental

Operated clinical annotation for dental AI. Several dentists read the same case in a stock open-source viewer, a clinical lead adjudicates their reads, and the approved result becomes a validation dataset.

The gap

Dental AI companies need validated, adjudicated datasets from real clinicians. The secure viewer and the storage already exist: Kitware ships VolView and Girder for exactly that. What is missing between "platform" and "submission-ready dataset" is the operated layer: recruiting and credentialing the clinicians, running the multi-rater reads, adjudicating disagreement, and packaging a result that survives regulatory review. Pyaar Dental is that layer, plus the loop it runs on.

Dental first because it is the lowest-friction wedge: cone-beam CT and 2D radiographs are everywhere, the AI use cases are concrete (caries, tooth detection, 2D-to-3D, orthognathic and craniofacial analysis), and contract dentists are recruitable and scalable in a way hospital staff are not.

The full-service stack, one accountable partner

Positioning: Kitware sells the app and its software-side regulatory development. Nobody in that offering sells the labeled dataset or the annotation workforce. That is Pyaar Dental's lane. Complementary, not competitive.

The loop

1. Contract dentists log into the control plane and see their assigned cases.
2. Each opens the imaging in VolView, the stock viewer, opened with URL params, no fork.
3. Three to five dentists submit structured reads.
4. Reads aggregate per case, so multi-rater agreement falls out by construction.
5. A clinical annotation lead reviews the reads, adjudicates disagreement, and approves.
6. Approved reads become a packaged validation dataset, delivered to the customer.

The control plane

The dentists and the lead run the campaign from a single board: one row per case, one column per dentist's read status, an inter-rater Agreement %, and the clinical lead's sign-off. Each row deep-links a dentist into the app scoped to them (role-based, no shared login), so a case moves from assigned, to read by three to five dentists, to adjudicated, to approved, without anyone leaving the board. It is the operations layer a clinical annotation lead actually lives in.

Architecture

Two planes, cleanly split. The data plane is imaging (Kitware VolView plus object storage). The business plane is the campaign (the Pando Dental control plane in Notion). The pyaar-dental app is the thin bridge between them.

flowchart TD
  Lead["Clinical Annotation Lead"] -->|"assign, adjudicate, approve"| Board["Pando Dental board (Notion)"]
  Board -->|"per-dentist Annotate link"| App["pyaar-dental app (Next.js on Vercel)"]
  Dentists["Contract Dentists A / B / C"] -->|"open their case"| App
  App -->|"?urls= link, no fork"| VolView["VolView (stock Kitware viewer)"]
  VolView <-->|"stream volume"| Blob["Object storage (imaging + reads)"]
  App -->|"POST structured read"| Blob
  Board -->|"approved, adjudicated cases"| Dataset["Submission-ready validation dataset"]

• Business plane (Notion / Pando Dental). The board is the source of truth for the campaign: which case goes to whom, each dentist's status, agreement %, the lead's sign-off. It is a fork of a reusable Notion OS, so a new program is a rename, not a rebuild.
• App (Next.js on Vercel). A manifest-driven case list. Each case has one "Open in VolView" action and a structured read form. Role-scoped links (RBAC by URL) send each dentist to their own view. Stateless and thin by design.
• Data plane (VolView + object storage). Stock VolView loads DICOM / NIfTI / MHA via itk.wasm straight from a URL, so no fork. Imaging and reads live in object storage (Vercel Blob in the sandbox, the customer's own Girder or bucket in a real deployment, so PHI never leaves their host).
• Ground truth out. N dentists reading one case produce N records under one key, so multi-rater agreement is a query, not a rebuild. Approved cases become the delivered dataset.

What's live today

• Demo: the read → annotate → submit loop, running on Vercel.
• Dental cases: PreDentalSurgery / PostDentalSurgery, pre and post orthognathic-surgery cone-beam CT from the 3D Slicer "CBCT Dental Surgery" sample data, hosted by Kitware. Using Kitware's own dental sample is deliberate: it is also the exact orthognathic / craniofacial domain of Kitware's medical-computing lead.
• Viewer: stock VolView, linked not forked. It accepts ?urls=[…]&names=[…] and loads MHA / NIfTI / DICOM via itk.wasm.

Built to pass validation

Clearing a dental AI model is a testing problem, and the hardest inputs are exactly what this produces. It closes four gaps in the validation process:

• Reference standard (ground truth). Regulators expect a defined truth source. For detection tasks that means expert consensus plus image-based markers (bounding boxes and masks). Several dentists mark each case, and the lead adjudicates disagreement into one consensus label.
• Multi-reader, multi-case (MRMC) reads. Reader studies compare aided versus unaided clinician performance across many readers and many cases. The board is that substrate: multiple dentists on the same cases, each read tracked, inter-reader agreement measured per case.
• Right-sized, not guessed. Standalone and reader studies carry real sample-size and statistical-power requirements, set up front so the campaign collects exactly enough cases and reads.
• A clean, firewalled test set. The costliest mistake is letting model developers touch the test data, which implicitly trains the model and can invalidate the results. Annotation stays separate from the AI team by design: role-scoped access, an independent lead sign-off, and a timestamped audit trail keep the test set sequestered.

The deliverable is a validation dataset built to survive that scrutiny: consensus labels, inter-rater agreement, subgroup coverage, and provenance.

How it's built

Next.js 16 on Vercel. Vercel Blob holds both the imaging volumes and the annotation JSON. Cases come from a manifest; each case page has a single "Open in VolView" button and a structured annotation form. N readers on one case produce N records under one storage prefix, so agreement metrics are a query, not a rebuild. The contribution is the assembly: proving the open-source pieces compose into a workflow a working clinician can actually use, and that the same artifact runs locally for real patient data.

Roadmap

• Phase 1 (done): read → annotate → submit loop, public sandbox.
• Phase 2: validation harness (Dice / IoU / inter-rater agreement vs ground truth).
• Phase 3: a "Submit annotation" button inside VolView (structured ROI → backend), itself a candidate Kitware custom-development engagement.
• Phase 4: local install (PHI stays on the customer's own host) plus a booking layer that assigns cases to specific clinicians with deadlines and a review queue.

Dental CBCT: 3D Slicer / Kitware "CBCT Dental Surgery" sample data. Viewer: Kitware VolView. Code: github.com/prahlaadr/pyaar-dental.