For Stakeholders

Why this matters

A previously-built feature — DHS insurance integration, one of the more substantial pieces of functionality in the clinic-web-canary module — has not been reaching production clinics since it was added. The production build of that module was silently failing to include it: TypeScript was satisfied (via any-typed shims), so the failure never showed up as a red CI check on the type-checking side, but the actual production bundler (Rollup, via Vite) could not process the direct imports the DHS code used and dropped the feature entirely, with no error surfaced to anyone shipping the module. Per the PR description, this has been true since DHS was first added to the canary package.

Risk

• Before this PR: any clinic depending on the production canary bundle had zero DHS

functionality, invisibly. There was no error, crash, or log line pointing at the gap — the bundle simply exported fewer things than the source code implied.

• This PR's fix: removes the root cause (direct cross-package source imports) by

replacing them with explicit React props, following a pattern (PatientTimeline) already proven elsewhere in the same package. This is architecturally the same kind of change repeated ~20 times across 11 files — mechanical, and each callsite is independently type-checked.

• Residual risk: the five places in the host app (clinic-web) that now pass the

user prop into a DHS canary component are plain .js files with no TypeScript coverage. If a future edit to one of those five files drops the prop, the affected DHS screen goes silently blank (no crash, no error) rather than failing loudly. This is documented as a known, accepted limitation in the PR, not a defect introduced by it — the same class of risk already existed for every other prop the host passes into canary features.

Impact if merged as-is

• DHS integration becomes available to ship to clinics for the first time since it was

built, pending the normal decision of when/how to turn on FEATURE_DHS_INTEGRATION per tenant.

• No behavior changes for any clinic not using DHS — the change is scoped entirely to how

six already-existing screens are wired together internally.

• No database schema, API contract, or permission model changes.

What to verify before treating this as "safe to merge"

The PR description itself calls out four manual checks that should happen before merge, beyond automated tests — see For Quality for the full list. The most consequential one: the three-hop nested render (DHSCheckInsurance → CheckInsuranceModal → ReviewStep → DHSCheckEligibility) fails silently if broken, so it needs an actual human click-through, not just a passing build.