Clients, Groups & Benefit Plans

Libraries: client, benplans, bensupport, sales (63 windows, 272 DataWindows) Requirement prefix: GRP

Purpose

This domain maintains the TPA's book of business: employer clients and their group hierarchies, the benefit coverages each group offers, and the benefit-plan rule structures that drive claims adjudication. It covers:

• Group maintenance (client): group identity, hierarchy (parent / master group), addresses, contacts, enrollment options, coverages offered, member categories, coverage-eligibility rules, plan-year and enrollment periods, group-level options, client-segment assignment, group/coverage termination, and stop-loss waiver entry.
• Benefit plan design (benplans): benefit plans, benefit packages, benefit rules (deductible / coinsurance / copay / maxima / exclusions / holds), benefit definitions (the service-classification criteria that rules attach to), rule contingencies, riders, and package-level rule interdependencies.
• Plan-design support data (bensupport): procedure / diagnosis / tooth / second-opinion code groups, carryover rules, coverage-level schedules, step-rate schedules, rounding rules, reason codes, and plan-conversion utilities.
• Sales / client reporting (sales): client-based reporting wizard (paid claims, lag triangles, IBNR, claimant registry), group claim-detail reports, and benefit service-category maintenance per client segment.

Actors

Actor	Evidence
Group / client administration staff — create and maintain groups, coverages, contacts, periods	client/w_client_enrollment opens client/w_client_maintenance in ADD / CHANGE / DETAIL modes
Plan-build analysts — create plans, packages, rules, definitions	benplans/w_benefit_plan_selection, benplans/w_create_benefit_rule, benplans/w_benefit_pkg_maint, benplans/w_benefit_def_maint
Plan-support analysts — maintain code groups, schedules, reason codes	bensupport/w_codes_maint, bensupport/w_level_sched_maint, bensupport/w_reason_code_maint
Sales / account managers — run client-based financial reports per client segment	sales/w_sales_report_wizard, sales/w_sales_benefit_category_maintenance
Security layer — user classes limit which groups a user may see	group pick lists join security_user_class_user and security_user_group (client/d_client_group_select, client/d_client_parent_group_ids)

Group hierarchy model

The official user guide frames the domain as Client Maintenance: "the activity of entering group level information into the system … the business rules and the parts of the client's corporate structure that affects claims processing." The client entity is the group; divisions and departments are sub-groups. Informational groups exist "for SFPI/M3 purposes only and do not reflect the client's corporate structure" (User Guide ch. 2). The guide's design describes four distinct group structures per client — Client Maintenance, Claims, Billing, and Reporting — each owned by a different functional area; only the Client Maintenance structure is required to add a new client, and the client master group must be identical across all four structures. The client master group is defined as "the highest level group … under which members may transfer between sub-groups without changing member numbers", and members may only be enrolled into the lowest-level sub-groups (leaf groups) — which explains why coverage resolution in code happens at leaf groups (User Guide ch. 2). Note that the code implements a single parent_group_id tree, and the guide's billing chapter states the billing hierarchy is the group parent/child definition maintained in Client Maintenance (User Guide ch. 4) — so the four-structures design appears to have collapsed into one shared hierarchy as built.

Groups form a tree via groups.parent_group_id (self-reference). Key attributes on groups: group_id (char 15, natural key), group_name, master_group_flg, grp_info_flg (informational-only group), funding_parent_group_id, group_type_cd, eff_dt / exp_dt / grp_exp_cd, tax_id, eligibility waiting-period fields (elig_waiting_period_type_cd, elig_waiting_period_cd, elig_waiting_period_no, elig_waiting_period_dt_from_cd), and external-carrier cross-reference fields (ext_elr, ext_control, ext_suffix, ext_account, ext_plan_number — shown as "ELR / CONTROL / SUFFIX / ACCOUNT / PLAN NO" in client/d_client_group_info_new_ext).

• The master group for any group is found by walking parent_group_id upward until a group with master_group_flg = 'Y' is reached (client/w_client_maintenance.wf_get_master_group_id, recursive).
• Hierarchy traversal uses Oracle CONNECT BY prior parent_group_id = group_id (upward, client/d_heirarchy) or CONNECT BY parent_group_id = PRIOR group_id (downward, e.g. client/w_client_term_group, bensupport/d_plan_rpt_group_rule_analysis).
• Coverages are resolved at leaf groups: the plan-analysis report gathers group_coverages only for groups with no children under the requested group (bensupport/d_plan_rpt_group_rule_analysis).
• Informational groups (grp_info_flg = 'Y') are excluded from hierarchy rollups (client/d_heirarchy filters grp_info_flg <> 'Y').

Key workflows

Group setup

1. User opens the client-enrollment browser (client/w_client_enrollment), searches by group id / name / contact, and chooses Add, Change, or View. The selection opens client/w_client_maintenance with mode ADD / CHANGE / DETAIL (wf_open_group_detail; DETAIL renders the window read-only — title suffix "(View Only Mode)" vs "(Edit Mode)" in ue_retrieve_windows).
2. Group Maintenance is a tabbed window (client/w_client_maintenance): Information (group info + contacts), Enrollment (enrollment options, enrollment/flex periods, group options), Coverages (coverages offered + per-coverage options), Categories (standard / non-standard member categories and values — master groups only), Coverage Eligibility (member-category-based eligibility rules per coverage).
3. On saving a new group, security rows are auto-created: security_user_group entries for user classes SFPI (skipped when the group id starts with 501-069), SFPI-Admin, and develop (wf_add_security).
4. A child group can be initialized by copying from its parent: the Copy Group Info dialog (client/w_client_copy_group_info) lets the user tick which sections to copy — group info, contacts, enrollment options, group options, coverages, categories (categories disabled unless the source is a master group) — each with its own source group and effective date. Billing and eligibility copy fields exist in the DataWindow but the eligibility copy call is commented out. The guide names this design Inheritance: "Client Maintenance options for all groups will be inherited by the sub-groups … unless specifically overridden or declined at the sub-group level"; on adding a new group the parent's options prefill the child, and the inheritance window carries checkboxes for General Information, Contacts, Enrollment, Coverage, Categories and Eligibilities — changing one effective date changes all of them (User Guide ch. 2).
5. Operational practice for contacts: contact information is normally maintained at the master level; staff are instructed to check the division first and fall back to the master. The maintained contact categories are Bills, Broker, COBRA, Confidential Contact, Enrollment, Executive, ID Cards, Miscellaneous, Registers, Sales Rep, and UR/CM (User Guide ch. 2, notes from Donna Harvey).

Coverage setup ("what the group offers")

Per group, group_coverages rows pair a coverage type (benefit_coverage_type_cd, from coverages) with a plan code (benefit_coverage_cd, from benefits), with eff_dt / exp_dt, waiting-period overrides, salary-based volume calculation fields (multiplier, increment, min/max/default amounts, rounding), ID-card form numbers, COBRA flags, tax status, and an "applied to members" mechanism (applied_to_members_dt, unapplied_chg_flg, mbr_cov_applied_cd, mbr_cov_reqd_flg) that records whether the coverage row has been pushed down to member elections (client/d_client_group_coverage_info, client/d_client_group_coverage_opts_new).

The guide explains the intent of the applied-to-members mechanism: discontinuing or changing a group coverage impacts the enrollment tables, so the user chooses to "update the members immediately, or defer making the changes … during the nightly processing at a later date. Updating large numbers of members immediately will consume a large amount of computer resources and should be discouraged." When the update runs immediately, a stored procedure updates the members and stamps the applied-to-members date (User Guide ch. 2).

It also documents the coverage/plan handshake: whenever a new group is created, all of its coverages must be added immediately, choosing from existing benefit plans or naming new ones; a new coverage plan auto-creates a benefit plan in INCOMPLETE status, the group staff notify the plan builders (Debbie or Joan in the guide), and the builder flips the status to COMPLETE when the plan load is done. Coverages that are not adjudicated in HOMER (Life, AD&D, LTD, SupLife) still get plans — marked NONPROCESS — because enrollment requires a plan per coverage (User Guide ch. 2).

Plan configuration (see the full model below)

Plans, packages, rules, and definitions are built in benplans and linked so that a group's coverage row resolves, at adjudication time, to an ordered set of benefit packages and prioritized rules.

Renewal / plan periods

There is no explicit "renewal" transaction in this domain. Renewal is represented by effective-dated rows:

• group_periods stores period definitions per group (period_type_cd, eff_dt, exp_dt, begin/end month + day, extended_year_flg). The Enrollment tab retrieves types ENROLLMENT and FLEX (client/w_client_maintenance line region lsa_period_types[1]='ENROLLMENT'; lsa_period_types[2]='FLEX'); open enrollment is the ENROLLMENT-type row with exp_dt IS NULL (client/d_enrollment_periods_open). group_periods.period_type_cd also participates in claims-side plan-year logic (clmsproc has CRUD on group_periods per the schema CRUD matrix).
• Period changes made on a parent can be extended to divisions: the window copies the edited period row to every sub-group via a datastore loop (client/w_client_maintenance event ue_extend_to_div).
• Coverage rows, category rows, enrollment options, and group options are all effective/expiration dated, so a renewal that changes plan design is entered as a new dated row rather than an update in place.
• The user guide likewise documents no renewal transaction; it references renewal only as an operational touch-point (account executives collect updated contact forms "upon renewal") (User Guide ch. 2), supporting the reading that renewal is a manual re-entry of dated rows. The guide's Group Periods procedure adds operator detail: flex periods are added at the master group level (right-click, add row), the extended-year flag is set "when the end month is set to mean greater than 12 months", and the extend-to-all-divisions box "can be checked only at the master level" (User Guide ch. 2).

Group / coverage termination

client/w_client_term_group ("Term Groups") terminates a whole group or drops one coverage type, with a chain of confirmation prompts and a final warning that the action "will take hours to undo":

• Drop one coverage: blocked while any member in the group subtree still has an active election of that coverage; otherwise updates group_coverages in the subtree with exp_dt, coverage_exp_cd, run_out_exp_dt.
• Term whole group: blocked while any member_eligibilities row in the subtree has exp_dt IS NULL; otherwise delegates to database procedures term_groups_master or term_groups_division depending on master_group_flg.
• A companion "term members" path expires (or deletes future-dated) elections / election_coverages rows in the subtree, or calls term_members_master / term_members_division.
• A pre-termination report of affected members can be produced (client/d_client_term_group_report).

The guide documents the intended termination semantics behind the stored procedures (User Guide ch. 2):

• Terminating a master group implies its divisions are terminated; "groups are terminated the day after the date entered as the EXP date at the group level."
• Groups cannot be terminated unless all coverages in the group are terminated.
• Run-out is defined per group coverage: no run-out when the coverage exp date equals the run-out end date; a null run-out end date on a coverage with an exp date signifies infinite run-out; a run-out date on a coverage with no exp date is meaningless.
• Operator procedure: search the group (division id for one division, master id for the whole client), enter term date, optional run-out date, and reason; pick one coverage type (single-line drop) or leave "All" (full termination); press Terminate Members first (expires active members with coverage starting before the date, deletes members whose coverage starts after it), then Terminate Groups (expires group coverages using the run-out date where present, else the term date) — each button asks for verification four times, and Terminate Groups refuses to run while members with the selected coverage remain active.
• Window access is restricted to Office Enrollment Managers, Office Managers, MIS, and developer classes.
• Terminated groups' plans and packages are deliberately not terminated — "the loss of eligibility should be enough. (Packages are reusable across plans and groups)" — and a claim arriving after group termination for services incurred during a valid election period will still process.

Plan conversion

bensupport/w_convert_plan moves selected group-coverage rows from one plan code to another by executing stored procedure sfpidba.new_group_coverages(group_id, new_plan, old_plan, coverage_type, 'N', 'N') per selected row, committing after each.

Stop-loss support in this domain

• client/w_carrier_maint / client/w_carrier_select maintain stop-loss carriers (carriers: code, name, contact, phone/fax/e-mail, active_ind, waiver_ind).
• client/w_member_waivers (opened from client/w_member_waiver_select) records per-member stop-loss waivers (stoploss_waivers: waiver from/thru and incurred from/thru dates); client/w_stoploss_period_select picks the applicable stop-loss contract year from group_stoploss_parms (specific carrier joined to carriers, falling back from division to master group when no period exists at the division — see the message logic in w_member_waivers).
• client/w_stoploss_group / client/w_stoploss_contract provide read access to stop-loss contract data (contract detail itself belongs to the Stop-loss domain).

Business rules

Each rule is stated so it can be tested against the legacy behavior.

ID	Rule	Source
GRP-1	Every group has a unique 15-character group id; a group may reference a parent group, forming a tree, and exactly the groups flagged master_group_flg = 'Y' act as hierarchy roots for category and stop-loss resolution.	client/d_client_group_info, client/w_client_maintenance.wf_get_master_group_id
GRP-2	The master group of any group is resolved by following parent links upward until a group with the master flag is found; if a group has no parent it is its own master.	client/w_client_maintenance.wf_get_master_group_id
GRP-3	Groups flagged informational (grp_info_flg = 'Y') are excluded from hierarchy traversals used for coverage resolution.	client/d_heirarchy
GRP-4	Group pick lists only show groups linked to one of the requesting user's security user classes.	client/d_client_group_select, client/d_client_parent_group_ids, client/d_client_child_group_ids
GRP-5	When a new group is saved, security access rows are created automatically for the SFPI, SFPI-Admin, and develop user classes; only the SFPI insert is skipped when the group id's first seven characters are 501-069 (SFPI-Admin and develop are written regardless). The three inserts sit inside a loop over the saving user's own user classes, guarded by a check that no security_user_group row yet exists for that class and group — so a user belonging to several such classes attempts the same three inserts once per class.	client/w_client_maintenance.wf_add_security (lines 947–968)
GRP-6	A group cannot be changed from master to non-master while it still has member categories defined.	client/w_client_maintenance.wf_set_cat_tabpage
GRP-7	A group expiration requires an expiration reason code (grp_exp_cd); the code list is a maintained code table.	client/w_client_maintenance.wf_validate_exp_code, client/d_client_group_info_new (dddw on exp code)
GRP-8	A group carries an eligibility waiting period (type, unit, length, from-date basis) that defaults into coverage-level waiting-period fields; coverage rows may override it.	client/d_client_group_info, client/d_client_group_coverage_opts_new
GRP-9	Each coverage a group offers is a group_coverages row keyed by group, coverage type, and plan code, effective-dated, with an ordering sequence (group_coverage_seq_no) assigned as max existing + 1 per group / plan / type.	client/d_client_group_coverage_info, client/w_client_maintenance.wf_set_seq_no
GRP-10	Coverage rows track application to members: applied_to_members_dt records when the coverage was applied, unapplied_chg_flg marks pending unapplied changes, mbr_cov_applied_cd states how it applies, mbr_cov_reqd_flg whether it is mandatory. The same mechanism exists for member categories and category values. Intent per the guide: member updates may run immediately (stored procedure stamps the applied date) or be deferred to nightly processing; immediate mass updates are discouraged.	client/d_client_group_coverage_opts, client/d_client_group_mbr_categories, client/d_client_category_values; (User Guide ch. 2)
GRP-11	Group-level enrollment options are code-table values (codes.code_key = 'ENROLL') attached to a group with effective / expiration dates.	client/d_client_group_enroll_opts, client/dddw_client_enrollment_opts
GRP-12	Group options are a typed name/value store: group_options defines each option and how its value is saved (val_saved_as_cd — code, date, number, or character); group_option_vals stores effective-dated values with one populated column among option_val_cd / option_val_dt / option_val_no / option_val_char. Consumers select the populated column via DECODE and match on the run date between eff_dt and exp_dt (null-as-open-ended, defaulted to 12/31/2049).	client/d_client_group_options, client/d_client_census_group_option_vals
GRP-13	Member categories can be attached only to master groups; category effective/expiration date changes are validated against existing values across the master group.	client/w_client_maintenance.wf_set_cat_tabpage, wf_check_cat_eff_dates, wf_check_cat_exp_dates
GRP-14	Coverage eligibility rules restrict a coverage to members with a given category value: rows of (group, coverage type, plan code, member category, category value, eff/exp dates).	client/d_client_grp_coverage_eligibility_rules, grp_covr_elig_rules table
GRP-15	Group periods (plan-year / enrollment / flex windows) are defined per group as recurring month+day ranges with effective dating and an extended-year flag; the currently open enrollment period is the ENROLLMENT row with no expiration date.	client/d_enrollment_periods, client/d_enrollment_periods_open
GRP-16	Enrollment-period changes entered on a parent group can be propagated to all of its sub-groups in one action.	client/w_client_maintenance event ue_extend_to_div
GRP-17	A new child group may be initialized by selectively copying the parent's group info, contacts, enrollment options, group options, coverages, and (for master-group sources only) categories, each as of a chosen effective date.	client/w_client_copy_group_info
GRP-18	A coverage type cannot be dropped from a group while any member in the group's subtree still holds an active election of that coverage as of the drop date.	client/w_client_term_group (count of election_coverages before update)
GRP-19	A group cannot be terminated while any member eligibility in its subtree is still open (no expiration date).	client/w_client_term_group (count of member_eligibilities before term)
GRP-20	Dropping a coverage expires every matching group_coverages row in the subtree with the drop date, reason code, and optional run-out date; whole-group termination is delegated to database procedures that differ for master groups vs divisions.	client/w_client_term_group, procedures term_groups_master / term_groups_division
GRP-21	Group termination requires a termination reason and multi-step user confirmation, including explicit confirmation of drop date, run-out date, and reason.	client/w_client_term_group
GRP-22	A group belongs to at most one client segment used for sales reporting (client_segment_groups), editable from group maintenance.	client/d_client_client_segment, client/w_client_maintenance (dw list)
GRP-74	Designed but not built: the guide specifies a sixth Client Maintenance tab, Reporting, carrying two group-level checkboxes — standard_rpt (a standard report is required for this group) and rpt_option (a special standard-report option applies to this group) — alongside the usual group/parent/sub-group navigation. The as-built window has five tabs (Information, Enrollment, Coverages, Categories, Coverage Eligibility) and neither column appears in the extracted groups schema. Treat group-level report selection as unimplemented intent unless a data extract shows otherwise.	(User Guide ch. 2); absence corroborated by client/w_client_maintenance tab list
GRP-23	A benefit plan is identified by coverage type + plan code (benefit_plans keyed by benefit_coverage_type_cd, benefit_coverage_cd) and carries claim-filing and appeal limits (length + period), COB method, lifetime maximum, dependent age limits (student / non-student), pre-existing condition periods (subscriber and dependent, prior and elapsed), package-search logic (pkg_logic_cd), plan status, and WDI payment schedule.	benplans/d_benefit_plan_maint, benefit_plans columns
GRP-24	A plan attaches an ordered list of benefit packages (plan_pkgs), each effective-dated, optionally network-specific (hcn_sys_key), with a pricing plan, pricing logic, UR firm, and CM firm; search_order_seq controls package search order and is renumbered from display order on save.	benplans/d_plan_packages, benplans/w_create_benefit_plan.wf_set_sequence
GRP-25	Every plan must include a default (no-network) package attachment — a plan_pkgs row with null hcn_sys_key and an expiration date that is null or strictly later than today (a row expiring today does not satisfy the check). The sole exemption: a plan whose benefit_coverage_type_cd is DRUGS and whose plan_status_cd is ASMEDICAL may have zero package rows — the exemption is on the zero-row branch, so it bypasses the scan rather than satisfying it, and a DRUGS/ASMEDICAL plan that does have packages is still required to include a no-HCN one. The guide states the intent: "If there are Packages with network affiliations, then there must also be an Out of Network package"; the no-HCN package "will serve as the catchall Package."	benplans/w_create_benefit_plan.wf_check_default_pkg (lines 133–147); (User Guide ch. 6)
GRP-26	Two attachments of packages with the same HCN under one plan may not have overlapping effective-date ranges.	benplans/w_create_benefit_plan.wf_check_dates
GRP-27	Renaming a plan code cascades the new code to the plan's package attachments in the same save.	benplans/w_create_benefit_plan.wf_rename_coverage_cd
GRP-28	A plan code must be unique within its coverage type.	benplans/w_create_benefit_plan.wf_check_cd_duplicates
GRP-29	A benefit package (benefit_pkgs) must have a package code, a default benefit definition, an unassigned-definition action (Hold / Exclude / Pay), and an unassigned-definition reason before it can be saved.	benplans/w_benefit_pkg_maint pfc_validation
GRP-30	Rules are attached to packages as effective-dated pkg_rules rows with a priority, member-scope flags (subscriber / spouse / dependent), and managed-care indicators (PCP, auth, pre-cert, pre-admission, referral).	benplans/d_pkg_rule_maint
GRP-31	A benefit rule (benefit_rules) has a type from code table BENRULE; observed types and their editors: DED (deductible), COI (coinsurance), COPAY, OOP (out-of-pocket), 100PCT (pay at 100%), CLAIMED / PAID (claimed / paid limits), EXCL (exclusion), HOLD. The guide confirms exactly nine rule types — Deductible, Coinsurance, Out of Pocket, Claimed Limit, Payable Limit, Copay, Exclusions, 100%, Hold — resolving the code-table question.	benplans/w_create_benefit_rule.wf_set_accum_type, benplans/dddw_benrule; (User Guide ch. 6)
GRP-32	Rule amounts are either retained flat values (retain_val, individual_max_val, family_max_val, max_individuals_met) or scheduled by coverage level (level_sched_flg = 'Y' with level_sched_sys_key); the two are mutually exclusive and unused columns are nulled before save, per rule type.	benplans/w_create_benefit_rule.wf_reset_rule_detail
GRP-33	The retained-value complement convention. For COI and OOP rules the user enters a "pay at" percentage and the system stores its complement (100 − entered) in retain_val — entering "pay at 80%" stores 20. The complement is applied on save in pfc_save, and only when the row status is not NotModified!; the inverse (100 − stored) is applied on retrieve, after which the row is re-marked NotModified! so a round-trip without an edit cannot double-convert. The entered percentage must be greater than 0 and no greater than 100 (ue_check_data). For deductible rules retain_val is set to 100 — but only when the rule is not level-scheduled: if level_sched_flg = 'Y' the value is nulled and the amount comes from the schedule instead (GRP-32). DED is the only type that receives a literal 100. COPAY is excluded from the complement and from the percentage validation: its field is labelled "Retain" with a two-decimal mask and is stored verbatim. The guide confirms the model — the retain value "states how much money should be withheld from payment"; deductible, exclusion and limit rules retain a fixed 100%, coinsurance and OOP are user-specified percentages of the considered amount, and copay retains a flat dollar amount. (The "dollar" reading of copay is the guide's; the code carries no currency literal, only the label and mask.)	benplans/w_create_benefit_rule (pfc_save lines 581–593, dw_1::pfc_retrieve, ue_check_data, wf_reset_rule_detail case DED); (User Guide ch. 6)
GRP-34	Exclusion rules carry no accumulator, schedule, carryover, per-day, or unit fields — all are cleared on save; HOLD rules similarly have no detail.	benplans/w_create_benefit_rule.wf_reset_rule_detail, wf_set_accum_type
GRP-35	Each rule accumulates against a named accumulator (accum_sys_key → reason_codes) whose accum_type_cd is derived from the rule type by wf_set_accum_type: RETAINED for COPAY, DED, EXCL, OOP; CONSIDERED for 100PCT, HOLD, COI, CLAIMED, PAID. This matches the guide's statement that maxima accumulate on the considered amount for coinsurance and limits and on the retained amount for deductible, OOP and copay (GRP-64) — code and guide agree on every overlapping type. The reason-code pick list is filtered to reasons of the rule's type or type ACCUM. Two code-level caveats: the CLAIMED branch returns CONSIDERED yet sets the column's value list to map "Dollar Maximum" to RETAINED (a display list, not the stored value); and wf_set_accum_code, which would have flipped COPAY between RETAINED and CONSIDERED, is entirely commented out along with both of its call sites.	benplans/w_create_benefit_rule (wf_set_accum_type lines 263–327, event ue_filter_reason_cds), benplans/dddw_reason_accum
GRP-36	A rule's scope can be constrained by rule period (length + PLANPERIOD code), member age band (min/max length + period), considered-amount band (min/max), consider percentage, accident indicator, days of week, per-day basis (PERDAY codes), per-unit flag, unit counts (min/max), and quantity ratio.	benplans/d_ben_rules, benplans/d_ben_rule_ded
GRP-37	Benefit rule codes may contain only letters, digits, and - / \.	benplans/w_create_benefit_rule pfc_save match check
GRP-38	A rule is linked to the benefit definitions it governs through rule_defs (rule ↔ definition many-to-many).	benplans/d_rule_def_link
GRP-39	A rule may carry contingency definitions (rule_contingency_defs) plus a with/without indicator and look-back period: contingency_ind = 'Y' means the rule applies only when a claim matching a contingency definition exists within the period; 'N' means it applies only when none exists. If a rule has no contingency definitions, the indicator and period are cleared and disabled. Guide semantics: "With … indicates that the rule should be used when the benefit definition is on the claim. Without … when the benefit definition is not on the claim." Worked examples: skilled-nursing-facility benefits ("confined for at least 3 days and admitted to the SNF within 14 days of a hospital confinement" — the look-back period) and diagnostic-test deductible rules applying only when no second-surgical-opinion line is on the claim.	benplans/w_create_benefit_rule (wf_set_contingency, contingency radio buttons), adjudication in clmsproc/n_claim_adjudication; (User Guide ch. 6)
GRP-40	Saving a rule updates the rule, its definition links, contingency links, tooth-type links, and package attachments in a single transaction; any failure rolls back all of it.	benplans/w_create_benefit_rule pfc_save
GRP-41	A benefit definition (benefit_defs) classifies services by up to seven criteria — procedure (up to three code-type-specific criteria), diagnosis (up to three), place of service, specialty, modifier, revenue code — plus an inpatient/outpatient indicator, and may instead be a compound definition composed of child definitions (compound_ben_defs). Guide semantics: criteria are ANDed ("every criterion specified must be met"); compound definitions "may only be made up entirely from other benefit definitions, and no other specific criterion may be used"; at assignment time "the most specific simple benefit definition (non-compound) will be resolved and used as the claim's designation".	benplans/w_benefit_def_maint, benplans/d_compound_ben_def, benefit_defs columns; (User Guide ch. 6)
GRP-42	Definition criteria are stored as SQL-style predicate expressions (IN pick lists, BETWEEN ranges, wildcards with * translated to %, AND/OR combinations); a criterion that is a single IN list is rendered back to the user as a pick list.	benplans/w_benefit_def_maint (wf_prepare_where_clause, wf_ispicklist, wf_decode)
GRP-43	Procedure and diagnosis criteria may reference named reusable code groups (procedure_groups / procedure_code_groups, diagnosis_groups / diagnosis_code_groups) maintained in plan support.	benplans/d_benefit_def_procs, bensupport/w_create_proc_group, bensupport/w_create_diag_group
GRP-44	Package-level rule interactions are stored per package: dependencies (apply a rule only in proportion to another rule's accumulator — apply_pct), requirements (rule applies only when an accumulator value is within a min/max band), and fulfillments (satisfying one rule fulfills another). The guide names these on the package screen: Applies to Additional Accumulator (dependencies; e.g. a mental-nervous benefit where 50% pays at 100% and the other 50% at 50%), Applies Within Accumulator Range (requirements; e.g. HMO mental-nervous visits 1–5 at 50%, 6–20 at 30%, 21–50 at 25% under one overall 50-visit limit), and Applies After Rule (fulfillments; e.g. supplemental-accident 100% rule before the normal deductible/coinsurance) — with the caveat that placing rule B in rule A's "Applies After Rule" box moves A after B in the firing order at runtime.	benplans/d_pkg_rule_dep, d_pkg_rule_req, d_pkg_rule_ful; (User Guide ch. 6)
GRP-45	Packages may attach riders (pkg_riders) and rider-conditional rule actions (rider_rules with rider_action_flg), so a member's rider election alters which rules apply. Guide truth table: member has the rider and exclude flag unchecked → rule applies; has the rider and exclude checked → rule does not apply; lacks the rider and exclude unchecked → rule does not apply; lacks the rider and exclude checked → rule applies. Valid riders are defined per package and member elections are validated against that list. (Note: the guide's terminology section also says "Benefit Riders — this is currently not set up in the Homer System"; the code implements the tables, so the note predates implementation.)	benplans/d_pkg_rider_maint, benplans/d_rider_rule; (User Guide ch. 6)
GRP-46	Carryover rules (code, percent, period length/type, and a flag for whether carryover also satisfies the rule) are reusable objects attached to rules via carryover_rule_sys_key.	bensupport/d_carryover_rules_maint, benplans/d_ben_rule_ded
GRP-47	A coverage-level schedule (level_scheds / level_sched_items) computes a rule amount per coverage level. The maintenance screen spells the formula out in header text reading left to right: Coverage Level = Flat Amount + ( Member Category * Multiplier ), followed by Rounded (rounding_rule_sys_key) and Step-Rated (step_rate_sys_key) columns that complete the row. Caution: level_sched_items.member_cat_cd holds a member-category code, not a number; reading the term as a head-count is an inference from the pick list's name (dddw_numeric_member_cats), and that pick-list object is absent from the extraction. Neither w_level_sched_maint nor the DataWindow evaluates the formula — it only validates and defaults (a multiplier of 0 is forced to 1 when a member category is entered) — so the arithmetic lives in the unextracted adjudication side and the count semantics need confirmation.	bensupport/d_level_scheds_items (header labels form the formula), bensupport/w_level_sched_maint
GRP-48	Step-rate schedules map value bands (from/thru) to rates; rounding rules define direction and significance.	bensupport/d_step_rate_items, bensupport/d_rounding_rule_maint
GRP-49	Second-opinion lists define penalty percent, penalty maximum, and a penalize-all flag, and are attached to packages (benefit_pkgs.second_opinion_sys_key).	bensupport/d_second_opinion, benplans/d_benefit_packages
GRP-50	Converting groups to a new plan code is executed by stored procedure sfpidba.new_group_coverages per group coverage row, committed row by row.	bensupport/w_convert_plan
GRP-51	Stop-loss waivers are recorded per member with waiver and incurred date ranges; the applicable stop-loss period is selected from the group's stop-loss parameters, falling back to the master group when the division has none.	client/d_member_waivers, client/w_member_waivers, client/d_contract_picklist
GRP-52	Sales reporting classifies benefit definitions into report service categories per client segment and report type (rpt_svc_cats / rpt_svc_cat_defs).	sales/w_sales_benefit_category_maintenance, sales/d_sales_ben_cat_maintenance_chosen
GRP-53	Plan status governs adjudication and follows a lifecycle: COMPLETE (claims may adjudicate), INCOMPLETE (claims hold in adjudication until completed), NONPROCESS (valid for election only — Life, AD&D, LTD, SupLife are never adjudicated), VOID (invalid for any purpose), AS MEDICAL (drug plans whose prescriptions are covered under the medical plan). A new coverage plan named during group setup auto-creates its benefit plan as INCOMPLETE; the plan builder manually sets COMPLETE when the load is finished. Adjudication always checks plan status before acting.	(User Guide ch. 2, ch. 6); ASMEDICAL corroborated by benplans/w_create_benefit_plan.wf_check_default_pkg
GRP-54	Members may only be enrolled into lowest-level (leaf) sub-groups. The client master group is the highest group under which members may transfer between sub-groups without changing member numbers, and must be the same group across the Client Maintenance, Claims, Billing, and Reporting structures.	(User Guide ch. 2); leaf-group coverage resolution corroborated by bensupport/d_plan_rpt_group_rule_analysis
GRP-55	Benefit rules execute in a hard-coded order by rule type — Exclusion, Hold, Claimed-amount limit, Quantity limit, Copay, Deductible, Coinsurance / Out-of-Pocket, Paid-amount limit — then, within a type, by package-rule priority 0–99 (higher fires first; default 0), then by largest period length/type, then alphabetically by rule code.	(User Guide ch. 6); execution itself is claims-side (clmsproc)
GRP-56	Benefit-definition assignment searches only the definitions cited by the selected package's rules, in rule-type order; a definition belonging to a hold or exclusion rule is assigned on first match; if more than one non-hold/exclusion definition matches, the claim is held for an examiner (who should also fix the overlapping definitions); if none matches, the package's unassigned action applies (hold for manual adjudication, exclude, or pay at 100%, with the package's default definition assigned). A definition manually assigned by a user is never overwritten by the nightly process; deleting it re-enables automatic assignment.	(User Guide ch. 6); package unassigned action corroborated by benplans/w_benefit_pkg_maint (GRP-29)
GRP-57	Because benefit rules and benefit definitions are undated masters, edits take effect immediately across every dated package and plan attachment (so, given claims lag, claims from the same service period can adjudicate differently). Required practice: change plan design by creating renamed copies of rules/definitions, not by editing shared masters in place.	(User Guide ch. 6); undated-master structure corroborated by benefit_rules / benefit_defs schema
GRP-58	Accumulator discipline: whenever any rule applies, all of its accumulator's values (considered, retained, and quantity) are added to, regardless of which value the rule's limit checks. The accumulator code defaults from the rule's reason code and may be overridden. Rules that must share a maximum (e.g. accident and non-accident deductibles) must share an accumulator code; rules with distinct maxima (e.g. 80% and 50% coinsurance) must use different accumulator codes. For DED, COI, OOP, COPAY, PAID and CLAIMED rules the accumulator must be of type ACCUM; for HOLD, 100% and EXCL rules the reason code itself may serve as the accumulator.	(User Guide ch. 6); type filtering corroborated by benplans/w_create_benefit_rule (GRP-35)
GRP-59	Package-rule managed-care switches (Authorization; Admission Notification / Pre-Certification; Referral) are tri-state: Y = a valid entry is required for the rule to execute, N = a valid entry must not be present, blank = always run the rule. The pre-certification and referral switches are mutually exclusive within a single rule. UR rules must be set up for every package within each plan.	(User Guide ch. 6); switch columns corroborated by benplans/d_pkg_rule_maint (GRP-30)
GRP-60	Naming conventions (operator-enforced): a plan code is 15 characters containing two dashes, begins with the 3-digit legacy (Wang) group number, and ends with the 3-digit flex option number immediately after the second dash; the plan description starts with the group name plus division letters. Dental rule codes must begin DNT, vision VIS, WDI WDI (medical needs no prefix), with matching description prefixes. Package codes abbreviate the group name and must distinguish network-steerage or benefit variants (e.g. SFPIOON250/750 vs SFPIHCN250/750); a plan with an HCN but no steerage needs only one package for both in- and out-of-network.	(User Guide ch. 6)
GRP-61	Procedure and diagnosis code groups may not contain overlapping code ranges — a code may not exist in more than one code group. A group may mix code types (e.g. a CPT range plus HCPCS codes beginning with J), and matching any listed type or group satisfies the criterion. Procedure code types: CPT, HCPCS, NDC, ASA, ADA, Custom; diagnosis type: ICD-9.	(User Guide ch. 6); group tables in bensupport (GRP-43)
GRP-62	Group termination semantics: terminating a master group implies its divisions; groups are terminated the day after the entered exp date; a group cannot be terminated until all its coverages are terminated; run-out end date equal to the coverage exp date means no run-out, a null run-out with an exp date means infinite run-out, and a run-out without an exp date is meaningless. Access to the termination window is restricted to Office Enrollment Managers, Office Managers, MIS, and developer user classes.	(User Guide ch. 2); blocks and updates corroborated by client/w_client_term_group (GRP-18..21)
GRP-63	Coverage, category, and option changes that affect enrolled members offer a choice of immediate application (stored procedure updates members and stamps the applied-to-members date) or deferral to nightly batch processing; immediate application to large member populations is discouraged.	(User Guide ch. 2); columns corroborated by GRP-10
GRP-64	Coinsurance and Out-of-Pocket rules are mutually exclusive — a single client group never uses both. Coverage-level maxima accumulate on the considered amount for coinsurance and limits, and on the retained amount for deductible, OOP and copay; quantity limits accumulate units. OOP may apply to all dollars or only after the deductible is met, and its limit may include amounts applied to the deductible.	(User Guide ch. 6)

Benefit plan configuration model

This is the heart of the domain: what a "plan" is, and how claims adjudication reads it.

Entity chain

The canonical resolution path, as the plan-analysis report (bensupport/d_plan_rpt_group_rule_analysis) implements it:

Step	Predicate	Note
Scope to leaf groups	gc.group_id IN (SELECT group_id FROM groups g1 WHERE NOT EXISTS (SELECT * FROM groups g2 WHERE g2.parent_group_id = g1.group_id) START WITH group_id = RPAD(:grp,15) CONNECT BY PRIOR group_id = parent_group_id)	Descends the subtree from the requested group and keeps only groups with no children
group_coverages → plan_pkgs	gc.benefit_coverage_type_cd = pp.benefit_coverage_type_cd AND RTRIM(gc.benefit_coverage_cd) = pp.benefit_coverage_cd	RTRIM on the left side only — char(15) padding matters (Migration note 3)
plan_pkgs → pkg_rules	pr.benefit_pkg_sys_key = pp.benefit_pkg_sys_key
pkg_rules → benefit_rules	br.benefit_rule_sys_key = pr.benefit_rule_sys_key

Two details are easy to get wrong when reading this report as a specification:

• groups is not joined to group_coverages. There is no groups.group_id = gc.group_id predicate. groups appears only as groups.group_id = RPAD(:grp,15), supplying the group name for the report header; the coverage rows are constrained solely by the leaf subquery above. The subtree scoping is therefore done entirely in the IN list.
• Three further joins are inner and can silently drop rules: r.reason_sys_key = pr.accum_sys_key (reason_codes), bp.benefit_pkg_sys_key = pp.benefit_pkg_sys_key (benefit_pkgs), and plan.benefit_coverage_type_cd = pp.benefit_coverage_type_cd AND plan.benefit_coverage_cd = pp.benefit_coverage_cd (benefit_plans). A rule whose accumulator reason code is missing will not appear in the report at all. The query is SELECT DISTINCT.

Plan (benefit_plans)

One row per coverage type + plan code. Holds plan-wide adjudication parameters:

Field group	Columns	Notes
Identity	benefit_coverage_type_cd, benefit_coverage_cd, description, plan_status_cd	Plan code doubles as the group's group_coverages.benefit_coverage_cd — the guide warns that "if the code in enrollment and the code in the plan are not identical then the system will not be able to assign a plan to a claim" (User Guide ch. 6). Status catalog: COMPLETE / INCOMPLETE / NONPROCESS / VOID / AS MEDICAL (GRP-53)
Timely filing / appeals	filing_period_length + filing_period_type_cd, appeal_period_length + appeal_period_type_cd	Period codes from code table PERIOD
Package search	pkg_logic_cd	Code table PKGLOGIC; defaulted to NORMAL on new plans (benplans/w_create_benefit_plan). The guide documents two values: Normal — search sequentially through the attached packages in their load order — and DentalStep — special logic for step-driven dental plans where deductibles fall and benefits rise each compliant year (User Guide ch. 6)
COB / maxima	cob_method_cd, lifetime_max_amt
Dependent ages	dep_age_student, dep_age_non_student	Defaults: 19 non-student, 21 student (User Guide ch. 6)
Pre-existing	pre_ex_sub_prior_*, pre_ex_sub_elapsed_*, pre_ex_dep_prior_*, pre_ex_dep_elapsed_*	Prior and elapsed period length/type for subscriber and dependent
Other	auto_assignment_ind, wdi_pmt_sched_cd

Package attachment (plan_pkgs) — versioning and network selection

plan_pkgs is the effective-dated, ordered link from plan to package. Each row: eff_dt / exp_dt, search_order_seq, hcn_sys_key (health-care network; null = default/no-network package), pricing_plan_sys_key, pricing_logic_cd (code table PRICELOGIC), ur_firm_sys_key, cm_firm_sys_key. Plan versioning is expressed here: changing a plan's design over time means expiring one plan_pkgs row and adding a new one; the plan header itself is not dated. Overlap of same-HCN attachments is rejected (GRP-26) and one live no-network attachment is required (GRP-25).

Guide semantics for these columns (User Guide ch. 6): the attachment order "will determine the ranking used when the system is determining which Package to use in claim's adjudication" — under Normal package logic the search is sequential, so load order matters when a provider is in more than one HCN; the guide instructs that when a plan has both out-of-network and network packages "the out of network package should be listed first". Pricing logic values are HCN (pricing at the health-care-network contract level), External (an outside source prices, e.g. an HCN that does its own pricing), and Package (pricing attached at the package level). An effective date must always be entered for a package attachment.

Package (benefit_pkgs)

A reusable bundle of rules per coverage type: benefit_pkg_cd, description, default_benefit_def_sys_key (definition assigned when no rule's definitions match), unassigned_action_cd (HOLD / EXCLUDE / PAY, with reason unassigned_reason_sys_key), pricing_plan_sys_key, second_opinion_sys_key, extraction_flg, procedure_flg. Package maintenance (benplans/w_benefit_pkg_maint) manages the attached rules (pkg_rules), riders, and the dependency / requirement / fulfillment structures.

Rule (benefit_rules) — the adjudication atom

Rule type (rule_type_cd, code table BENRULE) governs which fields are meaningful (GRP-31..36). Amounts are retained values or coverage-level schedules; accumulators are reason codes with RETAINED vs CONSIDERED accumulation; scope filters include period, age band, considered-amount band, weekdays, accident-only, per-day and per-unit bases. benefit_rules rows are shared masters — attaching to packages happens in pkg_rules (with its own effective dating and priority), so one rule can serve many packages, and the rule editor updates pkg_rules attachments in the same transaction (GRP-40).

Guide intent for special rule types (User Guide ch. 6): Hold rules route the claim to an examiner — the claim finishes all Hold rules, then skips the rest of automated adjudication; hold rules are "typically SFPI/M3 requirements", not part of the plan document. 100% rules mark a claim payable in full "merely for categorization and reporting purposes" — other rules and pricing may still reduce the payment; a 100% rule with no dollar maximum is never "executed" and exists to let benefit definitions be assigned (only definitions cited in a plan's rules are searched) and to define a plan's set of "Basic" definitions. Age bands are through-ages, not to-ages (a benefit for ages 35–40 is entered min 35 / max 39). Rules limited by an accident indicator set to Yes require a companion rule with the indicator set to No. When packages differ in benefits but must share one maximum (e.g. an HCN package covering routine care and an OON package that does not), separate rules are created that share the same accumulator code (GRP-58).

The exclusion and hold catalogs

Exclusion and hold rules are ordinary benefit_rules rows (types EXCL and HOLD), but the guide fixes the inventory each plan is expected to support and — crucially for a migration — names the criterion that drives each one. The criterion column tells you which reference data must migrate alongside the rule.

GRP-72 — Exclusion catalog. The system must provide for all of the following exclusion rules, each driven by the criterion named (User Guide ch. 6):

Exclusion	Driven by	Exclusion	Driven by
Not Medically Necessary	(none — examiner judgement)	Vitamins	CPT or NDC
TMJ	Diagnosis codes	Recreational / Educational therapy	Revenue code
Non-Accidental Dental	Diagnosis codes or Accident box	Certain DME	HCPCS
Non-impacted Wisdom	CPT / ADA	Transportation	HCPCS
Cosmetic Surgery	CPT	Meals	Revenue code
Routine Foot	Diagnosis codes	Personal Items	Revenue code
Radial Keratotomy	CPT	Exogenous Obesity	Diagnosis codes
Refractive Keratoplasty	CPT	Workers Comp	Condition code or Workers' Comp box
In-vitro / Artificial Insemination	CPT	War	Condition code or Workers' Comp box
Smoking Cessation	Diagnosis codes	Non-Emergency Weekend Admission	Day of week and diagnosis codes
Materials for Occupational Therapy	CPT	Experimental	Custom table
Intentionally Inflicted Injury	Diagnosis codes	Elective Abortion	CPT or diagnosis codes
Injury During Felony	Diagnosis codes

Two behaviors go with the catalog: examiners must be able to override an exclusion when the client directs it, and anything matching neither an inclusion nor an exclusion falls to "Unassigned" and is handled by the package's unassigned action (GRP-29, GRP-56).

GRP-73 — Hold catalog, and the hard-coded / table-driven split. Hold rules are usually not part of the plan document — they are TPA requirements. They divide into two varieties, and the distinction is the single most migration-relevant fact in this section: table-driven holds are data the users control, while hard-coded holds are behavior owned by another module and cannot be reproduced by migrating rule rows alone (User Guide ch. 6).

Hold rule	Owned by	Variety
Missing Information	Separate module	Hard coded
COBRA Waiting	Eligibility	Hard coded
COB	Eligibility / separate rule	Hard coded
Accident / Subrogation	Benefit rule	Table driven
Pre-Existing	Separate module	Table driven
Large Claims	Benefit package	Table driven
Operative Notes	Pricing	Table driven
Pre-Certification	Benefit rule	Table driven
Second Opinion	Benefit rule	Table driven
Possible Duplicates	Separate module	Table driven
Case Management	Separate module	Table driven
Physician Orders	Benefit rule	Table driven
No Provider Contract	Pricing	Table driven
Service Authorization	Benefit rule	Table driven
Pre-Notification	Benefit rule	Table driven
Student Status	Eligibility	Table driven
Annual Enrollment Forms	Eligibility	Table driven

A claim that enters Hold finishes all hold rules, then skips the remainder of automated adjudication and goes to an examiner. Held claims are not re-run by the nightly process until the hold clears — which is why the system must surface every known error, warning and hold reason on the claim's first pass rather than one at a time.

Definitions and contingencies at adjudication time

Claims adjudication (clmsproc/n_claim_adjudication, outside this domain but the consumer of this model) resolves, per claim line:

1. The benefit definition of the service, using package definition priorities (stored procedures sfpidba.sp_pkg_defs, results staged in temp_benefit_defs).
2. The candidate rules of the package (pkg_rules by priority), expanding each rule's definitions via sfpidba.sp_rule_defs (and d_adjd_* DataWindows over rule_defs).
3. Contingencies: for each rule with contingency_ind set, the contingency definitions (sfpidba.sp_rule_contingency_defs / rule_contingency_defs) are checked against the member's claim history within contingency_period_length + contingency_period_type_cd; the rule is skipped unless the with/without condition matches (GRP-39).

Tables read by the claims side (schema CRUD matrix): clmsproc reads benefit_plans, benefit_rules, benefit_defs, benefit_pkgs, pkg_rules, plan_pkgs, rule_defs, rule_contingency_defs, carryover_rules, level_scheds, group_coverages, group_periods, and writes accumulator-affecting structures (pkg_rule_requirements, pkg_rule_fulfillments).

Effective dating summary

Layer	Dated?	Mechanism
benefit_plans	No	Undated header; create/update audit columns only
plan_pkgs	Yes	eff_dt / exp_dt per attachment; overlap checks per HCN
benefit_pkgs	No	Undated master
pkg_rules	Yes	eff_dt / exp_dt per rule attachment
benefit_rules	No	Undated master; period fields describe accumulation windows, not row validity
group_coverages	Yes	eff_dt / exp_dt (+ run_out_exp_dt, applied_to_members_dt)
group_option_vals, group_enroll_opts, group_member_cat, grp_mbr_cat_val, grp_covr_elig_rules, group_periods	Yes	eff_dt / exp_dt pattern, null exp = open-ended

Coverage types that sit outside the benefit-rule model

Three coverage types are documented in the plan-design chapter as deliberate exceptions — they do not fit the rule engine described above, and a migration that models only rules/packages/definitions will miss them entirely.

Weekly Disability Income (WDI)

WDI is administered as a separate area within Plan Design because it does not lend itself to benefit rules. WDI rules are plan-based and shared — multiple clients re-use a single plan, unlike the one-client-per-plan norm elsewhere.

• GRP-65 — A WDI plan must carry at least: flat fees, % of salary, maximum number of weeks, number of days in a week, confinement / accident / illness / outpatient-surgery handling, weeks used, waiting period, and tax handling. (User Guide ch. 6)
• GRP-66 — The system supplies four WDI benefit definitions — Confinement, Accident, Illness, Outpatient Surgery. Users cannot create or edit them, but may use them in packages and package rules; the examiner decides when to assign them to claim detail lines. (User Guide ch. 6)
• GRP-67 — Periodic-payment automation (shared with orthodontics, GRP-68). WDI benefits pay out over time, so accumulators hold cumulative weeks paid, periodic payment amount, payment frequency (1st of month, 1st of quarter, or based on service date) and maximum number of weeks. A payment plan is open while the cumulative total paid is less than the maximum owed. While a plan is open, an incoming claim is denied with reason "Duplicate Claim Against Generated Claim". When no open payment data exists the claim is the first of a sequence: the system prompts the user to set up the accumulators, then generates the scheduled claims as part of the nightly cycle until the maximum is reached. The guide notes this was all manual at the time of writing. (User Guide ch. 6)

Orthodontics

• GRP-68 — Ortho services (procedure codes 08010–08999) are paid off over time rather than at once, using the same periodic-payment mechanism as WDI (GRP-67) but keyed on money rather than weeks: cumulative total paid, periodic payment amount, frequency of payment, and maximum amount owed. The open/denied/first-payment/nightly-generation behavior is identical. (User Guide ch. 6)

Prescription plans

Drug coverage behaves unlike any other coverage type because much of it is adjudicated outside HOMER by the card vendor.

• GRP-69 — The bulk drug plan. There is exactly one bulk drug plan, RX-BULK-000; it is simply added to the group. Enrollment creates a "fake" member with life status system and grants it the coverage, and the system then treats claims against that member as bulk payments. Bulk claims are entered client by client so the dollars apply to aggregate stop-loss, not to pay the claim: the check the system generates is voided and a manual check is cut to the prescription company. PBM service fees are submitted as a single claim against the same bulk member. (User Guide ch. 6)
• GRP-70 — Three distinct handling modes exist per client, and the plan build must state which applies: (a) do not adjudicate drug claims but record the charges so payments to the service and register worksheets are generated and the client replenishes the account; (b) apply the charges to the member's deductible only; or (c) fully adjudicate the claim. A drug-coverage election indicates a card — all other drug claims process under the member's medical election. (User Guide ch. 6)
• GRP-71 — Card, point-of-sale and mail-order drug claims skip checks that ordinary claims receive, because the outside agency has already performed them: card claims bypass coverage entirely and are excluded from CM/UR, and POS and mail-order claims skip eligibility-date checking. Duplicate checking on card claims is recorded as contested in the guide. A group-level switch decides whether drug charges apply to stop-loss (when they do, they always apply to medical). (User Guide ch. 6; the group-level switch is one of the undocumented group_options values — see Open questions #8)

Scope boundary

The Drug Plans module documents the PBM eligibility export side (Caremark/Optum flag files). The plan-design rules above are what a drug plan must express before those exports mean anything.

Sales / broker tracking (sales library)

The sales library is a client-facing reporting module (no broker/commission tables surfaced in it). The user guide's Sales Support chapter is a 1996 requirements outline, not a description of built screens: it envisions proposals, case flows, underwriting, and census handling (electronic and paper) — marketing activity reports, request-for-quote preparation for new and renewal cases, fax/electronic RFQ submission to carriers, automated presentation creation, and monitoring of sales submissions. Its RFQ data-source table shows the quoting inputs were expected to come from existing outputs: the billing file (company data, employee counts, proposed effective date, stop-loss parameters, unit premium rates), the aggregate stop-loss report (claims experience, large-claim and monthly claims/enrollment data), and the census (User Guide ch. 20). None of this maps to shipped sales windows — the library as built is the report wizard below — so treat ch. 20 as unimplemented intent.

Broker facts from the commissions and billing chapters that bear on this domain (User Guide ch. 8, ch. 4):

• Broker/agent master data must carry the broker's company name, contact name, and payee name; roughly two-thirds of cases have a broker, and a case may have multiple brokers with split formulas.
• "Policy numbers tie a group to a carrier"; Medicare-supplement policy numbers exist at the member or election level and are unique per broker.
• Per accounting and sales support, there is no need to track broker↔group relationships over time (no history requirement).
• Commission reporting needs client, date, dollars, plan year, broker code, and client number. (Commission withholding/disbursement itself is billing-side — see the billing module, BIL-43.)
• The billing hierarchy is the group parent/child definition maintained in Client Maintenance (no separate billing tree), and clients carry separate billing vs register addresses (User Guide ch. 4).

As built:

• Report wizard (sales/w_sales_report_wizard + u_sales_wizard_* steps, n_cst_sales_report_wizard / n_cst_sales_clntbased_report_wizard): the user picks a report type from report_info (sales/d_sales_report_select), selects groups (u_sales_wizard_group_select) and parameters, and the result renders in sales/w_sales_report_sheet.
• Client-based financials: paid claims by month (d_sales_clntbased_paid_claim, d_sales_clntbased_claims_by_month), lag / incurred triangles (n_cst_sales_clntbased_lag_triangle, d_sales_clntbased_lag_incurred), IBNR estimates (n_cst_sales_clntbased_ibnr, d_sales_clntbased_ibnr — driven off groups + group_coverages), HCN summaries, and coverage lists that exclude non-claims coverage types such as life / AD&D / LTD (d_sales_clntbased_coverages).
• Claimant registry (d_sales_clmnt_reg): payments per claimant from the fund register joined to claims, members, and vendors, with confidential variants.
• Detailed claims listing (sales/w_sales_rpt_group_claim_detail): claims by selected group subtree, claim type, and paid-date range, with discount and confidential variants, including per-line rule data (d_sales_rpt_group_claim_rule_data).
• Benefit category maintenance (sales/w_sales_benefit_category_maintenance, title "Benefit Category Maintenance for Segment:"): assigns benefit definitions to report service categories (rpt_svc_cats / rpt_svc_cat_defs) per client segment and report type; segments come from client_segments and groups map to segments via client_segment_groups (edited on the group screen, GRP-22).

Data + CRUD

Primary tables owned (CRUD) by this domain, with main outside readers:

Table	Purpose	CRUD here	Notable readers elsewhere
groups	Group master + hierarchy	client	~30 libraries; billing, enroll, funding, stoploss also write
group_coverages	Coverages offered per group	client, bensupport	enroll, clmsproc, billing (billfunc), cobra, stoploss, funding
group_contacts	Group contact people	client	census / report DWs
group_option_vals / group_options	Typed group option values	client	enroll, funding, idcard, provider, um_maint
group_enroll_opts	Enrollment options	client	enroll
group_member_cat, grp_mbr_cat_val	Member categories + values	client	enroll
grp_covr_elig_rules	Coverage eligibility by category	client	(client only)
group_periods	Plan-year / enrollment periods	client	billfunc, clmsproc (also write), enrollutils
benefit_plans	Plan headers	benplans	clmsproc, billing, enrollutils, um_*
plan_pkgs	Plan → package attachments	benplans	17 libraries incl. clmsproc, enroll, funding
benefit_pkgs	Package masters	benplans	claims, clmsproc
pkg_rules	Package → rule attachments	benplans	clmsproc, clmentry, clmutils
benefit_rules	Rule masters	benplans (also clmsproc)	clmentry, chkrundw, stoploss, sales
benefit_defs, benefit_def_procs, benefit_def_diags	Definition criteria	benplans	clmsproc, clmentry, pricing, um_main, sales
rule_defs, rule_contingency_defs	Rule ↔ definition links	benplans	clmsproc, claims
pkg_rule_dependencies / _requirements / _fulfillments	Rule interactions	benplans	clmsproc (requirements/fulfillments also written there)
rider_rules, pkg_riders	Rider effects on rules	benplans
carryover_rules, level_scheds, level_sched_items, step_rate_scheds, step_rate_items, rounding_rules, second_opinion_lists, reason_codes	Rule support objects	bensupport	clmsproc
procedure_groups, procedure_code_groups, diagnosis_groups, diagnosis_code_groups, tooth-type tables	Reusable code groups	bensupport	clmsproc, um_*
carriers, stoploss_waivers	Stop-loss carriers + member waivers	client	stoploss
client_segments, client_segment_groups, rpt_svc_cats, rpt_svc_cat_defs	Sales segmentation / categories	client, sales
grp_chg_prop_hist	Parent→child change propagation history	client

Migration notes

1. The rule engine is data, not code. Deductibles, coinsurance, copays, OOP maxima, visit limits, exclusions, and holds are all rows in benefit_rules typed by BENRULE codes, attached to packages with priorities and member-scope flags. A target system must reproduce: retained-vs-scheduled amounts, the stored complement convention for COI/OOP (GRP-33 — displayed "pay at 80%" is stored retain_val = 20), accumulator identity via reason codes with RETAINED/CONSIDERED accumulation, carryover rules, and the contingency with/without look-back mechanism.
2. Definition criteria are embedded SQL predicates (GRP-42). Migrating benefit_defs requires parsing predicate strings (IN lists, BETWEEN ranges, % wildcards, AND/OR) for procedure/diagnosis/POS/specialty/modifier/revenue columns, plus group references and compound (parent/child) definitions. This is the highest data-conversion risk in the domain.
3. Plan identity is a composite natural key (coverage type + plan code) shared verbatim between group_coverages and benefit_plans / plan_pkgs — including RTRIM-sensitive char(15) padding (joins use RPAD(:grp, 15) / RTRIM). Target models should introduce surrogate keys but must preserve the code pair for interfaces.
4. Effective dating conventions: null exp_dt = open-ended; some queries substitute 12/31/2049 as the open-ended date (client/d_client_census_group_option_vals). Versioning granularity differs by layer (see table above): plan headers and rule masters are undated, package and rule attachments are dated.
5. Hierarchy semantics rely on Oracle CONNECT BY; coverage resolution happens at leaf groups, master-group resolution walks upward. Any re-platform must reimplement subtree expansion for termination cascades, plan analysis, and stop-loss fallback.
6. Stored-procedure logic lives outside the extracted source: term_groups_master, term_groups_division, term_members_master, term_members_division, sfpidba.new_group_coverages, sfpidba.sp_pkg_defs, sfpidba.sp_rule_defs, sfpidba.sp_rule_contingency_defs are called but not defined in the PowerBuilder code. Their bodies must be recovered from the database before migration.
7. "Apply to members" is a deferred-propagation pattern: coverage / category changes are marked (unapplied_chg_flg) and applied to member elections later; the application step lives in enrollment-side code. Preserve the two-phase semantics.
8. Security coupling: group visibility is enforced in the data layer by joining security tables into every pick list; group creation writes security rows with hard-coded user classes (GRP-5) and one hard-coded group-id prefix exception.
9. Legacy cross-references: groups carries external carrier identifiers (ELR/control/suffix/account/plan no) and bensupport/w_wang_map maintains mappings from a predecessor system (wang_rule_map, wang_group_rule_map) — decide whether these survive migration.
10. Sales reporting reads adjudicated claims and fund-register views; migrating it is mostly a BI/report exercise, but rpt_svc_cats category mappings are per client segment and per report type and must be carried over for report continuity.

Open questions

Items marked Resolved were answered by the official user guide; residual SME confirmations are noted inline.

1. Parent→child change propagation — RESOLVED (intent): designed "Inheritance" feature, apparently never completed. The guide specifies the behavior the stub was meant to implement: "Whenever a new parent group is added or a group having sub-groups is altered, the system will ask if the changes should be applied to the sub-groups. If so, all of the sub-groups will be displayed in a list window with checkboxes set, to the specifications from the most recent inheritance triggered changes, and the user will be able to turn the checks off for each sub-group that is an exception" — with a further prompt to apply group-level value changes down to member level (User Guide ch. 2). That matches client/w_client_grp_chg_prop_hist (children listed with Include flags pre-checked from grp_chg_prop_hist) exactly — except the apply body is empty in code, and the guide still lists the sub-group inheritance window under Future Enhancements. Conclusion: designed but never finished; propagation is manual (or via the copy-group dialog at child creation). Residual: confirm no database trigger/procedure performs it.
2. BENRULE code values — RESOLVED. The guide enumerates exactly nine rule types: Deductible, Coinsurance, Out of Pocket, Claimed Limit, Payable Limit (= PAID), Copay, Exclusions, 100%, Hold — matching the nine observed in source one-for-one (User Guide ch. 6). (An early requirements list also names a "Pend" type, which became Hold.) A data extract remains a belt-and-braces check.
3. pkg_logic_cd semantics — RESOLVED. PKGLOGIC has two values: Normal (search sequentially through the plan's packages in attachment order — hence the emphasis on package load order) and DentalStep (step-driven dental plans: the system checks the member's current step level and whether scheduled procedures, e.g. an annual cleaning, were performed; deductible decreases and benefits increase each year until 100% at year five) (User Guide ch. 6). The step-advance algorithm's claims-side implementation still needs code/SP confirmation.
4. Stored-procedure bodies — still required for exact behavior, but the guide now documents the intended semantics of the termination procedures (master implies divisions; termination effective the day after the exp date; run-out conventions; member-first ordering — see GRP-62) and of definition resolution (GRP-56), giving the recovery effort an acceptance spec (User Guide ch. 2, ch. 6).
5. benefit_rules CRUD from clmsproc: the claims library shows create/update access to benefit_rules in the CRUD matrix; confirm whether adjudication actually writes rule rows (e.g., temp copies) or whether this is incidental. (Guide silent.)
6. Eligibility-rule copy — PARTIALLY RESOLVED. The guide's inheritance window design includes an Eligibilities checkbox among the six copyable sections (User Guide ch. 2), so copying coverage-eligibility rules was intended; the commented-out call is an unfinished implementation, not a withdrawal of the requirement. Confirm with SMEs before reviving it.
7. w_caremark_group_setup — RESOLVED (purpose), with a naming discrepancy. The guide documents the window as CareMark Group Setup: "for setting up a group who has taken a linked drug/medical plan directly connected with CareMark." At the master level the operator enters the OOP and DED accumulator codes; at the division level the per-coverage-level accumulator amounts; the Embedded checkboxes state whether single/family accumulator amounts are linked (unchecked = check Single first, then Family). Saving writes a group option value CVS at both master and divisional levels — "never directly tamper with that value, always change values through this window" — and the amounts feed a "flag file report" (the vendor accumulator extract). Even when family and n-tier amounts are equal, the tier amount must be re-entered when Embedded is checked; if the plan pays 100% after deductible, OOP fields stay blank/0 (User Guide ch. 2). Discrepancy: the code's window comment says "Create Matria Claim Files" while the guide says CareMark/CVS — likely a vendor change over time; confirm the current vendor interface contract with SMEs.
8. Group option catalog — PARTIALLY RESOLVED. Still a data extract, but the guide confirms one concrete option value: CVS (CareMark linked drug/medical linkage, maintained only via the CareMark window) (User Guide ch. 2); the drug-plan notes also imply group-level card/mail-order and apply-to-stop-loss switches (User Guide ch. 6). Extract group_options for the full dictionary.
9. Renewal process — CONFIRMED MANUAL. The guide contains no renewal transaction either; renewal surfaces only as an operational practice (contact-form refresh at renewal; ch. 20's "renewal cases" RFQ preparation was never built). Renewal is re-entry of new dated rows, plus bensupport/w_convert_plan for plan-code moves (User Guide ch. 2, ch. 20).
10. COBRA reserve amount entry point — the guide itself asks "Where does the COBRA reserve amount get entered into the system?" (User Guide ch. 2); unresolved in both guide and source. Ask SMEs (likely billing/COBRA side).