Connect every employer to their benefits administrator

Problem. EN exposes a per-dependent tobaccoUseInformation.useTobacco field. Controller.php:486 assigns the parent employee's tobacco value to every dependent instead of reading each dependent's own value.

Fix. Read employees[].dependents[].demographics.tobaccoUseInformation.useTobacco per dependent. Spouse-tobacco rates differ from employee-tobacco rates for many carriers, so this matters.

Problem. Controller.php:424 hardcodes $useTypes = ['Medical']. Even though we successfully push Dental, Vision, STD, LTD, and Group Life plans to EN, when we pull census back, we silently drop every enrollment for those same lines. Brokers see employees from EN but not their dental/vision/life/disability elections.

Fix. Expand $useTypes to match the push side (Medical, Dental, Vision, STD, LTD, Group Life). The benefit-type loop and plan-storage logic in lines 494-549 should already handle additional types — verify by tracing each enrollment branch.

Problem. EN exposes employees[].companyStructureMapping with eligibilityClass, division, department, businessUnit, and officeLocation. None of these are read by Plansight. For a multi-class employer (different contributions / waiting periods / plan eligibility per class), this means we can't honor the broker's class-based logic.

Fix (medium lift). Capture eligibilityClass on the census record at minimum. Treat it as a typed enum — surface in the RFP UI and let the broker map EN classes to Plansight rate classes. Division/department can be string fields for display.

Problem. EN sends employmentInformation.benefitHireDate, jobTitle, benefitWorkState, and employmentCompensation.annualBenefitSalary. None are read in the census import.

What we'd gain. Hire date drives waiting-period logic and ACA eligibility — without it, brokers manually enter dates we already have. Salary enables salary-based plan modeling (multiple-of-earnings life, salary-banded disability). Work state matters for situs-state rating on multi-state employers.

Problem. EN sends benefitTier per enrollment (EmployeePlusFamily, EmployeePlusSpouse, etc.). Plansight ignores it and re-derives tier from dependent count. For most cases the answer matches, but EN's value is the source of truth for what the employee actually elected — re-deriving can disagree (e.g., if an employee has dependents but waived spouse coverage).

Fix. Store EN's benefitTier as the authoritative tier on the census enrollment. Use Plansight-derived tier as a sanity check, log when they differ.

Problem. EN sends employeeBenefit.effectiveDate + terminationDate (and dependent equivalents). Plansight stores neither. For renewal pulls or mid-year changes, we can't tell from the census whether someone is actively enrolled or aged off.

Fix. Capture both dates on the census enrollment. Treat enrollments where terminationDate < today as inactive.

Problem. Plansight quotes voluntary product lines through Plan Facts, but the EN integration's QuoteNotification only maps Medical/Dental/Vision/STD/LTD/Life. Voluntary lines never reach EN — the broker has to re-key them.

Fix (larger). Add benefit-type branches in QuoteNotification.php:85-108 for the voluntary lines. Each needs its own service-attribute map and rate shape. EN's API supports them — Plansight's mapping doesn't yet.

Problem. The OpenAPI spec we audit against (Quoting Engine QuoteCensusApi v1 08 21 24.json) is from 2024-08-21. The Plansight code references API v1.0 for census (QuoteCensus.php:63) and v3.0 for notifications (QuoteNotification.php:700). No version negotiation. EN may have published changes since.

Also: the example census response includes benefitEligibility.isEligible, period, and decision fields that aren't in the OpenAPI schema. Plansight reads decision == 'Elected'. If EN tightens the schema, we'd silently break.

Fix. Confirm with EN that v1 census + v3 notifications are still current and that the example-response fields are formally part of the schema. Pin the spec we ship in integrations/EmployeeNavigator/docs/ to a known-good date and refresh on a schedule.

The idea (not built). Today, when a broker starts a renewal RFP in Plansight, they have to either upload current-plan PDFs (which Plan Facts then parses) or hand-key the existing plan design. If EN already holds the same employer's current plan data, we may be able to pull plans + plan-design + current rates from EN and pre-populate the "current plans" side of the renewal automatically — bypassing the PDF dance for employers that are already on EN.

What's documented today. The OpenAPI spec we have covers Quote Census only — employee + dependent + enrollment data, not plan design. EN's wider API surface likely includes plan endpoints (the OpenAPI health benefit / life benefit / supplemental benefit / disability benefit objects within the census imply richer plan-data shapes exist server-side). We need the broader EN partner API spec to confirm exactly what's reachable.

If feasible, what we'd gain. A "Connect EN → import current plans" button on renewal kickoff that eliminates 80% of the data-entry work for any employer already on EN. Better-than-Plan-Facts accuracy for those employers, since EN's plan data is the source of truth for what's actually being administered.

What changed. Plansight's dental plantype now has category-level summary fields under Schedule of Benefits: BenefitSchedPreventiveI (Type I), BenefitSchedBasicII (Type II), Type III (Major), and Type IV (Orthodontia). These are new — before, we only had the individual procedure-level fields (Exams, Cleanings, Basic Filling, Crowns, Dentures, Implants, Periodontics, Orthodontics, etc.), which already flow into EN's service-type fields (OralExaminations, CleaningsAdult/CleaningsChildren, Fillings, Crowns, etc.). Brokers were already filling those individual benefits in — they just rolled up implicitly under each category.

The gap. The new Type I–IV summary fields in config/plantypeFiles/dental.php aren't yet wired into the EN push the way the individual procedures are. Today their integrations.employeeNavigator config either points back at one of the same procedure-level EN attributes (e.g. BenefitSchedPreventiveI → OralExaminations) or is missing entirely (Type III, Type IV). That means the category-level value the broker enters at the top of the dental Schedule of Benefits doesn't actually land in EN as a Schedule-of-Benefits roll-up — it overwrites a single procedure on EN's side, or gets dropped.

What to do. Update the dental EN integration so each Type I–IV field pushes to the correct EN Schedule of Benefits roll-up rather than overwriting individual procedure values. Confirm the corresponding EN attribute names with the broader partner API spec (Edie's pending request) before wiring — we want the roll-ups to coexist cleanly with the individual procedure fields, not collide with them.