+
The bidirectional integration between Plansight's quoting platform and Vertafore's BenefitPoint agency management system — keeping every plan, rate, benefit summary, and renewal in sync between the system brokers quote in and the system of record they bill from.
A purpose-built, two-way data bridge between Plansight and BenefitPoint. Brokers quote and shop plans in Plansight, then push them to BenefitPoint with one click — and BenefitPoint's authoritative book of business flows back into Plansight so brokers always work from a single source of truth.
Brokers associate a Plansight account with a BenefitPoint account. Every product, plan, rate, benefit summary, and contribution rule on the BP side is imported and kept current — automatically — through scheduled change-tracking calls.
When a broker finishes shopping and the client picks a plan, Plansight builds the BenefitPoint product, benefit summary, rate structure, contributions, and eligibility — and pushes it directly into the BP record. No re-keying, no double entry.
Every plan tracks an origination reason — new, renewal, or replacement — and the integration applies the right copy-from-prior, send-fresh, or auto-match logic per reason. Renewal pushes auto-match the BP plan; new pushes prompt for taxonomy.
Every brokerage configures its own BenefitPoint API credentials and runs in isolation — separate Web Services authentication, separate per-brokerage cache, separate feature flags. The same code path serves single-office shops and 50-office multi-region brokerages alike.
Brokerages live in BenefitPoint. It's where they manage commissions, books of business, renewals, and the agency operations that keep the lights on. Plansight is where the work of quoting happens. Without integration, those two worlds require duplicate data entry on every plan that gets sold.
Quote in the platform built for it. Push the result into the system of record with one click. No spreadsheet hand-offs, no dual entry, no "I forgot to update BP." When BP is the source of truth on renewals, Plansight stays in lockstep — automatically.
Compliance, commissions, and reporting all run off BenefitPoint. The integration means every plan Plansight produces is BP-correct: right product type, right carriers, right rate structure, right benefit summary, right effective dates. Audit-ready by default.
The plan that wins on screen in Plansight is the same plan that gets billed, renewed, and serviced. No translation errors. No "we're showing one rate but BP has another."
Plansight is BenefitPoint's preferred quoting partner. The integration makes Plansight a natural extension of BP — the front-end where the modern broker workflow lives, feeding the agency-management spine BP already provides.
Quoting, presentation, and shopping are upstream activities — they're best done in a tool purpose-built for them (Plansight). Servicing, billing, commissions, reporting, and historical tracking are downstream activities — they belong in the system that's done them for decades (BenefitPoint). The integration is the seam: it makes the upstream and downstream behave like one system.
When a broker hits "Push to BenefitPoint" in Plansight, here's what happens.
The job loads every quote in the plan group from a fresh database read, verifies they all belong to the same plan group, and clears any prior error state. Single-mode pushes one quote; multi-summary mode pushes every quote as its own benefit summary.
Before building anything, the integration calls GetAccount to fetch the current primarySalesLeadUserID and primaryServiceLeadUserID directly from BP. These were historically cached on the Plansight quote, but recent changes always re-fetch them so renewals never carry stale lead assignments.
ProductModel::fromPlansightModels($quotes) assembles the BP product object: name, plan type, carriers (writing + billing), origination reason, effective and renewal dates, policy/group number, and every benefit attribute mapped through Plansight's BP-code dictionary.
By default, products push via the modern REST endpoint — CreateProductRest with a JSON body. Brokerages on custom WSDL URLs push via SOAP CreateProduct. The product is created with view level Core (110); admin overrides are available to "overwrite" an existing product.
After the product is created, postProcess() runs the dependent operations: UpdateBenefitSummary (or CreateBenefitSummaryFromCopy on renewal), CreateRateRest per rate type, CreateContributionRest per contribution structure, CreateEligibilityRuleRest, and a DeleteBenefitSummaryRest to clean up BP's auto-created "All Employees" empty summary if the broker wants to replace it.
If any step fails, the JSON error response is parsed and decorated. "Invalid billingCarrierID for the selected billingCarrierType" becomes "Billing carrier 'Aetna' is not valid for product type 'Medical PPO'" — with the carrier name, billing carrier type, and product type all resolved from the per-brokerage cache. The error is stored on the quote so the UI can show it next to the right plan.
The push runs as an async queue job. Pushing a multi-option plan group with renewal carry-over from prior plans can fan out to 20+ BP API calls — and BP's API can take a few seconds per call. Running on the queue means the broker's UI returns instantly, the user sees a "pushing..." status, and any retries happen without breaking the user's flow.
Two push-side capabilities are toggled per-brokerage rather than universally. Both are off by default; turn-on is a deliberate decision per brokerage.
replacement and links the new push to the prior product. For some brokerages this isn't desirable (their BP workflow expects every push to be a fresh new), so we expose a flag that disables the replacement path entirely — every push goes in as new.Both flags live on the brokerage record. Coordinate with whoever owns brokerage configuration before flipping either one — they meaningfully change what BP sees on the other side.
Plansight stays current with the BenefitPoint book of business through three nested jobs running on a low-priority queue.
PullProducts(brokerageId) finds every Plansight group with a benefitPointId and dispatches PullProductsByGroupId for each — typically hundreds of jobs for a large brokerage.
FindProducts(benefitPointId) lists every product on the BP account. The integration deduplicates BP's known internal product-replication bug, applies the reachBackRenewalDate filter to skip ancient plans, and dispatches PullProductById for each survivor.
Service::importProduct(groupId, productId) calls GetProductRest, FindBenefitSummaries, FindRates, GetContributionsSummaryList, GetEligibilityRuleSummaryList — and assembles a complete Plansight quote from the responses.
Every numeric BP attribute ID (45 = Per Individual deductible, 386 = Primary Care, 414 = Specialist, 902 = Telehealth, etc.) is translated to its Plansight equivalent through the master attribute map. Unsupported plan types are filtered against the deny-list.
A QuoteBenefitHistory is created or updated with source = 'benefitPoint', BP's product ID written back via setIntegrationData, and the right origination reason inferred from the BP product's history.
The full pull is heavy. For day-to-day freshness, the benefit-point:pull-changes artisan command runs on a schedule, calling BP's FindChanges API to pull only what's changed since last run — minutes of work instead of hours.
BenefitPoint's product taxonomy has hundreds of entries — annuities, executive benefits, individual lines, retirement products, and more. Plansight integrates the 24 plan types brokers actually quote in modern employee benefits.
Synced Medical HMO, PPO, POS, EPO, Indemnity
Synced Prescription Drug Carve-Out
Synced Stop Loss
Synced Telehealth, Patient Advocacy
Synced Transplant Carve-Out
ToDo Medical Gap (GAP)
Synced HRA
Synced HSA
Synced FSA
Synced COBRA Administration
ToDo FMLA / Leave Management
Synced Dental — Managed, PPO, HMO, Triple Option, Indemnity
Synced Vision & Voluntary Vision
Synced Basic Life and AD&D
Synced Voluntary Life and AD&D
Synced Short Term Disability (STD & Voluntary)
Synced Long Term Disability (LTD & Voluntary)
Synced Employee Assistance Program (EAP)
Synced Legal, Pet Insurance, Identity Theft
Synced Accident & Voluntary Accident
Synced Hospital Indemnity
Synced Critical Illness & Voluntary Critical Illness
Synced Cancer Coverage & Voluntary Cancer
Skip Group Term Life, AD&D-only, BTA
Skip 401(k), 403(b), 457, 529, IRA
Skip Annuities, Universal Life, Whole Life
Skip Individual Medical / Dental / Vision
Skip Executive Benefits (FCC) lines
Skip International Bundled, State Statutory DBL/TDB/TDI/SDI
BenefitPoint divides offerings into Plans (carry rate and benefit data — Medical, Dental, etc.) and Products (services without rate structures — Telehealth, COBRA, etc.). Plansight syncs Plan Information for both, but only pulls Plan Design + Rates for actual Plans.
Every plan type, product type, and benefit attribute · filterable by sync status
BenefitPoint identifies every benefit attribute by an internal numeric ID. Plansight maintains a master mapping that translates those numeric codes into Plansight's named fields, in both directions.
| Plansight Field | BP ID | Notes |
|---|---|---|
| Per Individual Deductible | 45 | Annual medical deductible, in-network individual |
| Per Family Deductible | 44 | Annual medical deductible, in-network family |
| Deductible Type | 973 | Embedded vs aggregate |
| HSA Eligible | 873 | High-deductible health plan flag |
| OOP Per Individual | 53 | Annual out-of-pocket maximum, individual |
| OOP Per Family | 52 | Annual out-of-pocket maximum, family |
| Primary Care | 386 | Office visit copay/coinsurance |
| Specialist | 414 | Outpatient specialist visit |
| Telehealth | 902 | Telemedicine |
| Emergency Room | 184 | ER copay/coinsurance |
| Urgent Care | 555 | Urgent care facility |
| Inpatient | 295 | Inpatient facility & physician |
| Mental Health Outpatient | 407 | Mental health outpatient services |
| Substance Use Inpatient | 670 | Substance use inpatient hospitalization |
| Rx Tier 1 (Generic) | 880 | Preferred generic drug tier |
| Rx Tier 4 | 84 | Non-preferred brand |
| Mail Order | 378 | Mail-order Rx |
BenefitPoint doesn't expose its attribute codes in normal API responses — they're internal IDs. Plansight extracted them via metadata calls (GetBenefitSummaryStructure, GetProductTypes, FindRates) when the integration was first built and maintains them as the source of truth for every push and pull. The full dictionary covers Medical, Pharmacy, Stop Loss, Dental, Vision, EAP, Basic Life, Voluntary Life, HRA, STD, and LTD.
Both sides of the pipe — what comes in from BenefitPoint, and where the resulting data lives in Plansight.
The modern REST endpoint for product creation, rate creation, contributions, eligibility rules, and benefit summary management. The default API surface for new pushes since 2024.
The legacy SOAP API on V4.2 / V4.3. Still used for accounts, listings, structure fetches, and any brokerage configured with custom WSDL URLs. Auth via session token cached for 55 minutes.
Where every imported account, plan, rate, contribution, and eligibility rule lands. The same store that powers Plansight's quoting flow — meaning BP-pulled data is immediately available to brokers without a translation layer.
Each brokerage has a dedicated cache holding BP offices, users, writing carriers, and billing carriers. Refreshed by the benefit-point:brokerage-cache command. Powers every dropdown that asks the broker to pick a BP entity.
Bulk pulls and brokerage-wide syncs run on the redis-low queue. Push jobs run on the standard queue with retries and error context capture. Nothing blocks the broker's UI.
The benefit-point:pull-changes command runs on a recurring schedule, calling BP's FindChanges API to keep Plansight current without re-fetching the full book of business.
The integration is designed to work for any brokerage that runs its book of business on BenefitPoint and quotes new and renewal plans through Plansight. The shape of the work is the same regardless of size.
One BP API user, one office, one set of carriers. Onboard once, push and pull from there. The integration's simplest case — and where most of the value comes through with the least configuration overhead.
One BP API user can have access to multiple regions and offices. The integration scopes every operation to the offices the API user can see, so a national brokerage can run dozens of regional offices through a single Plansight tenant without cross-contamination.
Brokerages that operate as multiple legal entities (acquisitions, subsidiaries, partner-brand structures) typically maintain separate BP carrier rosters. Each entity gets its own brokerage configuration — separate credentials, separate cache, separate feature flags — and shares only what should be shared.
Brokerages with hundreds or thousands of employer accounts move large amounts of data on a renewal cycle. The async queue architecture and scheduled FindChanges sync are designed for that scale — bulk pulls run on a low-priority queue, daily delta syncs keep things fresh without re-fetching the full book.
The same operations, the same struct definitions, the same BP code dictionary, the same job runners serve every brokerage running on the integration. Tenant-specific behavior is expressed through per-brokerage feature flags and credentials — never through forks of the integration code itself. That's how it stays maintainable as more brokerages join.
A self-contained Laravel package inside the Plansight monolith, designed to be testable, debuggable, and operable per-brokerage without affecting other tenants.
Backend: Laravel · PHP 8 · ~300 files
API: Native PHP SoapClient + Symfony NativeHttpClient for REST
Storage: AWS DynamoDB (per-brokerage tenant data)
Async: Redis queues — default for push, redis-low for bulk pulls
Cache: Per-brokerage flat-file BenefitPointCache + 55-min session token
Auth: Per-brokerage encrypted Web Services credentials
integrations/BenefitPoint/ ├── Api.php ← auth, SOAP/REST client, retry ├── Service.php ← 3,309-line orchestrator ├── BenefitPointCache.php ├── Controller.php ← all UI/HTTP endpoints ├── ContributionData.php ├── RateData.php ← 188KB rate-mapping helper ├── Operations/ ← 42 API call wrappers ├── Structs/ ← 128 PHP DTOs (Account, Product, │ Rate, BenefitSummary, …) ├── Enums/ ← 112 BP value sets ├── Jobs/ ← 6 async queue jobs ├── Commands/ ← 6 artisan CLI commands ├── Concerns/ ← shared traits ├── Contracts/ ← Operation interface ├── Views/ ← Blade templates └── Scripts/BP.js
Per-brokerage feature flags
Integration on/off, multi-summary mode, custom WSDL URLs — all per-brokerage. Can disable mid-incident without code change.
Structured error capture
Every push error stores parsed JSON, raw response, and resolved entity names on the quote — surfaceable in the UI without digging through logs.
Truncation-aware logging
SOAP request/response logged to bpDebug, with smart truncation for noisy operations like findOffices, createBenefitSummary, and getBenefitSummaryStructure.
A typical client's plan lives in both systems for years. Here's how the integration handles each phase of the renewal cycle.
Broker shops a new plan in Plansight, picks a winner, clicks "Push to BenefitPoint". The integration picks the BP plan type from BP's taxonomy, builds the product with origination reason new, sends rates and benefit summary, and stores the BP product ID on the Plansight quote.
The plan lives in BP. Plansight's scheduled pull-changes command keeps the broker's view in sync — if anyone updates the plan in BP (rate change, carrier change, contribution adjustment), Plansight reflects it within the next sync window.
120 days from renewal, Plansight surfaces the renewing plans. The broker shops the renewal in Plansight, comparing carriers and options. The integration knows the parent plan and pre-populates Plansight with the prior plan's structure.
When the renewal is ready, the broker pushes with origination reason renewal. The integration auto-matches to the existing BP plan, copies forward Broker of Record, Splits, Eligibility, and Contributions from the prior plan, and overwrites only what changed — rates, benefit attributes, dates.
If the broker switches carriers entirely, origination reason becomes replacement. The new plan gets pushed fresh, but with the parent's identity preserved so BP's reporting connects the old policy and the new one as a single ongoing relationship.
Mid-year amendments (rate changes, carrier corrections, eligibility tweaks) flow through the same push pipeline. The broker edits in Plansight, pushes, and BP's record updates. No re-keying.
Every quote in Plansight carries an originationReason: new, renewal, or replacement. The integration's behavior — what's copied from the prior plan vs. sent fresh, what's auto-matched vs. user-picked, what error patterns are tolerated — branches off this single field. Get the origination reason right and the rest of the integration follows.
Patterns that hold across every operation, every brokerage, every plan type.
One Plansight account binds to exactly one BP account, and vice versa. No fan-out, no fan-in. This constraint keeps multi-office brokerages modeling their structure deliberately, and simplifies every downstream operation by removing ambiguity about which BP record a Plansight quote belongs to.
BP's control splits setting must be enabled on the BP side for the integration to function. Without it, associations succeed silently but pushes do nothing — a known failure mode that's now part of the pre-onboarding checklist.
Sync from BP → Plansight runs on a schedule. Push from Plansight → BP is always user-triggered. The integration never silently writes to BP — every push corresponds to a deliberate broker action with a visible audit trail.
Plansight maintains a 150+ entry list of BP product type IDs the integration intentionally skips: annuities, executive benefits, individual lines, retirement products. The list is checked in code on every operation. New plan types are added deliberately, never by accident.
Every push error is captured on the quote it failed for, with a parsed JSON payload, a raw response, and resolved names for billing carrier, writing carrier, and product type. The broker doesn't need a log file to understand what went wrong.
BP session tokens cache for 55 minutes. When BP returns "session is not valid", the retry loop forgets the cache and re-logs in once, transparently. Brokers never see auth churn.
Plansight has the receiving side of a BenefitPoint single-sign-on flow scaffolded and routed. The endpoint is live in production. BenefitPoint hasn't enabled the emitter on their side yet — once they do, the controller fleshes out the click-through experience.
A pair of routes registered in routes/web.php:128-130 — both GET and POST on /benefitPointSSO. The controller (app/Http/Controllers/BPSSOController.php) is currently a placeholder that logs the inbound request payload via Log::debug and returns. Built by Trevor.
BenefitPoint hasn't shipped the SSO emitter yet. When they do (Vertafore handles the timing), Plansight will see real signed payloads at /benefitPointSSO and the controller body needs to: validate the signature, resolve the BP user to a Plansight user, mint a Plansight session, and redirect to the right deep link (account, quote, etc.) inside Plansight.
SSO from BenefitPoint into Plansight removes the second login. A broker working in BenefitPoint can click a Plansight link and land on the right account/quote without re-authenticating. It's also the most natural point of integration to surface Plansight inside the BenefitPoint UI itself once Vertafore exposes the deep-link API.
Owner: Trevor on the Plansight side. Status: Waiting on Vertafore. When they have a date, the controller body is a half-day of work.
Seven findings from a fresh pass through integrations/BenefitPoint/ in Plansight APP 9d1afd54d5df. None are existential — the integration works in production every day — but each is the kind of issue that produces "unreproducible" bug reports until someone goes looking. Rank order is rough impact-weighted.
Problem. Vertafore exposes FindChanges (returns only records modified since a timestamp) and Plansight has it implemented at integrations/BenefitPoint/Operations/FindChanges.php — but the only caller is Commands/PullChanges.php, which isn't wired into the main sync flow in Controller.php or Service.php. Every product sync today is a full refresh.
Why it matters. Full refreshes are slow and burn API budget. For brokerages with hundreds of accounts, this is the difference between a sync that takes seconds and one that takes minutes (or trips a rate limit, see #4 below).
Wire FindChanges into Service::syncBrokerageProducts(): check for a last_sync_at timestamp on the brokerage; if present, call FindChanges and use only the returned product IDs to drive detail fetches. Fall back to full sync when no timestamp exists or FindChanges errors. Update last_sync_at after a successful run.
Problem. When FindOffices, GetAvailableCarriers, or FindUsers returns an empty collection (transient error, partial outage, auth slip), Service.php:2579-2590 still writes the empty result over the prior cache. The next UI request that depends on offices or carriers gets a silently empty list. Users see "no offices available" with no error surfaced.
Fix sketch. Reject empty replacements before persisting — keep the stale cached value and log a warning. An "empty after fetch" should be treated as "fetch failed" until proven otherwise.
In Service::putBrokerageUserCache(), before writing each of offices, users, availableCarriers, and billingCarriers to Storage::put, check if the new value is empty. If it is and a non-empty cached value exists, log a warning ("BP cache update rejected — empty {key} from API") and keep the prior value. Only overwrite when the new value is non-empty OR the prior value was also empty.
Problem. Api.php:464-467 caches login tokens using just brokerage->id. The getLoginToken() method has a commented-out brokerageId parameter implying support for one Plansight brokerage bridging multiple BP tenants — but the cache key doesn't include it. If we ever turn that on (or a single brokerage's BP auth changes), tokens will collide across tenants.
Update loginCacheKey() in Api.php to include the Vertafore tenant ID when getBpData('brokerageId') is set: "benefitPointLoginCredentials_{$brokerageId}_{$tenantId}". Audit existing callers to confirm the right tenant context is passed.
Problem. Session-timeout retries use literal sleep(2) and sleep(5) at Api.php:122-127, 314-320, 330-336, 394-403. No exponential backoff, no jitter — under any kind of load spike, all retries hit BP at the same moment and amplify the spike. HTTP 429 (rate limit) is not detected at all on the REST path; we silently accept the failure and may retry-loop into a ban.
In Api::handle(), replace the fixed sleeps with exponential backoff + jitter: sleep(min(60, (2 ** $attempt) + mt_rand(0, 1000)/1000)). Detect HTTP 429 in the REST response branch and trigger the same retry loop with the documented carrier backoff (or default 30s) when a Retry-After header is present.
Problem. Controller.php:459-475 and Service.php:1429-1446 chain methods on $response->data (.count(), .reject(), .first()) without checking $response->wasSuccessful() first. When auth retries silently produce a null payload, you get "Call to a member function count() on null" — usually filed as a one-off bug.
The REST path has the same shape (Api.php:297-323) — JSON unpacking assumes the structure is what we expect, no schema validation.
Audit every ->handle()->data chain in integrations/BenefitPoint/Controller.php and Service.php. Wrap each in a guard: if (!$response->wasSuccessful() || empty($response->data)) { /* surface error */ }. For REST operations, add a small helper that validates the expected JSON keys exist before accessing nested fields.
Problem. Service.php:883-950 (the getBenefitType() switch on productTypeID), plus the static maps in ContributionData.php and RateData.php, hard-code BP's enum values. There's no validation that an incoming BP value is in the map. If Vertafore adds a new product type or renumbers a rate type, the parser silently maps to null or a default, and the data quietly stops flowing without anyone noticing.
Plansight's FindBPCodes command already exists to compare BP's GetProductTypes + GetRateTypes output against our hard-coded maps. It's just not run on a schedule.
Add a validating enum mapper to Service.php: mapBpEnum($value, array $map, string $context): ?string that logs a warning ("Unmapped BP enum {context}: {value}") when a value isn't in the map, then returns null. Use it in getBenefitType() and the equivalent helpers in ContributionData.php / RateData.php. Schedule FindBPCodes to run weekly and alert if maps have drifted.
Problem. Service.php:1529-1597 (mapPlansightToBpRate) copies tier values between Plansight and BP rate shapes. Two issues: it mutates $destItem['valueNum'] from source values without validating type, range, or BP field constraints (so an out-of-range value silently propagates and BP rejects the eventual write); and when tier counts diverge between Plansight and BP (3-tier dental on our side, 5-tier on theirs), the fallback path quietly drops un-mapped tiers without logging.
In Service::mapPlansightToBpRate(): (a) validate copied valueNum values are numeric and within constraints from GetRateStructure before assignment, log + skip on mismatch; (b) when source and dest tier counts differ, log every dropped tier with source/dest IDs and surface a single user-facing warning per quote that data was incomplete.
Five threads worth a 30-minute conversation with whoever owns BP integration. None are fixable in a single PR — they're decisions, not bugs.
FindChanges (Gap #1) is wired in, what's the intended frequency — hourly cron, on broker action, both? Should delta and full-refresh coexist with a periodic reconciliation run?FindBPCodes run that diffs against our hard-coded maps and pages someone if Vertafore added a new product or rate type we haven't mapped (Gap #6).Developer reference for the attribute IDs the BenefitPoint API uses across plans and benefit summaries. Each row pairs a BP attribute ID with its human label and the Plansight field it maps to. Source: the same data that drives the interactive Sync Map — re-extracted as a flat ctrl-F-friendly table.
124 attribute mappings across 8 benefit types. Each row pairs a BenefitPoint attribute ID with its human label and the Plansight field it maps to. Use browser find (Cmd-F / Ctrl-F) to locate by ID, name, or Plansight column.
| BP ID | BenefitPoint name | Plansight field | Sync |
|---|---|---|---|
| Medical (46 attributes) | |||
| General Plan Information | |||
| 45 | Annual Deductible/Individual | DeductibleIndividual | Synced |
| 44 | Annual Deductible/Family | DeductibleFamily | Synced |
| 973 | Deductible Embedded or Aggregate | DeductibleType | Synced |
| 112 | Coinsurance — Push uses BP ID 295. | HospitalFacility | Synced |
| 386 | Office Visit/Exam | PrimaryCareDoctor | Synced |
| 414 | Outpatient Specialist Visit | Specialist | Synced |
| 902 | Telemedicine | Telehealth | Synced |
| 53 | Annual Out-of-Pocket Limit/Individual | OOPIndividual | Synced |
| 52 | Annual Out-of-Pocket Limit/Family | OOPFamily | Synced |
| 873 | High Deductible Health Plan (HSA-eligible) | hsa | Synced |
| Preventive Services | |||
| 974 | Preventive Care — BP section ID 455. | PreventativeServices | Synced |
| 975 | Preventive Screenings — Push uses 974. | PreventativeServices | Synced |
| 571 | Well-Child Care — Push uses 974. | PreventativeServices | Synced |
| 254 | Immunizations — Push uses 974. | PreventativeServices | Synced |
| 570 | Well Woman Exams — Push uses 974. | PreventativeServices | Synced |
| 339 | Mammograms — Push uses 974. | PreventativeServices | Synced |
| 16 | Adult Periodic Exams with Preventive Tests — Push uses 974. | PreventativeServices | Synced |
| 168 | Diagnostic X-Ray and Lab Tests | Diagnostic | Synced |
| 971 | Complex Radiology | Imaging | Synced |
| Maternity Care | |||
| 450 | Pregnancy and Maternity Care (Pre-Natal) | MaternityOffice | Synced |
| Inpatient Hospital Services | |||
| 295 | Inpatient Hospitalization | HospitalFacility | Synced |
| 439 | Pre-Authorization of Services Required | — | N/A |
| 503 | Semi-Private Room & Board (incl. services) — Push uses 295. | HospitalFacility | Synced |
| Surgical Services | |||
| 408 | Outpatient Facility Charge | OutpatientFacility | Synced |
| Emergency Services | |||
| 184 | Emergency Room | EmergencyRoomCopay | Synced |
| Urgent Care | |||
| 555 | Urgent Care Facility | UrgentCare | Synced |
| Mental Health | |||
| 287 | Inpatient Care | InpatientMental | Synced |
| 407 | Outpatient Care | OutpatientMental | Synced |
| Alcohol Abuse | |||
| 294 | Inpatient Hospitalization — Push uses 670. | InpatientSubstance | Synced |
| 292 | Inpatient Detoxification Services — Push uses 670. | InpatientSubstance | Synced |
| 412 | Outpatient Services — Push uses 673. | OutpatientSubstance | Synced |
| 675 | Outpatient Detoxification Services — Push uses 673. | OutpatientSubstance | Synced |
| Substance Abuse | |||
| 670 | Inpatient Hospitalization | InpatientSubstance | Synced |
| 671 | Inpatient Detoxification Services — Push uses 670. | InpatientSubstance | Synced |
| 673 | Outpatient Services | OutpatientSubstance | Synced |
| 674 | Outpatient Detoxification Services — Push uses 673. | OutpatientSubstance | Synced |
| Other Services and Supplies | |||
| 174 | Durable Medical Equipment & Prosthetic Devices | MedicalEquipment | Synced |
| 250 | Home Health Care | HomeCare | Synced |
| 508 | Skilled Nursing or Extended Care Facility | Nursing | Synced |
| 251 | Hospice Care | Hospice | Synced |
| Outpatient Rehabilitative Therapy | |||
| 424 | Physical | Rehabilitation | Synced |
| 385 | Occupational — Push uses 424. | Rehabilitation | Synced |
| 515 | Speech — Push uses 424. | Rehabilitation | Synced |
| Habilitative Services | |||
| 877 | Physical | Habilitation | Synced |
| 878 | Occupational — Push uses 877. | Habilitation | Synced |
| 879 | Speech — Push uses 877. | Habilitation | Synced |
| Dental (17 attributes) | |||
| General Plan Information | |||
| 44 | Annual Deductible/Individual | DeductibleIndividual | Synced |
| 45 | Annual Deductible/Family | DeductibleFamily | Synced |
| 55 | Annual Plan Maximum | AnnualMaxIndividual | Synced |
| 314 | Lifetime Orthodontia Plan Maximum | LifetimeOrthoMax | Synced |
| Diagnostic and Preventive Services | |||
| 390 | Oral Exams | Exams | Synced |
| 74 | Bitewing X-Rays | XRays | Synced |
| 109 | Cleaning and Scaling | Cleanings | Synced |
| Basic Services | |||
| 64 | Basic Filling | BasicFilling | Synced |
| 391 | Oral Surgery: Extractions and Other | OralSurgery | Synced |
| 190 | Endodontic Treatment | Endodontics | Synced |
| 419 | Periodontic Treatment | Periodontics | Synced |
| Major Services | |||
| 137 | Crowns, Jackets and Cast Restoration Benefits | Crowns | Synced |
| 255 | Implants | Implants | Synced |
| Orthodontia Services | |||
| 392 | Orthodontia | Orthodontics | Synced |
| 152 | Dependent Children | OrthodonticsAge | Synced |
| 17 | Adults (and Covered Full-Time Students) | OrthodonticsAdult | Synced |
| 314 | Adult Lifetime Maximum | LifetimeOrthoMax | Synced |
| Vision (13 attributes) | |||
| General Plan Information | |||
| 195 | Examination | EyeExams | Synced |
| Benefit Frequency | |||
| 194 | Examination | ExamFrequency | Synced |
| 309 | Lenses | LensesFrequency | Synced |
| 207 | Frames | FramesFrequency | Synced |
| 122 | Contacts | ContactsFrequency | Synced |
| Lenses | |||
| 507 | Single Vision Lens | SingleVisionLenses | Synced |
| 73 | Bifocal Lens | BifocalLenses | Synced |
| 553 | Trifocal Lens | TrifocalLenses | Synced |
| 66 | Basic Progressive | BasicProgressiveLenses | Synced |
| Contact Lenses | |||
| 356 | Medically Necessary | ContactsNecessary | Synced |
| 178 | Elective | ContactsElective | Synced |
| Frames | |||
| 208 | Frame Allowance | FrameAllowance | Synced |
| Other Services | |||
| 133 | Corrective Vision Services (e.g. Laser Surgery) | LasikDiscount | Synced |
| Basic Life (14 attributes) | |||
| Guarantee Issue Amount | |||
| 187 | Employee | — | On Roadmap |
| Overall Maximum | |||
| 188 | Employee | maximumBenefit-1 | On Roadmap |
| Features | |||
| 7 | Accelerated Benefit (Life Only) | acceleratedDeathBenefit | Synced |
| 567 | Waiver of Premium (Life Only) | premiumWaiver | Synced |
| 122 | Conversion (Life Only) | conversion | Synced |
| 433 | Portability | portability | Synced |
| AD&D Schedule | |||
| 497 | Seatbelt Benefit | — | Synced |
| 28 | Airbag Benefit | airBag | Synced |
| 590 | Repatriation of Remains | repatriation | Synced |
| 100 | Child Care Benefit | childCare | Synced |
| Reduction of Benefits Schedule | |||
| 2 | Tier 1 (Age 64 or Younger) | — | Synced |
| 3 | Tier 2 (65-69) | — | Synced |
| 4 | Tier 3 (70-74) | — | Synced |
| 5 | Tier 4 (75-79) | — | Synced |
| STD (10 attributes) | |||
| Elimination Period | |||
| 252 | Accident | waiting_period_accident | Synced |
| 505 | Sickness | waiting_period_illness | Synced |
| 8 | Hospitalization | First Day Hospital | Synced |
| General Plan Information | |||
| 71 | Benefit Percentage | — | Synced |
| 569 | Weekly Benefit Maximum | — | Synced |
| 350 | Maximum Period of Payment | — | Synced |
| 373 | Minimum Weekly Benefit | — | Synced |
| 142 | Definition of Earnings | — | Synced |
| 449 | Pre-Existing Condition Limitations | — | Synced |
| 433 | Portability | — | Not Synced |
| LTD (16 attributes) | |||
| General Plan Information | |||
| 71 | Benefit Percentage | ltDisabilityBenefitSchedule-1 | Synced |
| 582 | Guaranteed Issue | ltDisabilityGuaranteeIssue | Synced |
| 371 | Monthly Benefit Maximum | ltDisabilityMaximumMonthlyBenefit-1 | Synced |
| 351 | Maximum Period of Payment | ltDisabilityBenefitDuration | Synced |
| 374 | Minimum Monthly Benefit | — | Synced |
| 181 | Elimination Period | ltDisabilityEliminationPeriod | Synced |
| 466 | Recurrent Disabilities | ltDisabilityRecurrentProtection | Synced |
| 142 | Definition of Earnings | ltDisabilityEarningsDefinition | Synced |
| 801 | Earnings Test | ltDisabilityEarningsTest | Synced |
| Limitations | |||
| 365 | Mental Illness | ltDisabilityMentalNervous | Synced |
| 526 | Substance Abuse | ltDisabilityAlcoholDrug | Synced |
| 501 | Self-Reported | — | Synced |
| 449 | Pre-Existing Condition Limitations | ltDisabilityPreExistingLimitations | Synced |
| Features | |||
| 539 | Survivor Benefit | ltDisabilitySurvivorBenefit | Synced |
| 485 | 100% Return to Work Incentive | — | Synced |
| 113 | COLA | ltDisabilityCOLA | Synced |
| EAP (4 attributes) | |||
| Plan Design | |||
| 384 | Number of Visits / In-person sessions per Issue | eapInPersonSessionsIssue | Not Synced |
| 553 | Chemical Dependency / Drug & Alcohol Counselors | — | Not Synced |
| 202 | Legal Resource and Referral / Financial Counseling | — | Not Synced |
| 557 | Utilization Reporting | eapUtilizationReports | Not Synced |
| HRA (4 attributes) | |||
| Communication and Enrollment | |||
| 192 | Enrollment Meetings | — | Synced |
| 191 | Enrollment Kits / Startup Kits | — | Synced |
| Compliance | |||
| 170 | Discrimination Testing | — | Synced |
| 430 | Plan Documents | — | Synced |
Active work and open ideas. Tracked in JIRA project PS, refreshed continuously.