Case Study · Design & Development
EvalPal turns a stack of paper questionnaires into a private, browser-based screening tool: seven validated instruments, automatic scoring, and health-data custody built in from the first commit.
Standardized mental-health screening still runs on paper. A practitioner hands someone a stack of questionnaires, PHQ-9, GAD-7, and longer instruments, to fill in by hand, then scores them by hand afterward. Filling a dozen forms is real cognitive load, often falling on the person least able to spare it. Once the forms are done, someone still has to add up the columns, apply the scoring rules, and type the result somewhere useful.
EvalPal moves the packet on-screen. You complete the instruments in a browser, get them scored automatically, and hand the clinician a clean PDF. The paper deliverable stays. The manual work goes away.
EvalPal is a live, multi-user web app at evalpal.app. A person signs in, gives explicit consent, and works through an instrument one item at a time, with save-and-resume for the long ones. The app scores each completed attempt against the instrument's own rules, shows the result, and generates a PDF report. Seven validated instruments are live: PHQ-9, GAD-7, the Autism Spectrum Quotient, the ASRS v1.1, the WFIRS-S, the Yale-Brown Obsessive Compulsive Scale with its symptom checklist, and a sleep-disorders questionnaire. An operator can add more.
It is a screening tool, not a diagnosis engine, and it says so plainly. The harder engineering is in making that screening trustworthy: correct scoring across very different instrument shapes, sensitive data handled responsibly, and a real answer when a response is concerning.
How it's built
Every instrument is data the engine reads, not code written for each one. That single decision is what makes the rest of the product possible.
Every instrument is a definition rather than a special case in the codebase. A definition holds its response scales, its ordered items and their scoring direction, its subscales, and its interpretation bands. One scoring engine reads all of them. That is what lets EvalPal handle question formats that look nothing alike: a 0–3 frequency item with a follow-up impairment question, an agree/disagree scale with per-item direction, a 0–4 severity scale with different anchor text on every option, a two-column current/past checklist. No instrument needs its own code path. Adding one is configuration.
The five instruments beyond the two seeded examples were loaded through an import pipeline. It reads a source PDF, uses Claude to extract its items and scales into a structured definition, validates the result against the instrument model, reports what it found, and loads it change-aware. Turning a printed clinical form into a scored, data-driven instrument is a repeatable pipeline, not an afternoon of manual transcription.
Responses are sensitive personal health information and treated that way: encrypted at rest, isolated per user, and gated behind explicit consent. A person can export everything they have submitted, or delete all of it, on demand. It is built to Canadian privacy expectations, and it is honest about its limits: screening, not diagnosis, and not a certified clinical system.
High-risk items, like the PHQ-9 self-harm question, carry a safety rule that lives in the instrument model alongside scoring. Detection is deliberately fail-loud: if a safety-relevant answer cannot be read back, the app refuses to score the attempt rather than score it and quietly skip the check. A fired flag is recorded and carried into the results and the report the clinician reviews, with crisis resources available alongside.
The whole app asks a single question: who is this, and what are they allowed to do. Only three files know the answer comes from Auth.js. Swapping the identity provider later is one new implementation, not a rewrite. It is a small discipline that keeps a young product from being married to an early decision.
Next.js 15 and React 19 on Vercel, Prisma over Postgres on Neon. A normalized schema carries the logic, instruments, scales, items, scoring rules, interpretation bands, attempts, responses, and safety flags, so the code stays small and the data model does the work.
Data-driven instrument model · one scoring engine · Claude-assisted form import · encryption at rest · per-user custody with export and delete · safety rules in the model · swappable identity seam.
What this shows
EvalPal is representative of the work Novadiem does well: a real product in a domain where the details are the point. It handles sensitive data responsibly, replaces hardcoded one-offs with a general engine, and uses AI where it earns its place, turning printed forms into structured data instead of bolting it on for show.
It went from a paper packet to a live, privacy-forward web app, designed and built end to end, from the data model and the scoring engine to the brand, the copy, and the deploy.
Full-stack products, AI where it earns its place, and the privacy and data discipline sensitive work needs, designed and built from one practice.
