Screen catalog — core enrollment screens

All objects in library enroll unless noted. Open modes referenced below (add / change / remove / detail) control field editability via w_enrollment_maintenance.wf_dw_edit_status.

w_group_member_select — "HOMER - Member Select"

• Purpose: "First screen for member enrollment. Allows a user to Add/Delete/Modify/View a member" (object comment). Presents a group/member treeview (tv_group_ids, tv_members) plus Search/Clear buttons; drills into a subscriber's family (d_enroll_dependents_for_subscriber).
• Actions: search by master group (w_master_group_select), by last name (w_member_select_by_last_name, w_member_select_by_last_name_no_group), or member ID (w_member_select_by_mbr_id); opens w_enrollment_maintenance via OpenSheetWithParm with the selected member and mode; can switch to the alternate search screen w_enroll_member_selection.
• Official operation (User Guide ch. 1): custom toolbar icons Edit Member (opens maintenance in edit mode, shown only to users with update authority) and View Member (view mode, shown only with view authority); By ID / By Name re-sort the group tree; an Include Expired Groups checkbox adds expired groups to the tree. Search-result routing: a single match opens maintenance directly (Eligibility tab for a subscriber, Dependents tab for a dependent); multiple name matches open the Select Member window, multiple SSN matches open the Member Search window (which can re-search by SSN or by eligibility date with a group filter); a member-id search with a group id searches that group first and falls back to all groups; a 9-character member id gets an assumed tenth character A. A member who is both a subscriber in one plan and a dependent on another is disambiguated with a view-selection prompt. Operators are told to use the Clear button before entering new criteria — an SSN + group search fails when the member is not in that group.
• Variant: w_group_hb1_member_select ("HOMER - HB1 Member Select") is the same first screen for HB1 members, opening w_hb1_maintenance instead.

w_enrollment_maintenance — "HOMER - Member Enrollment Maintenance"

• Purpose: "Window used to enroll members" (object comment); the full-function maintenance sheet for one subscriber family.
• Field groups (tab structure):
  • Subscriber Eligibility: demographics (d_enroll_member_demographics: master group, member ID, hire date, life status, gender, birth date, names, SSN, termination date, external member ID, phone), address (d_enroll_address), phone (d_enroll_member_phone), eligibility periods (d_enroll_subscriber_eligibility_period), subscriber categories (d_enroll_member_subscriber_categories), waiting periods (d_enroll_wait_pd; "All Wait Periods" button opens w_enroll_view_wait_period).
  • Dependents: dependent list (d_enroll_member_dependents), per-dependent sub-tabs for eligibility (d_enroll_dependent_eligibility_period) and categories (d_enroll_member_dependent_categories), address (d_enroll_dependent_address), student info (d_enroll_dependent_student_info), dependent waiting periods (d_enroll_dependent_wait).
  • Coverage: coverage elections (d_enroll_dependent_coverage_elections), member coverages (d_enroll_subscriber_member_coverage), riders (d_enroll_subscriber_coverage_riders), read-only eligibility reference (d_enroll_sub_elig_pd_display).
  • Physician / PCP: PCP assignment via n_enroll_member_pcp (search popup w_enroll_pcp_search over d_enroll_pcp_prov_criteria / d_enroll_pcp_search). The guide (written earlier) describes this tab as "planned as a future enhancement as Medillume III clients come on board", appearing only for HMO groups that require PCP selection, with one PCP selectable per member (a person may select more than one over time) (User Guide ch. 1) — the extracted code implements it.
• Meaningful validations:
  • Eligibility date ranges must not overlap for the same member/group (event ue_validate_new_date_range using f_verify_dates_outside_range); dependent dates must fall inside a subscriber period (wf_check_mem_elig, wf_validate_dep_eff_dt).
  • Expiration reason (dep_exp_cd) requires an expiration date (message exp_cd_no_date); clearing the date clears the reason and retracts pending COBRA non-qual events (eligibility DW itemchanged).
  • Subscriber SSN must be exactly 9 characters; birth date cannot be after today (itemchanged cases soc_sec_no, birth_dt).
  • Member ID defaulting per group option MEMBER_ID (NONE / SOC / SOC+LETTER / SYSKEY), subscriber suffix "A", dependents lettered B–Z (ue_set_new_row, wf_get_member_suffix; a 26th dependent gets no letter — see the ENR-12 migration note); uniqueness checked via uf_validate_mem_id.
  • Addresses standardized through the Mailers service with an override prompt (wf_stand_addr).
• Code-table enumerations: qmcso_flg Y/N (d_enroll_dependent_eligibility_period values list); coverage tiers from code key ELECTLEVEL; COBRA reason sets MBREXPCOBR / MBEXPNCOBR; group categories from dddw_group_categories. Life status drop-down values: Active; Deceased; System (Not real member); PCS Bulk Payee (User Guide ch. 1).
• Field semantics from the guide (User Guide ch. 1):
  • HIPAA Period Info (the waiting-period panel, d_enroll_wait_pd): Start Date is the subscriber's hire date used as the waiting-period start; Eff Date is the date the member elected Medical coverage; Exp Date is the termination date; multiple period sets are ordered by descending date. Periods must include time in SFPI/M3 plans and may include time on prior, non-administered plans.
  • Subscriber identification data shown at the top of the sheet is protected on the Dependents and Coverage tabs; it may only be changed on the Eligibility tab.
  • Eligibility periods: members of "Flex" groups will always have many eligibility periods (annual re-enrollment); rows are added/deleted via right-mouse menus.
  • Coverage tab: operators must not delete a Coverage Election while Member Coverage rows are assigned — member coverage must be deleted first; the system defaults member-coverage assignment from Coverage Type and Level (family-level extends to all eligible family members, single-level to the subscriber, Life always subscriber-only) and operators review before saving. The Additional Information pane (riders) "may be expanded later".
  • Student sub-tab: records student and spouse-employment data so other departments can research COB; its Other Insurance checkbox signals that COB needs research — it is explicitly not the COB data claims process against. Enrollment enters it initially; examiners maintain it during claims processing.
  • The Move Eligibility toolbar icon (division transfer) is restricted — "most users will not have access".
  • The guide instructs that COB records with incomplete information be entered with status "unknown".
• Actions: Save (transactional ue_update across all stores, then ID-card prompt wf_request_id_cards and drug transfer prompt wf_request_prescription_tsfr); expire eligibility with cascade (wf_expire_coverage / wf_expire_dep_coverages); move eligibility to another division (ue_move_mem_div → w_enroll_trans_div); request ID cards (ue_request_id_cards); show notes; open COB (ue_opencobwindow).
• Windows opened: w_enroll_member_select, w_enroll_trans_div, w_enroll_view_wait_period, w_member_select, w_subscriber_select.

w_quick_enroll_main — "Homer - Quick Enrollment"

• Purpose: single-screen intake of a new subscriber family (object comment: "Contains new COB Fuct.").
• Field groups: subscriber demographics (d_quick_enroll_subscriber), subscriber eligibility period (d_quick_enroll_sub_eligible_pd), waiting period (d_quick_enroll_sub_wait_pd), dependents grid (d_quick_enroll_dep + d_quick_enroll_dep_elig_pd), categories (d_enroll_category, d_quick_enroll_all_cat with valid-period compute), coverage elections (d_quick_enroll_sub_cov_elect) and member coverages (d_quick_enroll_covg_elect), family summary (d_quick_enroll_family), group panel (d_quick_enroll_group).
• Meaningful validations: required subscriber SSN, member ID, master group ID, gender, last name, and generated member key (ue_validate on the subscriber DW); waiting-period rows require expiration of the prior open period before adding another (dw_sub_wait ue_validate); member id letter toggling per group option (wf_toggle_mem_id_letter).
• Official member-category vocabulary (User Guide ch. 1): subscriber categories observed on the Quick Enrollment Subscriber tab include COVROVRRD, FLEX, LAST CHECK (date member information was last checked), OCCUPATION, PSEUDO SS# (a WANG-era requirement, to be retired), SALARY, SPOPREVEMP (spouse's previous employer) and SPOUSE EMP (spouse's current employer); dependent categories include PRIMARY and RELATIONS (relationship to subscriber). Categories are defined in the Codes table and tied to groups in Client Maintenance; the screen shows only categories tied to the member's group, and the subscriber's effective date defaults as the category effective date. (The guide itself flags COVROVRRD, FLEX and PRIMARY as needing SME explanation.)
• Enumerations: cobra_flg Y/N on elections (d_quick_enroll_sub_cov_elect).
• Actions: Save (ordered store updates in ue_save: subscriber → dependents → family → eligibilities → categories → dependent categories → students → COB, with per-store error codes); Cancel/reset (wf_reset_screen); request ID cards (wf_request_id_cards); prescription transfer (wf_request_prescription_tsfr); address standardization (wf_stand_addr).
• Windows opened: w_enrollment_cob_maint, w_quick_enroll_dep_addr, w_quick_enroll_dep_cat, w_quick_enroll_dep_student.

w_enrollment_cob_maint — "Coordination of Benefits"

• Purpose: maintain coord_of_bens rows per member and coverage type (marked "NOT REGISTERED" in comment; opened from quick enrollment and enrollment maintenance).
• Fields (d_qe_cob_detail): effective/expiration dates, carrier, policy number, plan phone/type, status and status reason, other subscriber name/phone, employer name/phone, and address numbers for plan, other subscriber and employer (d_cob_address).

Termination-letter and HIPAA screens

• w_enroll_custom_term_add_members — queue family members into custom_term_transactions (comment: "window to add members to the custom term transaction table"; uses shared d_family_members).
• w_enroll_custom_term_generate — generates termination letters from the queue into report_hist (blob report_data, report_hist_seq sequence) using letter forms d_custom_term_form / d_usfhp_term_form with subscriber/dependent/eligibility panels.
• w_enroll_custom_term_print — "Termination Letters Print Maintenance": select and print/reprint generated letters (d_custom_term_maintenance).
• w_enroll_hipaa_add_members — queue members into hipaa_transactions (insert with lock_cd).
• w_enroll_hipaa_generate — "Generate HIPAA Form": builds certificates for queued members (subscriber/dependent/eligibility panels d_enroll_hipaa_*), stores them in report_hist, marks queue rows lock_cd = 'PROCESSED' and deletes handled entries; can look up coverage via w_enroll_hipaa_member_coverage_search.
• w_enroll_hipaa_print — "HIPAA Print Maintenance": print/reprint stored certificates (d_hipaa_maintenance).
• w_hipaa_cert_report — runs/prints the HIPAA certificate report (d_hipaa_cert_report).
• w_hipaa_dead_file — "window for logging undeliverable HIPAA certificates"; history from notes keyed HIPAA Cert / HIPAA Dead File (d_hipaa_history).
• w_notes_hipaa_report_view — HIPAA notes report by member / group / all (d_notes_hipaa_report_*, search object u_notes_hipaa_report_search).

HIPAA menu

The frame menu homersys/m_sys_frame carries an Enrollment → HIPAA submenu of eight options. The guide describes only the first four — "There will be four options off the menu for managing HIPAA" (User Guide ch. 1) — so the last four are later additions; one of the four originals was never built:

Menu text (code)	Opens	Guide's name and intent (User Guide ch. 1)
Generate HIPAA Certificates	w_enroll_hipaa_generate	Generate HIPAA Certificates — one single-page certificate per family (members sharing a sub_member_sys_key), citing only that family's members present in the HIPAA table; output spooled to the print queue like claim form letters, queue rows marked processed as they go. On completion the user is asked whether the certificates processed successfully: yes deletes the processed rows (processed_ind = 'Y'), no clears processed_ind and returns to the menu. Mailed in window envelopes, so mailing-address alignment matters.
Print HIPAA Certificates	w_enroll_hipaa_print	Print HIPAA Certificates — select and print stored certificates. Kept a separate menu option deliberately so it could later move to the system's general print menu if printing moved to another department. This process must also create the member notes described below.
HIPAA Certificate Reprint	w_enroll_hipaa_add_members	Add members to HIPAA Certificate Table — manual queueing so a certificate can be produced, typically when the original mailing was not received. Interface uses the normal member search; after one member is selected the user is shown all members of that family and picks which to write to the HIPAA table. The guide saw no need for a remove option (staff simply pull the printed certificate and do not mail it). The code's menu label has since been reworded to "HIPAA Certificate Reprint" while still opening the add-members window.
Produce Free Form HIPAA Certificate	homersys/w_construct — titled "Under Development"	Produce Free Form HIPAA Certificates — a way to fill in spaces on a blank certificate by hand and route it to the print queue, like claim form letters. Flagged in the guide as lower priority. Never implemented: the menu item opens the application's placeholder window.
HIPAA Certificate Report	w_hipaa_cert_report	Not in the guide's four.
HIPAA Dead File	w_hipaa_dead_file	Not in the guide's four; supports the "HIPAA Dead File" note below.
HIPAA Mailing Labels	w_hipaa_printlabel_select	Not in the guide's four.
HIPAA Member Notes Report	w_notes_hipaa_report_view	Not in the guide's four; reports the note keys below.

Member note keys (User Guide ch. 1) — deliberately kept consistent and identifiable so the data could later be loaded into the membership tables and windows:

• HIPAA — general HIPAA notes, not system generated; this data was explicitly not to be loaded into enrollment later.
• HIPAA Cert — generated by the Print HIPAA Certificates option; must contain the date the certificate was printed in mm/dd/yyyy form plus text saying what the date represents.
• HIPAA Dead File — user generated when HIPAA letters cannot be delivered; same format as HIPAA Cert (date then text).

w_hipaa_dead_file reads its history from exactly these keys (d_hipaa_history over HIPAA Cert / HIPAA Dead File), confirming the convention survived.

HIPAA certificate letter template

The certificate softcopy originated as a Word document (hipaalet.doc on a staff share); the rendered form in the extract is d_hipaa_form (the print form behind w_enroll_hipaa_generate). The guide specifies the required merge fields (User Guide ch. 1):

Field	Rule
SendName	Name of the subscriber — printed even if the subscriber is not in the HIPAA certification table; if the subscriber is deceased, the first eligible dependent's name is used instead
SendAddr1 / SendAddr2 / SendCity / SendState / SendZip	Subscriber's address, likewise printed even when the subscriber is not in the HIPAA table
Date	Date the letter was printed
Plan name	Company name stored at the division level of the groups table
Subscriber name	As above — always printed
Identifier	Client number / division / subscriber SSN, e.g. 501-111A123456789
Dependents	First name and middle initial of every dependent of the subscriber found in the HIPAA table, separated by semicolons
Plan contact	Name, address and telephone number of the subscriber's master group
Fixed phone	Always print (216) 575-5366
Waiting-period start	Printed only for members in the HIPAA transfer table: subscriber first name with either hire date or earliest continuous HIPAA start date, then each dependent's first name with either earliest continuous HIPAA start date or earliest continuous coverage effective date. Derivation: find the earliest continuous coverage effective date, then check whether an overlapping HIPAA period reaches further back. Print not available if no date. Subscriber and dependent HIPAA start dates need not match.
Coverage began	First name and earliest continuous medical coverage effective date for each family member in the HIPAA table, subscriber first then dependents; not available if none
Coverage ended	First name and latest medical coverage expiration date per member, subscriber first; print Continuing when the date is 00/00/0000; deceased members (especially a deceased subscriber) must not be printed here

Two lines of the original document were retired: line 8 was dropped and line 9 reworded (User Guide ch. 1).

Open item carried from the guide. The guide records an unfinished delete step: rows must be removed from hipaa_transactions when the member's group does not hold the HIPAACert enrollment option for the period being printed, joining hipaa_transactions → members_eligibilities (via sub_member_sys_key / dep_member_sys_key) to obtain the group, then group_enroll_opts to check enroll_opt_cd. Marked "THIS STILL NEEDS TO BE DONE" (User Guide ch. 1); confirm with an SME whether it was ever completed, since eligibility for HIPAA certificate production is otherwise gated only by the client-maintenance HIPAA option switch.

QMCSO screens

Menu path: a single option, Enrollment → Support Orders (m_supportorders in homersys/m_sys_frame), opens w_enroll_qmcso_select. m_enroll_qmcso ("Menu Object for QMCSO") is the sheet-level frame menu used by the QMCSO windows: it inherits m_sys_frame and only re-configures the toolbar — Close and Find made visible, Edit enabled, the Clear item repurposed as toolbar icon Custom094! firing ue_clear, and Undo/Cut/Copy/Paste/Select All/Replace/Add/Delete hidden. It carries no QMCSO-specific menu options.

• w_enroll_qmcso_select — "Selection Window for QMCSO": pick members whose eligibility carries qmcso_flg (d_enroll_qmcso_select over member_eligibilities + members). Guide: criteria are group and/or dependent id (blank criteria list every accessible dependent); the QMCSO column renders green-with-check when QMCSO information exists, red when none; double-click opens maintenance (User Guide ch. 1).
• w_enroll_qmcso_maint — "Main QMCSO Entry Window": order details (d_qmcso_maint_select_info) and custodian info (d_qmcso_custodian_info over vendor_addresses/pm_addresses/vendors); opens w_provider_vendor_select to pick the custodian vendor. CRUD on qmcso_custodians / qmcso_guardians. Guide: the window records the dependent's legal guardian name and the address where all QMCSO correspondence is sent (standardized via Mailers+4); saving sets the dependent's QMCSO flag and Delete unsets it; this address is intentionally not shown on the enrollment Dependent Address sub-tab — a separate dependent mailing address must be entered there if needed (User Guide ch. 1).
• w_qmcso_member_detail — titled "QMCSO Time Periods"; a per-dependent sheet opened with a str_member parameter (dependent key, subscriber key, effective date) listing each QMCSO custodian period for that dependent — custodian (vendor) name, custodian system key, effective and expiration dates and the custodian's address lines/city/state/zip from pm_addresses (d_enroll_qmcso_select_detail). Supports pfc_addrow to add a period.

QMCSO business context (User Guide ch. 1)

Purpose and scope: courts may issue a Medical Child Support Order (MCSO) against a subscriber; orders apply to dependents who are the subscriber's children. Dependents under a QMCSO may have a separate mailing address held in the system, which is what the QMCSO switch indicates. An order may be determined not qualified, in which case the Claims department will not process claims for those children — the guide records that every medical child support order processed up to that point had been declined as not qualified. Users may enter QMCSO information only for members already enrolled; every child cited in the order must already exist as a dependent, so missing children must be enrolled first "as best as possible" (User Guide ch. 1).

QMCSO correspondence statuses (User Guide ch. 1) — a member may carry any one of:

Status	Meaning
Order Received	Order received, enrollment checked, no forms sent
Waiting for Determination	Order received, waiting for the internal SFPI determination
Notice Sent	Notice sent to child, employee, and attorney (if required)
Waiting for Administrator	Notice sent to child, employee and employer; awaiting return of the "notice of plan administrator's determination with respect to medical child support order"
Accepted	Plan administrator has declared the order qualified
Declined	Plan administrator has declared the order not qualified

Discrepancy for SME confirmation. No QMCSO status column exists anywhere in the extracted client code: qmcso_custodians carries only sub_member_sys_key, dep_member_sys_key, custodian_sys_key, vendor_sys_key, eff_dt, exp_dt and the ee_custodial_guardian flag (d_qmcso_maint_select_info, d_qmcso_custodian_info), and member_eligibilities.qmcso_flg is a plain Y/N switch. Confirm with an SME whether the six statuses were tracked outside HOMER, or were never built (see ENR-49).

Internal handling procedure (User Guide ch. 1) — the guide prescribes an Enrollment-department procedure, not system-enforced behaviour:

1. Enrollment receives the MCSO, logs the order and enters the data with status Order received.
2. Enrollment verifies every listed child is enrolled; missing children are enrolled as best as possible with the status set for QMCSO.
3. Enrollment enters the new address and sets the QMCSO switch for that address.
4. Simultaneously, a notice of receipt goes to the employee ("notice to employee regarding medical child support order" plus the plan procedures in "qualified medical support orders") and to each affected child ("notice to child regarding medical support order", "form to designate a representative of the child", plus the plan procedures) — copied to the attorney, with all three pages, if the order was submitted by an attorney.
5. Enrollment notifies Claims via a VIP note to hold claims for the children, retroactive to the order's effective date, until qualified status is determined.
6. Enrollment reviews the order against a checklist for a tentative determination and verifies a signed OBRA amendment containing the standard QMCSO language exists.
7. If all is in place, the employer receives the tentative-decision notice plus the proposed determination form for the plan administrator to sign.
8. Enrollment awaits sign-off, calling the employer if no response arrives ten days after the letters were sent, and resolves any disagreement with the employer.
9. The employee and each child (or each child's designated representative) are notified of the decision — "important notice", the determination notice, and, when qualified, the "alternate recipient claim submission slip"; copied in full to the attorney where applicable. The wording of the determination notice differs depending on whether the order is qualified.
10. Claims is notified to begin processing as of the order's effective date when qualified, or of the declination when not.

Custodian / guardian address handling. In code the correspondence party is a vendor: w_enroll_qmcso_maint searches vendors by name and/or TIN filtered to vendor status "QMCSO" within the signed-on client segment (iu_sql.of_count_vendors / of_get_vendor, with w_provider_vendor_select when several match), and the address shown is the vendor's address joined through vendor_addresses / pm_addresses — read-only country/USA and postal-code handling comes from the shared address model, and a vendor must be selected before the row can be saved ("You need to select a vendor"). The guide (ch. 1) instead describes typing the legal guardian's first/middle/last name and a free-entry address (line 1 = suite/apartment/PO box, line 2 = street, city, state drop-down, zip, a USA checkbox that swaps state+zip for a free-form Postal Code line) directly on the maintenance window, standardized through Mailers+4 with a light-yellow background on non-standardized addresses and the shared-address "just this member or everyone?" prompt — discrepancy for SME confirmation. A matching guardian-name DataWindow does exist but is orphaned: d_enroll_qmcso_entry (first/middle/last name plus addr_no over qmcso_guardians) is referenced by no window in the extract.

Both sources agree that saving QMCSO information sets the dependent's QMCSO flag and that Delete clears the information and unsets the flag, and that this correspondence address is deliberately not surfaced on the enrollment Dependent Address sub-tab — a dependent needing its own mailing address must have one entered there separately (User Guide ch. 1).

QMCSO form letters — not built. The guide states plainly that "the system does not currently support automatic generation of QMCSO form letters" and records the intended design: letters are categorized as initial letters and 2nd requests, several per category; the system should normally produce all letters associated with the member's current status while letting users customize them; and requests must not print immediately — the request writes a row to a request table and letters print during the nightly production cycle (User Guide ch. 1). The letter set specified is:

Letter	Stock	Data required
Notice to plan administrator of tentative decision on medical child support order	SFPI letterhead	Employee, Employer, Account (group no.), Plan, Date of Order, Children switch (more than one child, alters text), Child Name(s), Date, Dear (title + last name)
Notice of plan administrator's determination — not a QMCSO	SFPI letterhead	Employee, Account, Plan, Children switch, Child Name(s), Employer, Date, Reason 1-4, Comments
Notice of plan administrator's determination — is a QMCSO	SFPI letterhead	Employee, Account, Plan, Children switch, Child Name(s), Employer, Date
Notice to child regarding medical child support order	SFPI letterhead	Month, Date of Order, Plan, Account, Children switch, Child Name(s), Dear, Enclosures, CC
Notice to employee regarding medical child support order	SFPI letterhead	Month, Date of Order, Plan, Account, Children switch, Child Name(s), Dear, Enclosures
Form to designate a representative of the child	Blank paper	Employee, SSN, Employer, Account, Plan, Children switch, Child Name(s), Date
Alternate recipient claim submission slip	SFPI letterhead	Paid by (child the claim is filed for)

The four declination reasons carried on the "not a QMCSO" notice are that the order fails to clearly specify: (1) the last known mailing address of the participant and of each alternate recipient; (2) a reasonable description of the type of coverage to be provided, or how each type is determined; (3) the period to which the order applies; (4) each plan to which the order applies (User Guide ch. 1).

No QMCSO letter generation, request table, or nightly print step was found in the extract. The only QMCSO touchpoint outside the three windows is a QMCSO filter checkbox on reprint/w_reprint_maintenance, which retrieves each candidate report's stored text from report_hist.report_data and drops rows whose text does not mention any QMCSO dependent name for the recipient (d_qmcso_dependent_names) — a reprint-side filter over already-generated documents, not a generator.

HB1 screens

• w_group_hb1_member_select — "HOMER - HB1 Member Select" (see above).
• w_hb1_maintenance — "HOMER - HB1 Member Maintenance": member summary/detail (d_hb1_member_summary_info, d_hb1_member_detail over hb1_members: eff/exp dates, monthly premium, coverage type, exp code) and payment history (d_hb1_payment_detail over hb1_payments: received date, paid-thru date, check number, amount).

Eligibility export

• w_enroll_group_export — "Export Group Eligibility" (response window): enter a master group and as-of date; validates the group is a master group; extracts subscribers and dependents (relationship from member_cat_val RELATIONS, demographics, address, coverage type/level/plan, coverage dates) via a UNION cursor over the group hierarchy and writes a flat file named <group>-<yyyymmdd> to the enrolldump_path configured in the application INI.

Minor popups

Window	Purpose (from object comment)
w_enroll_member_select	Select a member (response; d_enroll_choose_member)
w_member_select	Select a member (response; d_enroll_member_select)
w_member_select_by_group_id	Select member from list retrieved by group ID only
w_member_select_by_last_name	Select member matching last-name criteria
w_member_select_by_last_name_no_group	Same, "configured to not need a group_id"
w_member_select_by_mbr_id	Select member matching member-ID criteria
w_subscriber_select	Select a subscriber for a member
w_master_group_select	Select a master group matching search criteria
w_enroll_member_selection	"Member selection screen for w_enrollment_maintenance. Alternate version." — search by member ID / SSN / name showing relationship, group and eligibility status (d_enroll_member_selection)
w_family_member_select	Select a family member to display notes
w_enroll_trans_div	"Response window to enter a Division to receive an existing eligibility period" (d_enroll_groups)
w_enroll_view_wait_period	"Response window to view and edit multiple HIPAA waiting period start dates" (d_enroll_wait_pd_display)
w_enroll_pcp_search	"Response window to select PCP provider" (used by n_enroll_member_pcp)
w_quick_enroll_dep_addr	"Dependent Address" entry for quick enrollment (d_enroll_address)
w_quick_enroll_dep_cat	Assign dependent categories (d_enroll_dep_category)
w_quick_enroll_dep_student	Edit dependent student information (d_quick_enroll_dep_student)
w_quick_enroll_cob	"** OLD ** Window for Quick Enrollment dependent Coordination of Benefits" — superseded by w_enrollment_cob_maint
w_enroll_cobra_dependent_address_sync	Response window over d_enroll_cobra_dependent_address_sync (COBRA dependent address synchronization; see Open questions)
w_hipaa_printlabel_select	"window to select groups for HIPAA mailing labels"

Member name standards (User Guide ch. 1)

A 20 Feb 1999 standard governing how names are keyed, driven by claims matching: HOMER does not require the operator to know a subscriber's SSN to enter a claim — it matches on group number, insured's name and insured's address as well as the SSN from the claim — so middle initials packed into the first-name field produced a high volume of claims that could not be matched to a single member.

The standard, and the one-off cleanup program specified to enforce it:

• Move an initial to the middle name field where the first name has the shape First Name + space(s) + Middle Initial + optional .
• Correct Ii to II and Iii to III in the first name.
• Move II, JR and III into the last name field where the first name has the shape First Name + space(s) + suffix + optional .

Standing rules: Enrollment must not key middle initials or suffixes into the member first-name field — the nightly transfer back to the Wang already recombines first name and middle initial, so combined keying is unnecessary; MIS must observe the same standards when writing run-in programs; and because the cleanup cannot correct every variant, staff are to correct naming variants by hand as they encounter them. Relevant fields are f_name / m_name / l_name on d_enroll_member_demographics (subscriber) and d_enroll_member_dependents (dependents). No code in the extract enforces or validates this — it is an operator and data-conversion standard, significant for the migration's name-parsing rules.

Per-group eligibility rules (User Guide ch. 1)

The guide states the principle — "Eligibility rules are based on group. Homer will allow us to automate customized eligibility rules. Generally, the user would like to enter an employment date (date of hire) and have the system generate the effective dates for coverage(s)." — and then enumerates, group by group (roughly 60 client groups in the 501-nnn and 500-nnn series, many with per-division variation), the concrete rules in force.

The recurring rule shapes, which are what matters for migration, are:

• Waiting period, expressed either as a flat elapsed period from hire (no waiting, 30/45/60/90/120/180 days, one/three/six months, one year) or as "first of the month coinciding with or next following N days"; several groups carry two or more waiting periods split by class (union vs. non-union, hourly vs. salaried, executives/officers vs. all others, full-time vs. part-time), and at least one group defers to the union contract.
• Mandatory vs. elective coverage per group and division, plus linked coverages that must be elected together (most commonly Medical + Drug; sometimes Medical + Dental + Vision).
• Life / AD&D defaulting, either a flat amount per class or a salary multiple (1×, 1½×, 2×) with a stated rounding rule (to the next higher, next lower, or nearest $1,000, or nearest $100) and a cap; some amounts are scheduled to step up on future dates, and amounts above a threshold require underwriting approval.
• Weekly disability (WDI) and LTD as either a flat weekly/monthly amount or a percentage of earnings (50%, 60%, 66.7%, 70%) with a maximum.
• Flex / reimbursement products (medical reimbursement prorated over a year, dependent care, supplemental and dependent life) offered per group.
• Divisions used as coverage variants — retiree vs. active divisions, COBRA-only divisions, and divisions distinguished only by which PPO or HMO applies.

Several entries also document encoding workarounds that carry real migration risk, where an unrelated coverage field is used as a flag: a code placed under Life, AD&D or LTD to signal which of three PPOs applies; 1 under HMO code to signal a Kaiser election; 1 under dependent life to charge a COBRA claim fee; a department code carried under dependent life and ID code so that a group's bill prints employee counts per department (User Guide ch. 1).

Note for migration. These rules are documented per named client group in prose only; no rules engine, rules table, or effective-date generator implementing them was found in the extracted client code — waiting periods are keyed as dates on d_enroll_wait_pd / d_quick_enroll_sub_wait_pd and coverage is elected manually. The guide's framing ("Homer will allow us to automate") suggests automated generation of effective dates from the hire date was an aspiration rather than shipped behaviour. Treat the full group list in the guide as the source specification and confirm current practice with an SME before assuming any of it is enforced.

Requirements

Continues the enrollment ENR-n sequence (ENR-1 to ENR-45 are on the enrollment overview). Existing IDs are unchanged.

ID	Requirement	Source
ENR-46	The system shall record, per dependent, one or more date-bounded QMCSO custodian periods identifying the party to whom that dependent's QMCSO correspondence is sent, and shall set the dependent's QMCSO flag while such information exists and unset it when the information is deleted.	enroll/w_enroll_qmcso_maint, d_qmcso_maint_select_info, d_qmcso_custodian_info (qmcso_custodians); w_qmcso_member_detail
ENR-47	The QMCSO correspondence address shall be held separately from the dependent's enrollment address and shall not be displayed on or sourced from the enrollment Dependent Address sub-tab.	(User Guide ch. 1); enroll/d_qmcso_custodian_info vs. d_enroll_dependent_address
ENR-48	QMCSO information shall only be entered for members already enrolled, and every child cited in a medical child support order must exist as a dependent before the order is recorded.	(User Guide ch. 1)
ENR-49	Each member under a medical child support order shall carry a correspondence status from the set: Order Received, Waiting for Determination, Notice Sent, Waiting for Administrator, Accepted, Declined. (No status field exists in the extracted code — see the discrepancy above.)	(User Guide ch. 1)
ENR-50	While a support order's qualified status is undetermined, claims for the affected children shall be held retroactive to the order's effective date, and Claims shall be notified when the order is subsequently accepted or declined. (Operator procedure via VIP note — not enforced in code.)	(User Guide ch. 1)
ENR-51	The system shall generate the QMCSO letter set (tentative-decision notice to plan administrator, determination notice in qualified and not-qualified variants, notices to child and to employee, representative-designation form, alternate-recipient claim submission slip) as initial letters and second requests, defaulting the letters appropriate to the member's current status while permitting user customization; requests shall be queued to a request table and printed in the nightly production cycle rather than on demand. Not implemented in the extracted code.	(User Guide ch. 1)
ENR-52	A free-form HIPAA certificate shall be producible by manually completing a blank certificate and routing it to the print queue. Not implemented — the menu option opens the "Under Development" placeholder window.	(User Guide ch. 1); homersys/m_sys_frame → homersys/w_construct
ENR-53	Generating HIPAA certificates shall mark queued rows processed as each certificate is produced, then ask the operator whether the run succeeded — deleting the processed rows on confirmation and clearing the processed indicator on denial.	(User Guide ch. 1); enroll/w_enroll_hipaa_generate (hipaa_transactions.lock_cd = 'PROCESSED')
ENR-54	Printing a HIPAA certificate shall create a member note keyed HIPAA Cert recording the print date as mm/dd/yyyy followed by explanatory text; undeliverable certificates shall be logged as HIPAA Dead File notes in the same format; general, non-system-generated HIPAA notes shall use the key HIPAA.	(User Guide ch. 1); enroll/w_hipaa_dead_file, d_hipaa_history, w_notes_hipaa_report_view
ENR-55	The HIPAA certificate shall be addressed and identified per the documented template: subscriber name and address always printed (first eligible dependent substituted when the subscriber is deceased), plan name taken from the division-level company name, identifier formed as client number / division / subscriber SSN, dependents listed as first name plus middle initial separated by semicolons, plan contact taken from the master group, not available printed for missing coverage dates, Continuing for an open expiration date, and deceased members omitted from the coverage-ended section.	(User Guide ch. 1); enroll/d_hipaa_form
ENR-56	Member names shall be keyed to the documented standard: middle initials in the middle-name field, suffixes (II, III, JR) in the last-name field, and neither in the first-name field — so that claims can be matched on group, name and address when an SSN is absent or incorrect.	(User Guide ch. 1); enroll/d_enroll_member_demographics, d_enroll_member_dependents
ENR-57	Eligibility rules shall be configurable per group and per division, covering waiting-period basis (elapsed period from hire, or first of the month coinciding with or following an elapsed period) with multiple class-based variants; mandatory versus elective coverages; linked coverage sets; class- or salary-based Life/AD&D defaulting with rounding rule and cap; percentage-of-earnings or flat WDI/LTD amounts with maximums; and flex/reimbursement offerings — with coverage effective dates derivable from the employment date.	(User Guide ch. 1); no rules engine found in the extracted code