Screen Catalog — pricing and moon libraries

What repricing is, and where these screens sit

Repricing is "the process for determining an 'Allowed Amount' for each detail line on a claim, except for certain types of pricing methods in which an entire claim is priced together (Whole Claim pricing)". The boundary against plan design is stated crisply and is worth keeping in front of anyone reading this catalog: "Generally speaking, Pricing Methods tell what is allowable while Benefit Rules tell what is payable from the amount allowable. Also, a Pricing Method is (usually) for a single procedure on each occurrence while a Benefit Rule is for a set of benefit definitions over a period of time." (User Guide ch. 12)

The three-level object model these screens edit maps to the guide's own vocabulary (User Guide ch. 12): a Pricing Plan "identifies a set of Pricing Methods… described in terms of the level at which it is defined: Package, HCN, Contract, Panel, or UR/CM"; a Pricing Method is a "distinct scheme employed to assign prices either to a whole claim, or to detail lines on a claim"; a Pricing Method Rule holds the "selection criteria for deciding when to apply a pricing method"; and the Pricing Formulas are "the actual mathematical formulas used by Pricing Rules in each Pricing Method… The result of Pricing Formulas will be the Allowed Amount."

Which pricing plan a claim uses (User Guide ch. 12) — the resolution order behind the level field: if a UR/CM record exists for the patient for that date and procedure and pricing has been specified, use it; otherwise check the Package; if the package indicates HCN pricing, "first look for pricing at the Panel, then at the Contract, and finally at the HCN. Use the first pricing found. (If none found the system must generate an error.)"; if the package indicates package pricing, use that. Auditability is a requirement, not a nicety: "The system must retain the level that the claim line was priced at, the pricing method that was used, and the sub-level of the pricing method that was used with each claim for historical purposes."

Global rules that override anything configured on these screens (User Guide ch. 12): the Overall Pricing Rule — "If the calculated allowed amount is greater than the billed amount, use the billed amount as the allowed amount" (it does not apply to the whole-claim methods Per Diem, Case Rate and DRG); definite duplicates skip pricing entirely and are priced at zero during adjudication pre-processing; a zero billed amount is accepted as zero; and some claim types are always 100% — "WDI, Dependent Care, HCR, and any claim where Medicare is primary". Member liability follows the contract: "Members are not liable for this difference only when the provider of service has a contract with a network in the Plan of Benefits that states that they are not liable. In all other instances, the members are liable."

Pricing library

w_pricing_plan_maintenance — "Pricing Plan Maintenance"

Purpose: maintain pricing plans, their dated methods, and each method's ordered rules with match criteria (pricing/w_pricing_plan_maintenance, PBExportComments "This window maintains a list of pricing plans").

Layout / field groups:

• Plan name search box (typing a new name + New creates a plan via all_purpose_seq.nextval; name must be ≥2 characters).
• Methods grid (d_pricing_plan_methods over pricing_methods joined to valid_methods): sequence, method, pricing type (WHOLE/DETAIL, display-only from valid_methods), from/thru dates, detail indicator Y/N, rollover indicator Y/N, EOB description (allowed_reason → reason codes), savings type (dddw_pricing_plan_savings_types), default DRG multiplier, default DRG cap rate.
• Rules grid (d_pricing_plan_rules, filtered to selected method) and rule editor strip (d_pricing_plan_rule_edit): description, Rule Type (Base/Inlier/Outlier), Inpatient/Outpatient (In/Out/Both), anesthesia-lines indicator (Yes/No/Both), per-diem amount + Per Diem Type (Day/Case), day from/thru, case rate amount, allow %, apply-allow-% code (dddw_pricing_apply_pct), allow additional amount, "Force Repriced Amt" (replace-with-claimed) Y/N, benefit def, Pricing Schedule button.
• Criteria tab strip: Syntax (read-only rendering of the composed criterion, "All lines" when empty), Procedure codes (per code type or Group), Diagnosis codes (per type/Group), DRG codes, Revenue codes, LOS, Specialties, POS codes — each with IN / BETWEEN / EQUAL TO operators and a NOT checkbox (wf_encode / wf_decode).

Behaviors / validations: method dates and required EOB/savings-type checks; PER DIEM whole rules require per-diem amount > 0; changing a method's type deletes its rules after confirmation; schedule button allowed only for FEE/DRG/TIERED PD/UNIT methods and opens w_pricing_schedule_select; methods and rules reorder by drag; save runs plan insert/update plus manual cascade deletes of pricing_rule_procs/pricing_rule_diags/pricing_rules (wf_check_row, dw_rule_edit buttonclicked, pfc_update, pfc_preupdate). Menu m_pricing_plan_maintenance.

Operator setup order (User Guide ch. 12): set up the Pricing Plan (a description; note "Providers may not share Pricing Methods"); describe the methods, giving a level and order when there is more than one; define the Rules for each Method; then define the formulas for each Rule.

Field meanings (User Guide ch. 12):

• Sequence — "Specifies the order that the system should process the methods when looking for the appropriate pricing formula. There cannot be more than one method with the same priority within a pricing plan." Drag-to-reorder is the documented interaction: "The order that methods appear on the screen will be the order that the system processes the methods."
• Pricing type WHOLE / DETAIL — Line pricing applies "to each claim line independently"; whole-claim pricing prices "all claim detail lines together (Composite)" and "is only required for Per Diem, Case Rate, and DRG methods". A plan may use both, and the ordering is fixed: "Line rules always run before whole claim rules."
• From / thru dates — pricing works off incurred dates, and "The Adjudication process will put claims in error if there are overlapping pricing plan periods."
• Detail indicator — "provides the ability to direct the system to either print or exclude detail line data on EOB/RA. (This is only allowed when Whole Claim Pricing has been selected.)"
• EOB description / allowed reason — mandatory, free-form, and self-extending: "Allowed Reason is a free form field to allow the user to control what gets printed on EOB/RA… If a reason not in the list is entered, the system should query the user whether it should be added. If yes, the system should automatically add the reason."
• Default DRG multiplier and DRG cap rate — these are contract-level inputs to the DRG formula ("CAP Rate and Hospital Multiplier must be entered into the Pricing Tables at the Contract Level. Each must be date ranged"), and they are needed even by non-DRG rules: "Some inlier/outlier tests will use components of reimbursement methods that are not part of the basic pricing rule being used. For example: Pricing rule is percent billed, but inlier/outlier checks against a DRG amount."
• Rule Type Base / Inlier / Outlier — "Whole claim pricing needs a rule type to handle inliers and outliers… Whole claim pricing will run base rules, then inliers, and then outliers." An inlier is where "a claim's Base Allowed Amount, Billed Amount, or length of stay is less than an amount defined in the client's service contract"; an outlier is the same test with more than. Sequencing: "Always obtain the Base Allowed Amount, then check for inliers and outliers."
• Inpatient / Outpatient / Both — "The system will have identified whether claim detail lines are inpatient or outpatient during Claims Entry background processing." Whole-claim methods default to inpatient and "Users will not be able to change from inpatient."
• Per Diem Type Day/Case — "Indicates if the Per Diem Rate is per day or per case. (This will always be D for normal Per Diem, but may be C for Tiered Per Diem.)" Formula: day rate multiplies amount by number of days; case rate uses the amount flat.
• Apply-allow-% code (before / after) — the distinction is consequential and is given verbatim: "Before directs the system to take the % against the calculated amount, compare the result to the amount billed and then use the lesser of the two amounts as the allowed amount. After directs the system to compare the calculated amount to the billed amount and then take the % against the lesser of the two and use that as the allowed amount."
• Anesthesia-lines indicator — anesthesia lines are identified by "modifiers 47 or 23; type of service code 7; provider specialty CRNA or ANES; procedure code type ASA; or procedure codes flagged anesthesia in the Procedure Code table".
• Benefit def on a whole-claim rule — used to build the synthetic line: "The system must generate an additional claim detail line containing the entire repriced amount for the claim. This is done to set up for adjudication." The guide annotates this as not actually implemented at the time of writing.

Criteria semantics (User Guide ch. 12) — this explains the IN / BETWEEN / EQUAL TO plus NOT controls: "Use SQL notation for defining selection criteria. Assume logical ANDs across selection criteria with logical ORs across pricing rules." Constraints: "DRG selection criteria may be entered for either whole claim or line based pricing"; "LOS selection criteria is only applicable for whole claim pricing and then only for inlier/outlier rules."

Failure and overlap behavior (User Guide ch. 12): "If something does not fall into a Pricing Rule, then the system will price at 0% and generate an error message indicating that additional Pricing Method information may be required. The message must also indicate which pricing level was used." And overlap is the plan-builder's problem: "Formulas may overlap in terms of selection criteria… If this occurs the pricing rules should be further refined. The system will not be set up to detect when this has occurred."

Fields with no chapter-12 counterpart: POS codes as a criterion, savings type, and the rollover indicator are not documented in chapters 7 or 12 and appear to postdate them; the allow additional amount field matches a stated future enhancement ("Add the ability to use an additional amount field. Example: MDR 90th percentile + 25 dollars"). Treat all four as needing SME confirmation.

Scope limit worth flagging for migration (User Guide ch. 12): HOMER stores inlier/outlier detection only. "Inlier/Outlier worksheets will not be a part of the Homer system. These may either be a series of Excel spreadsheets or paper worksheets. Homer will only contain rules for determining if inliers/outliers are present, not how to process inliers/outliers… the examiners will have to perform that manually."

Windows opened: w_pricing_schedule_select, w_pricing_plan_maintenance_select (plan pick list).

w_pricing_plan_maintenance_single — single-plan selector/editor

Purpose: response variant that maintains/selects a single pricing plan; opened from HCN/panel/contract pricing tabs with the current plan key and returns the selected plan key (pricing/w_pricing_plan_maintenance_single; caller e.g. provider/w_provider_hcn_maintenance dw_pricing buttonclicked).

w_pricing_fee_schedule (+ w_pricing_fee_schedule_select) — "Fee Schedule Maintenance"

Purpose: maintain named fee schedules (fee_schedules / fee_schedule_details) (pricing/w_pricing_fee_schedule).

Fields: schedule name search/create; detail rows: procedure code + type, modifier, specialty, state, zip, effective/expiration dates, fee amount; filter controls for code/date range.

Validations: effective date and fee amount required; expiration after effective; procedure code must exist in procedure_codes for the type.

Business definition and arithmetic (User Guide ch. 12): "A Fee Schedule is a Pricing Method that assigns a flat allowed amount to each procedure… The result of the fee schedule processing will always be multiplied by the number of units specified on the claim detail line." A "% to allow" (default 100%) is then applied.

Lookup precedence — the operative matching rule (User Guide ch. 12): "When searching Fee Schedules first look for complete matches on all criteria: Procedure code (most important), Modifier, Zip Code, Provider Specialty (least important). If no matches look for entries in table with nulls. There will be many of rows in the table with nulls." This is why most columns on a detail row are optional — null is a deliberate wildcard, not missing data.

Which zip (User Guide ch. 12): "the Zip code of the location where the service was performed (Block 32 on a HCFA-1500)… Note that if Block 32 is blank, the ZIP code of the provider (block 33) is used in its place." Zip use is switchable per benefit plan package.

w_pricing_conversion_schedule (+ w_pricing_conversion_schedule_select) — "Conversion Factor Schedule Maintenance"

Purpose: maintain conversion factor schedules (conversion_factors / conversion_factor_details): per procedure-code range and optional zip, dated multipliers Base / Time / Work / Practice / Malpractice (pricing/w_pricing_conversion_schedule, d_pricing_conversion_schedule). Start/end procedure codes validated against procedure_codes.

w_pricing_unit_schedule (+ w_pricing_unit_schedule_select) — unit schedule maintenance

Purpose: maintain unit schedules (unit_schedules / unit_schedule_details): per procedure code (+ type, modifier, zip, dates) units Base / Time / Work / Practice / Malpractice; schedule carries a unit type (dddw_pricing_unit_schedule_type, e.g. RBRVS) (pricing/w_pricing_unit_schedule, d_pricing_unit_schedule).

Unit type (User Guide ch. 12): the two documented types are McGraw Hill and RBRVS. The Practice, Work and Malpractice buckets are RBRVS-only ("For Provider Units, RBRVS only", "For Work Units done, RBRVS only", "For malpractice Units, RBRVS only"); Base and Time apply to both.

Why this schedule carries procedure code and zip (User Guide ch. 12): MDR pricing originally lived with fee schedules because it varies by procedure and zip, and was moved: "as of 3/22/99, We have decided that MDR must be included in Unit Based. To support this procedure codes and zip codes have been added to the unit tables."

Unit definitions come from plan design (User Guide ch. 12): "We will get the Unit definitions from Plan Design: Anesthesia, Home Health Care, Observation, Mental and Nervous/Substance Abuse."

w_pricing_drg_schedule (+ w_pricing_drg_schedule_select) — "DRG Weight Maintenance"

Purpose: maintain DRG weight schedules (drg_weights / drg_weight_details): DRG code (validated against drg_codes), weight, from/thru dates (pricing/w_pricing_drg_schedule).

How the weight is used (User Guide ch. 12), verbatim: "Use DRG code as of a time frame to look up a DRG WEIGHT value. Multiply DRG WEIGHT by a HOSPITAL MULTIPLIER to get a number. Add the Hospital specific CAP Rate to the number to get the BASE DRG amount. Apply inlier and outlier provisions to get the allowed amount." Both the multiplier and the cap rate come from the contract level, not from this schedule.

Rules (User Guide ch. 12): "Only providers of the type Hospital will use DRG codes"; "Any DRG based pricing that results in a zero allowed amount must be flagged as an error on the claim"; "(Note that inpatient and outpatient claims are processed separately.)"

Where DRG codes come from (User Guide ch. 12): "Some of our clients will give us DRG codes on the claim, others will require us to run DRG 'groupers' against the claim data to obtain a DRG code. There are several distinct groupers available. Our system will need the ability to define if a grouper is needed, and which grouper should be used. Groupers are applied during Adjudication." Chapter 7 adds the maintenance cadence: "Do not forget that the DRGs are date ranged and must be updated once a year" — renewal is documented as happening each July.

w_pricing_per_diem_schedule (+ w_pricing_per_diem_schedule_select) — "Tiered Per Diem Schedule Maintenance"

Purpose: maintain tiered per-diem schedules (tiered_per_diem_schedules / tiered_per_diem_details): day bands (days from/thru) with per-diem amount and type, dated (pricing/w_pricing_per_diem_schedule).

Why only tiered per diem has a schedule (User Guide ch. 12): plain per diem "will have the rates specified in the actual formulas cited by the pricing Rules" — only the tiered variant needs a day-band table.

Business meaning (User Guide ch. 12): "Per Diem varies depending on where you are in the hospital and the length of stay… Use where you are in the hospital (revenue codes and diagnostic procedure codes) and which number day of a stay to look up a per day flat amount which is all inclusive of charges on a claim." Within a band, Day type applies the amount for each day; Case type applies "one amount for all days in the range".

Validation (User Guide ch. 12): "Day ranges across a single Per Diem Tiered Schedule may not overlap", in addition to the global rule that no date ranges may overlap for any pricing schedule.

How length of stay is derived (User Guide ch. 12) — easy to get wrong and worth stating explicitly: "LOS is calculated as the total of units on all detail lines falling into whole claim pricing where the procedure code is in the Room and Board procedure code group", and "Remember that the number of days is days reported minus one. In other words if you are in the hospital for three calendar days, we do not count the last day (discharge day) as part of the stay." Because several lines may fall into one whole-claim rule, "LOS cannot be used as selection criteria for determining the appropriate whole claim rule"; the guide directs plan builders to use an inlier/outlier rule to raise a review message instead.

w_pricing_schedule_select — schedule pick list

Purpose: given a method (FEE/DRG/TIERED PD/UNIT) select the matching schedule; returns the schedule sys key stored in pricing_rules.schedule_sys_key (pricing/w_pricing_schedule_select; name resolution pricing/f_pricing_schedule_name).

Global schedule rules (User Guide ch. 12): a schedule is identified by a unique name; all schedules are date-ranged with no overlapping ranges; and — in contrast to pricing rules, which the guide says cannot be shared across networks — "All Pricing Schedules may be shared by any Pricing Rules." Only Fee Schedule, DRG, Unit Based and Tiered Per Diem methods use schedules: "Case Rate, Per Diem and % Billed Pricing Methods will not require schedules", which is exactly the gate the code applies on the Pricing Schedule button.

w_pricing_lookup_ucr — "Lookup UCR" unit-price calculator

Purpose: interactive UCR price check: pick a conversion schedule, enter procedure code + type, modifiers, zip, service dates, units and anesthesia minutes; computes price = units × Σ(multiplier × unit) with anesthesia units 1 + ⌊min/15⌋ and an RBRVS master-multiplier gate; "Could not determine price" when any component is missing (pricing/w_pricing_lookup_ucr ue_retrieve). Menu m_pricing_lookup_ucr.

The formulas this screen evaluates (User Guide ch. 12):

• Generic unit method — "Use procedure codes/modifiers as of a time period to look up a UNIT VALUE. Use zip code where the procedure was performed as of a time period to look up a MULTIPLIER. ALLOWED AMOUNT = UNIT VALUE * MULTIPLIER." MDR is the same, except the multiplier is retrieved by zip and procedure grouping.
• Base/time form — "(Base Units × Base Conversion Factor) + (Time Units × Time Conversion Factor)"; "Unless the claim is for anesthesia, the time conversion factor will always be zero."
• Anesthesia — base units come from the procedure and modifier, a time-units value is computed from the length of time anesthesia was administered, and the multiplier is found by zip, procedure grouping and provider: "ALLOWED AMOUNT = (BASE UNITS * BASE MULTIPLIER) + (TIME UNITS * TIME MULTIPLIER)". Physical-status modifiers add base units before the multiplier: "P3 adds 1 unit, P4 adds 2 units, P5 adds 3 units." The guide explicitly rejects the legacy Wang high/low averaging method.
• RBRVS, verbatim — "RBRVS # = MASTER MULTIPLIER * ((PRACTICE BASE * PRACTICE MULTIPLIER) + (WORK BASE * WORK MULTIPLIER) + (MALPRACTICE BASE * MALPRACTICE MULTIPLIER)). ALLOWED AMOUNT = RBRVS# * a percentage."

The code's anesthesia unit rule of 1 + ⌊minutes/15⌋ is not stated in the guide, which says only "Based upon the length of time that anesthesia was administered, compute a TIME UNITS VALUE" — the 15-minute increment needs SME confirmation, as does whether the physical-status add-on (P3/P4/P5) is applied anywhere in the code.

w_pricing_rbrvs — "RBRVS multiplier maintenance"

Purpose: maintain dated master multipliers per unit type (master_multipliers: unit type, multiplier, from/thru) consumed by RBRVS unit pricing (pricing/w_pricing_rbrvs, d_pricing_rbrvs; consumer pricing/w_pricing_lookup_ucr reads rbrvs_master_multipliers — see Open questions on the table-name pair). Menu m_pricing_rbrvs.

w_pricing_rbrvs — note on the master multiplier

(User Guide ch. 12) The RBRVS schedule the guide describes is deliberately minimal — From Date, To Date and "Multiplier – Standard multiplier" — because it holds the single master multiplier that scales the summed practice/work/malpractice products (see the RBRVS formula above). The guide adds that "Each procedure code in the RBRVS table will need a type of service code associated with it."

Modifier, E&M, multiple-surgery and operative-note detail

Chapter 12 spends more space on procedure-code modifiers than on any other pricing topic, because modifiers change the allowed amount before and after the pricing formulas run. The summary requirements live on the providers index as PRV-58 (modifier dispositions), PRV-59 (E&M ↔ surgery association), PRV-60 (multiple surgeries), PRV-61 (operative notes) and PRV-62 (anesthesia identification and holds); the detail tables below belong with the screens, because every one of them is a rule the replacement pricing configuration will have to express somewhere. General rules: "Adjustment for Modifiers is required when repricing based on medical procedures"; "Modifiers indicating Pay Separately are exempt from any special pricing rules, just price normally"; and "if a modifier is inappropriate for the procedure code on a claim detail line then the system should ignore the modifier" (User Guide ch. 12).

Implementation status for this entire section — documented-only, and structurally so. In the extracted client a modifier is only ever (a) a lookup key into a schedule — fee_schedule_details.modifier and unit_schedule_details.modifier are key columns on d_pricing_fee_schedule and d_pricing_unit_schedule, and w_pricing_lookup_ucr matches a modifier row then falls back to a null-modifier row (PRV-37); or (b) a benefit-definition match criterion in adjudication — clmsproc/n_claim_adjudication reads the user-entered modifier_criterion string and evaluates it through of_ValidCodeDef("MODIFIER", …), which decides which benefit definition applies, not what the line is allowed. No branch on any specific modifier value exists anywhere in the extracted source, and the structural reason is decisive: pricing_rules has no modifier column. Its criterion set is inpatient/outpatient, procedure group, diagnosis group, specialty, DRG, revenue, LOS and place of service (pricing/d_pricing_plan_rules) — a pricing rule literally cannot be conditioned on a modifier. Note also that conversion_factor_details carries no modifier column at all, so conversion factors are keyed on procedure-code range, type and zip only. Caveat on the strength of this negative: the client contains no claim-pricing engine. The pipeline stages are Corrections, Code Review, Pre-Adjudication, Dup Check, Pricing (RFPR), Adjudication, Payment Allocation, Audit, Funding (clmutils/w_bkgd_monitor), and the Pricing stage runs server-side in Oracle and is not in this extract — n_claim_adjudication simply consumes an already-populated allowed_amt. So for the modifier arithmetic below, "not implemented in the client" cannot rule out an implementation in database stored procedures. For E&M and multiple surgery the negative is stronger, because the columns that would have to drive them do not exist at schema level either. There is also a manual escape hatch: claims/w_claim_lines_remove_modifiers ("Change/Remove Claim Modifiers") lets a user edit a line's modifiers and puts the claim back on HOLD.

CPT modifier dispositions

Disposition	Modifiers	Pricing effect (User Guide ch. 12)
Hold for review by examiners	22, 32, 51, 54, 55, 56, 62, 99	Unusual procedural services (22), mandated services (32), multiple procedures (51), surgical care only (54), postoperative management (55), preoperative management (56), two surgeons (62), multiple modifiers (99)
Pay separately	(list is empty in the guide)	The chapter prints the heading "Pay Separately" with no modifiers under it — the category is named and relied on ("Modifiers indicating Pay Separately are exempt from any special pricing rules") but never populated. Open item for SME confirmation.
Surgery uplift	20	Add 20% to the allowed amount
Surgery uplift	50	Add 50% to the allowed amount
Assistant surgeon	80	Validate 80 against a table of valid modifiers. If not valid, set the allowed amount to zero with a specific reason code. If valid, look for other lines carrying any surgery code on the same date across any claim without an 80: if a previous claim carried an 80, hold the new claim; otherwise allow 20% of the allowable amount
Skip same-day-surgery hold and E&M rules	58, 59, 76, 77, 78, 79	Do not hold same-day surgery, and ignore the E&M rules below
Suppress duplicate processing	76, 77, 78, 79	"indicate to ignore dupe rule processing for any claim"
Technical / professional split	26	Split the UCR amount between technical and professional components using a table of percentages keyed on procedure code. MDR tables carry no modifiers, so MDR's separate non-electronic guidelines are what that table encodes
Anesthesia identification	47, 23	Marks the line as anesthesia — see PRV-62 and the physical-status add-ons (P3 +1 unit, P4 +2, P5 +3) already noted under Lookup UCR above
Operative notes required	66	Surgical team — triggers the operative-notes requirement below

The surgery uplift, assistant-surgeon and same-day rows apply specifically "For detail lines with procedure codes in the surgery procedure group". Separately, a *'d procedure code causes the E&M rule to be skipped; the guide notes "We will need to add actual entries to the procedure code table with asterisks to validate these codes. We do not have these electronically at this time."

HCPCS National Level II modifiers

Modifier	Effect (User Guide ch. 12)
AH	Indicates provider specialty Psychology — check it agrees with the provider's specialty in the provider table
AJ	Indicates provider specialty MSW, LSW or LCSW — same agreement check
AS	Pay 13% of the allowed amount for that procedure code (listed separately as "Apply a second percentage against the procedure")
CC	Hold for review
EM	Hold for review
LL	Hold for review
QK	Hold for review
QR	Pay separately
SG	Hold for review
TC	Affects the fee schedule

For MDR tables that do not use modifiers, "we will be ignoring the modifiers on the claims".

Evaluation and Management (E&M) association with surgery

E&M repricing is a cross-claim rule: an E&M service that belongs to a surgery's global period is not paid on top of the surgery, it is paid out of the surgery's remaining allowance. The search runs in both directions — when an E&M claim arrives the system looks for an associated surgical claim, and when a surgical claim arrives it looks for a matching E&M claim. Only claims already out of adjudication are considered. A line carrying modifier 24, 25, 57, 76, 77, 78 or 79, or a *'d procedure code, is exempt from matching entirely.

Surgical category (a procedure code group)	Match window relative to the E&M (User Guide ch. 12)
Minor, 0 days follow-up	Service-from dates must match exactly
Minor, 10 days follow-up	Surgical claim is at most 10 days before the E&M
Major	Surgical claim is at most 90 days before the E&M, or on the date of the E&M

Two further conditions: "The system must keep looking for all possible matches. We cannot stop after the first match is found"; and a candidate is only a match if the diagnosis codes agree — "If either primary or secondary diagnostic codes are in a common Major diagnosis group, then we have a match." The arithmetic is then: take the maximum amount allowable for the surgery (saved when the surgery was priced) and the amount actually allowed, find all other related E&M claims, and "subtract the total of the amounts that we did allow from the maximum allowable amount for the surgery to get the amount allowable for this new E&M claim".

Implementation status: documented-only. No E&M concept exists in the extracted source under any spelling, there is no global-period or follow-up-window logic, and no 0/10/90-day constants. Major diagnosis group matching exists only as the generic, data-driven diag_group_criterion evaluated by of_ValidCodeDef('DIAG_CD', …) — nothing E&M-specific is built on it.

Multiple surgeries on one claim

There is no multiple-surgery percentage ladder in HOMER, and the guide does not define one. This is worth stating plainly because the industry-standard expectation is a 100% / 50% / 25% sequence for the first, second and third procedure, and a replacement team would otherwise assume one is present and simply undocumented. Chapter 12 describes the rationale for reducing subsequent surgeries — "the allowed amount for surgeries generally includes an allowance for the time and effort spent to open and close the required incision… it is assumed that only one incision was required and therefore the allowances for the surgeries after the first on a claim are adjusted (usually downward)" — and then declines to automate it: "the system should process all claim detail lines according to normal pricing logic. The system must then message the appropriate examiner to review the surgery claim detail lines and manually re-price them. The system must generate a message to the examiner and hold the claim." The chapter even questions its own design at that point ("Why wouldn't we handle this in claims entry?"). The percentages chapter 12 does define are only the modifier-driven ones already tabulated above — modifier 20 (+20%), modifier 50 (+50%), modifier 80 assistant surgeon (20% of the allowable amount), and HCPCS AS (13%). None of these is a multiple-surgery sequence.

What the chapter does specify precisely is detection and exemption:

• Detection: "A claim has multiple surgeries when more than one detail line has a procedure code falling into the Surgery procedure code group without a type of service code of 7." (Type of service 7 is anesthesia, which is excluded from the count.)
• Exemption: lines whose procedure codes fall into the Diagnostic, Fracture Care, Breast Biopsy or Moh's Micrographic procedure code groups "are exempt from multiple surgery special processing".
• The reduction "may not be true based on either the presence of certain modifiers or certain procedure code groups" — which is what the exemption groups and the modifier table encode.

Implementation status: documented-only. No multiple-surgery logic, no exemption-group names and no per-surgery reduction percentages appear in the extracted source. Procedure-code groups are entirely data-driven (of_ValidCodeDef('PROC_GROUP_CD', …) against d_adjd_proc_groups), so the four exemption groups above could only ever exist as rows in the procedure-group tables, never as code — check the database for groups by those names. The only surgery-related objects in the client are the unrelated Second Surgical Opinion claim form (clmentry/u_claims_tab_sso) and its surgery_recommended_ind field.

Operative notes

Operative notes are required when (User Guide ch. 12)	Detail
Code Review recommends it	"Code Review recommends that Operative Notes be requested"
The procedure exceeds UCR by more than 25%	and the claim is not part of an HCN benefit package
The procedure code is an "unlisted" CPT code	Roughly seventy codes enumerated in the chapter: 15999 (excision pressure ulcer), 17999 (skin, mucous membrane, subcutaneous tissue), 19499 (breast), 20999 (musculoskeletal general), 21299, 21499, 21899, 22899, 22999, 23929, 24999, 25999, 26989, 27299, 27599, 27899, 28899, 29799, 29909, 30999, 31299, 31599, 31899, 32999, 33999, 36299, 37799, 38999, 39499, 39599, 40799, 40899, 41599, 41899, 42299, 42699, 42999, 43499, 43999, 44799, 44899, 45999, 46999, 47399, 47999 and onward
Modifier 66 is present	Surgical team

Behaviour: "If operative notes are required but not present, the system must generate a hold message 'Review for Operative Notes'." The system records only whether notes are present — set at claims entry if they arrived with the claim, or later at manual adjudication when they turn up — and the user is responsible for telling it so. Critically, "The system will not act upon the contents of the Operative Notes, since the information has not been entered into the system. Examiners will have to manually act upon the contents"; and "Claims with Operative Notes cannot be adjudicated automatically, so the system must generate an error message indicating that the examiner must review the claim."

Implementation status: the flag exists, the behaviour does not. claim_entries.operative_notes_ind is a live, user-editable checkbox ("Oper. Notes:") present on every claim-entry form variant (clmentry/d_claim_entries_common and its per-form siblings), and it is passed through to the outbound EDI record (clmutils/u_edi_outbound_edi). But nothing reads it to raise a hold, generate a message, block automatic adjudication or change pricing — no "Review for Operative Notes" message exists in the source, and neither do the 25%-over-UCR test or the unlisted-code list. Two request letters exist as manually selected print forms (clmforms/d_claims_frm_request_op_report_from_ee, …_from_pvdr); they are not driven by the indicator.

Pre-pricing (potential allowed amount)

Chapter 12 requires a pre-pricing step that runs before any pricing formula: "There are cases where the presence or absence of Procedure Code Modifiers indicate that a 'Potential Allowed Amount' be substituted for the Billed Amount used by Pricing Formulas." The worked example is line combining: "$250 office visit along with a $400 surgery without a modifier. The system must be able to price the office visit at zero and consider the surgery as being $650 and then apply a percentage if necessary before going into the Pricing Method. If the modifier were present on the surgery detail line, then each detail line would have been priced normally." Two consequences the chapter draws: a zero billed amount (or zero potential allowed amount) means no pricing logic runs and zero is accepted; and "for all of these 'special' Pre-Pricing Rules, the system will need to provide Y/N switches at the Benefit Plan Package level to allow certain Packages to skip the pre-processing. The system should default all of these switches to Y." The chapter is openly unfinished here, asking of its own rule "What exactly determines this? How would you know to combine the lines in the following example?" and, of the overall pricing rule, "When there's no modifier, pre-allowed amount = original billed amount?" — so this is specification-in-progress, not settled behaviour.

Implementation status: documented-only. No pre-allowed or potential-allowed column exists anywhere in the schema — the allowed-amount columns are allowed_amt, allowed_after_copay_amt, allowed_after_ded_amt, allowed_after_coi_amt, total_allow_amt and grand_total_allow_amt, with no "pre" or "potential" variant — and no package-level skip switches were found in benplans, pricing or clmsproc. The distinct Pre-Adjudication stage that does exist (of_ProcessClaimDef, claim status RFPA) assigns benefit definitions, not prices, and runs before the separate Pricing stage; do not mistake one for the other. Note that pricing_rules.apply_allow_pct_cd (Before/After, PRV-46) defaults to BEFORE in w_pricing_plan_maintenance and is read by no client code — it too is consumed server-side.

MOON library

Coverage caveat: neither chapter 12 (Repricing Rules) nor chapter 7 (Provider Maintenance) names MOON. The guide documents the problem space these screens address — out-of-network pricing, outside-entity repricing, repricing sheets and follow-up on outstanding pricing requests — so the notes below are matched by function and should be confirmed with an SME. Bill status codes (MOONSTATUS), negotiator, PPOs, submitter and the MOON claim id have no counterpart in either chapter and appear to postdate them.

w_moon_claims — "MOON Claims"

Purpose: the negotiation work queue over moon_negotiations (moon/w_moon_claims).

Field groups (d_moon_negs grid): Claim Id, Group Id, Provider, Specialty, Provider Phone, Orig Claim Amt, Date to MOON (bill_dt), Bill Status (MOONSTATUS codes, filter list d_moon_keys), Negotiator, Negotiated Amt, Discount Amt, Percentage (computed display), Information, PPO's (ppo_field), MOON Claim (bill_claim_id), Examiner, Date to Examiner, Submitter.

Why an OON negotiation queue exists at all (User Guide ch. 12): "When an outside entity performs the repricing for our claims, we will not send them claims for repricing that we have determined to be OON. We will apply the OON pricing methods. This means that all clients using an HCN must define an OON package holding the pricing methods for us to use in this case." Out-of-network claims are therefore SFPI's own problem to price or negotiate.

Date-to-MOON and date-to-examiner aging (User Guide ch. 12): the guide's requirement for tracking outstanding pricing work is "The system should provide the ability to monitor claims that have been waiting for repricing responses from an HCN", with a per-HCN parameter for "how long to wait before following up on outstanding pricing requests… Default 30 days, but allow users to override", automatic reminders to the HCN's designated pricing contact, and a fallback: "If the system cannot locate a pricing contact, then the examiner must be messaged so that they can manually contact the HCN."

Negotiated rates and case management (User Guide ch. 12): "Case Management also needs to have the ability to set Pricing Methods. (Such as renegotiated rates.)" — but bounded: "Case management cannot be allowed to reprice all claims. Each HCN may dictate whether repricing may be done. Case Management must honor that dictate." This is the likely business origin of the OON product's "Override CM Neg. Rates" and "Override All CM" switches, though the guide does not name those fields.

Validations / behaviors: claim must exist and not already be in negotiations; auto-fill of examiner/amount/group/provider/specialty/phone on claim-id entry; submitter stamped by department (BACKGROUND/EXAMINER/NURSE); status defaults PENDING with today's bill date; outcome columns editable only by UM/MIS; examiner assignment stamps sent-to-examiner date; queue filter by claim id or selected bill statuses (saved per user in the ini "MOON PREFS"); print via d_moon_negs_rpt; double-click locks and opens the claim editor (w_claim_editor) through the claim-control service. Can also be opened programmatically with a claim id to silently enqueue a claim (moon/w_moon_claims open event). Menu m_moon_claims.

w_moon_oon_product_maintenance (+ w_moon_oon_product_select) — "OON Products"

Purpose: maintain out-of-network negotiation products (moon/w_moon_oon_product_maintenance, PBExportComments "Main window for Moon product maintenance").

Field groups: product header (d_moon_oon_products: Product, Description, Comments); purchasing groups (d_moon_oon_product_groups: group + name, from/thru dates — captioned "The following groups have purchased the above product for the types of claims listed below."); HCN exclusions (d_moon_oon_product_hcn_exclusions: HCN, from/thru dates); claim types (d_moon_product_claim_types: Claim Type, from/thru, Minimum Claimed $, Threshold Claimed $, Allowance Days, Pay By Days, Retention Days, Override All CM, Override CM Neg. Rates, Override Manual Price).

Validations: product id + description required; group and HCN rows require assignment + valid dates with no overlapping ranges per group/HCN; claim-type rows require claim type, valid minimum and threshold amounts, and override CM / override rates values; hard delete with confirmation. Menu m_moon_oon_product_maintenance.

w_moon_in_repricing — inbound EDI repricing review

Purpose: "Review responses to outbound EDI requests for repricing" (moon/w_moon_in_repricing PBExportComments) over edi_in_repricing.

Fields (d_moon_in_repricing): Claim Id, Claim Line, Procedure Code, From Date, Claimed Amount, Line Pricing Amount, Whole Claim Pricing Amt, Reject Code, Trading Partner, Processed Indicator, Processed Date.

Behaviors: filter by claim id, trading partner (d_edi_trading_partner_search / dropdown, "All" wildcard), Active (processed_ind='N') vs Complete radio, and processed date (added for the automation process); warns when one claim has lines in both Active and Complete statuses; rows editable and saved back (library CRUD on edi_in_repricing). Menu m_moon_in_reprice_menu.

How repricing responses are handled (User Guide ch. 12): a repricing sheet is itself a claim — "All claims, including repricing responses, must be initiated in Claims Entry and images must be scanned and stored. The Automated Adjudication function will decide how to handle repricing responses during the process of identifying duplicate claims." Two rules bear directly on the line-versus-whole-claim columns on this screen:

• Line allocation — "If the reprice sheet only had a single total repriced amount for the entire claim, the system will have used the reprice percentage entered to calculate a repriced amount for each detail line using the claimed amount for each detail line during claims entry background processing."
• Whole-claim detection and its error cases — for a UB92 reprice sheet where all extended amounts are zero or null, no percentage is entered, and a per-diem or DRG number is present, "use whole claim pricing". If an extended amount or a percentage is present and a per-diem or DRG number is present, raise "Conflicting pricing information". If nothing is repriced at all, raise "missing repricing information".

Related checks the guide requires (User Guide ch. 12): "When a repricing sheet comes in, Adjudication will need to check the number of days versus the calculated figure based upon the date ranges entered. If the calculated value is different by more than one day from the days entered, flag the claim as an error for the examiner. (the claim may need to be split)"; "We will not perform interim claim processing for repricing sheets"; and "The source of the claim: HCN, Provider, Etc. implies whether repricing should occur. It is crucial that this is done properly during Claims Entry."

The network-membership reconciliation behind rejected sheets (User Guide ch. 7): when a sheet was repriced but the provider is not in-network in HOMER, the error routes to the Provider department to add the provider and establish the network affiliation; when "we consider a provider in network, but the HCN does not", the claim is marked "Waiting for a repricing sheet" so adjudication holds it while the HCN is asked to add the provider and resend; when the provider is genuinely out of network, the HCN is notified to remove it.

w_moon_provider_list — "MOON Provider List"

Purpose: read-only distinct list of providers/phones that have appeared in negotiations (moon/w_moon_provider_list, d_moon_neg_providers: distinct provider_name, phone_no, created date from moon_negotiations).

Claim-side companion screens (other libraries, for reference)

• claims/w_claim_line_pricing_rules — "Enter Pricing Information": popup from the claim editor to record a line's savings type, savings amount and reason into claim_line_pricing_rules (PBExportComments "Pop up Window used in the Claims editor to record manually entered pricing data").
• claims/w_convert_to_reprice_form — "Convert To Reprice Form": converts a non-repricing claim form to a repricing form.
• clmentry/u_claims_tab_ub92_reprice_in / ..._out / generic / HCFA variants — claim-entry tabs for repricing sheets; reprice info page (dw over claims_reprice_info) requires repriced amount + discount pct unless out-of-network / member-not-on-file (see PRV-38).
• clmutils/w_edi_outbound_edi_processor — "Outbound edi main window": builds and cuts outbound repricing EDI files from the outbound_edi_* staging tables.