DENTALVIEW

Preparing your clinical command center

Teaching Clinics7 min read

Requirements, Sign-Off & Student Progress

Define graduation requirements, approve student procedures, and track per-student progress.

From Tally Sheets to a Live Quota System

Every dental program tracks the same thing: has each student performed enough of each procedure type, verified by faculty, to graduate? On paper this is tally sheets, signature hunts, and end-of-term panic. In DentalView it's a live system: the dean defines categories once, students log procedures as they work, professors sign off, and completion computes itself — trustworthy because only approved work counts.

The Requirements page: category cards and the cohort matrix

Defining Requirement Categories

On the Requirements page, the dean creates categories — "Restorations," "Oral Surgery / Extractions," "Endodontics" — and maps each to the procedure codes it covers, with a target count per student. Design decisions that matter:

  • One procedure type belongs to one category. Selecting a code in a new category moves it out of its old one — nothing double-counts, which is what keeps the totals defensible at accreditation time.
  • Targets are per student, so cohort demand scales automatically (30 students × 10 restorations = 300 approved restorations the program must supply).
  • Tracked-only categories (target 0) count activity without gating graduation — useful for procedures you want visibility on but don't quota.
  • Categories can be edited, reordered, or deactivated (kept but excluded from the matrix); deleting one stops tracking its progress, with a confirm prompt.

Academic Terms Live Here Too

The Requirements page hosts the Academic Terms manager: create named windows ("SY 2026–27, First Semester") and mark one Current. The current term powers the behind-pace flag on At-Risk Students and the term filters across faculty reports — set it up before the term starts and the analytics calibrate themselves (full detail in the Academic Terms article).

The Sign-Off Loop

Every student procedure enters a review queue. In Case Reviews, a professor either approves it — it now counts toward requirements — or returns it for redo, which requires a written remark so the student knows exactly what to fix. This loop is the integrity of the whole system: a number on a report card means a specific professor reviewed specific work, and the trail says who and when. Professors can also open a student's case read-only, comment privately for grading, or share feedback with the student.

The Cohort Matrix

Below the category cards, faculty see the whole program at once: students × categories, each cell showing completed-versus-target, with an Overall pill per student — red below 65%, amber 65–79%, green at 80%+ — and a cohort-average footer. Read it in two directions: a red row is a struggling student (the At-Risk page has the triage tools); a weak column is a case-supply problem — the program isn't generating enough of that procedure type for anyone (Case Mix diagnoses that).

A student's My Progress view with the Do next strip

What Students See

Each student's My Progress view shows their own pipeline per category — approved, pending sign-off, needs-redo — against each target, plus a "Do next" strip that prioritizes for them: redo returned work first, chase pending sign-offs, then attack the largest remaining gap. Students see only themselves; the comparison views belong to faculty.

Habits That Keep the Numbers True

Record procedures the day they happen (backdating is possible, batch-entry habits erode trust); professors should work the queue at least weekly — a stale queue quietly distorts every downstream report; and check the matrix monthly rather than at term end, because a supply problem found in October is fixable in a way a February discovery is not.

Was this article helpful?

Need more help? Contact our support team