For Support

What changed that a user might notice

For most clinics: nothing. This PR doesn't change any DHS screen's behavior, layout, or copy. It fixes whether the DHS screens are present in the production build at all.

The one group who might notice something is a clinic that already had DHS enabled and configured before this PR shipped — for them, DHS features that were silently absent from the app (buttons/tabs that simply weren't there) should now appear, assuming their branch still has a valid DHS branch-code mapping and the feature flag is on for their tenant. If a clinic reports "the DHS button just showed up" or "I don't remember configuring this," that is expected and not a bug — check with engineering/product whether this was a known-broken tenant before this fix.

If a user reports a DHS screen is missing

Walk through the same gating conditions the code checks, in order:

1. Is the feature flag on for this tenant? (FEATURE_DHS_INTEGRATION) If not, no DHS UI

appears anywhere, by design.

1. Does the user have the relevant permission? Each screen requires a specific

permission: viewDhsIntegration (settings), checkDhsInsurance (check insurance), checkDhsEligibility (check eligibility), createDhsApproval (approval submission), createManualDhsApproval (manual update), viewDhsApprovals (approval detail/log). Check the user's permission group under Settings → Groups.

1. Is the branch mapped to a DHS branch code? The patient-facing screens (check

insurance, check eligibility, approval submission) additionally require the patient's branch to have completed the "Load Branches" step of the DHS Integration Settings wizard. No mapping, no button — even with the flag on and the permission granted. This is the single most common reason a fully-permissioned user won't see a DHS action button.

1. Has the clinic actually connected a DHS account? Settings → Integrations → DHS

Integration → step 1 (Client Secret) must have a successful "Save & Test Connection" before step 2 can complete.

If a DHS approval seems "stuck" or a status doesn't update

• The Approval Detail page (reached from the DHS approvals log) shows the raw

request/response payload DHS returned — useful for confirming whether Dentolize sent the request correctly and what DHS actually said back, before escalating to engineering.

• The Manual Update action (in the patient chart, per pending operation) lets staff mark

an operation's status by hand if the automatic sync isn't reflecting what DHS shows on their side. This is a legitimate workaround, not a bug report on its own.

• If a patient's balance/invoice doesn't reflect a just-approved DHS submission, ask the user

to refresh the page before escalating — see the known caching caveat in For Quality, which explains one scenario where a refresh is the correct interim fix.

What this PR does NOT affect

• NPHIES (Saudi) integration screens and workflows — separate feature, untouched here.
• Any DHS business logic — approval eligibility rules, status values, what counts as

"eligible for resubmission" — is unchanged. Only whether the screens ship at all changed.