Skip to main content

Screen catalog: plan design (benplans) and plan support (bensupport)

Plan-design screens share menus benplans/m_plan_design / m_plan_edit and common ancestors benplans/w_header_detail_maint (header/detail maintenance), benplans/w_maint_single (single-DataWindow maintenance), and benplans/w_response_selection (select-and-return response window).

benplans/w_benefit_plan_selection — Benefit Plan selection​

  • Purpose: list/search benefit plans (d_benefit_plan_select over benefit_plans: coverage type, plan code, description, filing/appeal limits, package logic, status, audit columns). Launches plan create/edit.

benplans/w_create_benefit_plan — Plan editor​

  • Purpose: create/edit one plan and its ordered package attachments.
  • Field groups: plan header (d_benefit_plan_edit / d_benefit_plan_maint): coverage type (dddw dddw_benefit_coverage_type_codes), plan code, description, status, package logic (PKGLOGIC codes; defaults to NORMAL), filing limit and appeal limit (length + PERIOD code). Package attachments grid (d_plan_packages over plan_pkgs): package (from d_benefit_packages picker), eff/exp dates, HCN, pricing plan, pricing logic (PRICELOGIC codes), UR firm, CM firm, search order.
  • Validations: search order renumbered from display order on save (wf_set_sequence); a live no-network default package required except ASMEDICAL drug plans (wf_check_default_pkg); no overlapping date ranges for the same HCN (wf_check_dates — "Effective Date must be BEFORE Expiration Date!"); missing-data check (wf_check_nulls); plan-code rename cascades to attachments (wf_rename_coverage_cd); plan code unique per coverage type (wf_check_cd_duplicates).
  • Actions: add/delete attachment rows, print plan (d_print_benefit_plan + nested package reports).
  • What a plan is (User Guide ch. 6): "Benefit Plans contain a set of benefit packages, which describe the possible ways claims may be paid under the plan. Plans are for a specific type of coverage (medical, dental, etc.), and correspond to an electable coverage option for a member." The plan also holds "guidelines for selecting a package, as well as additional general information, such as appeal and claim filing limits".
  • Plan code naming convention (User Guide ch. 6) — an operator rule, not a suggestion: "It is very important the users follow the naming conventions for Plans set forth here. The field is 15 characters and must contain two dashes… the first three digits of the Plan Code should be the actual three digits of the Wang group number… The last 3 digits must be the flex option number found in the coverage tab on the Homer enrollment screen. These last 3 digits must be immediately preceded by the second dash. The first dash can be placed anywhere in the name. The middle part of the Plan Code is optional." Description: "It should start with the group name and include the letters of any divisions that are included in the plan." The reason the convention is load-bearing: "Currently this code must match the Benefit Coverage Code from the 'Coverage' tab in the enrollment file… If the code in enrollment and the code in the plan are not identical then the system will not be able to assign a plan to a claim." Even option-less plans carry a 000 suffix.
  • Status codes (User Guide ch. 6): COMPLETE — "claims may be adjudicated using the plan"; INCOMPLETE — "claims will hold in adjudication status until plan is completed"; NONPROCESS — "valid for election purposes only, and we do not process these claims. Examples: Life, AD&D, etc."; VOID — "not valid for any purposes"; and AS MEDICAL — "Use this for Plan type 'Drugs' when Prescription Drugs are covered under the Medical Plan." Plans are created INCOMPLETE automatically and "when the plan is completely loaded the status will need to be manually updated to 'complete'". "The Adjudication process will always check the current status of a Plan before determining action. Plan Designers must maintain a Plan's status."
  • Package Logic (PKGLOGIC) (User Guide ch. 6): "Normal logic is to search sequentially through the packages for the correct package to use on the claim, therefore, it is extremely important that the packages be loaded in the proper order." DentalStep drives step-driven dental plans, which "require special Plan level logic" checking the member's current step level and procedure history.
  • Search order and the out-of-network catch-all (User Guide ch. 6): "Packages For This Plan must be ordered here in the sequence that the system should process claims, for example, if there are out of network and network packages attached to a plan – the out of network package should be listed first." Multiple networks are expressed by attaching multiple packages, and the rule the code's wf_check_default_pkg enforces is stated plainly: "If there are Packages with network affiliations, then there must also be an Out of Network package" / "In Plan Design there must always be a Package set up with not HCN cited. This will serve as the catchall Package." On an attachment row, "If the package is not for an HCN, then the choice should be 'none'", and "An effective date for a package must always be entered."
  • Pricing Logic (PRICELOGIC) (User Guide ch. 6): HCN — "the pricing logic is at the Health Care Network level – or attached to an HCN contract within the Homer system"; External — "the pricing logic comes from an outside source, for example an HCN that does its own pricing"; Package — "the system should look for pricing logic at the package level, not at a provider contract, or at HCN contract."
  • Filing limit (User Guide ch. 6): "Filing limits are set up during Plan Design, and should be generated by the system when Plans are added, but are allowed to be modified later. There will be a general filing limit of 15 months for every claim, the system will reject all claims exceeding this limit. Filling limits can begin at either the Date of Service, or the start of the Plan Year."
  • Package pick list (User Guide ch. 6): the list "will only contain packages of the same type of coverage as the plan being loaded", and is opened by "Entering an asterisk in the Benefit Package Code field located above the pick list".
  • How a plan is applied at runtime (User Guide ch. 6): the claim's patient and primary claim type are identified; the patient's election coverage points to a single benefit plan; the system picks a single package by examining the applicable HCN; it then identifies the rules in that package, limits them by the package rules, resolves the benefit definitions those rules require, assigns one definition to each claim line, and processes the claim against the package rules using it.

benplans/w_benefit_pkg_selection — Package selection​

  • Purpose: list benefit packages (d_benefit_pkg_selection) for edit/create.

benplans/w_benefit_pkg_maint — Package editor​

  • Purpose: maintain one package: header, rules, riders, and rule interactions.
  • Field groups: headers d_benefit_pkg_header1 / d_benefit_pkg_header2 (package code, description, default benefit definition, unassigned action + reason, pricing plan, second-opinion list, extraction / procedure flags); Summary tab (d_pkg_summary: per rule — type, code, dates, member scope decoded as Sub/Spouse/Deps combinations, PCP/Auth/Cert/Adm/Ref requirement string, accumulator, reason); rule attachment editor (d_pkg_rule_maint over pkg_rules with priority, member flags, managed-care indicators); rule picker (d_benefit_rule_picklist); riders (d_pkg_rider_maint, d_rider_rule); dependencies (d_pkg_rule_dep: accumulator + apply %), requirements (d_pkg_rule_req: accumulator min/max band), fulfillments (d_pkg_rule_ful: fulfilled rule).
  • Validations (pfc_validation): package code, default benefit definition, unassigned action ("ie. Hold, Exclude, Pay"), and unassigned reason are mandatory; unassigned-reason pick list filtered by the chosen action.
  • Opens: benplans/w_benefit_def_response (definition picker), bensupport/w_response_save_as_string (save-as prompt).
  • What a package is (User Guide ch. 6): "Consists of a set of benefit rules that should be applied to claims being adjudicated under this package. The package also contains additional information as to which defaults should be used for unassignable claims, pricing, and other processing… Effective and termination dates for packages are at this level… The main criterion for package selection is based upon which healthcare network the provider on the claim belongs to."
  • How many packages to create (User Guide ch. 6) — the operator decision procedure: "if the Plan has any HealthCare Networks and if so, is there steerage for in-network benefits. If the plan has a network and there is steerage then you will need to create a package for the HCN and a separate package for the out of network benefits. If the plan has a network but there is no steerage then you only need to create one package that can be used for both in and out of network benefits. If your plan does not have an HCN but there are divisions with different benefits then you will need to create a separate package for each plan of benefits." The package code should encode that distinction — the guide's examples are SFPIOON250/750 versus SFPIHCN250/750. (The guide gives the code field length as 15 characters in one place and 14 in another — confirm against the database column.)
  • Unassigned action and reason (User Guide ch. 6): the three dispositions for a claim line whose benefit definition is not cited in any of the plan's rules are "If not covered, do not pay the claim. No manual intervention required / If not covered, always pay at 100%. No manual intervention required / If not covered, examiner must review claim." In the two non-hold cases "the plan must also designate what Benefit Definition should be defaulted to these claims" — which is what the Default Benefit field supplies. Current practice per the guide: "we have chosen to hold any claim detail line that could not be assigned a Benefit Definition."
  • The managed-care indicators are three-state, not boolean (User Guide ch. 6): for each package rule there are switches for Authorization Required, Admission Notification / Pre-Certification Required, and Referral Required — and "switches two and three are mutually exclusive within a single rule". The three settings: "Y – Valid entry is required in order to execute the rule; N – Valid entry must not be present in order to execute the rule; Blank – Always run the rule." Examiner-facing consequence: "If switch is Y or N in any rule, then things are required as far the examiner is concerned. If blank, then UR is not required." The guide also states "Utilization Review rules must be set up for every Package within each Plan."
  • Attaching a rule (User Guide ch. 6): "As the individual rule is chosen it is mandatory that an effective date be entered. When a rule is no longer in effect for a package, an expiration date would need to be entered for that rule." The accumulator shown beside a rule is not editable here — "the system automatically fills this in from the rule itself".
  • Priority (User Guide ch. 6): priority overrides the default search order within a rule type only. "you can set priority levels between 0 and 99. The higher the priority number, the earlier adjudication will attempt to apply the rule… By default, all rules are set to a priority level of 0 when created." The default order is rule type, then accumulator type, then rule period, then rule code alphabetically.
  • Riders — the four-way truth table (User Guide ch. 6): "If the member had the rider and the exclude flag is not checked then the rule applies. If the member had the rider and the exclude flag was checked then the rule does not apply. Visa versa, if the member did not have the rider, and the exclude flag was not checked then the rule does not apply, and if the member did not have the rider and the exclude flag was checked, then the rule does apply." Worked example: "if there were a rider that altered the deductible level from 80% to 70%, then there would be two deductible rules, each citing the rider. The 80% would apply when the rider was excluded, and the 70% deducible would apply with the presence of the rider (not excluded)." Note the guide contradicts itself elsewhere — one passage states "Benefit Riders — This is currently not set up in the Homer System" — so confirm with an SME whether riders are live.
  • Dependencies, requirements and fulfillments (User Guide ch. 6), which is what the three link grids implement:
    • Dependencies ("Applies After Rule") — "Allow for amount accumulated under one rule to be also applied to other rules." Worked example: a supplemental accident benefit needs both a 100% rule and a paid-limit rule attached to the package, but "only the limit rule not the 100% rule needs to be listed in the 'Applies After Rule' area", and "This must be done for each normal deductible and coinsurance rule". The effect is a runtime reordering: naming rule B inside rule A moves A after B in the firing order.
    • Requirements ("Applies Within Accumulator Range") — "Allow for one rule to require that values accumulated under another rule be within a certain range." Worked example: mental and nervous visits "1-5 payable at 50%, visits 6-20 payable at 30% and visits 21-50 payable at 25% with an overall visit limit of 50". The guide concedes "This is an extremely confusing concept, but one that is necessary in order to have complete flexibility within the plan load."
    • Fulfillments ("Applies to Additional Accumulator") — splitting accumulation, "intended for situations such as the … mental nervous benefit where a 50% is payable at 100% and the other 50% is payable at 50%. The second 50% portion would be listed in this space."

benplans/w_benefit_rule_select — Rule selection​

  • Purpose: search/list benefit rules (d_benefit_rule_list; rule-type filter dddw_rule_type adds an "<All>" row via UNION).

benplans/w_create_benefit_rule — Rule editor​

  • Purpose: create/edit one benefit rule with its detail, definitions, contingencies, tooth types, and package usage.

  • Field groups: master (d_ben_rules over benefit_rules): rule code (charset restricted, GRP-37), description, rule type (dddw_benrule), reason (dddw_reason_cd, filtered by rule type or ACCUM — ue_filter_reason_cds), accumulator (dddw_reason_accum), narrative (2000 chars), rule period (length + PLANPERIOD), age band (min/max, PERIOD codes), considered amount band and percentage, accident flag, weekdays (dddw_daysofweek), units between min and max, contingency period. Details tab (d_ben_rule_ded) relabeled per type — "Copay Details", "Deductible Details", "Coinsurance Details", "Out of Pocket Details", "100PCT Details", "Claimed Limits", "Paid Limits", disabled for EXCL/HOLD (wf_set_accum_type): Rule Applies (Retain / Pay at / Maximum of vs coverage-level schedule dddw_level_sched), per-individual / per-family maxima, members-to-meet, carryover (dddw_carryover_rule), per-day basis (PERDAY codes), per-unit flag, quantity basis + unit ratio. Definition list tab (d_rule_def_link + d_benefit_def_list with criteria search) — add/remove definitions the rule governs. Contingencies tab (d_rule_contingency + definition list; With / Without radio buttons drive contingency_ind, defaulting to With when contingencies exist — see GRP-39). Teeth tab (d_rule_tooth_types / d_tooth_types) for dental rules. Package usage (d_pkg_rules) shows/edits which packages carry the rule.

  • Validations / behaviors: per-type field nulling (wf_reset_rule_detail); DED forces retain_val = 100; COI/OOP store 100 − "pay at" (pfc_save); duplicate rule-code check (wf_dup_check); single-transaction save across five DataWindows (pfc_save); print rule report (d_print_rule + nested contingency/def/pkg reports).

  • Opens: bensupport/w_response_save_as_string.

  • What rules are (User Guide ch. 6): "Benefit rules are the building blocks for adjudication. Basically, rules tell the system what amounts are payable for a claim." A sample package is a set of rules such as "$200 deductible per calendar year on all major medical claims / 80% coinsurance on the next $2000 considered … / $10 copayment on all office visits / A limit of only one physical exam per year / Exclude all claims related to drug or substance abuse / Pay all infant immunization claims at 100%." Reuse warning: "Rules can be reused by a number of benefit packages, however extreme care must be taken when reusing rules because of the application of benefit definitions within the rule."

  • Rule code prefixes (User Guide ch. 6) — the convention behind the restricted charset (GRP-37): "15 spaces are available for abbreviated name of the Rule – Dental rules must begin with 'DNT', Vision rules must begin with 'VIS', WDI rules must begin with 'WDI', medical rules do not need to begin with 'MED'." Descriptions follow the same split ("if Dental it should begin with 'DENTAL'").

  • Retain values by rule type (User Guide ch. 6) — this is why the code forces retain_val = 100 for DED and stores 100 − "pay at" for COI/OOP: "the retain value… states how much money should be withheld from payment for a claim when a rule applies… For deductible, exclusion and limit rules, the retain value is a fixed value of 100%… Coinsurance and out of pocket rules are specified by the user as a percentage of the considered amount… Retain values for copay rules are specified as a flat dollar amount."

  • Reason code versus accumulator code (User Guide ch. 6) — the guide flags this section "IMPORTANT - EVERYONE MUST READ":

    • Reason — "used as a reference to give claimants, providers and examiners a clear description of why a rule applied to a claim. The explanation provided by the reason code is printed on claimant EOB's and provider RA's."
    • Accumulator — "designate where accrued values should be kept when a rule applies, and also indicate which values should be checked to see if a rule is within its limits… Accumulators are kept for each member and for each time period specified by rule… Regardless of which accumulator value, considered, retained, or quantity, is applicable to the rule, all accumulators are added to whenever a rule applies."
    • Worked example: "if the plan contains both an 80% and a 50% coinsurance, you will need to use two separate Accum codes so that whatever is processed at 50% will not accumulate towards the 80% coinsurance limit."
    • Type constraint matching the editor's ue_filter_reason_cds behavior: "For Rule Types of HOLD, 100% and EXCLUSION, it will be possible that the Reason Code and Accum Code may be the same… For Rule Types of DED, COI, OOP, COPAY, PAID AND CLAIMED you will need to make sure that the Accumulator Code Type is 'ACCUM'." The accumulator defaults from the reason code and may then be overridden.

  • Accident flag — rules come in pairs (User Guide ch. 6): "If 'yes' is chosen for a rule, then there must also be a rule that says 'no'. For example: a deductible rule for a specific amount if charges are due to accidental dental then the flag would need to be set as 'yes'. Then if there were a different deductible amount for charges not due to an accident, there would need to be another rule set up for the same thing but with the flag set to 'no'." The same pairing pattern applies when an HCN package covers routine care and the OON package does not — two rules sharing one accumulator code.

  • Age band is a through age (User Guide ch. 6): "mammograms for persons age 35-40, the min would be 35 and the max would be 39, as the system looks at a through age, not a to age. You may also just have a min or a max; both are not necessary."

  • Limits and periods (User Guide ch. 6): "Rules apply either after and/or until a certain level is met within a particular time frame… Based upon the rule type, the level value may either say at what point does a rule begin to apply, or at what point does a rule cease to apply." A deductible applies until $200 is retained; a two-exams-per-year limit does not apply until after two visits. With both individual and family maxima, "If either limit is met, then the rule is considered to be satisfied", and coverage level is read as of the time of the claim.

  • Per-individual / per-family maxima measure different things by type (User Guide ch. 6): "For Coinsurance, maximum is based upon total amount considered… Deductible, Out of Pocket, and Copay are based upon total amount retained… Limits are based on either amount considered or a quantity of units."

  • Members-to-meet and chip-in (User Guide ch. 6): members-to-meet is "The number of individuals in a family that must satisfy the individual coverage level maximum for the rule to apply" — the alternative to chip-in, where "each member accumulates to an individual level and all of the members dollars also contribute to the family level". A related hard rule: "We will never take more than the single limit from one family member."

  • Per-unit flag (User Guide ch. 6): "Whether the retained amount applies a single time, or for each unit." Limit type: "Designates what type of maximum to accumulate. Either allowed amount, payable amount or by a type of unit."

  • Quantity basis and unit ratio (User Guide ch. 6): "User may enter a unit conversion ratio that may be either informational, or may be applied to the units on claim detail lines before processing the rule. The result of the conversion is not stored with the claim; it is only used during rule processing. If the ratio is not set up or is merely informational, we assume a one-to-one ratio." Examples: "360 minutes = 1 visit; 8 hours = 2 visits; 1 day = 1 visit". For chiropractic, inpatient hospital, outpatient physical/occupational/speech therapy and mental-nervous therapy, "the system must calculate the number of days to use as the units for the claims detail line, and ignore all units entered on the form for that line". Two further rules: "Anesthesia will never be subject to these limits", and "we must always create a hold rule for Home Health Care that will indicate that the units on the claim detail line must be reviewed prior to running any other Plan Rules."

  • Observation — the unit ceiling that converts an outpatient bill to inpatient (User Guide ch. 6): "Observations will process the Claimed Limit rules normally, but on a UB92, if the total units on all Observation claim detail lines exceed 23 (Per Bonnie 3/30/1999) it should be an inpatient visit rather than an outpatient bill. If this occurs, the system must generate an error message to alert the examiner to reject the entire claim and request the claim on the proper form." Note this is a claim-level test — the units are totalled across all Observation lines, not evaluated line by line. The two chapters disagree and the difference is material — chapter 11 states the same rule as "Observation – On UB92, if hours exceed 24 units (hrs) it then becomes an inpatient visit rather than an outpatient bill. Ex. 36 hrs = 2 inpatient days. If this occurs, we generate a warning and route the claim through manual Adjudication" (User Guide ch. 11). Three things differ: the threshold (23 vs 24), the disposition (reject the claim and demand re-submission on the correct form vs. warn and route to manual adjudication), and whether excess hours are converted into inpatient days (chapter 11's "36 hrs = 2 inpatient days"; chapter 6 has no conversion). Discrepancy for SME confirmation — do not pick one. Chapter 6 is the later and more specific statement (it carries a dated attribution), but neither is corroborated by code. Implementation status: the data exists but the rule does not. Procedure codes carry an Observation flag, procedure_codes.proc_cd_observation_ind, maintained on bensupport/w_procedure_code_maint (bensupport/d_procedure_codes) — but no consumer of that column was found anywhere in the extracted source, and no 23- or 24-unit Observation test appears in clmsproc. The threshold rule is documented-only; only the flag that would feed it is implemented.

  • What an occurrence is (User Guide ch. 6) — this term is load-bearing wherever a rule period or a claimed limit is expressed "per occurrence", so the guide's definition is given in full. "Occurrence Based Claimed Limits represent distinct services for a specified condition. An occurrence is defined as:

    • For services using interim claims processing (UB92 only), an occurrence is the set of claims (including the final claim) having detail lines falling into the rule's definition list and having dates of service within the date range specified on the final claim. Use date of admission (box 17) and the latest through date (box 6) as the date range. Claims rejected during duplicate processing do not contribute toward Occurrences.
    • For all other services, an occurrence is any claim falling into the rule's definition list that is not a duplicate."

    So an occurrence is a claim-grouping concept, not a line-level or date-level one: outside interim UB92 processing it is one non-duplicate claim, and within interim UB92 processing it is an entire admission's worth of claims collapsed into one. Chapter 11 adds the adjudication consequence: "Claims that invoke rules that accumulate by occurrence must be manually adjudicated after the first occurrence of that specified condition. (The first occurrence can be automatically adjudicated.)" (User Guide ch. 11). Implementation status: implemented, but narrower than documented. OCCURRENCE is a live accumulator/rule period value in clmsproc/n_claim_adjudication, handled in three places: the period-range resolver opens the window to all dates but sets the single-claim flag (case "OCCURRENCE" → ldt_from = Date(1500,1,1), ldt_thru = Date(2999,12,31), ls_single_clm_flg = "Y"); the accumulator-date derivation ignores period length entirely (case 'OCCURRENCE' → from and thru both set to the claim date, "Period Length is ignored"); and the maximum check short-circuits, returning the individual maximum rather than a satisfied/unsatisfied verdict (if ls_accum_period = 'OCCURRENCE' then return ld_indiv_max). The value reaching that switch is benefit_rules.rule_period_type_cd, chosen on the rule editor from benplans/dddw_plan_period, which reads code table PLANPERIOD. That dropdown is entirely data-driven — no period-type list is hard-coded in benplans — so whether "Occurrence" is offered to a plan designer at all depends on whether a PLANPERIOD / OCCURRENCE row was seeded in the codes table, which the extracted client cannot tell us. Confirm against the database. The code therefore scopes an occurrence to the single claim being adjudicated. The user guide (ch. 6) states that for interim UB92 processing an occurrence is the set of claims across an admission, keyed on box 17 and box 6 — discrepancy for SME confirmation. No interim-claim grouping for occurrence accumulation was found in the extracted source, and chapter 11's "manually adjudicate after the first occurrence" hold was not located either.

  • Copay same-day rules — the per-day basis (PERDAY) on the Details tab: a copay rule declares when several detail lines share one copay and when each line gets its own. Chapter 11 is the fuller source and is the one to build from; chapter 6 states a narrower three-method version. Chapter 11: "Each Copay rule itself will indicate the circumstances under which detail lines share a common Copay… (Note that while these options may be defined within the Rule, not all of these instances will be programmed for initially. Copay options not coded for will generate error messages to examiners indicating that the Copay must be handled manually.)" (User Guide ch. 11)

    Guide option (ch. 11)PERDAY code in clientBehaviour
    Same Day Same ProviderPERDAYDRFor one member, all lines whose benefit definitions are in the copay rule and that share a provider take a single copay. History must be checked so copay already taken for those definitions for that provider is not taken twice.
    Same Day Any ProviderPERDAYFor one member, all lines whose benefit definitions are in the copay rule take a single copay regardless of provider. History must likewise be checked.
    Each Service SeparateNEvery matching detail line gets its own copay. "Note that this will occasionally be wrong, but the money can be refunded in cases of dispute."
    (per occurrence)PEROCCURTreated by the client exactly like N — the rule applies for every occurrence, nothing is netted off. No guide counterpart.

    Worked examples the guide uses to separate the first two, for an office visit plus two lab charges: with the same provider, Same Day Same Provider yields one copay for everything together, while with a different provider for the labs it yields one copay for the office visit and one for both lab charges together; Same Day Any Provider yields one copay for everything together in both cases. Each Service Separate yields three copays in both cases. The guide also records the collapsing rule in chapter 6's shorter form: "Same day & same provider = one visit / Same day, different provider where one is an office visit and another is Lab charge = one visit / Others are all separate visits" (User Guide ch. 6) — note that chapter 6's second clause (an office visit and a lab charge from different providers counting as one visit) has no counterpart in chapter 11 and none in the code; flag it for SME confirmation. Implementation status: the mechanism is implemented, but it is switched off for copay — read this carefully before migrating. The field is benefit_rules.per_day_cd, edited via benplans/d_ben_rule_ded through dropdown benplans/dddw_perday (code table PERDAY, so the display labels are database rows, not code). benplans/w_create_benefit_rule defaults it to PEROCCUR both on a new row and whenever the rule type changes. The enforcement routine is clmsproc/n_claim_adjudication.of_PerDay, which returns "the number of days already considered under rule… subtracted from the units on the claim to get the units that are still applicable". PERDAYDR sets the provider key from service_provider_sys_key so matching is provider-scoped; PERDAY sets it to zero "to signify that no provider necessary"; N and PEROCCUR return zero days consumed. It checks both the current claim's line-rule datastore and prior history (d_adjd_rule_lines), satisfying the guide's "must check historical claims" requirement, and it marks overlapping service dates off a date array rather than comparing single dates, so multi-day lines net correctly. Room-and-board lines get a one-day adjustment when units are one less than the elapsed days (of_IsRoomAndBoard), and for RETAINED accumulators partially-retained prior amounts are prorated into days before being marked off. The caveat: of_PerDay is called from exactly one site, and that site excludes copay — IF ls_rule_type <> 'COPAY' THEN … of_PerDay(…) (clmsproc/n_claim_adjudication, the per-day check preceding rule application). The COPAY rule branch contains no per-day logic of its own. So on a copay rule the "once per day" selection is storable, editable and visible, but has no effect at adjudication time; the per-day netting takes effect only for the other rule types (DED, COI, 100PCT and so on). The user guide (ch. 11) describes this field as the defining characteristic of a copay rule — "Copay Rules will be of five types… determined by the value selected in the 'once per day' area of the Rules Window" — so the guide and the code are in direct conflict on the one rule type the guide wrote the feature for. Discrepancy for SME confirmation, and a migration risk: copay same-day netting is specified but not in force. Two further documentation mismatches: the guide states Same Day Any Provider "will not be available immediately" and must hold for manual adjudication, whereas PERDAY is implemented as ordinary logic in of_PerDay; and the guide announces "five types" but enumerates only three, while the client offers four PERDAY values (PERDAY, PERDAYDR, PEROCCUR, N).

  • Contingencies — With / Without (User Guide ch. 6): "With is used to indicate that the rule should be used when the benefit definition is on the claim. Without is used to indicate that the rule should be used when the benefit definition is not on the claim." The worked example is a second surgical opinion benefit: deductible and coinsurance rules for the diagnostic-lab definitions carry a contingency on the MD\SSO definition with the exclude box checked, "so… anytime a claim line was assigned one of the above listed DXL benefit definitions and the claim did not contain another line which was assigned the MD\SSO benefit definition the system would apply the deductible or coinsurance rule."

  • Teeth tab (User Guide ch. 6): "You may pick specific tooth groups such as molars or bicuspids if the rule only applies to a certain tooth group."

  • Package usage is read-only (User Guide ch. 6): "This area displays the packages where this rule is used, this field cannot be edited through the rules."

  • Rule type semantics (User Guide ch. 6): "Hold rules indicate that the claim should be held for manual review by an examiner, usually because additional information is required. 100% rules indicate that the claim should be identified as payable in full under the plan of benefits. It does not, however, mean from the adjudication standpoint that the claim will always be paid for the full billed amount… In this sense, 100% rules are merely for categorization and reporting purposes." The 100% rule has a second, structural use: it is how benefit definitions get assigned to lines not cited in any other rule, "Remember that the nightly process will only utilize Benefit Definitions that are actually cited in a Plan's Rules."

  • Default rule execution order (User Guide ch. 6): exclusions, then hold, then claimed limits, then copay, then deductible, then out-of-pocket / coinsurance, then paid limits. The guide states this order in three places with minor inconsistencies (one list omits the 100% rule; another swaps coinsurance and out-of-pocket) — the authoritative order should be taken from the adjudication code, not from this chapter. Within a rule type the order is accumulator type, then package priority, then rule period, then rule code alphabetically.

benplans/w_benefit_def_selection / w_benefit_def_response — Definition pickers​

  • Purpose: search benefit definitions (d_benefit_def_selection / d_benefit_def_picklist); response variant returns the chosen definition.

benplans/w_benefit_def_maint — Benefit definition editor​

  • Purpose: maintain the service-classification criteria of one benefit definition.
  • Field groups: header (d_benefit_def_header1: code, description, short desc, inpatient/outpatient indicator); one tab per criterion — Procedures (3 code-type slots: type dddw + criterion multiline or pick list, plus reusable procedure groups via d_proc_cd_and_groups_list/_selected), Diagnoses (same pattern), Place of Service (d_pos_list), Specialty (d_specialty_list), Modifier (d_modifier_list), Revenue (d_revenue_list), Compound (child definitions, d_compound_ben_def). Each tab offers "Criterion" vs "Pick List" entry modes with add/remove (u_cb_add_remove).
  • Behaviors: criteria stored as SQL predicates; * converted to %, BETWEEN…AND protected during prefixing (wf_prepare_where_clause); IN-only criteria round-trip as pick lists (wf_ispicklist, wf_decode); usage report (d_benefit_def_usage) shows where a definition is used; summary/print DWs (d_benefit_def_summary, d_benefit_def_rpt1).
  • Opens: bensupport/w_response_save_as_string.
  • What a definition is, and how criteria combine (User Guide ch. 6): "Benefit definitions categorize claims based upon information contained on the claim." Across criterion types the logic is AND: "Every criterion specified must be met for the service to be considered as part of the benefit definition. For example, if there were a benefit definition called Well care Immunizations, defined as all of the procedures for immunizations and any diagnosis of well care, then the claim would need to be both an immunization procedure AND have a well care diagnosis… If the claim fails any of the criterions, then it fails the definition." Within a single criterion type the logic is OR: "The user can choose to specify multiple code types and code groups within a benefit definition. If the claim matches any of the types or groups, then it is considered to have met that criterion."
  • Compound definitions (User Guide ch. 6): "benefit definitions may also be made from other benefit definitions to create hierarchical definitions… Compound benefit definitions may only be made up entirely from other benefit definitions, and no other specific criterion may be used." At assignment time "the most specific simple benefit definition (non-compound) will be resolved and used as the claims designation", though "Benefit rules can reference either compound or simple benefit definitions."
  • Maintenance hazard (User Guide ch. 6), with the guide's own worked example: "if a Benefit Definition is changed, and that Benefit Definition is referenced by another Benefit Definition, then the referring Benefit Definition should be reviewed to compensate for the changes. Ex. Benefit Definition A = CPT 100-200; B = CPT 201-300; X = A & B. If B is split so that A = 100-200, B = 201-250, C = 251-300, then X must also be changed to be A, B & C. Otherwise Benefit Definition X will no longer include all of the CPT codes that it was originally intended to have." This is the risk the usage report (d_benefit_def_usage) exists to manage.
  • Definitions and rules are not date-ranged (User Guide ch. 6) — stated twice in the chapter and important for migration: "Since Benefit Rules and Benefit Definitions are not date ranged, changes to them will be immediately available across all of the date ranges of Benefit Packages and Benefit Plans. (So, because of claims lag, claims from the same time period could end up being adjudicated differently if Benefit Rules or Benefit Definitions are modified.) If Benefit Rules or Benefit Definitions need to be changed, the users should consider creating new versions with different names."
  • How a definition is assigned to a claim line (User Guide ch. 6): "Benefit Definitions are assigned to each claim detail line, not to an entire claim." The search is scoped and ordered: "Only those benefit definitions which are assigned to rules included in the package for which the claim line applies will be searched. The system will search through those benefit definitions in rule type order. The system will assign the first definition it matches if the definition belongs to a hold or exclusion rule. If it is unable to find a matching benefit definition from the hold and exclusion rules, then it will search all the remaining rules to see if it can find a single definition. If it matches more than one definition, the claim will be held" for an examiner to resolve — and to fix the overlapping definitions in the package.
  • Manual override protocol (User Guide ch. 6) — a general system behavior worth knowing when reading any nightly-generated field: "The system will skip the logic for assigning Benefit Definitions when a Benefit Definition is already present and was entered by a user. (If a user deletes a Benefit Definition, from a claim detail line, the system will re-calculate Benefit Definition for that detail line at night. Deletions are not considered user assignations.)" The mechanism is a message on the claim: "When the user manually sets a field, the system will record an informational message attached to the claim/claim line, which will indicate to the background process to ignore automatic assignment. To re-institute a system generation for the field, the user should delete the contents of the field."

bensupport — plan support screens​

bensupport/w_codes_maint / w_code_selection — Code table maintenance​

  • Purpose: maintain rows of the generic codes table (d_codes_maint, d_code_key_maint, d_code_key_selection) — the source for BENRULE, PKGLOGIC, PERIOD, PLANPERIOD, PERDAY, PRICELOGIC, ENROLL, CONTACT, ROUNDTYP, VALSAVED, MBRCOVAPP, MBRCATAPP and similar code keys used across this domain.

bensupport/w_procedure_code_maint / w_diagnosis_code_maint / w_proc_code_display / w_diag_code_display​

  • Purpose: maintain and look up procedure and diagnosis codes (d_procedure_codes, d_diagnosis_codes, display windows resolve a typed code to its description).

bensupport/w_create_proc_group / w_proc_group_selection — Procedure groups​

  • Purpose: create/edit named procedure code groups (procedure_groups + procedure_code_groups; d_proc_groups, d_proc_cd_groups, d_proc_groups_edit) referenced by benefit-definition criteria (GRP-43).
  • Why groups exist (User Guide ch. 6): "Procedure groups are created to simplify selecting procedures for Benefit Definitions… Without procedure groups, users would have to individually list all procedures separately for each benefit definition." Worked example: "you could set up a procedure group for immunizations called IMMUN, which would consist of the procedure codes of type CPT in the range between 90700 and 90749 or the codes of type HCPCS that begin with the letter 'J'. If the claim satisfied either the CPT or HCPCS specifications, then that criterion would be considered as part of that procedure group."
  • Hard validation rule (User Guide ch. 6): "Code groups can not have code ranges that overlap, such that a code may not exist in more than one code group."
  • Code types (User Guide ch. 6): "Procedure types include CPT, HCPCS, NDC, ASA, ADA, and Custom. Currently, there is only one diagnosis type, ICD-9."
  • Ongoing maintenance obligation (User Guide ch. 6): "When electronic updates are received for CPT codes (for example) someone will always need to ensure that new codes are assigned to an appropriate Procedure Code Group so that they can be referenced in Plan Maintenance."

bensupport/w_create_diag_group / w_diag_group_selection — Diagnosis groups​

  • Purpose: same pattern for diagnosis groups (diagnosis_groups, diagnosis_code_groups).

bensupport/w_create_second_opinion / w_second_opinion_selection — Second-opinion lists​

  • Purpose: maintain second-opinion procedure lists (d_second_opinion over second_opinion_lists: penalty %, penalty max, penalize-all flag; d_so_cd_groups for member codes). Attached to packages.
  • What the list means (User Guide ch. 6): "Second Opinion Lists and Procedures are a list of procedures, which require a second opinion and the penalty if a second opinion is not gotten." The penalize-all flag chooses whether the penalty hits the surgical procedure only or all related charges. Second opinions are identified on incoming claims by CPT4 codes 99271–99275 or arrival on a Second Surgical Opinion form (User Guide ch. 12).
  • Rule interaction (User Guide ch. 6): the corresponding benefit-rule switch is three-state — "Y = yes, run rule. N = no, do not run rule, blank indicates to always run the rule regardless of second opinion." A known unresolved gap: related charges such as lab work cannot be tied back to the second opinion, and the guide records that "This problem will not be resolved in the initial delivery of the system."

bensupport/w_create_tooth_group / w_plan_required_teeth / w_plan_required_surfaces​

  • Purpose: dental support — tooth-type groups (d_tooth_types, d_tooth_type_edit, d_tooth_numbers) and the procedure codes that require tooth (d_plan_required_teeth) or surface (d_plan_required_surfaces) identification.

  • Reference data (User Guide ch. 6): "Tooth Types and Tooth Code Numbers identify individual teeth that can be grouped into a set, such as molars and bicuspids." Quadrants are "Upper Right: Tooth 1–8; Upper Left: Tooth 9–16; Lower Left: Tooth 17–24; Lower Right: Tooth 25–32", and "Bridges will always be discussed in terms of ranges of teeth". Surfaces are Medial, Distal, Occlusal, Buccal, Incisal and Lingual. Extra teeth must be representable: "Extra teeth may exist for certain people. These are called Supernumerary teeth. The system must be able to store information regarding these 'extra' teeth."

  • Why required-teeth and required-surfaces lists exist (User Guide ch. 6): dental frequency rules are evaluated per tooth and per surface — for example filling codes are monitored for frequency "by tooth number and surface", sealants by tooth number, and osseous surgery "by tooth or quadrant" — so the claim cannot be adjudicated unless those identifiers were captured for the procedures that need them.

  • Dental frequency defaults (User Guide ch. 6): chapter 6's "Dental Processing Rules" section names the procedure-code ranges that must be monitored for frequency, the axis each is monitored on, and — for several — a default interval to use when the plan does not state one. "Length of time can be expressed two ways: By plan year / By prior 'X' number of years, months, weeks, days, etc." Where the guide gives a default it is written below in bold; the remainder are monitored "plan by plan" with no default supplied.

    Service (ADA codes)Monitored byDefault interval
    Exams (00120, 00150)number of times / length of time, plan by plannone given
    Full-mouth x-rays (00210, 00330)number of times / length of time, plan by plannone given
    Bitewing x-rays (00270, 00274)number of times / length of time, plan by plannone given
    Prophy and fluorides (01110, 01120, 01203–01205)number of times / length of time, plan by plannone given
    Sealant (01315)tooth numbernone given
    Fillings (02110–02387)tooth number and surfacenone given — "If prior filling before 'X' number of months, second filling is OK"
    Inlay / onlay (02510–02664)tooth number5 years
    Crowns (02710–02810)tooth number5 years
    Labial veneers (02960–02962)tooth number5 years
    Bridges (06210–06792)tooth numberonce every 5 years
    Osseous surgery (04260)tooth number or quadrant6 months
    Rebase / reline, dentures and partials (05710–05761)tooth number, or plan by plan6 months
    Perio scaling (04341)tooth number or quadrantnone given
    Dentures (05110–05140)ranges of tooth numbersnone given
    Permanent partial dentures (05211–05281)tooth number / ranges of tooth numbersnone given

    Chapter 6 also specifies several cross-procedure history checks that are not frequency limits but share the same lookback machinery: a crown claim must be checked for a prior temporary crown (02970) and, if found, "flag claim for examiner to check amount to reduce allowable by"; permanent partial dentures must be checked for prior temporary partials (05810–05821) and the permanent reduced "by the amount previously allowed and paid for the partial"; once a tooth has been extracted (07110–07241) "then only Pontics (06210–06252), Partials, and dentures (05110–05281) are allowed", and conversely pontics, partials and dentures "are only allowed if a tooth was previously extracted"; and a root canal (03310–03330) on a tooth that already had one generates a warning. Ortho services (08010–08999) "are typically paid off over time rather than all at once" and need cumulative-total-paid and periodic-payment accumulators — "currently this is all done manually". Implementation status: documented-only, and the generic machinery behind it is suspect. None of these ADA code ranges, and none of the default intervals, appear anywhere in the extracted source — a search for the literal codes (02510, 02710, 02960, 04260, 05710, 06210, 01315, 02110) returns nothing, and the only hits for "crown", "inlay", "veneer", "osseous" and "reline" are static label text on the dental claim-entry and print forms (clmentry/d_claims_dental_infoa, clmprint/d_claim_print_sfpi_dental). Dental frequency is therefore expected to be configured by hand as ordinary Claimed Limit benefit rules — a procedure group, a rule period type and a period length — using the tooth-type groups and the required-teeth / required-surfaces lists maintained on these screens. Two code findings qualify that expectation and both matter for migration:

    • Frequency accumulation by tooth is not a supported rule setting. clmsproc/n_claim_adjudication carries a hard-coded workaround keyed on a magic benefit-definition id: "this is a temporary work around until rule can denote accumulations by tooth. The presence of benefit def -110 denotes that accumulation is by tooth". Every guide row above that is monitored "by tooth number" depends on this hack, and anything monitored by surface or by quadrant has no mechanism at all.
    • A maintainer's comment in the same object, dated 2008, states that "it is believed that none of the frequency rules are working". Treat every frequency-based dental limit as unverified behaviour to be confirmed with an SME rather than as working logic to be reproduced.

bensupport/w_carryover_rule_maint — Carryover rules​

  • Purpose: maintain carryover rules (d_carryover_rules_maint): code, description, carryover percent, period length + type, and "Deductible Satisfied" flag (rule_fulfillment_flg).
  • What carryover does (User Guide ch. 6): "Carryover describes how allowed amounts from prior periods apply to current periods by member and by family… For example, if a deductible rule has carryover, claims falling into the Carryover period apply to deductible in both the current deductible period and the next deductible period." The carryover period is "the portion of a previous period in which the allowed amounts are of interest", and on the rule editor "The default value will be 'NONE'."

bensupport/w_level_sched_maint / w_level_sched_selection — Coverage level schedules​

  • Purpose: maintain coverage-level schedules (d_level_scheds + d_level_scheds_items). Item formula per coverage level: Flat Amount + (Member Category × Multiplier), optionally Rounded (dddw_rounding_rules) and Step-Rated (dddw_step_rates_w_null) — the labels in d_level_scheds_items spell out the formula.
  • Why the formula exists (User Guide ch. 6): "Level Schedules and Level Schedule Items allow for customizable values based upon benefit coverage level (single, family, etc.). Values may be based upon a flat amount, or member category values such as salary. Values may also then be step-rated." The salary case is the common one — the guide notes that deductible and coinsurance levels are "sometimes… based on things, such as salary, rather than a flat amount. (Member Cat Values)". A schedule is selected from a rule's Details tab wherever a single per-individual or per-family amount will not do.

bensupport/w_step_rate_maint / w_step_rate_selection — Step-rate schedules​

  • Purpose: maintain step-rate schedules (d_step_rate_scheds) and their bands (d_step_rate_items: From / Thru / Rate).
  • What the bands do (User Guide ch. 6): "Step Rate Schedules and Step Rate Items allow for a table of value conversion ranges. For example, if amount between 1000 and 2000, then use 10; If amount between 2001 and 3000, then use 20." They convert a computed value (typically a salary-derived amount from a coverage level schedule) into the value actually used.

bensupport/w_rounding_rule_maint — Rounding rules​

  • Purpose: maintain rounding rules (d_rounding_rule_maint): code, description, direction, significance.

bensupport/w_reason_code_maint — Reason codes​

  • Purpose: maintain reason codes (d_reason_code_maint over reason_codes): code, type, description, narrative, legend code, CAS code. Reason codes double as adjudication accumulators (type ACCUM) and per-rule-type denial/processing reasons (see rule editor filtering).
  • Description versus narrative (User Guide ch. 6) — the distinction matters because one of them is customer-facing: "The 'description' column is a short cryptic for our own reference, while the 'narrative' is what will actually print on the EOB or RA." Type examples given: "100%=Flex reimbursement rules, Paid=1 million lifetime max, or Deductible=calendar year". The guide warns that "great care should be taken when creating new reason codes", and that accumulator codes in particular dictate "which custom accumulator will be used for this particular rule's limit".

bensupport/w_plan_analysis_by_group — Plan analysis reports​

  • Purpose: report all rules (d_plan_rpt_group_rule_analysis) or accumulators (d_plan_rpt_group_acm_analysis) effective for a group, expanding the group subtree to leaf groups and joining group_coverages → plan_pkgs → pkg_rules → benefit_rules → reason_codes — the canonical adjudication join.
  • Opens: w_group_response_selection.

bensupport/w_plan_find_pkgs — Find packages​

  • Purpose: locate packages by contained rule/definition (d_find_packages).

bensupport/w_convert_plan — Convert Plans​

  • Purpose: reassign selected group coverages to a new plan code via stored procedure sfpidba.new_group_coverages, one commit per row, with status text ("=====COMPLETED====="). Uses d_group_coverages, d_group_coverage_selection, and a plan picker (d_benefit_coverage_cd style over benefit_plans).

bensupport/w_load_proc_diag_codes — Load Proc / Diag Codes​

  • Purpose: bulk-load procedure and diagnosis code files (d_load_procedure_codes, d_load_diagnosis_codes; helper u_load_procedure_codes).

bensupport/w_um_cm_serv_proc_cd_maint — UM/CM service procedure codes​

  • Purpose: maintain the procedure-code mapping used by UM/CM services (d_um_cm_serv_proc_cd_maint; dddws dddw_benefit_defs_cm_serv, dddw_proc_cd_cm_serv).
  • What the list is for (User Guide ch. 6): the guide documents this as an exclusion list — "Add procedure codes to the list of codes to ignore no matter what in the internal CM system" — scoped by benefit definition as well as procedure code and type, which matches the screen's benefit-definition dropdown. Context: case-management alerts fire when an HCPCS code, an ICD-9 code or a benefit definition in the CM codes table appears with a claimed amount over a threshold, and "Which set of CM rules to employ will be assigned to each Benefit Package during Plan Design."

bensupport/w_wang_map — Legacy Wang rule mapping​

  • Purpose: maintain mappings from the predecessor (Wang) system's rules to HOMER rules (d_updt_wang_rule_map, d_updt_wang_group_rule_map, d_wang_group_list over wang_rule_map / wang_group_rule_map). Migration-relevance: historical cross-reference only.

bensupport/w_response_save_as_string — Save As prompt​

  • Purpose: ancestor response window prompting for a string value (used by plan / package / rule / definition "Save As" flows).