Dentolize · DHS (NPHIES) Integration Walkthrough
On this pageBefore 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 about

For 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:

  1. FEATURE_DHS_INTEGRATION enabled for the training company.
  2. A valid DHS client secret saved (step 1 of the wizard shows a green "saved" alert).
  3. At least one branch with an NPHIES code.
  4. 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:

  1. 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.
  1. The secret is never shown again. Only **** plus the last four characters. If they

lose it, DHS reissues — Dentolize cannot recover it.

  1. 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.

  1. 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.

  1. Patient profile → Check Insurance.
  2. 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.

  1. Walk the five steps: Select Coverage → Insurance Company → Insurance Policy → Policy

Class → Review.

  1. 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.

  1. On the policy step, show all three choices — auto-create, manual form, and skip. Point

out that skipping the policy also skips the class.

  1. 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

  1. Patient profile → Check Eligibility.
  2. The Fill Missing Fields modal opens if anything is missing. Everything already known

is greyed out; only gaps are editable.

  1. 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.

  1. Show the result: a green Eligible or red Non-Eligible tag, with the check time on

hover, and a Re-check button.

  1. 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 thisWhat happensLesson
Select an operation spanning several teethGrouped-teeth refusalOne operation per tooth
Select one with quantity 2Quantity refusalSplit it
Select operations from two branchesMixed-branch refusalOne branch per claim
Select an already-invoiced operationIt isn't counted at allApprovals 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):

StepTeach
Patient InfoNearly all pre-filled and locked. Usually only Membership Number needs typing.
Request InfoMost dropdowns have one option today — that's expected, not broken.
Encounter InfoPick the practitioner from the search box; it auto-fills licence and speciality. SCFHS License is required and often blank.
DiagnosisAt least one diagnosis is required. If ICD search finds nothing, use the "Use this code" option. All five Medical Details boxes are required.
ServicesRead-only except Service Type. VAT is 15%, calculated, not editable.
ReviewRead 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:

StatusActions
PENDING / DRAFTCheck Status · Cancel Approval
APPROVED / PARTIALLY_APPROVEDCancel Approval
CANCELEDRead-only: who cancelled, when
ERRORRetry
REJECTED / DENIEDNothing

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:

  1. Turning the approved switch off resets that treatment's insurance value to zero.
  2. 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:

  1. Why don't the DHS buttons appear for this branch?
  2. What's the difference between Check Insurance and Check Eligibility?
  3. Name three reasons GET Approval might refuse your selection.
  4. An approval says ERROR. What do you do, and how is that different from REJECTED?
  5. You need to change the price of a treatment with a pending approval. How?
  6. When would you use Manual Update, and what does it permanently record?
  7. 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.