For Marketing

Before you write anything: this feature is unreleased and gated to a beta cohort. Nothing here may be published as available, shipping, or live. Everything below is launch-ready material, not launch-ready claims.

The one-sentence version

Dentolize now talks to NPHIES directly, so a clinic can confirm a patient's insurer, check their cover, and get a treatment pre-approved without ever leaving the patient's chart.

The problem, in the customer's words

Ask a Saudi clinic manager what wastes their front desk's day and you will hear some version of this:

"The patient says they're with Bupa. We open the payer portal, log in, type the ID, find out it's actually Tawuniya. Log in again. Check eligibility. Then the doctor plans the treatment, and someone has to retype every procedure code into the portal to get approval. Then we check the portal three times a day to see if they answered. And sometimes we invoice before the answer comes and it gets rejected and we eat the cost."

That is four separate problems: discovery, verification, re-keying, and waiting. This feature addresses all four.

Positioning

Category: insurance workflow automation, embedded in the clinical record.

The wedge: most practice-management systems treat insurance as a billing afterthought — a field on the invoice. This treats it as a clinical workflow that starts at check-in and ends when the payer commits. The pre-auth is submitted from the treatment chart, by the person planning the treatment, using data that is already in the system.

The defensible bit: the guards. Anyone can add a "submit to NPHIES" button. Making the rest of the system respect the pending approval — refusing to invoice it, freezing its price and tooth, unlocking them again on cancellation — is the part that actually prevents revenue leakage, and the part that is genuinely hard to bolt on later.

Message pillars

1. One screen instead of two systems

Discovery, eligibility and pre-auth all happen inside the patient record. No portal, no second login, no re-keying. The pre-auth wizard arrives pre-filled from the chart: the procedures, the tooth numbers, the prices, the practitioner, the dates.

Proof point: of the ten fields on the pre-auth's patient step, nine arrive pre-filled and locked. On the sandbox walkthrough only Membership Number required typing.

2. The system knows what's pending

While an approval is with the payer, the treatment is frozen: it cannot be invoiced, re-priced, moved to another tooth, or reassigned. When the payer answers, the approved amounts land on the operations automatically. When an approval is cancelled, the treatment unlocks so it can be corrected and re-sent.

Proof point: six protected fields, an invoicing block, a quotation-conversion block, and automatic amount reconciliation from the payer's own service-line response.

3. It chases the payer for you

A background job polls pending approvals every minute. Nobody has to remember to check.

Proof point: one-minute schedule, up to 100 approvals per pass, with the payer's status mapped onto eight clinical states including Partially Approved.

4. Credentials handled properly

The clinic's DHS client secret is validated before it is stored, encrypted at rest with AES-256-GCM, and never shown again — only a ****#### mask. Rotation is a separate, deliberate action that only replaces the old secret once the new one is proven to work.

Proof point: this is worth saying plainly to a security-conscious buyer. Many competitors store payer credentials in plain text.

5. Insurers get created as you go

When discovery finds an insurer, policy or class the clinic doesn't have yet, the wizard offers to create it inline, pre-filled from the payer's own data. Previously this meant leaving the patient, creating three records by hand, and coming back.

Language guide

Use:

• "Submit a pre-authorization without leaving the patient chart"
• "Confirm cover before you treat"
• "Approvals that update themselves"
• "Treatments stay locked while the payer decides"
• "NPHIES-connected"

Avoid:

• ❌ "NPHIES certified" / "NPHIES compliant" — this is an integration with the DHS platform;

certification is a separate claim nobody has made.

• ❌ "Instant approvals" — the payer decides the timing. Dentolize polls every minute; the

payer may take days.

• ❌ "Automatic claim submission" — this is pre-authorization, not claim submission. They

are different steps and conflating them will get corrected by any clinic manager.

• ❌ "Works with all insurers" — coverage depends on what the exchange returns.
• ❌ "Now available" — it is behind a flag, for beta companies only.

Assets you can build from

The Feature Tour has real screenshots from the branch build: the setup wizard, the eligibility pre-flight, the Approvals tab, and all six steps of the pre-auth wizard. They are unretouched product, not mockups.

Two caveats before you reuse them:

• The screenshots come from a seeded demo clinic ("Sandbox Dental", patients named

"Patient 011"). Re-shoot with realistic names before anything customer-facing.

• No screenshot shows a successful payer response, because the sandbox has no real DHS

credential. If a launch asset needs a green Approved state, it must be captured from a properly credentialled environment — do not fabricate one.

Launch sequencing

Because rollout is per-company via a beta flag, this is not a "big bang" launch. The natural shape is:

1. Design-partner phase — a handful of beta clinics, no public marketing.
2. Reference-building phase — collect real numbers from those clinics: minutes saved per

pre-auth, rejections avoided. This feature's story is much stronger with one real customer figure than with any amount of capability description.

1. General announcement — only once the flag rule is widened.

The single most valuable thing marketing can do during phase 1 is instrument for phase 2: agree now with the beta clinics what "before" looks like, so there is a baseline to compare against.