Integrating Digital Impression Workflows with CAD/CAM Lab Systems

The Manual Manufacturing Bottleneck

In dental appliance manufacturing, the traditional workflow goes like this: a clinician takes a physical impression using polyvinyl siloxane material, the front desk packages it with a paper prescription, it ships to a lab via courier, the lab pours a stone model, scans it into their CAD system, designs the appliance, manufactures it, and ships it back. The total turnaround is typically 2-3 weeks, and the failure modes are numerous.

Physical impressions distort during shipping — temperature changes, compression, and material degradation are all real problems. Paper prescriptions are frequently incomplete or illegible. And once an order ships to the lab, there is essentially no visibility into its status until the appliance arrives (or does not). Remake rates in this workflow run around 12-15%, and each remake means a new patient appointment, new materials, and another 2-3 week wait.

Intraoral scanners have matured to the point where they capture full-arch impressions in 90 seconds with sub-50-micron accuracy — better than physical impressions. But having a scanner does not solve the workflow problem by itself. Scanner software exports proprietary formats, each lab has different submission requirements, and there is no standard way to attach clinical parameters (bite registration, protrusion targets, tooth-specific instructions) to a digital scan file. We needed to build the integration layer between clinical capture and lab production.

The Technical Scope

The project had four main engineering challenges: normalizing scan data across multiple scanner brands and file formats, building a CAD/CAM integration layer that prepares data for each lab's specific manufacturing workflow, designing a lab order model rich enough to carry clinical intent through the manufacturing process, and implementing quality validation at the point of capture to catch issues before they become expensive remakes.

Digital Impression Workflow Architecture

The workflow starts when a clinician completes a scan. We built a lightweight desktop agent that runs on the clinic workstation and monitors the scanner software's output directory. When a new scan file appears, the agent validates scan quality (mesh completeness, point cloud density, artifact detection), and uploads it to our cloud platform. The goal is for the scan to reach the cloud within seconds of capture, while the patient is still in the chair — that way, if quality validation fails, the clinician can rescan immediately.

Multi-Scanner Format Normalization

Across the practices using the system, we deal with six scanner brands: iTero, 3Shape TRIOS, Medit i700, Carestream CS 3800, Planmeca Emerald, and Dentsply Primescan. Each exports in different formats — STL, PLY, OBJ, DCM, and proprietary binary formats. This is the unglamorous but critical foundation of the entire system.

• Format detection: We identify scanner brand and file format using magic bytes and file structure analysis, not file extensions. File extensions are frequently wrong when clinical staff manually rename files or when scanner software uses non-standard naming conventions.
• Coordinate system normalization: Different scanners use different coordinate systems and units. We normalize all scans to a standard orientation (occlusal plane aligned to XY, anterior toward +Y) and consistent units (millimeters). Without this, downstream processing would need scanner-specific logic everywhere, which is a maintenance problem that gets worse with every new scanner brand.
• Metadata extraction: Scanners embed clinical metadata differently — some in DICOM headers, some in JSON sidecars, some in proprietary XML. We extract patient ID, scan date, arch type, and scan settings into a unified metadata schema. The normalization layer converts everything to a canonical annotated PLY mesh with embedded metadata, while preserving the original file for lab-specific export.
• Compression: Raw scans range from 15MB to 120MB depending on scanner and resolution. We apply lossless Draco mesh compression that reduces sizes by 60-80% for faster upload and storage, while maintaining full geometric fidelity. This matters for clinics with limited upload bandwidth — a 120MB file over a 10Mbps connection takes a while.

Clinical Data Attachment

A scan alone is not enough to manufacture an appliance. The lab needs clinical parameters: target protrusion distance, vertical dimension of occlusion, tooth-specific instructions, and the prescribed appliance type. We built a structured prescription form that clinicians complete on a tablet immediately after scanning. The prescription data is linked to the scan files via a shared order ID and stored as a FHIR-compatible clinical document. This structured format replaces the handwritten paper prescriptions that were a constant source of errors and back-and-forth phone calls with labs.

CAD/CAM Integration Layer

The CAD/CAM integration layer bridges clinical data and manufacturing. Different labs use different CAD software (3Shape Dental System, exocad, Dental Wings) and different manufacturing processes (3D printing, CNC milling, thermoforming). The platform needs to prepare scan data in the exact format each lab expects, including any CAD-specific preprocessing like margin marking, insertion path calculation, or undercut blocking.

Lab Profile Configuration

Each partner lab is configured with a manufacturing profile specifying: accepted file formats and version requirements, mesh density and tolerance parameters, required preprocessing steps, preferred coordinate system, and API endpoint details. When a new lab joins, we run a calibration process using reference scans to verify that our export pipeline produces files that pass the lab's quality checks without manual intervention. This calibration step catches format incompatibilities early — things like triangle winding order differences that cause mesh normals to flip, which silently breaks some CAD software.

• Format conversion: The export pipeline converts our canonical format to whatever the lab requires. For 3D printing labs, we export watertight manifold meshes in binary STL. For CNC milling labs, high-density point clouds in IGES. For exocad labs, their native DWOS format with embedded design parameters. Each conversion path has its own unit tests with reference geometry.
• Design parameter injection: Clinical parameters from the prescription are translated into CAD-specific constraints. A 7mm protrusion target becomes a bite registration offset matrix that the CAD software uses to position the mandibular arch relative to the maxillary arch. This translation is lab-specific because different CAD systems represent the same clinical intent differently.
• Material mapping: The platform maps prescribed appliance types to each lab's available materials and processes. A Herbst-style appliance might be manufactured via selective laser sintering in nylon at one lab but via CNC milling in PMMA at another. The export format and design parameters differ for each combination.

Version Control for Manufacturing Data

All manufacturing data is versioned and immutable. If a clinician modifies the prescription after submission, a new version is created with a diff showing what changed, who authorized it, and why. The lab receives a notification with the specific changes highlighted. This versioning has been useful in dispute resolution — when there is a question about whether an appliance matches the prescription, we can show the exact data the lab received, including sub-millimeter design parameters and the full change history.

Lab Order API & Routing Engine

Not all labs are interchangeable for every order. Some specialize in specific appliance types, some offer faster turnaround for rush cases, some have lower costs for standard work, and geographic proximity matters for cases needing physical try-ins. We built an order routing engine that scores labs for each order based on capability, quality history, current capacity, cost, and geography.

Routing Algorithm

• Capability filtering: The router first eliminates labs that cannot handle the order — wrong appliance type, incompatible scan format, or temporarily closed intake. This sounds obvious but prevents the most common routing errors.
• Quality scoring: Each lab carries a dynamic quality score based on historical metrics: rejection rate, remake rate, fit accuracy ratings from clinicians, and on-time delivery percentage. Quality scores update continuously as new data comes in. Labs below a threshold are flagged for review and deprioritized.
• Capacity awareness: The router queries each lab's current production queue depth (via their API) and considers historical turnaround for the specific appliance type. For urgent cases, it can identify labs with same-day or next-day production capacity.
• Cost optimization: When turnaround is not the primary constraint, the router considers pricing — which varies by appliance type, material, and volume tier. The system tracks committed volume against each lab's pricing tiers to optimize network-wide costs across the billing period.

Order Submission API

Orders are submitted through a REST API we developed with our primary lab partners. The API follows a request-acknowledge-status pattern: we submit the order, the lab acknowledges receipt within 60 seconds (or we retry), and status updates flow back through webhooks as the order progresses. For labs without API support, we built automated portal submission using Playwright that logs in, fills out the order form, uploads files, and captures the confirmation number. The Playwright approach is fragile — portal UI changes break it — but it bridges the gap until smaller labs build proper APIs.

Real-Time Production Tracking

Before this system, checking order status required a phone call to the lab and a hold time of 5-15 minutes for a vague answer. We defined a standardized 12-stage production pipeline that maps to common manufacturing steps across all partner labs: Order Received, Scan Validated, Design Queued, Design In Progress, Design Complete, Design Approved, Manufacturing Queued, Manufacturing In Progress, Post-Processing, Quality Check, Shipped, and Delivered.

Status Pipeline

Each lab maps their internal production stages to our standardized pipeline. This mapping is imperfect — labs have different internal processes and some stages do not map one-to-one. We handle this by allowing labs to skip stages that do not apply to their workflow and by defining a minimum set of required status updates (Received, Shipped, Delivered) that all labs must provide regardless of their internal process.

• Notifications: Practice staff receive push notifications at key milestones — design complete (opportunity to review), shipped (with tracking), and any problem status (rejection, defect, delay). Notification fatigue was a concern, so we let practices configure which stages trigger alerts.
• Patient communication: Optionally, the system sends automated SMS or email to patients at Shipped and Delivered stages. This reduced "where is my appliance?" phone calls to practices noticeably.
• SLA monitoring: Each order carries expected completion timestamps based on the lab's committed turnaround. Orders behind schedule trigger escalation alerts — first to the lab, then to the practice manager if the delay exceeds the SLA by more than 24 hours.
• Network analytics: A dashboard shows aggregate production metrics: orders in pipeline by stage, turnaround by lab and appliance type, and trend lines for quality metrics. This data drives quarterly lab performance reviews and contract negotiations.

Quality Control Automation

Quality control happens at two points: at capture (while the patient is in the chair) and at lab receipt (when the lab opens the digital files). The economics strongly favor catching issues early. A rescan while the patient is present costs 5 minutes. A remake after the appliance is manufactured costs new materials, 10 days of turnaround, and a return appointment.

Point-of-Capture Validation

The scan capture agent runs automated quality checks immediately after upload, while the patient is still in the operatory. These checks target the issues that most commonly cause lab rejections.

• Mesh integrity: Checks for holes (missing data), non-manifold edges (topological errors that break CAD software), degenerate triangles (near-zero area faces that cause rendering artifacts), and self-intersecting geometry. Scans with more than 3 defects or any defect larger than 2mm trigger a rescan recommendation.
• Margin definition: For appliances requiring precise tooth margin coverage, a curvature analysis algorithm verifies that gingival margins are clearly captured with sufficient contrast between tooth and soft tissue. Unclear margins are the number one cause of lab design rejections in our data.
• Occlusal clearance: Verifies that the bite registration has adequate interocclusal space. Insufficient clearance means the appliance will be either too thin (structurally weak) or too thick (uncomfortable) — either way, it is a remake.
• Coverage completeness: Compares scan extent against the prescribed appliance coverage area and flags gaps where tooth surfaces are missing or insufficiently detailed.

ML Quality Scoring

Beyond the rule-based checks, we trained a convolutional neural network on approximately 12,000 labeled scan-outcome pairs (scan quality features mapped to lab acceptance/rejection and final fit ratings). The model produces a quality score from 0 to 100. Scores above 85 correlate with a 97% lab acceptance rate. Between 70 and 85, scans pass with warnings. Below 70, the clinician is prompted to review and likely rescan. The ML model catches quality issues that are hard to express as rules — things like subtle scan stitching artifacts or insufficient detail in posterior regions.

Results & Manufacturing Metrics

The system rolled out across 45 practices over an 8-week phased deployment. Here are the production metrics after several months of operation.

• Scan-to-lab time: From an average of 4.2 days (physical impression shipping) to under a minute (digital transmission). This alone recovered 4 business days from the turnaround cycle.
• Total turnaround: Average order-to-delivery dropped from about 17 days to about 7 days. Rush orders with participating labs can complete in 3 business days.
• Remake rate: Overall remakes dropped from around 15% to about 3%. The reduction comes from three sources: eliminating impression distortion during shipping, point-of-capture quality validation catching scan issues, and structured prescriptions reducing lab miscommunication.
• Lab rejection rate: Incoming scan rejections at labs dropped from 14% to about 2%, largely eliminating the back-and-forth that used to add 3-5 days to problematic orders.
• Shipping cost: Eliminating physical impression shipping saves roughly $14K per month across the network in courier fees, packaging, and insurance.

The main ongoing challenge is maintaining the Playwright-based portal automation for labs without proper APIs. Portal UI changes break the automation, and we spend a few hours each month fixing these integrations. We are gradually pushing labs toward API-based submission, but adoption is slow — smaller labs do not have the engineering resources to build APIs, so the portal automation remains necessary for the foreseeable future.