Enrollment & Eligibility

Libraries covered: enroll (member enrollment maintenance, quick enrollment, HIPAA certificates, QMCSO, HB1, eligibility export), enrollutils (mass termination / re-enrollment, FSA notices), enrolaud (enrollment audit log), enrolrpt (census, annual statements, dependent-eligibility audit, error reports).

Purpose

This domain maintains the population that all claims, billing and ID-card processing depend on: who is a member, which group/division they belong to, for what date range they are eligible, and which benefit coverages they elected. It supports full-screen enrollment maintenance (enroll/w_enrollment_maintenance), a streamlined "Quick Enrollment" intake (enroll/w_quick_enroll_main), group-level mass termination and re-enrollment (enrollutils/u_terminate, enrollutils/w_reenroll), a member-level audit log (enrolaud/w_enrollment_log), and an enrollment reporting catalog (enrolrpt).

Business context (official)

• Enrollment/Eligibility "feeds all other parts of HOMER" — verifying coverages, paying claims, and billing. All enrollment data is manually entered; there is no standard electronic intake ("EDI Enrollment" exists only as case-by-case custom programming for run-in loads of large new groups) (User Guide ch. 1).
• Enrollment is initiated two ways: Initial Enrollment from a census received at new-client setup (SSN, name, birth date, elected coverage), completed upon receipt of an Enrollment Form; existing clients add employees via an Enrollment Form, and changes are conveyed on a Record Change Form (User Guide ch. 1).
• Procedural precision is a legal/financial control: stop-loss insurers require a copy of enrollment materials at claim submission, and a carrier may deny reimbursement when enrollment did not follow the Plan Document — leaving the client responsible for the claim (User Guide ch. 1).
• Group structure: a client's corporate structure is groups and sub-groups under a single CLIENT MASTER GROUP, itself under a top-level SFPI or M3 master designation; "informational" groups exist for SFPI/M3 purposes only. Members are enrolled at the client master group level, but coverage may only be elected in groups with no subordinate sub-groups (the lowest, leaf divisions). Options defined at the master group are inherited by sub-groups unless overridden or declined (User Guide ch. 1). This matches the leaf-group expansion and CONNECT BY hierarchy handling in code (ENR-33, idcard/d_group_subs).
• Enrollment Maintenance operates in three modes — Query, Update, Add — chosen by the user's security setup; Add must begin with a subscriber, since dependents exist only under a valid subscriber's elections (User Guide ch. 1). These correspond to the code's open modes detail/change/add (enroll/w_enrollment_maintenance wf_dw_edit_status).

Actors

Grounded in window titles, menus and security joins (no explicit role model exists in these libraries):

• Enrollment clerk / plan administrator staff — operates member select, enrollment maintenance and quick enrollment screens (enroll/w_group_member_select "HOMER - Member Select", enroll/w_enrollment_maintenance "HOMER - Member Enrollment Maintenance").
• Supervisory / utility user — runs group-level termination and re-enrollment (enrollutils/w_term, enrollutils/w_reenroll) and eligibility export (enroll/w_enroll_group_export).
• Auditor — reviews change history in the Enrollment Audit Log (enrolaud/w_enrollment_log).
• System (MIS) — referenced in error messages ("Please contact the MIS Dept.", enroll/w_enrollment_maintenance ue_set_new_row); maintains group options that drive screen behavior.
• Access to master groups is restricted per user via security tables (enroll/d_enroll_master_group_ids joins security_user_class_user/security_user_group on user_id).
• The user guide confirms the departmental split: the Enrollment department enters member data, initial COB and QMCSO information; claims examiners and UM maintain COB/student data thereafter; view-only vs edit vs add vs delete access, the Move Eligibility icon and the Audit Log are all security-restricted, and the Delete Member function "is not available to all users" (User Guide ch. 1).

Key workflows

New enrollment (full maintenance)

enroll/w_group_member_select ("HOMER - Member Select") is documented as the "First screen for member enrollment. Allows a user to Add/Delete/Modify/View a member". It opens w_master_group_select, the member-search popups, and enroll/w_enrollment_maintenance, which carries an open mode (add / change / remove / detail) that drives field editability (wf_dw_edit_status).

w_enrollment_maintenance is a tabbed sheet over one subscriber family:

• Subscriber Eligibility tab — demographics (d_enroll_member_demographics), phone, address, subscriber eligibility periods (d_enroll_subscriber_eligibility_period), subscriber categories (d_enroll_member_subscriber_categories), waiting periods (d_enroll_wait_pd).
• Dependents tab — dependent list (d_enroll_member_dependents), per-dependent eligibility periods (d_enroll_dependent_eligibility_period), categories, address, student info (d_enroll_dependent_student_info), dependent waiting periods.
• Coverage tab — coverage elections (d_enroll_dependent_coverage_elections over elections), member coverages (d_enroll_subscriber_member_coverage over election_coverages), coverage riders (d_enroll_subscriber_coverage_riders).
• PCP tab — primary care physician assignment via enroll/n_enroll_member_pcp and enroll/w_enroll_pcp_search.

Official add procedure: after a group is set up through Client Maintenance, a person may be added only when an Enrollment Form has been received, and it must be verified that the form was completed within 31 days of the person's effective date under the plan; otherwise the person is a Special enrollee or Late enrollee and may only be added in accordance with the group's Plan Document (User Guide ch. 1). This check is an operator procedure — no 31-day validation exists in the extracted code.

Saving is a single transaction: ue_update saves member detail → dependents → family rows → subscriber eligibility → categories → dependent tab → elections → member coverages → riders → COB datastores → PCP → COBRA non-qual events, then commits; any failure rolls the whole save back (enroll/w_enrollment_maintenance event ue_update on tab_subscriber). After a successful save the window checks for ID-card requests (wf_request_id_cards → global f_submit_mem_id_req) and prescription-plan transfers (wf_request_prescription_tsfr).

Quick Enrollment

enroll/w_quick_enroll_main ("Homer - Quick Enrollment") is a one-screen intake for a new subscriber family: subscriber demographics (d_quick_enroll_subscriber), dependents (d_quick_enroll_dep), group/category assignment (d_enroll_category, d_quick_enroll_all_cat), subscriber eligibility and waiting period (d_quick_enroll_sub_eligible_pd, d_quick_enroll_sub_wait_pd), and coverage elections (d_quick_enroll_sub_cov_elect, d_quick_enroll_covg_elect). Popups collect dependent address (w_quick_enroll_dep_addr), dependent categories (w_quick_enroll_dep_cat), student info (w_quick_enroll_dep_student) and coordination of benefits (w_enrollment_cob_maint).

Save order (subscriber → dependents → family → eligibilities → categories → dependent categories → students → COB) is enforced in enroll/w_quick_enroll_main event ue_save, with distinct error codes per failed store.

Official intent: Quick Enrollment exists to speed up enrollment of new subscribers and their dependents, and to re-enroll families in flex plans (mass adds at plan-year re-enrollment); it "should not be used to maintain member information after members have been enrolled" — that is Enrollment Maintenance's job. On a re-enrollment, the screen defaults member, dependent, category and coverage data from the family's most recent data; a member who is already active cannot be re-added unless dates match exactly, and adds that would overlap a prior period are rejected. Coverage elections defined here all belong to the single eligibility period entered up front. Client Maintenance must have set up the group's coverages before Quick Enrollment begins (User Guide ch. 1).

Life events / changes

Changes are made in w_enrollment_maintenance in change mode. Evidenced life-event mechanics:

• Expiring an eligibility period — entering exp_dt plus a reason (dep_exp_cd) cascades expiration into elections and election coverages (wf_expire_coverage, wf_expire_dep_coverages) and evaluates COBRA consequences (wf_non_qual_event).
• Clearing an expiration date — clears the reason code and retracts any pending COBRA non-qualifying event (event itemchanged on the eligibility DataWindow).
• Division transfer ("Member Move Function") — ue_move_mem_div moves a saved eligibility period's elections/coverages to a sibling division; the target division is picked in enroll/w_enroll_trans_div. Changes must be saved first ("This function can only transfer data that has been Saved to the Database"). The guide documents the move as: pre-checks (member valid in the original group, eligibility dates within the new group's effective dates, coverage exists in the group coverage table), benefit-coverage-code translation (one-to-one coverage-type match rewrites the election with the destination code; otherwise the group id embedded in the coverage code is swapped and re-checked; untranslatable codes are left unchanged, the user is alerted, and a note record is written), then a fixed delete/re-insert order: delete coverages, elections, eligibility periods; insert new eligibility periods, elections, coverages. The move is only valid when no claims have been paid in the wrong division — when claims exist, a documented manual procedure applies (claims pulled back to corrections and held, member put on audit hold, elections terminated as of the most recent paid date and new eligibility started the day after, then claims reassigned) (User Guide ch. 1).
• Category value changes — operators must not type over an old category value; the correct procedure is to enter an expiration date on the current category row and add a new row with the new value, preserving history (User Guide ch. 1).
• Dependent addresses — the system always defaults the subscriber's address as a new dependent's address; a separate dependent address is entered on the Dependents Address sub-tab (User Guide ch. 1).
• Drug plan changes — expiring or changing a Drugs election sets a flag that triggers the prescription-transfer dialog after save (wf_expire_coverage sets ib_drug_processing; wf_request_prescription_tsfr opens w_drugplan_member_maint). The guide confirms the intent: for members with drug coverage, the Prescription Plan Member Maintenance window is raised whenever drug coverage is added/changed or its effective or termination date changes, and at the end of Quick Enrollment when the new member elected drug coverage in a group having PCS or EXP (ExpresScripts); its sole purpose is to generate rows in the drug transfer tables from which PBM files are built (User Guide ch. 1).

Terminations

• Member-level — via expiration date + reason on the eligibility period, with the cascade above.
• Group-level mass termination — enrollutils/u_terminate (hosted by enrollutils/w_term) takes a group, a termination date and a termination code, validates them, and calls enrollutils/n_term_enroll, which collects affected subscriber keys (d_term_keys: eligibilities active on the term date) and issues batched SQL updates: ELECTION_COVERAGES.MEMBER_ELECT_EXP_DT/_EXP_CD, ELECTIONS.ELECT_EXP_DT/ELECT_EXP_CD, MEMBER_ELIGIBILITIES.EXP_DT, and MEMBERS.MBR_TERM_DT, each restricted to records effective on and not already expired before the termination date. Errors are shown in enrollutils/w_term_errors`. Checkboxes let the operator choose scope (coverages / elections / eligibilities / members / all).
• Re-enrollment — enrollutils/w_reenroll reverses a mass termination for selected divisions and coverages: it validates the new period against group coverage periods (wf_check_group_covr) and group periods (wf_checkperiods), then calls of_termenroll_eligibilities / _elections / _coverage / _categories in n_term_enroll to create follow-on periods for members whose latest eligibility was expired with the matching code (d_reenroll_elig).
• Termination letters — enroll/w_enroll_custom_term_add_members, w_enroll_custom_term_generate and w_enroll_custom_term_print maintain a custom_term_transactions queue and generate/print letters stored in report_hist (blob report_data).

Quick facts evidenced elsewhere

• HIPAA certificates of creditable coverage — enroll/w_enroll_hipaa_add_members queues members into hipaa_transactions; w_enroll_hipaa_generate builds certificates into report_hist and marks queue rows PROCESSED; w_enroll_hipaa_print prints/reprints; w_hipaa_dead_file logs undeliverable certificates; history is kept as member notes with keys HIPAA Cert / HIPAA Dead File (d_hipaa_history).
  • Queue population (guide): besides the manual add screen, a database trigger populates the HIPAA table (processed indicator + dep/sub member sys keys) whenever a member loses Medical coverage — except for termination reasons Re-Enrollment, Deceased Dependent, Deceased Subscriber (only when single), Client Termination, and Transferred Division ("Coverage No Longer Offered" was removed from the exclusion list per Bonnie and Marsha, 01/12/2009). A companion trigger removes/re-adds queue rows when medical coverage is reinstated or a termination reason is changed (User Guide ch. 1). This explains why no code in enroll inserts the automatic queue rows.
  • Certificate rules (guide): HIPAA replaced Proof of Good Health as of July 1998; certificates are generated only for members in groups for which SFPI manages HIPAA (client-maintenance HIPAA option, cf. HIPAACert enroll option checked in w_enroll_hipaa_generate). One single-page certificate is produced per family (all members sharing a subscriber sys key), citing only the family members in the queue; it is always addressed to the employee (if the subscriber is deceased, to the first eligible dependent), with an extra copy to any dependent having a separate address. The certificate date is the print date; group number + member id are used in place of the subscriber SSN; reprints and member-requested "snapshot" certificates (independent of the queue) are supported, and after generation the operator confirms success before processed queue rows are deleted. Certificates track prior-coverage credit: an 18-months-of-creditable-coverage checkbox disregarding coverage before a 63-day break, waiting-period/hire dates, and coverage begin/end dates per member (open-ended coverage prints "Continuing") (User Guide ch. 1).
  • HIPAA-tracked coverage terminations include members who terminate normal coverage and elect COBRA, and members who terminate from COBRA; currently only Medical termination is tracked, though the design allows all coverage types (User Guide ch. 1).
• QMCSO — eligibility rows carry qmcso_flg; enroll/w_enroll_qmcso_maint maintains orders and custodians (qmcso_custodians, qmcso_guardians), and election_coverages carries qmcso_order_no.
  • Business process (guide): a court-issued Medical Child Support Order applies to a subscriber's children; a dependent under QMCSO may have a separate mailing address held by the legal guardian, which is used for QMCSO correspondence only and is deliberately not shown on the dependent Address sub-tab. All children cited in the order must already be enrolled as dependents before entry. Order statuses are Accepted, Declined, Notice Sent, Order Received, Waiting for Administrator, Waiting for Determination. The documented procedure: log the order, enroll missing children, send notices of receipt to employee and each child (with representative-designation form and plan procedures; CC to attorney where applicable), have claims held retroactive to the order's effective date via a VIP note until qualification is determined, review against a checklist, verify a signed OBRA amendment, obtain the plan administrator's signed determination (follow up after ten days), then notify all parties — claims processing begins as of the order effective date only for qualified orders. In practice every order processed to date had been declined as not qualified. Form letters (initial and 2nd-request categories, mapped per status) were specified to be queued to a request table and printed in the nightly production cycle, but automatic generation was not implemented (User Guide ch. 1).
• Member delete — accessible only from the Application Functions Enrollment menu and restricted by security; deletion is prohibited for any member that has appeared on a bill. A dependent delete removes only the dependent's records (coverages, categories, eligibility, waiting periods, drug member numbers, family rows, COB, student rows); a subscriber delete removes all dependents' records first, then the subscriber's (coverages, elections, categories, eligibility, waiting periods, notes, ID card rows, drug member numbers, family row). The member row and its address are deleted only when the member does not also appear in family as a dependent elsewhere. The Delete Member window takes SSN plus a subscriber or dependent sys key (not both), obtained from MIS (User Guide ch. 1). The implementing object is homersys/n_delete_member (see COB-22 on the COB page).
• Proof of Good Health (POGH) — obsolete since HIPAA (July 1998); "there are currently no windows under this option in Homer". The guide preserves the historical rules (POGH required when enrolling more than 31 days after hire, on single-to-family level changes, adds, or coverage increases; applies to Life and Medical only; handled either by the carrier or by SFPI/M3 under a detailed correspondence workflow with statuses such as Waiting for Application, Waiting for Carrier, Waiting for Employee, Accepted, Declined, Closed) (User Guide ch. 1). No POGH code exists in the extracted enrollment libraries — consistent with the guide.
• CMS Section 111 (Medicare reporting) — the guide documents an operator batch procedure over three windows not found in the extracted enrollment libraries: TIN Reference File (Create File button), MSP Input File (Write File, Backup Table before and after, Apply Input File) and CMS Response File (Test File to dry-run every insert/update with per-row status, then Load File; dispositions and executed queries saved to files). Operators must strip the trailing newline from created files and always back up the table before applying, reloading from backup on error (User Guide ch. 1). See Open questions for the owning library.

Data standards (official)

• Member names — first-name fields must contain only the first name: middle initials go in the middle-name field and suffixes (II, III, JR) in the last-name field. The WANG-era habit of keying "First M." into the first name breaks claim-to-member matching, because claim entry matches subscribers by group number, insured name and address as well as SSN; a one-time cleanup program (move trailing initials to middle name, normalize Ii/Iii to II/III, move suffixes to last name) was run, and operators are instructed to correct remaining variants manually as encountered (User Guide ch. 1).
• Addresses — the Mailers+4 software standardizes all addresses on entry (this identifies the vendor behind the invo_mailers/nvo_mailers service, ENR-21/22). When Mailers+4 cannot standardize an address the operator directs the system how to handle it, and non-standardized addresses are always displayed with a light yellow background. An address may not contain both a PO Box and a street address (Mailers+4 cannot standardize that combination) — two separate addresses must be entered; if only the second address line is filled, the application moves it to the first line. Duplicate checking is performed within address type, so the same address text may exist under separate keys for, e.g., groups vs providers. Changing an address shared by other members/entities prompts whether the change is for the current member only or for all sharers (User Guide ch. 1). Note an internal inconsistency in the guide: the window descriptions define Line 1 as suite/apartment/PO Box and Line 2 as street, while the address-standards section states the reverse — resolve against the live screens/database.
• Per-group eligibility rules — the guide carries a client-by-client catalog ("SFPI Client Eligibility Rules") of waiting periods ("first of the month coinciding with or next following N days", work-day counts, hour thresholds), salary-based Life/AD&D formulas with rounding and min/max clamps, linked coverages (e.g. Medical+Drug), mandatory vs optional benefits, and billing-code conventions (e.g. "put a 1 under LTD to charge the COBRA claim fee"). These correspond to the configuration consumed by ENR-9 (waiting-period computation) and ENR-19 (salary-based benefit amounts) and confirm that waiting-period/benefit derivation was intended to be automated per group ("the user would like to enter a date of hire and have the system generate the effective dates for coverage(s)") (User Guide ch. 1). The catalog itself is client configuration data, not system behavior, and several entries document off-label use of coverage fields as billing flags — a data-cleanup concern for migration.

Business rules

All statements below are grounded in the cited object; wording is technology-agnostic. The sequence continues past ENR-45: ENR-46 to ENR-57 (QMCSO, HIPAA certificates, member name standards, per-group eligibility rules) are defined in the core screen catalog.

ID	Requirement	Source
ENR-1	The system shall represent every enrolled person as a member record and link members into families; the subscriber is the family row whose subscriber key equals its dependent key.	enroll/d_enroll_member_demographics (subquery on family with sub_member_sys_key = dep_member_sys_key), enroll/d_enroll_member_dependents
ENR-2	The system shall record eligibility as date-bounded periods per member per group/division, keyed by subscriber key, dependent key, group and effective date, with optional expiration date and expiration reason code.	enroll/d_enroll_subscriber_eligibility_period, enroll/d_enroll_dependent_eligibility_period (member_eligibilities)
ENR-3	The system shall reject a new or changed eligibility period whose date range overlaps another period for the same member and key values; open-ended periods conflict with any later period.	enroll/f_verify_dates_outside_range, enroll/w_enrollment_maintenance event ue_validate_new_date_range
ENR-4	The system shall require that a dependent's eligibility dates fall inside some eligibility period of the subscriber (and validate subscriber/dependent effective dates on entry).	enroll/w_enrollment_maintenance wf_check_mem_elig, wf_validate_sub_elig_eff, wf_validate_dep_eff_dt
ENR-5	The system shall not accept an eligibility expiration reason without an expiration date, and shall clear the reason when the expiration date is cleared.	enroll/w_enrollment_maintenance eligibility DW event itemchanged (cases exp_dt, dep_exp_cd; message exp_cd_no_date)
ENR-6	When an eligibility period is expired with a reason, the system shall cascade that expiration date and reason to all elections and member coverages effective on or before that date whose expiration is later or open.	enroll/w_enrollment_maintenance wf_expire_coverage, wf_expire_dep_coverages
ENR-7	The system shall classify a coverage termination as COBRA-qualifying when the coverage type is COBRA-eligible and the expiration reason is in the COBRA reason code set; for COBRA-administered groups, a non-qualifying termination of COBRA-type coverage shall offer generation of a COBRA "Unavailability of Coverage" letter.	enroll/w_enrollment_maintenance wf_check_cobra (coverages.cobra_elig_flg, code key MBREXPCOBR), wf_non_qual_event (code key MBEXPNCOBR, group_enroll_opts.enroll_opt_cd = 'CobraADM', group_coverages.cobra_type_cd <> 'NOCOBRA')
ENR-8	On save, the system shall remove incomplete COBRA event records that correspond to eligibility expirations recorded as non-qualifying events.	enroll/w_enrollment_maintenance event ue_update (delete from cobra_event where status_cd = 'INCOMPLETE')
ENR-9	The system shall compute a waiting-period end date from a start date, a unit and a length. The units are the literal strings none, days (calendar days), months (rolling the year once; a length over 11 is treated as 0), years, and work days (whole 5-day weeks converted to 7 calendar days each, plus the remainder). A null length is treated as 0.	enroll/w_enrollment_maintenance wf_add_elapsed_days. Note: the unit comparison has no default branch, so an unrecognised unit yields no computed date at all — a migration should reject unknown units explicitly.
ENR-10	The system shall store member waiting periods as date-bounded records with a waiting-period start date, maintainable for subscriber and dependents.	enroll/d_enroll_wait_pd, enroll/d_enroll_dependent_wait (member_waiting_periods), enroll/w_enroll_view_wait_period
ENR-11	The system shall generate internal member keys from a database sequence at row creation.	enroll/w_enrollment_maintenance ue_set_new_row (gnv_app.inv_sql.uf_next_member_seq()); enroll/w_quick_enroll_main validates a generated key is present
ENR-12	The system shall default the external member ID according to the group's MEMBER_ID option: NONE (manual), SOC (SSN), SOC+LETTER (SSN plus suffix letter), or SYSKEY (9-digit zero-padded system key plus suffix letter); the subscriber suffix is "A" and dependents are lettered sequentially B through Z, each derived from the prior dependent's suffix rather than from the row number. Under SYSKEY a dependent's id is built from the subscriber's system key, not its own.	enroll/w_enrollment_maintenance ue_set_new_row, member-ID itemchanged case, wf_get_member_suffix (both overloads); option read from group_option_vals via d_enroll_group_option_vals. SOC alone appends no letter; NONE leaves the entered id untouched
ENR-13	The system shall validate member-ID uniqueness within the master group before accepting a defaulted or entered member ID.	enroll/w_enrollment_maintenance (gnv_app.inv_sql.uf_validate_mem_id(ls_memid, is_master_group_id))
ENR-14	The system shall require subscriber SSN (exactly 9 characters), member ID, master group, gender and last name before saving a subscriber; birth date must not be later than the current date.	enroll/w_quick_enroll_main ue_validate; enroll/w_enrollment_maintenance SSN length check and birth_dt itemchanged
ENR-15	The system shall support group-level enrollment options that alter entry behavior, including an SSN option ("SSNo") that is checked per group.	enroll/w_enrollment_maintenance wf_check_ssno_enroll_opt, wf_check_subssnoltr_enroll_opt (group_enroll_opts)
ENR-16	The system shall record benefit elections per subscriber, coverage type, coverage plan and sequence number, with effective/expiration dates, status, expiration reason, COBRA flag, coverage level (tier), benefit amount and beneficiary name.	enroll/d_quick_enroll_sub_cov_elect, enroll/d_enroll_dependent_coverage_elections (elections)
ENR-17	The system shall record which family members are covered by each election as member-coverage rows keyed by the election identifiers plus the covered member, with their own effective/expiration dates, status and QMCSO order reference.	enroll/d_enroll_subscriber_member_coverage, enroll/d_quick_enroll_covg_elect (election_coverages)
ENR-18	The system shall define coverage levels (tiers) in the ELECTLEVEL code table; known values include Single, Family, SpouseOnly, DepsOnly and Emp+Spo+1, with additional extended levels permitted.	enrolrpt/d_coverage_levels (CODES where CODE_KEY = 'ELECTLEVEL')
ENR-19	For salary-based benefit coverages, the system shall compute the benefit amount as the group's default amount plus salary times the group multiplier, rounded to the group's rounding increment using the group's rounding style (nearest, up, down), then clamped to the group's minimum/maximum; the salary comes from the member's SALARY category value.	enroll/w_enrollment_maintenance wf_calc_benefit_amount, wf_round_amount, wf_get_salary_amount (group_coverages)
ENR-20	The system shall validate that a member coverage's effective date is consistent with the member's eligibility and the parent election before acceptance.	enroll/w_enrollment_maintenance wf_valid_eff_mem_covg, wf_check_mem_elig
ENR-21	The system shall standardize member and dependent addresses through the address-standardization service before saving; when standardization fails, the operator shall be asked whether to save the address anyway, and declining aborts the save.	enroll/w_enrollment_maintenance wf_stand_addr, enroll/w_quick_enroll_main wf_stand_addr (invo_mailers.of_standardize_address, of_save_address)
ENR-22	Addresses shall be stored as shared records referenced by number; when a changed address has multiple references, the standardization service is invoked without forcing an update in place.	enroll/w_enrollment_maintenance wf_stand_addr (single_ref / force_update handling), addresses.addr_no usage across DataWindows
ENR-23	Saving enrollment changes shall be atomic: all member, family, eligibility, category, election, coverage, rider, COB and PCP changes commit together or roll back together.	enroll/w_enrollment_maintenance event ue_update; enroll/w_quick_enroll_main event ue_save
ENR-24	After a successful save, when subscriber or coverage information changed for coverages whose group configuration requires ID cards, the system shall ask the operator whether to request new ID cards and submit a request per qualifying coverage.	enroll/w_enrollment_maintenance wf_request_id_cards, wf_check_id_card_print, global f_submit_mem_id_req
ENR-25	After a save that expires or changes a drug election, the system shall prompt for a prescription-plan transfer and open the drug-plan member maintenance function.	enroll/w_enrollment_maintenance wf_expire_coverage (sets drug-processing flag), wf_request_prescription_tsfr
ENR-26	The system shall allow moving a saved eligibility period's elections and coverages from one division to another division of the same parent group; unsaved changes must be saved or the transfer is cancelled.	enroll/w_enrollment_maintenance event ue_move_mem_div, enroll/w_enroll_trans_div
ENR-27	Group-level termination shall expire, as of the entered date and with the entered reason code, all member coverages, elections and eligibilities effective on and not already expired before that date for subscribers of the selected group, and set the member termination date; scope (members / eligibilities / elections / coverages) is operator-selectable.	enrollutils/u_terminate, enrollutils/n_term_enroll of_term_elections / of_term_eligibilities / of_term_members / of_term_coverage, enrollutils/d_term_keys
ENR-28	Group-level re-enrollment shall create follow-on eligibility, election, coverage and category records for members whose most recent eligibility was expired with the specified termination code, after validating the new period against the group's coverage periods and group periods.	enrollutils/w_reenroll, enrollutils/n_term_enroll of_termenroll_* / of_create_*, enrollutils/d_reenroll_elig
ENR-29	The system shall maintain per-dependent student records (student/spouse indicator, school, status code, effective/expiration dates, school address, phone, other-insurance indicator).	enroll/d_enroll_dependent_student_info, enroll/d_quick_enroll_dep_student (students)
ENR-30	The system shall maintain coordination-of-benefits records per member and coverage type (carrier, policy, plan type, status and reason, other-subscriber and employer details with addresses).	enroll/d_qe_cob_detail (coord_of_bens), enroll/w_enrollment_cob_maint
ENR-31	The system shall flag eligibility periods subject to a QMCSO and maintain QMCSO orders with custodian/guardian parties; member coverages may reference a QMCSO order number.	enroll/d_enroll_dependent_eligibility_period (qmcso_flg Y/N), enroll/w_enroll_qmcso_maint, enroll/d_qmcso_custodian_info, election_coverages.qmcso_order_no
ENR-32	The dependent-eligibility audit shall, for groups opted in via the DEPAUDIT group option, generate first and second request letters, track response state in a DEPAUDIT member category value (e.g. No, 2ndLetter), and on the second letter suspend non-responding dependents by expiring their eligibility with reason Suspended and closing their waiting periods.	enrolrpt/w_dep_audit, enrolrpt/d_dep_audit_group_list (group_option_vals option DEPAUDIT)
ENR-33	The system shall restrict master-group selection to groups the signed-on user is authorized for, and resolve divisions through the group parent hierarchy.	enroll/d_enroll_master_group_ids (security joins), hierarchical CONNECT BY prior group_id = parent_group_id queries in enroll/d_enroll_group_option_vals, enroll/w_enroll_group_export
ENR-34	The system shall support export of a master group's eligibility (subscribers and dependents, with relationship, demographics, address, coverage type/level/plan and coverage dates) to a flat file named <group>-<yyyymmdd>, at a configurable path, for members active as of the entered date.	enroll/w_enroll_group_export (cursor cur_recs, enrolldump_path INI setting)
ENR-35	The system shall record HB1 members separately with coverage type, monthly premium and date-bounded periods, and record HB1 payments with received date, paid-through date, check number and amount.	enroll/d_hb1_member_detail (hb1_members), enroll/d_hb1_payment_detail (hb1_payments), enroll/w_hb1_maintenance
ENR-36	Every enrollment change to member, eligibility, election, coverage, category, address, COB, student and waiting-period data shall be viewable per family in an audit log combining current rows with recorded audit events (who, when, insert/update/delete, changed values).	enrolaud/w_enrollment_log, enrolaud/d_audit_trail_enrollment (aud_trail_mbr)
ENR-37	A person may be added to a group only upon receipt of an Enrollment Form verified as completed within 31 days of the person's effective date; otherwise the person is a Special/Late enrollee and may be added only per the group's Plan Document. (Operator procedure — not enforced in code.)	(User Guide ch. 1)
ENR-38	Members shall be enrolled at the client master group level, while coverage may be elected only in groups having no subordinate sub-groups (leaf divisions); group options defined at the master group are inherited by sub-groups unless overridden or declined.	(User Guide ch. 1); consistent with leaf-group logic in idcard/d_group_subs and hierarchy queries (ENR-33)
ENR-39	A coverage election shall not be deleted while member-coverage rows are assigned to it; member coverage rows must be deleted first. (Stated as an operator rule; deletion-order enforcement not found in extracted code.)	(User Guide ch. 1)
ENR-40	When a coverage election is added, the system shall default member-coverage assignment from the coverage type and level together with the family's eligibility periods — e.g. family-level Medical extends to all eligible family members, single-level only to the subscriber, and Life-type coverage always to the subscriber only; the operator reviews assignments before saving.	(User Guide ch. 1); defaulting logic in enroll/w_enrollment_maintenance Coverage tab
ENR-41	When a dependent is added, the system shall default the subscriber's address as the dependent's address; a separate dependent address may then be maintained.	(User Guide ch. 1); enroll/w_quick_enroll_dep_addr, enroll/d_enroll_dependent_address
ENR-42	Member deletion shall be prohibited for any member that has appeared on a bill; a dependent delete removes only that dependent's records, a subscriber delete removes all dependents' records first, deletions follow a fixed child-to-parent order, and the member row and its address are removed only when the member is not also a dependent in another family.	(User Guide ch. 1); homersys/n_delete_member
ENR-43	The HIPAA certificate queue shall be populated automatically (database trigger) when a member loses Medical coverage, excluding termination reasons Re-Enrollment, Deceased Dependent, Deceased Subscriber (only when single), Client Termination and Transferred Division; reinstatement of coverage or a change of termination reason shall add/remove queue rows accordingly.	(User Guide ch. 1); queue table hipaa_transactions (trigger not in PowerBuilder source)
ENR-44	HIPAA certificates shall be produced one per family (members sharing a subscriber key), addressed to the employee — or the first eligible dependent when the subscriber is deceased — with a copy to any dependent having a separate address; the certificate date is the print date; group number + member id substitute for the subscriber SSN; reprints and member-requested snapshot certificates are supported, limited to groups with the HIPAA option.	(User Guide ch. 1); enroll/w_enroll_hipaa_generate, w_enroll_hipaa_print, w_enroll_hipaa_add_members
ENR-45	Member life status shall be one of: Active; Deceased; System (not a real member); PCS Bulk Payee.	(User Guide ch. 1); life_status on enroll/d_enroll_member_demographics

Data

Core tables and how the enrollment libraries touch them (CRUD derived from _re/analysis/schema.json):

Table	Role	enroll	enrollutils	enrolaud	enrolrpt
members	One row per person (subscriber or dependent): names, SSN, member_id, master_group_id, birth/hire dates, gender, life status, mbr_term_dt, addr_no	CRUD	RU	CRUD*	CRUD*
family	Links subscriber to family members (sub_member_sys_key, dep_member_sys_key); subscriber row has sub = dep	CRUD	R	CRUD*	R
member_eligibilities	Date-bounded eligibility per member per group/division (eff_dt, exp_dt, dep_exp_cd, qmcso_flg, cobra_rights_sent_dt)	CRUD	CRUD	R	RU
elections	Benefit election per subscriber + coverage type + plan + sequence (dates, status, level/tier, COBRA flag, benefit amount, beneficiary)	CRUD	CRUD	R	R
election_coverages	Covered members per election (dep_member_sys_key, member_elect_eff_dt/exp_dt/status/exp_cd, qmcso_order_no)	CRUD	CRUD	R	R
addresses	Shared, reference-counted addresses (addr_no, std_addr_flg)	CRUD	—	R	R
member_waiting_periods	Waiting-period spans per member	CRUD	—	R	—
member_cat_val	Member category values (SALARY, RELATIONS, DEPAUDIT, …)	CRUD	—	R	CRU
students	Dependent student records	CUD	—	R	—
coord_of_bens	Coordination of benefits	CRUD	—	R	R
aud_trail_mbr	Enrollment audit events	—	—	R	—
hipaa_transactions	HIPAA certificate work queue	CRUD	—	—	—
hb1_members / hb1_payments	HB1 enrollment and premium payments	CRUD	—	—	R (payments)

Subscriber vs dependent pattern. Everywhere in this domain, sub_member_sys_key identifies the subscriber and dep_member_sys_key the person the row is about; the subscriber's own rows have sub_member_sys_key = dep_member_sys_key (subscriber eligibility filter in enroll/d_enroll_subscriber_eligibility_period; dependent filter sub <> dep in enroll/d_quick_enroll_dep; enrollutils/d_term_keys). elections hang off the subscriber only; election_coverages fan out to each covered member.

member_accums. The accumulator table shares the same sub/dep key pattern (member_accums.sub_member_sys_key / dep_member_sys_key, from_dt/thru_dt) but per schema.json used_by it is read/written only by claims libraries (claims, clmsproc, clmutils, clmrpt, homersys) — no enrollment library touches it. Migration must nevertheless preserve key compatibility, since accumulators are joined to members enrolled here. See Open questions.

Enrollment audit subsystem (enrolaud)

enrolaud/w_enrollment_log ("Enrollment Audit Log") shows change history for one family:

• Operator finds a member by last name (w_member_select_by_last_name) or SSN (w_homer_social_search); the window resolves the subscriber via family and gathers all dependent keys (event ue_retrieve).
• The audit source is table aud_trail_mbr with columns dep_member_sys_key, sub_member_sys_key, audit_dt, tbl_name, tbl_key (a tilde-delimited snapshot of key/values, up to 500 chars), audit_activity (3-char action), audit_user_id, chg_desc and chg_comment (2000 chars each) (enrolaud/d_audit_trail_enrollment).
• Per-table tabs (members, member_eligibilities, elections, election_coverages, member_cat_val, addresses, coord_of_bens, students, member_waiting_periods) merge two sources: the current base-table rows, rendered as an "Insert … by create_user_id on create_dt" baseline (each d_audit_trail_* DataWindow selects from the live table with literal action 'Insert'), plus decoded audit rows, which the window parses out of tbl_name/tbl_key with wf_get_token (tilde-delimited) and date-format conversion wf_cvt_string_date, then appends via the wf_set_* functions.
• A "deleted" checkbox (cbx_deleted) toggles inclusion of deleted-record events.
• Each tab renders a sentence per event: "On <date> user <id> <action>d this record" (compute in enrolaud/d_audit_trail_members).

The writer of aud_trail_mbr is not in these four libraries (no INSERT into it found here); it is presumed populated by database triggers or shared services. Flagged in Open questions.

PBM / carrier eligibility feeds

Searched all four libraries for mmo_enrollment_work, ppo_enrollment_work, sp_aetna_enrollment, and "aetna"/"melissa": none are referenced from these libraries. What these libraries do evidence:

• MMO audit report (enrolrpt/w_mmo_audit, enrolrpt/d_mmo_audit) — an audit/export of repriced claims for MMO-affiliated groups: it derives the MMO group and section numbers per master group from database function SFPIDBA.F_GET_GROUP_MMO_INFO(master_group_id, 'MMOBASEGRP'|'MMOSECTION'), restricted to claims whose claim_id starts EMMO, and sums REPRICE_DISCOUNT_AMT as "MMO Pricing"; the window offers Retrieve and Export over a date range.
• Flat-file eligibility export (enroll/w_enroll_group_export) — the generic outbound eligibility feed described under ENR-34.
• Drug-plan transfer hand-off (enroll/w_enrollment_maintenance wf_request_prescription_tsfr) — opens the drug-plan module's member maintenance for PBM-side changes; the PBM file production itself lives outside these libraries (drugplan library).

Any mmo_enrollment_work / ppo_enrollment_work / sp_aetna_enrollment processing must live in another library or in the database — see Open questions.

Reports (enrolrpt catalog)

Purpose	Windows / DataWindows
Annual employee statements — per-group benefit statement with coverages, dependents, beneficiary; group-level options control salary, partner, all-coverage inclusion, custom instructions; receipt is recorded per member by date	w_annlstmt, w_annlstmt_option_maintenance (annual_statement_options), w_annlstmt_report_date ("Receive Annual Statements"), d_annlstmt_*
Census reports — parameterized member listings selected from the batch_reports table (report_type = 'census'); variants by name, birth date, city/state, state, zip, eligibility period, hire date, coverage-with-dependents, PCP, life/AD&D, flex, sales summary	w_census_rpt_args_sheet, w_census_rpt_display, dddw_rpt_select, d_census_*
Medicare-age censuses — members with Medicare COB, and members over age 65 (age computed from birth date as of a report date, with coverage level/plan)	d_census_medicare_with_cob, d_census_over_65
Dependents over age — dependents older than a threshold as of a date, with subscriber info	w_enrollrpt_deps_over_age, d_enrollrpt_deps_age
Enrollment error reports — members with elections but no member coverages ("members without coverages") and single members enrolled in multi-person coverage levels	w_enrollrpt_error_rpts, d_enrollrpt_nocov, d_enrollrpt_single_in_multi
Dependent eligibility audit — first letter, second letter, final report and reprints for DEPAUDIT groups (see ENR-32); final report exportable to text	w_dep_audit, d_dep_audit_*
MMO audit — see feeds section	w_mmo_audit, d_mmo_audit
HB1 member/payment report	w_hb1_report, d_rpt_hb1_payment
HIPAA notes report (in enroll) — HIPAA-related notes by member/group/all	enroll/w_notes_hipaa_report_view, d_notes_hipaa_report_*
FSA notices & dependent-care tax statements (in enrollutils) — flexible spending account notices, summary listings, and end-of-year dependent-care tax reports by filing period	enrollutils/w_fsa_notices, w_fsa_depcare_tax_statements, d_fsa_*

Migration notes

• Effective-dating is the backbone. Nearly every entity (member_eligibilities, elections, election_coverages, member_waiting_periods, students, member_cat_val, group config) is a date-bounded span with null = open-ended. The overlap rule (ENR-3) and the containment rules (ENR-4, ENR-20) are enforced client-side only (PowerScript loops over DataWindow rows, e.g. f_verify_dates_outside_range); a migrated system should enforce them server-side.
• Cascades are client-side too. Expiration cascade (ENR-6), COBRA event generation (ENR-7/8), ID-card requests (ENR-24) and drug transfer (ENR-25) all run in window code after user prompts; batch termination (ENR-27) builds dynamic SQL strings with 1000-key IN-lists and commits per batch (enrollutils/n_term_enroll) — no single transaction, and interrupted runs can leave partial terminations.
• Member ID scheme is group-configurable (ENR-12). The dependent suffix table runs B–Z only, and wf_get_member_suffix has no default branch: a 26th dependent silently receives no suffix letter, producing a member id that collides with the subscriber's system-key root rather than an error. Treat this as a latent duplicate-ID defect to fix, not to reproduce (enroll/w_enrollment_maintenance wf_get_member_suffix). SSNs are stored raw as char(9) and widely used as identifiers (exports, annual statement matching by SSN in enrolrpt/w_annlstmt_member_select) — a privacy/redesign concern.
• Shared address book with reference counting via the Mailers service (ENR-21/22). The standardization vendor call is a COM/DLL-style non-visual object (invo_mailers); equivalent functionality (CASS-style standardization with user override) must be provided.
• Audit trail duplication: aud_trail_mbr stores tilde-delimited snapshots parsed by UI string code, with two date formats in the wild (wf_cvt_string_date handles both). Migrate to structured audit rows; the log view expects per-table before/after visibility including deletes.
• Hard-coded literals to externalize: code keys ELECTLEVEL, MBREXPCOBR, MBEXPNCOBR; category codes SALARY, RELATIONS, DEPAUDIT; group options MEMBER_ID, DEPAUDIT, CobraADM, SSNo; sentinel dates 12/31/2049, 12/31/2050, 01/01/1900 used as "open" markers in SQL.
• Oracle-specific SQL throughout (CONNECT BY group hierarchies, outer-join (+), DECODE, SYSDATE, TO_DATE); dynamic SQL via EXECUTE IMMEDIATE in termination; rownum used for grouping in audit DataWindows.
• Legacy/dead code: w_quick_enroll_cob is marked "** OLD **"; w_enrollment_cob_maint and d_qe_cob_detail are commented "NOT REGISTERED"; large commented blocks exist in save paths. Confirm scope before porting.

Open questions

1. Who writes aud_trail_mbr? No inserts exist in these libraries; presumed database triggers or a shared service. The trigger set and the exact tbl_key/chg_desc encodings must be recovered from the database before the audit log can be re-implemented.
2. Where do mmo_enrollment_work, ppo_enrollment_work and sp_aetna_enrollment run? Not referenced in enroll/enrollutils/enrolaud/enrolrpt. Locate the owning library or database jobs; only the MMO claims-audit report and the generic eligibility export exist here.
3. member_accums interplay — accumulators are claims-owned; is any enrollment action (termination, re-enrollment, division transfer) expected to reset or carry over accumulators? No such code exists in these libraries.
4. Retroactivity policy — the code validates overlaps and containment but nowhere restricts how far back an effective/expiration date may be set; retro changes silently cascade (ENR-6) with no billing-adjustment hook visible in these libraries. Confirm intended retroactivity limits and downstream billing behavior.
5. uf_validate_mem_id / uf_next_member_seq semantics live in a shared non-visual object (gnv_app.inv_sql, outside these libraries); exact uniqueness scope and sequence source need confirmation from homersys/system libraries.
6. Medicare handling — resolved (User Guide ch. 1): Medicare status is tracked through COB records — plan types Medicare and InternMed (Internal Medicare) and status reason Medicare — not through a member-level Medicare field; census reporting (d_census_medicare_with_cob, d_census_over_65) reads those COB records. Medicare Secondary Payer reporting to CMS is handled by the separate Section 111 file windows (TIN Reference File / MSP Input File / CMS Response File). Remaining sub-question: which library hosts the Section 111 windows (see item 11).
7. HB1 meaning — hb1_members/hb1_payments model premium-paying members ("HB1 Member Maintenance", monthly_premium, paid_thru_dt) but the business meaning of "HB1" is not stated in code or comments.
8. Mailers service contract — resolved (User Guide ch. 1): the vendor product is Mailers+4 (Melissa Data's CASS address-standardization package); the guide also documents the user-facing behavior (operator prompt on standardization failure, light-yellow highlight for non-standardized addresses, shared-address update prompt, no PO Box + street combinations). The exact DLL version and the str_mailers_address field contract still need confirmation against the deployed installation.
9. w_enroll_cobra_dependent_address_sync exists (response window over d_enroll_cobra_dependent_address_sync) suggesting COBRA dependent addresses can be synchronized with subscriber addresses; the triggering conditions were not fully traced.
10. Dead/disabled code — subscriber-address saves are commented out inside ue_update (address saved via the Mailers path instead); confirm the authoritative address save path before migration.
11. CMS Section 111 windows — the user guide (ch. 1) documents TIN Reference File, MSP Input File and CMS Response File windows with a backup/test/apply operating procedure, but none of these windows exist in enroll/enrollutils/enrolaud/enrolrpt. Locate the owning library (and the SECTION_111_MSP_INPUT table) before migration.
12. Employment history vs single hire/term date — the guide's "Enhancements from WANG" list states that effective and termination dates "will be retained for employees who are terminated and rehired any number of times" via the eligibility tab, yet members carries only single hire_dt/mbr_term_dt columns; confirm that rehire history is represented solely as multiple eligibility periods.