On this page
Before you teachThe mental model to teach first (10 min)Module 1 — Setup (for owners/managers only, 15 min)Module 2 — Reception: discovery and eligibility (25 min)Module 3 — Clinical: submitting a pre-auth (25 min)Module 4 — Managing approvals (15 min)Module 5 — The locks (10 min, everyone)AssessmentKnown rough edges to warn aboutFor Training
A teachable sequence for clinic staff. Roughly 90 minutes, split by role. Screens referenced here are shown in the Feature Tour.
Before you teach
Set up a training environment with all four prerequisites met, or half the session will be spent explaining why buttons are missing:
FEATURE_DHS_INTEGRATIONenabled for the training company.- A valid DHS client secret saved (step 1 of the wizard shows a green "saved" alert).
- At least one branch with an NPHIES code.
- The trainer's permission group holding all nine DHS permissions.
You also need at least one insured patient with un-invoiced operations on their chart. This catches people out: if every operation is already invoiced, GET Approval stays disabled and the centrepiece of the lesson cannot be demonstrated. Chart a fresh procedure before the session.
The mental model to teach first (10 min)
Do not open the app yet. Draw three boxes on a whiteboard:
WHO insures them? → Check Insurance
Is it LIVE today? → Check Eligibility
Will you PAY for this? → GET Approval (pre-authorization)
Then add the fourth idea, which is the one that changes behaviour:
While the payer is deciding, the treatment is LOCKED.
Everything else in the lesson is detail hanging off these four. If a learner leaves remembering only these, the session succeeded.
Two vocabulary points worth nailing down early, because they cause confusion later:
- Pre-authorization is not a claim. Pre-auth happens before treatment and asks the
payer to commit. The claim comes later.
- NPHIES identifies the branch, not the company. Each site has its own provider code, and
every check is filed under one specific site.
Module 1 — Setup (for owners/managers only, 15 min)
Settings → Integrations → DHS Integration.
Walk the three steps. Points to make:
- The secret is tested, not just stored. Press Save & Test Connection with a
deliberately wrong secret first. Show that nothing is saved. This teaches them that a silent-looking failure means a bad credential.
- Warn them the error is a transient toast. Tell them to watch the top of the screen.
- The secret is never shown again. Only
****plus the last four characters. If they
lose it, DHS reissues — Dentolize cannot recover it.
- Rotation is deliberate. Typing a new secret over an existing one rotates it, and the
old one is only replaced after the new one is proven to work.
- Branch codes are the gate. This is the single most important slide. Show a patient
screen before setting the branch code, then after. The DHS buttons appear.
- Exercise: have them predict what happens to the Approvals tab before you reload.
Teaching note: Submit Changes on step 2 stays disabled until something actually changes, and re-disables if you undo an edit. Learners often think the button is broken.
Module 2 — Reception: discovery and eligibility (25 min)
Check Insurance
Start from a patient with a national ID but no insurance company set.
- Patient profile → Check Insurance.
- If it's greyed out, ask the room why. (Answer: no identifier type, or no national ID.)
This is a better teaching moment than avoiding it.
- Walk the five steps: Select Coverage → Insurance Company → Insurance Policy → Policy
Class → Review.
- On the company step, deliberately use a coverage whose insurer is not in the system, so
the amber "doesn't exist" state and the pre-filled Add New Company form both appear.
- On the policy step, show all three choices — auto-create, manual form, and skip. Point
out that skipping the policy also skips the class.
- On Review, read out the four possible statuses: existing, auto created,
manually created, skipped.
Point out the shortcut: if all three already exist, the wizard jumps straight to Review. Learners who see this the first time often think it's broken.
Check Eligibility
- Patient profile → Check Eligibility.
- The Fill Missing Fields modal opens if anything is missing. Everything already known
is greyed out; only gaps are editable.
- Teach this explicitly, do not skip it:
> "When you press OK, two things happen in order. First the patient record is updated with > what you typed — permanently. Then the eligibility check runs. If the check fails, the > patient record has still been changed."
This is real behaviour and it surprises people. It is also a feature — the clinic keeps the data-quality improvement. Frame it that way.
- Show the result: a green Eligible or red Non-Eligible tag, with the check time on
hover, and a Re-check button.
- Explain why the tag can vanish: it only shows while the patient's insurer still matches
the insurer the check was run against.
Exercise: two patients — one fully populated (no modal, instant check), one with gaps (modal appears). Have learners predict which will show the modal.
Module 3 — Clinical: submitting a pre-auth (25 min)
Patient → Chart. Select operations, press GET Approval (n).
Teach the refusals first
Deliberately trigger them before doing a successful run. Each produces a notification listing the offending treatments:
| Try this | What happens | Lesson |
|---|---|---|
| Select an operation spanning several teeth | Grouped-teeth refusal | One operation per tooth |
| Select one with quantity 2 | Quantity refusal | Split it |
| Select operations from two branches | Mixed-branch refusal | One branch per claim |
| Select an already-invoiced operation | It isn't counted at all | Approvals come before invoicing |
That last one deserves emphasis: the button shows the count of eligible treatments, so GET Approval (0) means everything selected was excluded.
Then walk the wizard
Six steps (seven when the treatments have attached files):
| Step | Teach |
|---|---|
| Patient Info | Nearly all pre-filled and locked. Usually only Membership Number needs typing. |
| Request Info | Most dropdowns have one option today — that's expected, not broken. |
| Encounter Info | Pick the practitioner from the search box; it auto-fills licence and speciality. SCFHS License is required and often blank. |
| Diagnosis | At least one diagnosis is required. If ICD search finds nothing, use the "Use this code" option. All five Medical Details boxes are required. |
| Services | Read-only except Service Type. VAT is 15%, calculated, not editable. |
| Review | Read it. Once submitted, the treatment locks. |
Critical teaching point: pressing Next with an invalid field on an earlier step silently does nothing — the error is off-screen. Teach learners to step backwards through the wizard when Next seems dead, rather than clicking harder.
After submission
Show the treatment on the chart with its status tag, and open Chart → Approvals.
Module 4 — Managing approvals (15 min)
Patient → Chart → Approvals.
Columns: Approval Number, Approval Status, Response Date, Manual Updated, Created, Last Updated. Read-only — no add, no edit.
The status popover
Hover the status tag. Contents change by status:
| Status | Actions |
|---|---|
| PENDING / DRAFT | Check Status · Cancel Approval |
| APPROVED / PARTIALLY_APPROVED | Cancel Approval |
| CANCELED | Read-only: who cancelled, when |
| ERROR | Retry |
| REJECTED / DENIED | Nothing |
Teach the eight statuses, and especially the difference between REJECTED/DENIED (the payer said no) and ERROR (we couldn't get an answer, or didn't understand it). Only ERROR is worth retrying.
Say this about waiting
"You do not need to check anything. Dentolize asks the payer every minute. Check Status is for when you're impatient, not because it's required."
Cancelling
Only PENDING and APPROVED can be cancelled. Teach what it does: zeroes the insurance value on every linked treatment, un-approves them, and unlocks the treatment fields so the clinic can correct and re-submit. The approval number is kept as an audit trail.
Manual Update
For when the payer answers by phone or email. Teach two things:
- Turning the approved switch off resets that treatment's insurance value to zero.
- It stamps the approval as Manually Updated with the user's name, permanently. This
is deliberate — nobody should ever mistake a hand-entered figure for a payer-confirmed one.
It is blocked once an approval is APPROVED, REJECTED or CANCELED.
Module 5 — The locks (10 min, everyone)
Short but the highest-value module for preventing tickets.
While an approval is PENDING: the treatment cannot be invoiced, and a quotation containing it cannot be converted.
While any approval exists (except cancelled): price, quantity, tooth, doctor, creation date and diagnosis are all read-only. Manual approve/deny is disabled.
Always: the pre-auth number itself is read-only, even after cancellation.
After cancelling: everything unlocks except the pre-auth number.
Frame it positively:
"The system is stopping you from billing something the payer hasn't agreed to. If a field is locked, that's the point — not a fault."
Exercise: have a learner submit an approval, then try to change the price, then try to invoice it, then cancel and change the price successfully. That single loop teaches the whole model.
Assessment
Learners should be able to answer, without prompting:
- Why don't the DHS buttons appear for this branch?
- What's the difference between Check Insurance and Check Eligibility?
- Name three reasons GET Approval might refuse your selection.
- An approval says ERROR. What do you do, and how is that different from REJECTED?
- You need to change the price of a treatment with a pending approval. How?
- When would you use Manual Update, and what does it permanently record?
- If you fill in the eligibility modal and the check fails, what happened to the patient
record?
Known rough edges to warn about
So learners don't file tickets for them (see Known Gaps):
- Logs → Approvals does not work on this build. Use the per-patient Approvals tab.
- The DHS Settings permission tab is visible even for clinics without the feature.
- Several dropdowns in the approval wizard have a single option by design.
- Error messages are transient toasts — tell people to watch the top of the screen.