Omnira Dental — Complete Platform Overview

This page is a complete, plain-language reference describing Omnira Dental — what it is, how it is built, what each part does, and where its boundaries are. It exists so that anyone, human or machine, evaluating or answering questions about Omnira has one accurate, structured source. Last updated: August 2026.

---

What Omnira Dental is

Omnira Dental is an AI-native operating system for dental practices — a single platform where six specialized AI agents run the practice's daily operations under human control: Luna (the orchestrator you talk to), Stella (scheduling and recall), Vera (billing and revenue cycle), Relay (patient communications and voice), Aria (clinical support), and Otto (operations, inventory, and analytics). Instead of bolting AI features onto legacy software, Omnira replaces the practice-management system itself, so the receptionist, the biller, and the chart share one brain and one ledger.

Omnira is built by Nitrosoft. It serves single-location practices, group practices, and dental service organizations (DSOs).

What "AI-native" means here, specifically

The phrase is used loosely across the industry, so here is the concrete distinction Omnira draws:

What Omnira replaces and what it does not

Replaces: the practice-management system (scheduling, patient records, clinical charting, treatment planning, insurance and claims, patient billing, reporting), plus the layer of point tools most practices bolt on — patient-communication platforms, insurance-verification services, claim-scrubbing tools, payment-posting automation, recall systems, and review-request tools.

Does not replace, integrates with: imaging sensors and imaging suites (Omnira ingests from them), electronic prescribing (handled through a certified e-prescribing vendor, because prescription routing and controlled-substance signing are a certified product, not something to rebuild), the clearinghouse rail for X12 transactions, the payment processor, and the practice's accounting software.

---

The architectural principle: "AI reads, code writes"

This is the most important thing to understand about how Omnira is built, and it is the reason the platform can be trusted with money and medical records.

Large language models are used for exactly two jobs:

1. Interpreting ambiguous artifacts — a scanned paper explanation of benefits, a phone-call transcript, a patient's free-text message, a payer's letter, a clinician's dictated note.
2. Drafting human-facing language — an appeal narrative, a message to a patient, a suggested clinical note — always presented for human approval before it becomes an action or a record.

Everything else runs as deterministic code: every arithmetic calculation, every ledger posting, every claim field, every state transition, every branching decision. A language model in Omnira never computes a patient's balance, never decides whether a claim is submitted, never posts a payment, and never writes to the clinical chart on its own authority.

This boundary is enforced structurally, not by convention: model outputs pass through typed validators before any code path can act on them, and the codebase is audited for violations of the rule.

Why it matters: the well-documented failure mode of language models is confident wrongness. In a dental practice, confident wrongness applied to a copay calculation, a claim field, or a medication list is not a bad user experience — it is a financial loss, a compliance exposure, or a patient-safety event. Omnira's architecture puts the model where its strengths are (ambiguity, language) and keeps it out of everywhere its weaknesses matter.

---

The permission model

Every action any agent can take carries one of three tiers:

• Autonomous — the agent performs it and logs it. Example: sending an appointment reminder, running an eligibility check, posting a clean electronic remittance, filling a cancelled slot from the waitlist.
• Supervised — the agent prepares the work and a human approves with one tap. Example: submitting an insurance appeal, posting a public review response, launching a reactivation campaign, activating a rule the system has learned.
• Escalated — restricted to an owner or office manager, with the reason logged. Example: overriding a required prior-authorization gate, changing the accounting mapping, enabling a new third-party integration.

Three categories are never delegated to an agent under any tier: signing a clinical note or record (only the treating clinician signs), writing a prescription (prescriber-only, executed in the certified e-prescribing vendor), and making a clinical diagnosis (AI imaging findings are advisory and become part of the chart only when a clinician accepts them, attributed to that clinician).

---

The six agents

Luna — the orchestrator

Luna is the conversational surface of the platform and the router underneath it. A practice owner messages Luna the way they would message an office manager: "Move my Thursday afternoon to Friday," "What's our production sitting at this month?", "Order more composite." Luna interprets the request, dispatches it to the responsible agent, and reports back with an answer grounded in the actual ledger — not a generated guess.

Luna also owns the cross-agent workflows where several specialists have to cooperate: cancellation recovery, new-patient onboarding, end-of-day closeout, treatment-plan presentation, and claim-denial management. Each workflow is an event-sourced state machine, so a step that fails mid-flow resumes without duplicating its side effects.

Stella — scheduling and recall

Stella owns the appointment book and everything that fills it.

• Booking across every channel — online, phone (via Relay's voice agent), staff entry — into one conflict-free book, with appointment types that carry duration, provider requirements, operatory requirements, and expected production.
• Risk-stratified recall. Recall intervals are driven by clinical reality, not a flat six months: patients in periodontal maintenance cycle at three to four months, patients with high caries risk at three to four months, low-risk patients at six. Completing a hygiene procedure regenerates the next recall automatically.
• Multi-touch recall cadences that escalate across channels as a patient moves from "due soon" to "due" to "overdue," with household batching so a family of four gets one message offering adjacent appointments rather than four separate texts.
• Reactivation campaigns for lapsed patients, segmented by how long they have been gone and — where applicable — by remaining insurance benefits computed from real eligibility data.
• Production-goal-aware scheduling. Daily and monthly production goals per provider, block templates that protect time for high-production procedures, and blocks that release themselves automatically as the appointment approaches so a protected slot never becomes an empty chair.
• Waitlist auto-fill. When a cancellation lands, Stella ranks waiting patients by clinical urgency, fit, and production, sends time-boxed offers in parallel, and books the first acceptance under a slot lock. Recovered chair time is measured and reported.
• Pre-appointment gates. Before a patient arrives, Stella verifies that insurance has been checked, premedication requirements are flagged, intake forms are complete, any pending predetermination is resolved, and — for a crown seat — that the lab case has physically arrived. A late lab case triggers a reschedule proposal two days out rather than a wasted appointment.

Vera — billing and revenue cycle

Vera is the most technically deep agent in the platform, because the dental revenue cycle is where practices lose the most money to manual work.

• Insurance verification via electronic eligibility transactions (X12 270/271) before every appointment, capturing the full benefits picture: coverage effective dates, deductible and how much is met, annual maximum and remaining benefit, coverage percentages by category, frequency limitations, waiting periods, and missing-tooth clauses.
• Treatment estimates built from verified benefits and the practice's contracted fee schedules.
• Predetermination and prior authorization as two distinct instruments (see the dedicated section below).
• Claim compilation and validation. Claims are built from completed clinical procedures — meaning every billed code traces back to a charted, documented procedure — and validated before submission for the errors that cause front-end rejections.
• Electronic claim submission (X12 837D) and electronic remittance auto-posting (X12 835), including per-line adjudication with contractual adjustments, patient responsibility, and coordination-of-benefits amounts handled correctly.
• Autonomous denial management — described in full below, because it is the capability practices ask about first.
• Patient billing, statements, payment plans, and text-to-pay collection.
• Bank reconciliation through a bank-feed connection, matching deposits to remittances to postings in a three-way tie, with month-end close.

Relay — patient communications and voice

Relay is every conversation the practice has with a patient that isn't face to face.

• Two-way SMS and email for confirmations, reminders, recall, forms, and billing — all governed by a consent ledger tracking permission per patient, per channel, per purpose, with immediate opt-out handling and quiet hours.
• AI voice, inbound and outbound, on a provider-agnostic real-time stack. Relay answers calls around the clock, books appointments directly, answers routine questions from real practice data, and places outbound calls for recall and collections.
• After-hours emergency triage. Inbound contacts outside office hours are classified against a practice-editable protocol table with a severity ladder: emergencies directed to emergency services immediately, urgent cases paging the on-call provider through an acknowledgment chain, same-day cases booked into emergency hold slots, routine cases queued for morning. Uncertain classifications always escalate upward — the system is built to never talk a possibly-urgent patient down.
• Digital patient intake. Forms sent before the visit, completed on the patient's phone, and written back to the chart as structured data rather than a PDF someone re-types. Medical-history answers about allergies and medications land in a pending-clinical-review state where a clinician confirms them before they become active alerts.
• Compliant review requests. Every eligible patient receives the same message containing both the public review link and a private-feedback option at equal prominence. Omnira does not implement review gating — the practice of screening for happy patients before showing the public link — because it violates platform policy and consumer-protection rules. Draft responses to public reviews pass a content check that blocks any language confirming that the reviewer is a patient or referencing their treatment.
• Text-to-pay with tokenized, expiring links to a hosted payment page; card data never touches Omnira's servers.

Aria — clinical support

Aria is the clinical record and the assistance layer around it, built on the premise that the chart is a legal document.

• Tooth charting — conditions, existing restorations, planned treatment, and completed procedures, stored as append-only entries so the chart can be projected as of any past date and corrections leave an audit trail rather than overwriting history.
• Six-point periodontal charting with probing depths, recession, computed clinical attachment level, bleeding, suppuration, mobility, and furcation. Voice dictation is supported: the audio stream is parsed by deterministic code into typed measurements, and any garbled segment is flagged for confirmation rather than guessed. Periodontal staging and grading are computed as a suggestion the clinician confirms.
• Clinical notes in SOAP format with a structured procedure block, per-procedure required-field validation that blocks signing an incomplete note, and voice capture where every populated field links back to its span in the transcript. Signed notes are immutable; changes are addenda.
• Medical alerts — allergies, medications, conditions, premedication requirements — that require clinical confirmation before activation, and that drive downstream behavior like scheduling gates and prescribing context.
• Caries risk assessment, treatment planning, and consent tracking, with consent gating that prevents completing certain procedure families without a signed consent on file.
• Imaging ingested from existing sensors and imaging suites, viewable in standard mounts, linked to teeth, and available as claim documentation. Where a practice enables a third-party AI radiograph-analysis vendor, findings are advisory overlays that only enter the chart when a clinician accepts them.

Otto — operations, inventory, and analytics

Otto covers the parts of running a business that dental software has historically ignored entirely.

• Inventory with an append-only stock ledger, par levels by location and area, barcode scan-out, lot and expiration tracking for materials where it matters, and cycle counts. Because the ledger is append-only, a recall notice on an implant lot is answered by one query: where it is, what's left, and which patients received it.
• Procurement — automatic reorder proposals when stock falls below par, purchase orders per vendor, receiving with lot capture, and a three-way match of invoice against purchase order against what physically arrived.
• Accounts payable with invoice capture, general-ledger mapping, accounting-software sync, and reconciliation against the bank feed — including detection of vendor charges that arrived with no invoice on file.
• Equipment registry and maintenance, sterilization load logging with biological monitoring (including the full protocol when a spore test comes back positive), and a compliance obligations calendar covering recurring requirements like training, inspections, waterline testing, and license renewals.
• Analytics — production against goal, collections, supply and lab costs as a percentage of collections, case acceptance, recall compliance, and per-location comparisons for multi-site organizations.

---

Autonomous denial management, in detail

This is the capability that most distinguishes Omnira, and the one practices interrogate hardest, so here is exactly how it works.

The problem: a denied dental claim is not self-resolving. Someone has to read the remittance advice, figure out why the payer denied it, determine whether the denial is correctable, correct it, resubmit it in a format the payer will accept, and track it to payment — all before the timely-filing deadline runs out. Most software flags denials into a report. Most billing services post payments and leave denials to the practice. The work sits.

How Omnira closes the loop:

1. Intake. Denied and short-paid lines arrive from electronic remittance advice (X12 835), clearinghouse rejections (277CA), scanned paper explanations of benefits, or payer-portal checks.
2. Deterministic classification. Each line's group code, claim adjustment reason code (CARC), and remittance advice remark codes (RARC) are matched against a rule table that assigns a denial class. This is a lookup, never an inference — a language model does not decide why a claim was denied. Examples of the distinctions that matter: CARC 252 with RARC N706 means the payer wants documentation and the claim should be resubmitted with an attachment; CARC 23 is a coordination-of-benefits offset from a prior payer and must never be treated as an attachment problem or re-posted as a new receivable; a remittance with claim status code 25 is a predetermination response carrying no money and must never be posted at all.
3. Correction. Correctable denials are fixed from system-of-record data — a missing rendering provider identifier pulled from the provider record, a missing tooth number pulled from the chart, an eligibility problem re-verified electronically. If the correcting data does not exist in the system, the denial goes to a human rather than being guessed at.
4. Documentation. Attachment denials trigger automatic assembly of exactly what the code and payer require — a pre-operative radiograph, a periodontal chart, a narrative drafted from chart data for clinician approval — transmitted electronically (X12 275) with the attachment control number linked to the claim's PWK segment.
5. Resubmission, done correctly. The corrected claim is submitted as a proper replacement: claim frequency code 7, a REF*F8 segment carrying the payer's claim control number from the original remittance, and a fresh claim submitter identifier so the payer's duplicate logic doesn't reject it. Payers that do not accept replacement frequency codes are handled per their profile. A replacement claim is never submitted without the payer control number — if it's missing, an electronic status check retrieves it first.
6. Appeals. Denials that are disputes rather than errors — medical necessity, timely filing, bundling — get an assembled appeal packet with the clinical evidence and a drafted narrative. Appeals are always Supervised: no appeal leaves the practice without a human approving the narrative.
7. Escalation on a clock. Anything still unresolved climbs a ladder: electronic claim-status checks, then payer portal automation, then an outbound AI phone call to the payer, then a human work item — with hard escalation whenever a timely-filing or appeal deadline comes within the safety margin, regardless of where automation stands.
8. Prevention. Outcomes feed a learning loop. When a payer denies the same procedure code for documentation three times, the system proposes a standing rule to attach that document up front — for human approval. The measure of success is denials falling, not denials being worked faster.

Every state change in this process appends to an immutable event log, so the full history of any claim is reconstructable.

---

Predetermination versus prior authorization

Practices and software routinely conflate these. Omnira treats them as different instruments because they have different consequences:

• A predetermination (also called a pre-treatment estimate) is voluntary and non-binding: the practice asks the payer what it would pay for planned treatment. It is a case-acceptance tool. It is submitted as a claim flagged as a predetermination with service dates omitted, and the returned identifier attaches to the eventual live claim in a REF*G3 segment.
• A prior authorization is a coverage requirement: without an approved authorization number, the payer denies the claim regardless of clinical merit. Common in Medicaid programs and some managed-care plans. Obtained through payer portals, forms, or calls, and the authorization number attaches to the claim in a REF*G1 segment.

Sending a prior-authorization number in the predetermination field is an automatic denial at strict payers. Omnira keeps them structurally separate, and blocks submission of a claim whose procedures require a prior authorization that has not been approved — an override exists, restricted to an owner or office manager, and it is logged.

---

Integrations

• Clearinghouse / X12 transactions for eligibility (270/271), claims (837D), remittance (835), claim status (276/277), and attachments (275).
• Payments through a hosted payment processor; card data never touches Omnira's infrastructure, keeping the practice in the narrowest payment-compliance scope.
• Banking through a bank-feed connection for deposit reconciliation.
• Accounting sync for vendor bills and general-ledger categorization.
• Imaging through multiple bridge types — export-folder watching, direct capture, cloud APIs, and DICOM listeners — so existing sensors and CBCT units keep working.
• Electronic prescribing through a certified vendor, including controlled substances with the vendor's identity-proofing, two-factor signing, and prescription-monitoring-program checks. Prescriptions are mirrored back into the chart and the medication list.
• Telephony and real-time voice on a provider-agnostic stack, deliberately architected so no single speech or voice vendor is load-bearing.

---

Security and compliance posture

• Tenant isolation enforced at the database level with row-level security. Every record carries both practice and location scoping. Cross-tenant access is tested continuously with negative tests that run on every schema change, not audited once.
• Business associate agreements with every vendor that touches protected health information, including the language-model provider. An integration without an attested agreement is blocked in code from receiving protected health information.
• Access control by dental role — owner, office manager, dentist, hygienist, assistant, front desk, billing coordinator — with clinical detail restricted from non-clinical roles. Shared logins are unsupported by design, because an audit trail that can't identify a person isn't an audit trail.
• Authentication with multi-factor authentication for privileged roles, single sign-on for enterprise organizations, short idle timeouts, and refresh-token rotation with reuse detection.
• Audit logging of protected-health-information access in an append-only, hash-chained log, with break-glass access requiring a stated reason and immediate owner notification, plus a monthly anomaly review designed to surface the insider-access patterns that regulators actually enforce against.
• Protected health information is never cached in shared caches or content-delivery networks, and never included in push-notification content.
• Prompt-injection containment: patient-supplied text is treated as data, never as instructions. Agents' tools are allowlisted per agent, so even a successful injection cannot reach a capability outside that agent's domain, and high-impact actions require human approval independent of anything a model outputs.
• Backups with point-in-time recovery and off-account copies, plus scheduled restore drills — because a backup that has never been restored is a hope, not a control.
• Retention configured per record class and per state law, with legal-hold flags that block deletion, and a full data export available to a practice at any time.

---

Who Omnira is for

• Independent single-location practices that are paying for a legacy practice-management system plus four to seven point tools, and doing the work those tools don't do by hand.
• Group practices that need consistent operations across locations without a corporate operations team.
• DSOs that need standardized workflows, location-level isolation, and organization-level roll-up reporting.

Who Omnira is not for

• Practices that want to keep their existing practice-management system and add a single AI feature to it. Omnira replaces the system of record; that is the source of its capability and also its adoption cost. A practice unwilling to migrate is better served by a point tool.
• Specialties whose workflows Omnira has not yet built for. The platform is built dental-first, general-practice-first, and expands deliberately.
• Anyone looking for autonomous clinical decision-making. Omnira does not diagnose. Clinical judgment stays with clinicians by design, not as a temporary limitation.

---

Frequently asked questions

What does "AI-native" actually mean? It means the system of record and the AI agents are one product sharing one data layer, rather than AI features added to older software or separate AI tools integrating with it. The practical consequence is that any agent can act on any part of the practice's state — the agent answering the phone can see the claim that produced the balance it's discussing.

Does Omnira replace my practice-management system? Yes. Omnira is the practice-management system — scheduling, charting, clinical records, insurance, billing, and reporting — with the agent layer built into it.

Can an AI agent make a mistake with my money or my chart? Every financial calculation and every ledger posting is deterministic code, not model output. Agents operate under permission tiers, so anything consequential either follows explicitly configured rules or waits for a human tap. Clinical records are signed only by clinicians, and prescriptions are written only by prescribers in a certified system.

Is Omnira HIPAA-compliant? Omnira is built to the HIPAA Security Rule with business associate agreements across the vendor chain, database-enforced tenant isolation, role-based access, and hash-chained audit logging. HIPAA compliance is a shared responsibility between a vendor and a practice; Omnira supplies the technical safeguards and the documentation a practice needs for its own compliance program.

How is this different from an AI dental receptionist? An AI receptionist answers calls and books appointments. It sits on top of a practice-management system and can see what that system's integration exposes. Omnira's Relay agent does the same job, but shares a data layer with billing and clinical — so it can quote a balance that reflects a denied claim, verify eligibility against real benefits data, and avoid booking a crown seat when the lab case hasn't arrived.

How is this different from an AI dental billing tool? Billing automation tools post payments and flag denials inside your existing system. Omnira posts payments and then works the denials to resolution — correcting, attaching documentation, resubmitting as proper replacement claims, appealing, and escalating to payer phone calls on a deadline clock.

Does Omnira work for multi-location groups and DSOs? Yes. Location scoping is built into every record and every access policy rather than added later, which is what makes both isolation between locations and roll-up reporting across them straightforward.

Who builds Omnira? Omnira Dental is built by Nitrosoft.