Stop-Loss Screen Catalog

All windows are in the stoploss library. "DW" = DataWindow object(s) driving the screen; citations are library/object.

w_sl_contract_selection — Stoploss Contracts (search)

• Type / menu: maintenance selection sheet (ancestor w_maint_selection), menu stoploss/m_sl_contract_selection (New / Open / Save / Delete toolbar).
• Purpose: find stop-loss contracts and open them in the contract editor.
• Criteria: contract code (prefix), description (prefix, case-insensitive), group (matches contract groups including all descendant groups via hierarchical subquery), level and carrier (drop-downs from stoploss/d_sl_contract_select_ddw, codes SLLEVELS + stoploss/dddw_sl_carriers), and "Within Years" (contract end date within the last N years, default 1). (stoploss/w_sl_contract_selection control tags)
• Results DW: stoploss/d_sl_contract_select (code, description, level, dates, carrier name, period, deductible, minimum attachment).
• What "level" and "carrier" mean here (User Guide ch. 17): level is the specific/aggregate split, and the two are genuinely separate commercial arrangements — "Specific and Aggregate Stoploss have separate premiums and different rates", "each will have its own premium and each premium may be paid separately if they are held by separate carriers", so one group may appear under two carriers in the same period. Specific stop-loss is "claim dollars accumulated on a per member or per family basis"; Aggregate is "dollars accumulated by all members within a client group". A third arrangement, Aggregated Specific, "applies the specific Stoploss to a member/family claim, and then applies the aggregated Specific Stoploss to a claim".
• Why contracts are searched within a recent window (User Guide ch. 17): contracts normally follow plan years but are user-dated so that mid-year carrier switches can be represented, and "User must enter an end date and a termination reason before adding additional carriers" — so a group accumulates one dated contract row per carrier per period.
• Navigation: edit service opens stoploss/w_sl_contract_maint keyed by sl_contract_sys_key. (dw_selection.constructor)

w_sl_contract_maint — Stoploss Contract editor

• Type / menu: sheet with m_generic_edit_menu; save commits/rolls back explicitly (pfc_save).
• Layout: header band stoploss/d_sl_contract_header (code, description; defaults from latest prior contract with the same code — dw_sl_contract.ue_afteritemchanged) above a four-page tab:

  • General — stoploss/d_sl_contract_maint (shared with the header updater): dates, incurred/paid ranges, carrier, level, contract period, deductible / minimum attachment, TLO, run-in/run-out, reimbursement percents and limits, policy no, notes. Drop-downs from codes PERIOD and SLPERIODS (dw_tab_sl_contract.constructor); per the guide, the contract period encodes the paid/incurred contract type (0/12, 12/12, 15/12, 24/12, 12/15, 12/24, with-TLO variants) from which default incurred/paid date ranges derive, user-overridable (STL-58), and TLO = Terminal Liability Option in months extending the paid-date end (STL-59) (User Guide ch. 17). Full validation set in dw_tab_sl_contract.pfc_validation / dw_sl_contract.pfc_validation (STL-1..STL-9).

    Field meanings from the guide (User Guide ch. 17): Deductible is the specific deductible the client must fund before a reimbursement can be filed — "Before we can file for Specific Stoploss reimbursements the Client must have paid up to the limit of the Specific deductible." Minimum attachment is the floor under the aggregate attachment point: "Attachment point is the dollar level at which the carrier becomes responsible for paying claims under aggregate Stoploss rules… Attachment points may not drop below the minimum attachment point even if the membership drops so much that the calculation of the attachment point would be less than this minimum", and "The Minimum Attachment Point is used annually, at the end of the Plan Year." A related guard, the % Rule, "states that the calculation of a client's attachment point for Aggregate Stoploss may not fluctuate downward more than a specified percentage between any two months. The % Rule will always be 0%, 5%, or 10%." Run-in "governs the processing of claims that were incurred for some limited amount of time (usually three months) prior to the group effective date. Run-in limits will always be for some amount of time and may additionally be for a flat dollar amount as well. Run-in time limits are implied by the Stoploss contract type when selected." The reimbursement percents and limits correspond to the guide's standard versus domestic reimbursement rates plus a coinsurance limit and a maximum limit per contract.

    Date-range derivation (User Guide ch. 17): "Plan year start date will be used as the start date of the paid date range. Plan year end date will be used as the end date of the incurred date range." Stop-loss years correspond to plan years.

  • Groups — pick list d_sl_group_select (object not in extract) filtered by a group id search box and a group-search popup (w_group_response_selection, other library); add (>) / remove (<) buttons maintain stoploss/d_sl_contract_group_maint rows; only base groups in the selected hierarchy branch are added, duplicates skipped (dw_tab_sl_contract_groups.pfc_addrow).

  • Coverages — coverage checklist stoploss/d_sl_contract_coverages_checkbox (codes SLCOVERAGE); excluded-plans checklist stoploss/d_sl_contract_excl_plan_checklist filtered to selected coverages; factor grid stoploss/d_sl_contract_factor_grid with bottom tabs "Factors - Standard" / "Factors - TLO" (tab Tag selects factor_type_cd), a "2-tier only" checkbox (Single/Family levels), and factor-defaulting help text. Grid enabled only for AGGREGATE contracts (wf_contractlevel, dw_tab_factors.ue_filter). Buttons "Change Dates" / "New Factors" are present with no coded behavior.

    Why factors exist and why the grid is aggregate-only (User Guide ch. 17): "Aggregate Stoploss attachment point will employ factors in its calculation. We must establish different sets of factors in the Stoploss parameters for each coverage defined in Client Maintenance for each client group." Attachment points "are generally calculated as a rate (aggregate factor) times the number of members in a group", recalculated monthly as a performance benchmark, with "A final attachment point … calculated at the end of the Stoploss year, which is then used to determine any carrier liability under Aggregate Stoploss."

    The Single / Family / Composite levels and the "2-tier only" checkbox (User Guide ch. 17): the three factors are Single, Family and Composite, and "users must enter Single and Family together, else just Composite. Each factor looks at coverage levels to determine what to use." Precedence between the factor grid and per-coverage values: "The single, family, and composite amounts entered in the 'factors' area of the tab will always be applied to all of the coverage(s) selected below. Additionally, any aggregate single, aggregate family, and aggregate composite amounts entered on the coverage lines will be applied instead of the amounts entered in the 'factors' area." The TLO factor set follows the same override rule. One operator trap: "The single, family, and composite amounts will always be cleared (and must be re-entered if needed) when a contract has been added via the 'inherit contract' button."

    Why coverages are selectable and plans excludable (User Guide ch. 17): the arrangements cover different claim populations — "Specific Stoploss only applies to medical claims", "Aggregated Specific Stoploss only applies to medical claims", but "Aggregate Stoploss can apply to any mixture of coverage(s)". One population is always out: "Sometimes we receive claims that are of the type 'ineligible'. These are claims that our Plan Document says to deny, but which the Client has, for reasons of their own, decided to pay anyway. Ineligible claims must always be bypassed by all of our Stoploss processing." Amounts the carrier or the member paid never count toward aggregate: "Aggregate Stoploss only looks at eligible dollars that were paid by the client."

  • Options — option value list stoploss/d_sl_contract_option_val_list (metadata from sl_contract_options, typed values, code options via stoploss/dddw_sl_option_codes); laser members stoploss/d_sl_contract_laser_maint (add via w_sl_member_selection; deductible required per row); domestic provider TINs stoploss/d_sl_contract_domestic_tin_maint (numeric only). Business intent: a laser is a member with a unique specific-deductible override, and the domestic-provider list drives the domestic reimbursement rate as opposed to the standard rate (STL-70). (User Guide ch. 17)

• Persistence: hidden window-level DWs (d_sl_contract_group_maint, d_sl_contract_option_val_list, d_sl_contract_factor_maint, d_sl_contract_coverage_maint, d_sl_contract_excl_plan_maint, d_sl_contract_laser_maint, d_sl_contract_domestic_tin_maint) diff the visible checklists/grids at save (ue_preupdate events) and share data with the tabs (pfc_postopen). Contract key from sequence SL_CONTRACT_SEQ is pushed into all child rows (pfc_preupdate, wf_getkey).

w_sl_member_selection — Select Stoploss Laser Member (response dialog)

• Type: response selection (ancestor w_response_selection), opened from the contract editor's laser list.
• Criteria: member id / SSN prefix, last/first name prefix, effective date (defaults today; matches member eligibilities effective on that date), plus a hidden filter restricting to members eligible in the contract's groups when a contract key is passed (sle_sl_contract_sys_key.Tag).
• Result DW: d_sl_member_selection (object not in extract); returns subscriber key, dependent key, group id, relationship to the caller (dw_selection.ue_set_return). (stoploss/w_sl_member_selection)

w_sl_specific_rpt — Specific Stoploss Report (daily run)

• Inputs: group (padded to 15; examples shown "SFPI, 501-003, 501-003A, SFP-Pittsburgh"), paid date, time-from (default 01:00:00), time-thru (default 23:59:59).
• Behavior: validates group and group security (f_check_group_security), then runs n_stoploss.of_SpecificStoplossRpt(group, from, thru) which prints the exceeder detail (stoploss/d_sl_spec_rpt) and summary listing (stoploss/d_sl_spec_listing) directly to the printer. Status button shows progress text (ue_updatestatusinfo); Cancel prompts for confirmation via n_stoploss.of_cancel. (stoploss/w_sl_specific_rpt; stoploss/n_stoploss)

w_sl_spec_summary — Specific Stoploss Summary

• Menu: m_retrieve_print_save (retrieve/print/save); Enter key triggers retrieve.
• Inputs: Group ID, Plan Start Date (blank = current, else latest, plan for the group), "Include pending", "Family Specific" (switches report DW between stoploss/d_sl_specific_stoploss_summary and stoploss/d_sl_specific_stoploss_family_summary).
• Threshold radio group: All Members / Over 50% / Over 100% / Over N% / Over N dollars, filtering on pct_met, pct_pending, total_paid_amt, or total_pending_amt (dw_report.ue_filter).
• Why 50% is a preset (User Guide ch. 17): the 50% threshold is the carrier-notification trip point, not an arbitrary round number. The original request was for "a report that lists only those claimants that have exceeded 50% of their specific. Report needs to track by amount processed and or paid", recorded as the "50% Notification" work request; the guide also asks for a carrier-level flag for whether a carrier "require[s] notification at 50%". The same convention governed the legacy combined run: "whenever Stoploss report is run, both aggregate and specific reports come out. (Specific at 50% of specific threshold.)"
• Why "include pending" matters (User Guide ch. 17): held and unfunded claims still move a member toward the deductible, and the guide asks that "Around the end of each Stoploss year (30 days prior), it will be necessary for the system to indicate to examiners that there are held claims for members who are currently exceeding a set percentage of specific Stoploss maximums."
• Validation: group entered, group security, group exists, valid plan date, plan with a positive individual (or family) specific limit exists (dw_report.pfc_retrieve).
• Post-processing: rewrites each row's group to the member's latest eligibility group (2021 change) and de-duplicates repeated patients in individual mode; a commented 2018 per-group override for 501-883 remains in source.
• Export: "Export to Excel" builds stoploss/d_sl_specific_stoploss_summary_excel with headers, recomputed percentages and grand totals, then SaveAs. Print runs through print preview (pfc_print).

w_sl_summary — StopLoss Summary Report (legacy chooser)

• Menu: m_census_args_menu; also invoked by stoploss/m_stoploss1 ("Run Report" → ue_reportchooser).
• Behavior: on open, only "Specific" / "Aggregate" radio buttons are visible (ue_forcechoice); choosing one reveals the parameter controls and sets a report flag (1=specific, 2=aggregate). The forced choice reverses the legacy behavior the guide describes, where "whenever Stoploss report is run, both aggregate and specific reports come out" — the guide's reviewers asked for exactly this split ("Split the report into two reports. The Aggregate stoploss report is being used in two distinct ways which is wrong to do.") (User Guide ch. 17).
• What the aggregate report is for, and its known instability (User Guide ch. 17): it "lists # of lives (EE and Dependent) and multiplies this by a factor to calculate an estimated attachment point for the month and the year", alongside total and aggregate claim amounts. Two documented problems survive in any report built on this data: membership lag ("Adjustments in the Stoploss premium may be required due to membership lag. (Late adds and late terminations)") and non-determinism ("the aggregate Stoploss report will show different totals for the same month which were run at different times depending on changes to enrollment or adjustments to claims since the report was first run"). Whether the report recalculates each month or freezes a processed month was still unsettled when the guide was written — a question worth resolving before migration. COBRA members "must be included in all Stoploss counts". Parameters: group (padded to 15), plan start date, level amount + Percent/Dollars (defaults 100 / Percent), include-pending, plus a ... picker that fills group/date from d_sl_parm_select (object not in extract).
• Specific path (ue_spec): enumerates stop-loss groups under the entered group for the start date (stoploss/d_sl_stoploss_groups), retrieves stoploss/d_sl_specific_summary per group, applies the threshold filter, sets the heading, prints.
• Aggregate path (ue_agg) and button variants cb_sp/cb_ag: retrieve d_sl_spec_summary / d_sl_spec_2 (objects not in extract), save each group's output as <group>.psr and print. (stoploss/w_sl_summary)

w_sl_specific_summary — untitled duplicate summary window

• Plain window (not a PFC sheet) duplicating w_sl_summary's specific (d_sl_spec_summary) and aggregate (d_sl_spec_2) print loops with Specific / Aggregate / Cancel / Exit buttons; no menu reference found in the library — apparent dead code. (stoploss/w_sl_specific_summary)

w_sl_spec_clm_listing — Specific Stoploss Claims Listing (per member)

• Menu: m_stoploss2 (Retrieve + Print toolbar).
• Inputs: member search panel (u_member_search), "Stoploss Start Date or Year" (defaults to the current year; a 4-digit year expands to the full year, a date is used as-is).
• Behavior: resolves the member's stop-loss plan through stoploss/d_sl_member_stoploss_parms (eligibility group walked up the group hierarchy); exactly one plan must match, else the user is told to enter a specific start date ("multiple stoploss plans") or that none exists. The user guide (ch. 17) states that overlapping stop-loss years should resolve automatically rather than prompt: "If the date ranges in two Stoploss years for a single client overlap, then the system will always choose the set of parameters with the most recent Stoploss year." — discrepancy for SME confirmation (the code requires the operator to disambiguate). Retrieves stoploss/d_sl_spec_clm_listing with group, subscriber, patient and plan start date; an "excel" button does SaveAs. A wf_getstoplossdate helper embodies the same plan-resolution SQL (largely superseded in the retrieve event). (stoploss/w_sl_spec_clm_listing)

w_sl_variable_clm_listing — Variable Stoploss Claims Listing

• Menu: m_stoploss2. Export-comment in source: "Similar to w_sl_spec_clm_listing but with a variable date range instead of a fixed Stop Loss Year".
• Inputs: member search panel, Paid Start Date (defaults one year ago today) and Paid Stop Date (defaults today), both mm/dd/yyyy masks; thru must not precede from.
• Behavior: retrieves stoploss/d_sl_variable_clm_listing (payments in the range against any overlapping specific plan's coverages) and, in parallel, hidden export DW stoploss/d_sl_export_maz (claim-line level: DOS, primary diagnosis, procedure, charge/allowed/paid, status, check no, provider) which "Export to Excel" saves. (stoploss/w_sl_variable_clm_listing)

w_wang_idcard_sheet — Process ID Card Requests (Wang Version)

• Shell sheet that opens the response dialog on post-open and closes itself. (stoploss/w_wang_idcard_sheet)

w_wang_idcard_response — Select ID Cards To Process

• Inputs: batch type radio (Miscellaneous = E, Group = G), optional "Prev Request Date" (blank processes outstanding requests; a date reprocesses that day's completed requests).
• Behavior: wf_process_idcards retrieves stoploss/d_wang_idcard_req (outstanding) or the completed-date variant, builds fixed-length 314-character card records into stoploss/d_wang_idcard_data (2 cards for Family/Single+1 levels, 1 for Single; coverage letter M/D/V), prompts for a .CRD filename under G:\APPS\IDCARDS\ (misc<MMDD>.crd / grp<MMDD>.crd), warns on overwrite, saves as text, and — for outstanding runs — stamps req_complete_dt and commits, rolling back with an operator warning if the update fails. (stoploss/w_wang_idcard_response)

w_open_windowname — developer window opener

• Prompts for a window class name and opens it as a sheet, allowed only when the user holds the Oracle DEVELOPER role (user_role_privs); otherwise shows "You must have Developer security to run this program." A stray "none" button contains unrelated, non-functional address-standardization test code (reads uninitialized variables). (stoploss/w_open_windowname)

Menus

Menu	Used by	Notes
stoploss/m_stoploss1	w_sl_summary	Adds hidden "Run Report" (frame File menu) sending ue_reportchooser, and "Specific Report" under Edit.
stoploss/m_stoploss2	w_sl_spec_clm_listing, w_sl_variable_clm_listing	Frame menu variant exposing Retrieve and Print toolbar items.
stoploss/m_sl_contract_selection	w_sl_contract_selection	Frame menu variant exposing New / Open / Save / Delete.

Non-visual objects and structures

Object	Role
stoploss/n_stoploss	Stop-loss engine: plan loading (of_GroupSpecPlans), date-window math, register bumping (of_SpecRegTotal), daily report driver (of_SpecificStoplossRpt), cancel/yield/status plumbing.
stoploss/n_stoploss_sql	Embedded SQL helpers: current and last eligibility group for a subscriber.
stoploss/str_spec_plan	Bounded arrays (10 plans x 10 coverages) holding plan dates, incurred/paid windows, limits, coverages.