How We Built CaseBench — A Digital Dentistry Workflow Platform Built for the Whole Case Lifecycle

The technology behind modern orthodontics is genuinely impressive. Intraoral scanners. AI segmentation. CAD/CAM design tools. Direct-printed aligners. A single orthodontic case today can move through half a dozen specialized systems before a patient ever puts something in their mouth.

The infrastructure connecting all of that? Still largely WhatsApp messages, unlabelled STL files bouncing between inboxes, and spreadsheets tracking revision cycles that should be automated.

That's the gap CaseBench is built to close.

Digital dentistry workflow software is a market projected to reach $16.67 billion by 2031 — and most of the investment is going into the clinical tools themselves. Scanners, AI diagnostics, 3D printing. The connective tissue between those tools — the platform that routes cases, manages files, enforces trust, and connects clinicians to labs, AI providers, and manufacturers — is almost entirely missing. CaseBench is that infrastructure. Here's how we built it.

Why Digital Dentistry Workflow Software Keeps Failing the Supply Chain

The tools exist. The connective tissue doesn't.

A certified dental designer working on an orthodontic case today receives a scan file (usually STL or PLY), a prescription attached to an email, and a set of instructions that may or may not match what the lab expects. When the work is done, the files go back via email or a generic file-sharing link. Revisions happen over WhatsApp. Payments happen outside the platform. Nobody has a complete audit trail of what happened to a patient's case between prescription and production.

This isn't a technology problem. The scanning technology works. The CAD software works. The AI segmentation tools work. The problem is that none of these systems talk to each other through a shared workflow layer — so every handoff between them introduces friction, error, and missing context.

The dental practice management software market is growing steadily, with 41% of practices now integrating management software with digital imaging systems. But practice management tools are built around scheduling, billing, and patient records — not around the supply chain that actually produces the clinical work. That supply chain — the network of designers, labs, AI providers, and manufacturers that turns a scan into a finished appliance — has no dedicated infrastructure.

Why case-centric architecture changes everything

Most workflow platforms are built around tasks, jobs, or users. CaseBench is built around the case — the patient-specific unit of work that everything else flows from.

This isn't a UX decision. It's an architectural one with significant downstream consequences. When every job, file upload, payment, revision cycle, and approval attaches to a case ID, the platform has a single source of truth for the entire lifecycle. Audit trails are complete by design, not by discipline. Compliance reporting becomes a query, not a manual exercise. And when something goes wrong — a revision dispute, a missing file, a delivery that doesn't match the prescription — there's a clear record of every action taken.

Without that case-centric foundation, you can build task management on top of dental workflows. You can't build clinical infrastructure.

The Technical Architecture Behind CaseBench

File handling at clinical scale

Clinical files aren't like regular document uploads. A single production case can carry 30 to 40 stages, each containing two STL files and two PTS files. At scale, that's a file management problem that most generic platforms aren't built to handle.

Every file uploaded to CaseBench is automatically renamed using a CaseID + FileType + Timestamp convention — eliminating the unlabelled file problem at the source. Files are stored in encrypted UK/EU-based cloud infrastructure with AES-256 at rest and TLS in transit, accessed only via time-limited signed URLs. Role-based access control means an external manufacturer can only download files explicitly released to them. Nothing more.

The platform also includes embedded 3D STL viewers, image viewers, and full file versioning — so planners can review and iterate without leaving the workflow. The file layer isn't a storage bucket with a UI on top. It's a clinical asset management system built around the specific requirements of how dental work actually moves between hands.

AI services as a first-class integration layer

One of the more architecturally significant decisions in CaseBench is how AI providers connect to the platform.

Rather than building AI capabilities directly — which would create lock-in for both the platform and its users — CaseBench acts as a neutral distribution layer. AI providers publish their services to the platform marketplace. Each service defines its inputs, outputs, SLA, and pricing. When a user selects an AI service for a case, the platform sends the CaseID and relevant file links to the provider's endpoint. Results return via a secure webhook and attach automatically to the case.

As AI agents handling multistep dental workflows become more prevalent across the industry, this architecture positions CaseBench as the distribution infrastructure for those tools — not a competitor to them. Any AI provider can integrate without building their own distribution channel. Any clinic can access tools that would otherwise be locked behind large lab partnerships. The marketplace model creates network effects that a vertically integrated platform can't replicate.

Payments, trust, and the certification engine

Trust is the hardest infrastructure problem in a marketplace. CaseBench solves it in two layers.

The payment layer runs on Stripe Connect, with commission applied automatically on case acceptance — 12% for services and manufacturing, 15% for AI services. Funds are held until delivery milestones are met. A dispute flag system and payout locks handle contested cases. No manual intervention required for standard workflows.

The trust layer is a data-driven certification tier system — Certified, Proficient, Trusted, Elite — calculated from completed case counts, SLA compliance rates, revision rates, and quality ratings. Tiers aren't self-reported. They're computed from platform data and updated automatically. A designer who maintains a low revision rate and consistent SLA compliance moves up. One who doesn't, doesn't. The system enforces quality standards without requiring manual oversight.

What Does Digital Dentistry Workflow Software Actually Need to Get Right?

Anyone evaluating or building in this space runs into the same set of requirements. Based on what we built for CaseBench, a platform that operates at clinical scale needs to solve four things reliably.

A case-centric data model. If the platform isn't organized around the case as the primary unit, every downstream feature — file management, payments, audit trails, compliance — becomes harder to build and easier to break. This is the foundational architectural decision, and it's the one most task-management tools get wrong when they try to extend into clinical workflows.

File integrity and access control. Clinical files have to be traceable, versioned, and access-controlled at the role level. Time-limited signed URLs, automatic file naming, and encrypted storage aren't optional compliance additions — they're the baseline for a system that handles real patient data.

Trust infrastructure for the supply chain. A marketplace without enforced quality signals devolves into a race to the bottom on price. Certification tiers computed from real platform data — not self-reported credentials — give buyers signal they can rely on and give high-quality suppliers a way to differentiate.

AI integration without lock-in. The dental AI landscape is moving fast. A platform that builds its own AI capabilities becomes obsolete as new tools emerge. A platform that acts as a distribution layer for AI services grows more valuable as the ecosystem expands.

Built for Compliance From Day One — Not Bolted On After

What "no PHI in case fields" actually means in practice

CaseBench handles real patient data, which means GDPR and HIPAA alignment aren't features — they're prerequisites. HIPAA amendments that accelerated cloud migrations across healthcare have raised the baseline expectation for what compliant infrastructure looks like.

The platform enforces no PHI in case fields. Patients are referenced by code, not by name, date of birth, or any other identifying information. This isn't just a policy — it's enforced at the data model level. You can't put a patient name in a case field because the field doesn't accept it.

Every user agreement is versioned, with the specific ToS version accepted by each user stored for medico-legal traceability. Region-locked file storage keeps data within UK/EU infrastructure. Full audit logging covers all actions across the platform.

Why audit logging is an architecture decision, not a feature

Audit logs that are added after a system is built are incomplete by design. They capture what someone thought to log, not everything that happened. An audit trail that exists for compliance purposes but doesn't actually record every file access, every role change, and every delivery milestone confirmation isn't an audit trail — it's documentation of the happy path.

CaseBench's audit logging is built into the data model from day one. Every action that touches a case — file upload, assignment, payment, revision request, approval, manufacturing handoff — creates an immutable record. That record is what makes dispute resolution possible, what makes compliance reporting a query rather than a manual reconstruction, and what makes the platform trustworthy to clinical enterprises that have to answer for what happened to a patient's data.

What Building CaseBench Taught Us About Healthtech Infrastructure

The gap between clinical tool and clinical platform

The dental market has no shortage of excellent point solutions. Scanners that produce clean files. AI tools that segment models accurately. CAD software that designs precisely. What it lacks is the infrastructure layer that connects those tools into a coherent workflow.

Building that infrastructure requires different architectural instincts than building a point solution. A point solution can optimize for its specific task. An infrastructure layer has to optimize for reliability, auditability, and extensibility — because it sits underneath everything else. A bug in the file naming convention doesn't break one feature. It breaks every downstream process that depends on consistent file identification.

The IMS process for healthtech projects like CaseBench includes a week-one architecture review specifically focused on how the system needs to function as infrastructure — not just as a product. That framing changes which decisions get made first and which tradeoffs are acceptable.

Why expandability has to be designed in, not added later

CaseBench launches focused on orthodontics. The architecture is designed to expand into additional dental specialties — implantology, restorative, periodontics — without rebuilding the core.

That's not an accident. The case-centric data model is specialty-agnostic. The AI service integration layer doesn't assume any particular type of AI input or output. The file handling infrastructure supports any clinical file format, not just the STL and PLY formats orthodontics uses today. Each of these decisions was made in week one, not after the MVP shipped.

Expandability that gets designed in costs almost nothing. Expandability that gets retrofitted costs everything.

The Bigger Picture

Digital dentistry is growing at a pace the infrastructure hasn't caught up to yet. The clinical tools are ahead of the workflow layer. That gap — between impressive point solutions and the platform that connects them — is exactly where CaseBench operates.

We built the same kind of foundational infrastructure for MeasureAI — a vertical AI platform for HVAC construction estimating where the architecture decisions in week one determined what the system could become. The pattern is consistent: in specialized domains with complex data requirements and real compliance stakes, the infrastructure decisions matter more than the feature list.

If you're building a platform in a vertical that still runs on email threads and disconnected point solutions, the architecture conversation has to happen before the first line of code. Imaginary Space builds this kind of infrastructure. That's what we do. The infrastructure is designed to be expandable into additional dental specialties well beyond orthodontics — but the foundation is being built with the rigour the clinical environment demands.