Cloud Orthodontic Software and Dental Lab Software: What They Track, What to Build

A crown or aligner case that leaves a practice on Monday has to come back, be checked and be ready before the patient sits down for the seat appointment, and three different systems each hold a piece of it. The practice management system (PMS) holds the appointment. The intraoral scanner’s portal holds the scan. The lab’s system holds the status. None of them, on its own, can tell anyone whether the case will make it in time.

If you build lab or orthodontic software, that deadline is where to start. If you’re building a wider dental product, start with our dental software development page.

What Does Cloud Orthodontic Software Do?

Cloud orthodontic software is practice management built for orthodontics and hosted by the vendor, so staff access it from a browser instead of a server in the office. It schedules long treatments, tracks each patient’s phase and appliance, stores records and images, and bills contracts and payment plans, often across several locations from one database.

What makes it different from general dental practice management software is time. A general dental visit is usually one appointment and one claim. An orthodontic case runs for many months, with a contract signed at the start, payments spread across the treatment, records taken at set points, and adjustment visits at intervals the treatment plan sets. The software has to carry all of that as one case, from contract to retention.

Buyers range from a single orthodontist to an orthodontic service organization (OSO), a group that runs many ortho offices under shared management. For a group, “cloud” mostly means one patient record and one set of reports across every office. The core feature set overlaps heavily with orthodontic software in general; the difference is where it runs. For where ortho software sits among everything else a practice runs, see the dental technology guide.

Orthodontic Software Companies and Their Developer Routes (as of October 2026)

For anyone building alongside orthodontic practice software, the useful question is what door each vendor publishes for other software to connect, because that decides whether your product can read or write the patient’s case at all. Here’s what five of them publish, as of October 2026.

directly under the paragraph above. Server-rendered HTML table (snippet target), not an image.

The group behind topsOrtho formed in 2022, when topsOrtho, Gaidge, EasyRx, Oasys Crossfire and OrthoMinds joined PracticeTek. One name from that list turns up whichever side of the market you search: EasyRx describes itself as lab management software for orthodontic practices and labs, and it sits on the prescription handoff between them.

Treatment planning is a separate layer from practice management. Software that plans tooth movement or designs aligner stages is regulated as a medical device (see FDA and HIPAA below), and these are among the products cleared under FDA product code PNN:

Source: FDA 510(k) database, read October 25, 2026. Most recent PNN clearance per product.

If your platform needs treatment planning, connecting to a cleared product and building your own are two different projects: the second puts your software on the PNN path.

What an Orthodontic Platform Tracks That a General PMS Doesn’t

Orthodontics runs on treatment months. These are the objects a platform has to model as data, not as free-text notes:

• Treatment phases. Records, active treatment, refinement, retention, each with its own visit interval.
• Appliances and aligner stages. For aligners: the total number of stages, the current stage, the date each set was handed over, and refinement rounds, which add stages after the first plan. For brackets: wire changes and adjustment dates.
• Records at set points. Photos, cephalometric X-rays, 3D scans and cone beam CT (CBCT) at the start, during treatment and at the end, each tied to a date and a phase. Image storage and viewing are their own build; see cloud dental imaging.
• The contract. Total fee, down payment, monthly amount, who pays it, and what happens if treatment runs long.
• Insurance that pays over time. Orthodontic benefits are often paid in installments, not one claim. Delta Dental of Massachusetts, for example, states that “in most cases” it “issues reimbursements for orthodontic care through automatic monthly payments, not exceeding 12 installments,” with the first payment “based on the date of banding/placement of appliances.” Schedules vary by payer and plan, so the platform has to hold each patient’s payment schedule and stop expecting payments if coverage ends.
• Parents and guardians. Many orthodontic patients are minors, so the person who gets the reminders, signs the contract and pays the statement is often a parent, sometimes two in different households. Model the responsible party and each contact separately from the patient. Reminder and recall logic is covered in dental recall and patient engagement software.

What Dental Lab Management Software Has to Handle

A lab’s day is a queue of cases with due dates someone else set. The best dental lab management software for a given lab is the one that handles these well, and the list is the same for an in-house build:

• Prescription intake. The practice’s Rx, with the scan or impression attached, arriving through a portal or a prescription bridge instead of a paper slip.
• Case tracking by stage and technician. Received, design, production, finishing, quality check, shipped, each with who has it and since when.
• The due date that matters. The practice’s seat appointment. If the appointment moves, the case’s priority moves with it.
• Remakes as data. Each remake linked to the original case with a reason code, including whether the cause sat with the practice (impression, shade, prescription) or the lab (fit, finish). Without the reason, the lab can’t see which practice or which step keeps causing them.
• Quality check before it ships. A recorded check, with who did it and when.
• Shipping. Carrier, tracking number and expected arrival, visible to the practice.
• Invoicing per practice. Lab fees, remake credits and statements by account.
• Materials and inventory. What each case used, so cost per case is known.
• A practice portal. Where the practice sends new cases and checks status without calling.

Established systems cover much of this list, among them Magic Touch, Evident and GreatLab. A build earns its place when the case flow itself is what sets a lab apart, or when many locations or practice accounts need their data in one place.

How a Scan Gets From the Chair to the Lab

The impression is now usually a file, and the file has a format. An intraoral scanner uploads the scan to its maker’s cloud or portal. The lab receives it from there, either through a connection the practice and lab set up inside that portal, or as an exported file. What each scanner maker publishes for other software differs as much as the PMS routes do (as of October 2026):

• Dentsply Sirona publishes the DS Core API for developers and names “Lab Management System Providers and Labs with own SW solution” among its audiences. You build a prototype in a test environment, and “Your integration will be evaluated for viability” before production access.
• 3Shape lists its connections in its Unite integration guides, mostly practice management and other dental software. A developer program isn’t published.
• Align (iTero) integrations are announced partner by partner. In February 2026, Henry Schein One announced an integration, “Developed in collaboration with Align Technology,” that “automatically imports iTero scans into patient records” in Dentrix, Dentrix Ascend (now marketed as Ascend by Dentrix) and Dentally. A public developer program isn’t published.
• Medit forms practice-to-lab partnerships by invitation inside Medit Link: “The partnership will be automatically formed once they accept the invitation” (Medit Link help). Some PMSs bridge to it, Open Dental among them. A public developer program isn’t published.

Once the file arrives, its format matters. 3Shape’s own export guide defines the three a lab meets most:

• STL: “Standard 3D mesh format supported by 3Shape and many third-party applications.” The exported model is monochrome.
• PLY: “Similar to STL, but preserves adapted colors.”
• DCM: “Native 3Shape scan format used by applications such as Dental System, Ortho System, and Implant Studio.” It keeps the original scan colors.

For a lab or ortho software team, two things follow. First, a lab that works with many practices receives scans from several scanner brands, each through its own connection, so the software has to ingest from more than one source and attach each file to the right case. Second, build for the common breaks: emailed files, re-keyed patient details, scans never linked to a case.

Store the file once, reference it from the case, and carry the patient and practice identifiers with it. Storage and viewing for larger 3D and CBCT files is covered in cloud dental imaging.

Connecting Lab and Ortho Software to the Practice PMS

The seat appointment lives in the practice’s PMS, so any software that wants to say “this case is late for its appointment” has to read the PMS. How you do that depends on the system.

Open Dental is the clearest published example. Its LabCases API has read access since version 24.2.28 and create access since 24.4.19, plus updates. Each lab case carries the patient, the laboratory, the appointment it belongs to (AptNum), the planned appointment, and five dates: created, sent, received, checked and due, along with instructions, the lab fee and an invoice number. That’s enough to build a late-case alert: the case isn’t marked received and checked two days before its seat appointment.

Other systems take other routes. Dolphin integrations go through Dolphin’s listed partners, arranged through the practice’s Dolphin rep, so the route starts with that conversation. Whatever the system, write through the vendor’s API and never straight into the PMS database, which bypasses the vendor’s rules and can break on the next update.

We build these integrations to each vendor’s published route, including the local service an on-site PMS needs at each office. Where the practice’s PMS doesn’t expose lab cases, the lab system holds the case and reads only the appointment from the PMS.

Cloud or On-Prem for Ortho and Lab Software?

Cloud moves the server out of the office, and some of the work moves with it. The internet becomes the dependency: Planet DDS’s own Cloud 9 FAQ suggests that practices wanting a backup “could purchase a broadband wireless hotspot,” so plan offline behavior for the front desk, or at least a clear failure message. Scan and CBCT files are large, and upload time and storage cost show up in a cloud design in a way they don’t on a local server.

For an OSO or a dental service organization (DSO) with many offices, one record and one report set is the main reason to move; more on that in DSO technology. The on-site piece stays where the PMS does. If your cloud product connects to desktop Dentrix, Eaglesoft or an on-site Dolphin server, a local service at each office does the reading and writing. And before signing with any hosted vendor, ask in writing what data export you get, in what format, and how long it takes.

FDA and HIPAA: What Applies to Lab and Ortho Software

Two rules decide more about the build than any feature list, so settle them before you scope.

FDA. The FDA lists “orthodontic software” as product code PNN, Class II, defined as “software that is to be used for the diagnosis and treatment planning of orthodontic patients and conditions,” for prescription use only. As of October 25, 2026, 36 clearances in the FDA’s 510(k) database carry that product code, two of them dated September and October 2026. Sequential aligners themselves are a separate Class II product code, NXC.

Case tracking, invoicing and scheduling don’t plan treatment, but features such as aligner staging or a setup viewer sit close to the line. Whether a given feature falls inside PNN is a regulatory decision: make it with your regulatory partner before you build. What we offer is IEC 62304-aligned development and testing; we work alongside your regulatory partner on submissions. More on the standards involved in international medical device standards.

Dental labs have their own exemption from FDA establishment registration: 21 CFR 807.65(i) covers “dental laboratory” personnel who “provide a service through the use of a previously manufactured device.” It applies to the lab’s registration; software a lab builds or sells is judged on its own intended use.

HIPAA. The American Dental Association’s business associate FAQ states that “Dental laboratories are considered health care providers” and that “No business associate agreement is necessary to share PHI with a lab concerning treatment of an individual.” HHS guidance says the same about treatment disclosures between providers in its FAQ 240. A software company is different: if your platform stores or processes PHI for a practice or a lab, you’re their business associate and need a BAA with each customer, and with your own hosting and messaging providers.

We sign a BAA with our clients. For the wider program, see becoming HIPAA compliant. This section is general information, not legal or regulatory advice.

What We Build for Dental Labs and Orthodontic Teams

For most single offices and smaller labs, I think configuring one of the products above is the right call, and the effort is better spent on the connections between systems. When the workflow is your product, we build it:

• Lab case tracking with prescription intake, remake reason codes and a practice portal
• Practice-facing case status tied to the seat appointment
• Orthodontic treatment, aligner-stage and contract tracking, with parent and guardian contacts
• PMS integrations built to each vendor’s published route
• Cloud platforms built for HIPAA, under a signed BAA

Delivered for a global dental instruments company building a practice platform: a web platform with role-based access, treatment templates, materials and inventory management, dentist profiles and a real-time dashboard, built to HIPAA.

Delivered for a dental practice management software company: an MVP practice management platform with billing, patient notifications and an insurance API integration. It cut administrative time by 40%, brought appointment no-shows down 30% and raised patient satisfaction scores 20%. Read the dental PMS platform case study.

Builds start with a 6-week discovery that ends in a clickable prototype and a fixed-price scope sheet, then run in 2-4 week sprints.

For lab or ortho products that also need the medical record. ConnectHealth is a separate integration product for connecting to medical EHRs: 20+ EHRs, including Epic and athenahealth, deployed in your own cloud environment. Run it yourself, or have us build on it.