Overview
Business view
Dentolize has a DHS integration — a link to the Dubai Health Authority's insurance clearinghouse that lets clinic staff check a patient's insurance eligibility, verify their coverage, and submit treatment pre-approval requests without leaving the patient's chart. It's made of six screens: a settings wizard to connect the clinic's DHS account, a "check insurance" lookup, an "eligibility check" lookup, an approval-submission wizard, an approval-detail viewer, and a manual status-update tool for when the automated sync misses something.
None of that is new in this PR. All six screens already existed in the codebase. The problem this PR fixes is that they never actually reached a live clinic. Since the feature was added, the production build of the module that hosts these DHS screens (clinic-web-canary, an isolated "canary" package clinics get bundled updates from ahead of the main app) has been silently failing. The build tool couldn't handle the way the DHS screens were importing code — things like "who is the logged-in user" or "the phone-number search box" — directly from the main clinic app's source files instead of receiving them as normal component inputs. TypeScript didn't catch it because the imports were typed as any. The result: every clinic using the production canary bundle got a version with zero DHS features in it, while the code sat in the repository looking finished.
This PR is unrelated in spirit to a typical feature PR — it changes no business logic and adds no new capability. It is the fix that lets the DHS integration ship for the first time. Every one of the six screens now receives what it needs (mainly, "who is the current user and what are they allowed to do") as an explicit input from its parent screen, the way the rest of the canary package's features already worked. That one change is enough to make the production build succeed.
Technical view
What changed: packages/clinic-web-canary is a separate Vite --lib build, published and consumed by clinic-web as @dentolize/clinic-web-canary. Prior to this PR, 11 files inside it imported 17 symbols directly from the source trees of clinic-web and clinic-mobile (e.g. @dentolize/clinic-web/src/context/userContext), suppressed via 8 declare module ... : any shims in packages/clinic-web-canary/src/declaration.d.ts. Those shims satisfied tsc but not Rollup: building the canary package for production (vite build --lib) tried to transform a .js file living outside the canary project root and failed with a JSX parse error at packages/clinic-web/src/context/userContext.js:17. Per the PR description, this meant the canary bundle shipped only 9 exports with zero DHS chunks, silently, since the feature was added.
The fix: every cross-package import is replaced with a React prop. The host (clinic-web) already calls useUser() in each of the five places that mount a DHS feature; it now also forwards user={user} into the canary component. Inside canary, all nine component interfaces type user as a new DHSUser type (packages/clinic-web-canary/src/features/DHS/shared/DHSUser.ts), so a missing prop is a TypeScript compile error at every internal hop — including the three-level chain DHSCheckInsurance → CheckInsuranceModal → ReviewStep → DHSCheckEligibility. Two GraphQL queries and one utility function that were imported from clinic-mobile's barrel files were copied into canary-owned files instead, and DHSStatusPopover (485 lines of shared style + tooth-helper imports) was replaced with a 121-line canary-owned DHSStatusTag that only implements the read-only rendering the one call site actually used.
See The Build Fix: Prop Injection for the full technical breakdown, and The DHS Screens for what each of the six screens does.
Status: this is a bug fix for an already-built, unreleased-in-practice feature. It does not introduce any new DHS capability, and it does not change what a clinician sees on any of the six screens — it changes whether the code that renders them is present in the bundle at all.