Utilization Management & Case Management

Libraries: um_main (search, follow-up, shared lookups — 16 windows), um_ur (the four utilization-review case workspaces — 4 windows), um_cm (case management, CM potentials, CM time billing — 6 windows), um_maint (reference data and vendor extracts — 14 windows). Together: 40 windows, 138 DataWindows. Closely coupled logic also lives in clmsproc/n_claim_adjudication (applying UM cases to claims), claims/w_add_claim_to_internal_cm (attaching a claim line to a CM case), clmshare/n_cst_return_claim_to_corrections (backing a claim out of a case) and homersys/m_sys_frame (all launch points).

Purpose

• Record utilization-review events — admission notifications, authorizations, pre/post-occurrence certifications and referrals — as UM cases for a member, each with one or more services, per-service authorization rules (units and date ranges approved), diagnosis/procedure coding, physicians, provider and hospital contacts (um_ur/w_um_pre_certification, um_ur/w_um_authorization, um_ur/w_um_admission_notification, um_ur/w_um_referral).
• Run case management cases with the same structure plus CM involvements, claim-to-case linkage, benefit-definition scoping, claim hold rules and automatic time (billing) capture (um_cm/w_um_case_management).
• Identify CM candidates: UR nurses flag "CM potentials" from any UR case, and claim-generated potentials arrive from the claims side; a work queue supports resolving each potential into a CM case or "No Case" (um_cm/w_um_cm_potentials_report, um_cm/w_cm_potential_resolution).
• Feed claims adjudication: benefit-plan rules keyed on authorization/pre-certification/pre-admission/referral indicators select different benefit terms depending on whether a matching UM case exists (this is where missed-precertification penalty benefits are applied), and open CM services consume approved units / accumulate savings as claims pay (clmsproc/n_claim_adjudication, clmsproc/d_adj_open_service).
• Maintain UM reference data: UR/CM firms ("entities") and their warnings, medical directors, CM trigger code sets, and extracts of enrollment/claims data for external disease-management and CM vendors (um_maint/*).

Actors

• UR nurses — create and work admission notifications, authorizations, certifications, referrals; assigned automatically as case manager from the nurse assignment table (user_info joined to user_assignments, where user_info.control_cd = 'NURSE' and benefit_coverage_type_cd = 'UM', matched to the patient's last-name range and group — um_ur/w_um_pre_certification ue_open).
• Case managers — work CM cases; their session time on each case is captured automatically for billing (um_cm/w_um_case_management wf_start_billing / wf_stop_billing).
• UR/CM Manager — a security grouping (USER_DEPT_GROUP dept 'UM', group name "UR/CM Manager") that unlocks manager-only rule fields (exceed plan limits, exceed lifetime max, apply excess units to stop-loss) and lets billing review see all users' time records (um_ur/w_um_pre_certification ue_postopen, ue_set_secure_fields; um_cm/w_cm_billing wf_retrieve).
• UM department users (gnv_app.inv_DeptGroups.of_IsDeptUser('UM')) — get case notes and have their CM time typed "Billable"; non-UM users' time is "Non-Bill" (um_cm/w_um_case_management wf_determine_time_type).
• Medical directors — physicians recorded in medical_directors who perform rule-level reviews/appeals (um_maint/w_medical_director_maintenance, um_main/w_medical_director_review).
• External CM/DM vendors — receive enrollment and claims extracts (um_maint/w_matria_*, w_hcrm_*, w_springbuk_*, w_dm_enrollment_dump).
• Claims examiners — per the user guide they have read-only access to all UM and CM records except notes, and are the people who normally add and update Pre-Determination records; the guide directs that they use the same screens as the nurses with HOMER security enforcing the difference. They also close potentials on negative responses (UMC-60) and, for clients where UR is done outside, hold the paper UR forms and review claims against them by hand (User Guide ch. 19).
• Director of UM / CM manager — owns the CM trigger data; sets up entities, warnings and medical directors initially and hands them to Client Maintenance once the data is stable (User Guide ch. 19).

Case categories

A new case starts from the UM search workspace; the type chosen maps to a category code stored in um_cases.um_category_cd and to a maintenance window (um_main/w_um_new_case, um_main/w_um_search pfc_addrow and wf_record_maintenance):

New-case option	Category code	Window
Admission Notification - Pre	Pre-Adm	um_ur/w_um_admission_notification
Admission Notification - Post	Post-Adm	um_ur/w_um_admission_notification
Authorization	Auth	um_ur/w_um_authorization
Certification - Pre-Occurrence	Pre-Cert	um_ur/w_um_pre_certification
Certification - Post-Occurrence	Post-Cert	um_ur/w_um_pre_certification
Referral	Referral	um_ur/w_um_referral
Case Management	CM	um_cm/w_um_case_management
Dental Pre-Determination, Medical Necessity, Medical Pre-Determination	—	radio buttons disabled; "not yet available" (um_main/w_um_new_case, um_main/w_um_search)

Categories themselves are data (um_categories); the status, notification-type, physician-type and service-type code tables are all retrieved per category (um_main/dddw_um_record_statuses filters um_record_statuses by um_category_cd; um_ur/w_um_pre_certification wf_retrieve_dddw).

The user guide defines the four UR activities operationally: an authorization records permission granted by a healthcare network or client for services, regulated by time period, units, maximum dollars, specific provider and PCP applicability; admission notifications are effectively yes/no flags over implied hospital benefit definitions (pre = prior notice of a stay, post = notice after an emergency admission, subject to a plan-specific notification deadline — an "observation" over 24 hours counts as an admission for some plans); referrals record a PCP's permission for treatment by another provider (managed-care networks only); pre/post-occurrence certifications are the non-hospital equivalents of admission notifications. Late or missing notification triggers adjudication penalties (User Guide ch. 19). The guide also fully specifies the three disabled case types — Dental/Medical Pre-Determination ("Pre-Determination of Medical Necessity", entered mostly by claims examiners and never required to pay claims) and Medical Necessity (review of procedure codes flagged for necessity review in Plan Design) — including statuses, claim matching and form letters (User Guide ch. 19); they were designed but not implemented in the extracted client (see Open questions).

Status & disposition vocabularies (User Guide ch. 19)

The guide records the intended per-category status lists. The production um_record_statuses table remains authoritative — the code-relevant values ServOpen/Serv… (UMC-29, UMC-32) are later additions that do not appear in the guide:

Category	Case statuses per the guide
Admission Notification, Pre-Certification, Authorization	Open, Closed, Consult, Pending, Future Admit, Holding Referred to Medical Director, Holding For Appeal, Void (the 12/1999 training copy trims this to Open, Closed, Consult "not using at present", Pending, Future Admission)
Referral	Open, Closed, Consult, Pending, Holding Referred to Medical Director, Holding For Appeal, Void
Pre-Determination / Medical Necessity	Approved, Rejected, Pending, Holding Referred to Medical Director, Holding For Appeal, Void
Case Management	Open, Consult, Closed — Consult selectable only on a new record

Void means the case was opened in error and must never be billed. The guide's admission-notification dispositions: Discharge Planning in Progress (the default — consistent with the code default DC Plan, UMC-6), Expired, Follow-Up with Specialist, Home, Home Health Care, Hospice, Office, Outpatient Chemical Dependency, Outpatient Mental Nervous, Outpatient Skilled Therapy, and Transfer to Acute Care / Long Term Care / Skilled Nursing Facility / Inpatient Acute Rehabilitation. Service and procedure resolutions are Approved / Denied / Unknown; review types are Medical Director, Independent Review and their Appeal variants (reviewer list filtered by director type); review outcomes are Approval, Denial, Partial Approval, Administrative Approval, Independent Review; appealers are Member, Provider, Employer, Other; sample admission notification types are Transfer, Emergent/Urgent, Doctor Direct, Scheduled, and sample admission service types are Maternity, Mental Nervous, Alcohol/Substance Abuse, Acute Rehab, Transplant, Acute Inpatient (User Guide ch. 19).

Key workflows

Intake → review → determination (UR case types)

1. Find the member. UM Search (um_main/w_um_search) searches by last name / SSN / member id / group id or directly by notification (case) number (wf_urcm_search_notification), enforcing per-group user security (security_user_class_user). It loads the family list, demographics, group info, examiner, confidential contact, stop-loss carrier, and the member's UM case history (um_main/d_um_record_list), and pops the warnings window (member-inactive, per-plan-package UR/CM firm warnings, "Utilization Review Not Done" / "Case Management Not Done" — um_main/w_um_warning_display).
2. Create the case. "New" opens the case-type chooser (um_main/w_um_new_case) and then the category's workspace. A case number is generated as the first 3 characters of the user id + Julian date (yyyyddd) + a 6-digit sequence (um_ur/w_um_pre_certification dw_case::pfc_new). Defaults: coverage type Medical, disposition DC Plan, late-notification / motor-vehicle-accident / workers-compensation flags N. A newborn or not-yet-enrolled patient can be recorded as an unassigned patient (name/birth date only) and re-assigned to a real member later (unassigned_ind, dw_case::buttonclicked → um_main/w_um_case_patient_select).
3. Record the service. Requested/approved date ranges, notification type, service type, unit type (code table UMSRVCUNIT; the arithmetic supports DAYS, VISITS, HOURS, MONTHS), requested/approved/used unit totals, servicing and referring providers (provider search), hospital contacts, diagnosis codes and procedure codes with validation against the master code tables (um_ur/w_um_pre_certification service tab). Pre-certifications and admission notifications allow exactly one service; authorizations, referrals and CM cases support multiple services with page navigation (w_um_pre_certification dw_service::pfc_new "Only one Service may be created for a Pre-Certification"; w_um_authorization dw_service::pfc_new uses rownum paging).
4. Authorize units (rules). Each service carries numbered rules (um_rules): date range, min/max units approved, units requested/used, optional alternate pricing (list price, purchase price, amount toward purchase, link to a pricing plan via w_pricing_plan_maintenance_single), hard/soft savings. The rule thru date is auto-derived from the from date and max units by unit type unless the date-override flag is set (w_um_pre_certification dw_rule_info::itemchanged). Service totals and estimated last day in hospital / next follow-up date are recomputed from the rules (dw_service::ue_afteritemchanged).
5. Medical director review. Any rule can accumulate reviews (um_medical_reviews): review type, appealer type, request/response dates, medical director, and outcome from um_review_outcomes (um_main/w_medical_director_review). The determination of the case overall is carried by the per-category status code (um_record_status_cd) and disposition (um_case_dispositions), both mandatory at save (w_um_pre_certification dw_case::ue_validate).
6. Save & lock. Saving validates every pane, writes all panes in one transaction, then (re)locks the case (ue_save). Cases use a database lock latch (um_cases.lock_seq_no + lock_user_id/lock_dt); opening a case locked by someone else is refused with the holder's name and time (um_main/u_urcm_sql of_lock_case / of_unlock_case).
7. Follow-up. The follow-up worklist lists open, non-referral cases in the user's group hierarchy ordered by next follow-up date; double-click opens the case in its category window (um_main/w_um_follow_up, um_main/d_um_follow_up: um_record_status_cd <> 'Closed' and not like 'Serv%'). For admission-type services the nurse confirms discharge (confirmed by Hospital / Insured or Family / Doctor's Office / Outside Case Mgt) and the actual days stayed are computed from admission to discharge date (um_ur/d_um_an_service value list; w_um_admission_notification dw_service::ue_afteritemchanged).

Operational context from the user guide: nurses field the initial call, and for inpatient stays approve an initial length of stay plus extensions against published clinical criteria (M&R / InterQual in the design draft, HCIA in the 1999 training copy — the criteria_guideline_units field was reserved to hold the criteria-derived units). Rule #1 on a service represents the initial length-of-stay / initial quantity line and every later rule is an extension; nurses deliberately stack multiple rules with distinct date ranges to set up tiered per-diem pricing. UR records other than authorizations are not owned by a specific nurse — the next available nurse works them. Admission-notification follow-up practice: the requested-from date is the admit date, the requested-through date is the requested discharge date (not the actual one); the follow-up date defaults to the day after the estimated last covered day and is entered manually only for retroactive reviews or when unauthorized days surround authorized days (then set two days after the last rule through date); "follow-up done" is set only after all dates are accounted for and the member is discharged (User Guide ch. 19).

What case management is for (User Guide ch. 18, ch. 19)

The guide's working definition: case management is the determination of a course of treatment that will preserve a member's benefits, with cost effectiveness and specification of providers as possible components. Nurses look at every potential case; where CM will not help they say so and close it, and where it will they work with the providers, the patient, the employer, the stop-loss carrier and the health plan — negotiating rates and, when it benefits both the patient and the plan, allowing items outside the plan to be covered. Most of the time they work inside the plan's framework. Case management is therefore the one UM activity that can both generate UM records allowing or denying services and set pricing rules, which is why it alone reaches into the Pricing module.

Three things trigger case management: a UR incident showing CM is appropriate (the best source, because it catches the member early in treatment); a member calling for verification of benefits, or an examiner forwarding a claim they think CM could help; or a claim arriving that the system's diagnosis/procedure trigger lists flag — by which point CM has often already been done elsewhere. UR is not a precondition: "sometimes we will not have done UR for a claim but CM is still called for." Whether CM is done at all, and by whom, is defined at the benefit-package level — the same place the UR firm is named.

CM is performed by Medillume III (SFPI — internal, in this system), a health-care network (in this system, ours or leased, or on the network's own software), an outside CM service, or the stop-loss carrier; the guide names Safeco and Prohealth as the only two outside entities doing their own CM, and notes that results from all of them have to be tracked for adjudication regardless of who produced them. Chapter 18 adds the claims-side integration requirement that claims examiners need to see CM notes, specifically negotiations, with a more flexible retrieval method than was available at the time; conversely nurses need access to examiners' notes (pre-determination reviews, pre-existing-condition and subrogation determinations), and the UR/CM screens are expected to carry current examiner initials and extensions so callers can be referred without digging through the client book. Patient notes are to have limited access for confidentiality — see UMC-57.

Two open design questions are recorded in chapter 18 and never answered there: whether denial or pend letters are generated from the system at all and from whose system when the issue is UR or CM (see Open questions 4), and a "Preferred Suppliers' File" that is listed as a chapter topic but never described (see Open questions 12).

The rest of chapter 18 is a 1995–96 wishlist of work requests against the legacy system, not a specification of HOMER. Most of it was answered by the design this module implements — a past-due follow-up report (the follow-up worklist), a weekly Case Management Alert report (whose rules became the CM trigger sets), and user-deletable CM charges (the CM Billing window). Four items have no counterpart anywhere in the extracted client and are recorded here only so they are not mistaken for lost functionality: fax management, a split-screen telephone log with timer alongside a provider/price list and electronic file, a Savings Log report, and a caseload report by sales rep. The chapter also reports a legacy defect — patients dropping off the company and stop-loss logs once their follow-up date passed — which the shipped management report avoids by selecting on case date overlap rather than follow-up date (User Guide ch. 18).

Case management identification → case lifecycle

1. Identification. A CM potential (cm_potentials) is created either (a) by a UR nurse from inside any UR case via the "Create Potential CM" button — the CM firm is resolved from the member's Medical plan package (plan_pkgs.cm_firm_sys_key; refused with "There is no CM Firm associated to the Plan Package" if none), and the row is stamped entity_generator_cd = 'UR', status_cd = 'Normal', procedure_status_cd = 'Proposed' (um_ur/w_um_pre_certification cb_cm_potential::clicked, um_cm/w_um_cm_potential_create); or (b) from the claims side with entity_generator_cd = 'Claim' and generator_link = claim_id (consumed by um_cm/w_um_cm_potentials_report). Per the user guide the claim-side producer is the nightly claims batch: for clients whose plan package requires CM it first tries to match the claim to existing CM cases, then to medical-necessity data, and finally evaluates the CM entity's trigger set — HCPCS codes, ICD-9 codes and benefit definitions each with a network-affiliation scope, a claimed-dollar threshold and an inpatient/outpatient scope, plus "a UR record indicating CM exists" — and on a hit writes a claim message to the nurses and the cm_potentials row, once per claim detail line, always with status Normal (a developer note places the trigger evaluation in the Audit step rather than Adjudication proper) (User Guide ch. 19). The Oracle code implementing this still needs to be recovered — see Open questions.
2. Work queue. The CM Potentials report filters by CM company, group, member, create-date range, resolution (CaseOpened / No Case / Unresolved = null), status (code table CMPOTNTLST) and generator (UR vs Claim) (um_cm/w_um_cm_potentials_report ue_retrieve). From a row the user can open the generating UR case or claim, resolve the potential (um_cm/w_cm_potential_resolution — hard-coded choices CaseOpened, No Case, Unresolved), or create a CM case.
3. Case opened. Creating a CM case from a potential opens um_cm/w_um_case_management with category CM; on first save the potential is automatically resolved: cm_case_sys_key set to the new case, resolution_cd = 'CaseOpened', resolution user/date stamped (UPDATE of cm_potentials in um_cm/w_um_case_management, keyed by the potential passed in from the report).
4. CM case content. Same case/service/rules/reviews structure as UR cases, plus: CM involvements checklist per case (cm_case_involvements ↔ cm_involvements), per-service benefit-definition scoping (um_benefit_definitions), claim hold rules (below), and multiple services.
5. Time capture. Opening a CM case starts a timer; closing it (or switching cases) writes a cm_billing record with elapsed minutes, the case status at the time, and a billing type: Consult when the case status is CONSULT, otherwise Billable for UM-department users and Non-Bill for others (um_cm/w_um_case_management wf_create_billing_record, wf_determine_time_type). The CM Billing window reports internal/external detail and summary views and lets managers mark records billed (um_cm/w_cm_billing, code tables UMTIMETYPE, UMBILLSTTS).
6. Claims linkage. Adjudication attaches paying claim lines to open CM services (below); rows land in um_case_mgt_claims.

Potential lifecycle rules from the user guide: potentials may never be created free-hand or deleted from the work queue — only claim adjudication and the UM maintenance screens create them, guaranteeing a valid claim id or UM record key in every row. A claim-generated potential and its claim message close each other — closing either closes the other, and the claim message auto-closes when a nurse creates the UM/CM record that removes the trigger condition. UR-generated potentials must be closed manually (there is no claim to close them), and closing one is supposed to update the status field of the generating UM record. The status field is a delivery priority (Urgent / Priority / Normal — claim-generated rows always start Normal, users may change it at any time); the procedure status (Proposed / Done) is manually maintained by users; "total claims paid to date for this and related diagnoses" is manually entered, usually by claim examiners rather than nurses. A person must be assigned to chase outstanding, unanswered potentials (User Guide ch. 19). The guide also anticipates a third generator value Examiner (potential raised directly by a claims examiner) — only UR and Claim are observed in the extracted code (see discrepancies in Open questions).

Claims-to-case application (um_case_mgt_claims)

• During adjudication, a claim line is matched to an open CM service: category CM, case status ServOpen, case/service date ranges covering the line, the line's benefit definition in the service's um_benefit_definitions, and the line's procedure or diagnosis codes present among the service's UM codes (clmsproc/d_adj_open_service). Matched lines are written to um_case_mgt_claims (case, service, rule, claim id/seq, dates, units, payable amount) and the matched rule's units_used (unit-based rules) or soft_savings (dollar-based rules where units_requested is 0/null) is incremented; re-adjudication first backs the claim's prior contribution out (clmsproc/n_claim_adjudication service-commit logic around the d_adj_um_cm_mgt_service / d_adj_um_rules_service datastores).
• A claim line can also be attached manually by case number (claims/w_add_claim_to_internal_cm): it validates the claim line, finds an open service (warning of similar services in a ±2-month window otherwise — clmsproc/d_adj_similar_services), inserts the um_case_mgt_claims row, logs a claim message, and can recalculate a case's rule usage from scratch by cursor over its um_case_mgt_claims rows.
• Returning a claim to corrections deletes its um_case_mgt_claims rows and reverses the rule usage (clmshare/n_cst_return_claim_to_corrections).

Interaction with benefit rules (missed pre-cert penalties)

Benefit-plan package rules carry four nullable indicators — auth_indicator, pre_certification_indicator, pre_admission_indicator, referral_indicator. During adjudication each candidate benefit rule is skipped unless the claim's linkage to UM cases (claim_line_um_rules, retrieved by clmsproc/d_adjd_claim_line_um_rules, matched by um_category_cd — 'Auth', 'Pre-Cert'/'Post-Cert', 'Pre-Adm'/'Post-Adm', 'Referral') agrees with the indicator (clmsproc/n_claim_adjudication, "Check UM Indicators" block). A plan can therefore define a richer benefit rule that applies only when pre-certification exists and a penalty rule that applies when it does not; the UM module's job is to make the case exist and be linked.

The user guide documents the intended switch semantics: each setting is tri-state — Y (a valid UM record must exist for the rule to execute), N (a valid record must not exist), blank (always run the rule) — and for every rule with switches set the plan defines what happens when no matching record is found: deny the claim line for reason "failed UR"; approve and continue under an override benefit package within the same plan (the penalty tier, with optional "allowances overrule plan limits" and "pay violations of plan limits as ineligible" flags); or hold the claim for an examiner and raise a potential. Package ordering resolves the circularity that UR needs benefit definitions but may itself change the package: packages are browsed in a client-defined order, the lowest-ranked serving as the out-of-network/basic package, and once UR is checked it is not re-checked after a package switch (User Guide ch. 19). The guide models only three switches (Authorization, Admission Notification/Pre-Certification combined, Referral — the latter two mutually exclusive within a rule, and "requires both auth and referral" satisfied by either) whereas the code checks four independent indicators (auth/pre_certification/pre_admission/referral) — the code's four-way model governs; the guide's pairing rules are a discrepancy for SME confirmation.

The case header additionally carries case-level benefit-term fields (apply_to_adjudication_ind, deductible, coinsurance pct/limit, lifetime and yearly maximums — um_ur/d_um_pc_case). The user guide resolves both: the deductible / coinsurance / maximums / CC block is pre-determination form letter content ("Predetermination Letter Information"), manually entered because the provider (and hence the real package terms) is unknown when the call is taken, and printed to the subscriber and requesting physician with response_printed_dt stamped at print time; apply_to_adjudication_ind is a CM-case switch — "if no, do not match incoming claims to the Case" — consumed by the batch matcher, not by client code (User Guide ch. 19).

Claim hold rules

CM cases (and admission notifications/authorizations) can define hold rules per service (um_hold_rules): a hold message (um_hold_messages), a claims date range, an always-hold flag (default Y), claimed-amount less-than/greater-than thresholds, and child lists that scope the hold to benefit definitions (um_benefit_holds), diagnosis codes (um_diagnosis_code_holds), procedure codes (um_procedure_code_holds), providers (um_provider_holds) and — on authorizations/admissions — provider specialties (um_specialty_holds) (um_cm/w_um_case_management holds tab, um_main/w_um_hold_rule_child, um_ur/w_um_authorization). Each hold rule must have a hold message (dw_hold_rules::ue_validate). No code in the extracted claims libraries reads these tables at adjudication/entry time — per the user guide they are enforced by the nightly automated adjudication batch: any claim detail line falling into a hold rule with always-hold Y is held for the case managers with a message carrying the user-defined hold reason; the remaining hold rules are still evaluated for the line, then the rest of the automated adjudication logic is bypassed for it, and claims in Hold status stay out of the nightly run until released. Hold rules exist precisely to stop claims that matched a UM case from auto-adjudicating. Entering a CM exclusion-exception benefit definition must auto-create a matching benefit-definition hold (message "held due to a UM Exclusion Exception") so an examiner always reviews those lines (User Guide ch. 19). The batch implementation must still be recovered from the database — see Open questions.

CM negotiated rates (User Guide ch. 19)

The rule-level alternate-pricing fields in the extracted client (list_price, purchase_price, amt_toward_purchase, no_alt_pricing_ind, pricing_plan_sys_key, hard/soft savings) are the data side of a pricing mechanism whose consumer lives in the nightly batch. The guide's rules:

• A UM rule is tied to exactly one pricing plan, and UM pricing may only create a new plan for that rule or update the one already attached — unlike plan pricing, it may not pick an existing plan. A column on the pricing-plan table marks plans created for UM so they are excluded from the plan-pricing selection list. The available methods are % billed, per diem, fee schedule (all provider-by-provider) and "no alternative pricing"; no inliers or outliers are allowed.
• The batch prices all lines with CM negotiated rates first and falls back to standard plan pricing for whatever is left; a line that is part of the case but falls into no pricing rule, or falls only partially into one, messages the claim (update the rule, or split the line), and a line that finds no alternate pricing at all is held unless no_alt_pricing_ind is Y (UMC-44/45/46).
• Only CM cases have pricing — the other categories carry the same rule columns but do not price.
• Nurses deliberately create several rules with adjacent date ranges on one service to express tiered per-diem pricing; that is what the split of min/max units approved is for.
• If CM were not ready at first delivery, the stated fallback was for CM to keep recording negotiated rates as notes and for examiners to price those claims by hand under manual adjudication.

UM rules engine (um_rules) — structure and evaluation

• Structure. One row per authorization line: service_sys_key FK, rule_no (sequential per service, next = max+1), rule_from_dt/rule_thru_dt, units_requested, min_units_approved, max_units_approved, units_used, unit_requested_type_cd (copied from the service; changing the service's unit type rewrites all rules), alternate-pricing fields (list_price, purchase_price, amt_toward_purchase, no_alt_pricing_ind, pricing_plan_sys_key), savings (hard_savings, soft_savings), manager-only flags (exceed_plan_limits_ind, exceed_lifetime_max_ind, apply_excess_units_to_stoploss), date_override_ind, and a derived reviews count (um_ur/d_um_pc_rules, w_um_pre_certification dw_rule_info::pfc_addrow).
• Entry-time evaluation. Rule thru date is derived from units (DAYS/VISITS: from + units − 1; HOURS: from + trunc(units/24); MONTHS: month-relative) unless overridden; totals roll up to the service (total_unit_allowed/used/requested) and drive estimated_last_day_in_hospital (max rule thru + 1) and next_follow_up_dt (+1 more day) (w_um_pre_certification dw_rule_info::itemchanged, dw_service::ue_afteritemchanged).
• Claim-time evaluation. For CM cases, adjudication debits units_used / credits soft_savings per paying claim line (above). For unit ceilings, the attach flow compares line amounts against list_price/units_requested less hard_savings (claims/w_add_claim_to_internal_cm ue_add_to_case).

Data

Table	Role	CRUD (in these libraries)
um_cases	Case header: category, status, disposition, patient/subscriber, overall dates, flags, requestor/notified-by, lock latch, case-level benefit terms, hard/soft savings	C/R/U/D in the five case windows; R in search, follow-up, reports
um_services	Service under a case: requested/approved dates, unit totals, provider, discharge, follow-up	C/R/U/D in case windows
um_rules	Authorization lines per service (see above)	C/R/U/D in case windows; U by adjudication and claim attach
um_medical_reviews	Medical-director reviews per rule	C/R/U/D via w_medical_director_review; cascaded delete with rules
um_physicians	Ordered physician list per case (name, phone, type, specialty)	C/R/U/D in case windows
um_provider_contacts	Hospital/provider contacts per service (Primary/Secondary)	C/R/U/D in case windows
um_diagnosis_codes, um_diagnosis_groups, um_procedure_codes, um_procedure_groups	Clinical coding per service, validated against master diagnosis_codes / procedure tables, with group selection helpers	C/R/U/D in case windows
um_benefit_definitions	Benefit definitions scoped to a service (CM/auth)	C/R/U/D in CM/auth windows; R by adjudication matching
um_hold_rules + um_benefit_holds, um_diagnosis_code_holds, um_procedure_code_holds, um_provider_holds, um_specialty_holds	Claim hold definitions per service	C/R/U/D in CM/auth/admission windows
um_case_mgt_claims	Claim lines applied to CM case services	C/U/D by clmsproc, claims, clmshare; R in case windows
cm_potentials	CM candidate queue (generator UR or Claim, status, resolution)	C via UR windows; U via potentials report/resolution and CM case open; D cascaded on UR case delete (entity_generator_cd = 'UR')
um_cm_possible_case_claim	Claims flagged as possible CM cases (with message seq)	R only (um_main/w_cm_possible_rpt); producer external
cm_billing	CM time records (start, elapsed minutes, type, status-at-time, billed flag)	C/U by CM window timer; R/U in w_cm_billing; D cascaded on case delete
cm_case_involvements / cm_involvements	Involvement checklist per CM case	C/R/U/D in CM window; R in management report
cm_triggers, cm_trigger_diag_codes, cm_trigger_proc_codes	Named trigger sets: diag/proc codes each with network affiliation, dollar threshold, inpatient/outpatient scope	C/R/U/D in um_maint/w_cm_trigger_maintenance
um_entities, um_entity_warnings, um_entity_medical_directors	UR/CM firms (type UR, UR/CM, CM), their warnings and directors	C/R/U/D in um_maint/w_um_entity_maintenance
um_warnings	Warning message catalog	C/R/U/D in um_maint/w_warning_maintenance
medical_directors	Medical director registry	C/R/U/D in um_maint/w_medical_director_maintenance
Code tables: um_categories, um_record_statuses (per category), um_case_dispositions, um_review_types, um_review_outcomes, um_appealer_types, um_notification_types, um_notified_by, um_physician_types, um_service_types, um_hold_messages; codes keys UMSRVCUNIT, CMPOTNTLST, UMTIMETYPE, UMBILLSTTS	Dropdown sources	R (no maintenance windows found in these libraries)

Business rules

ID	Rule	Source
UMC-1	Every UM case belongs to exactly one category (Pre-Adm, Post-Adm, Auth, Pre-Cert, Post-Cert, Referral, CM); the category selects the maintenance window and filters the status, notification-type, physician-type and service-type code lists.	um_main/w_um_search wf_record_maintenance; um_main/dddw_um_record_statuses; um_ur/w_um_pre_certification wf_retrieve_dddw
UMC-2	Case numbers are generated as UPPER(first 3 chars of user id) + Julian date yyyyddd + a 6-digit zero-padded value from the shared Oracle sequence all_purpose_seq; service numbers use the identical scheme and the same sequence.	um_ur/w_um_pre_certification dw_case::pfc_new, dw_service::pfc_new
UMC-3	A case may be edited by only one user at a time. of_lock_case takes logical_lock_seq.nextval and writes it with UPDATE um_cases SET lock_seq_no = :seq WHERE case_sys_key = :key AND lock_seq_no IS NULL — the null test makes the latch atomic; of_unlock_case sets it back to null. On failure the holder's lock_user_id and lock_dt are read back and displayed (defaulting to "Unknown"/today). Note: the client never writes those two audit columns — only lock_seq_no — so they must be populated by a database trigger yet to be recovered.	um_main/u_urcm_sql of_lock_case, of_unlock_case; um_ur/w_um_pre_certification ue_postopen
UMC-4	A user may only search/open members of groups their user class is authorized for, and only work in a client segment they are assigned to.	um_main/w_um_search wf_urcm_search_notification; um_main/u_urcm_sql of_validate_client_segment
UMC-5	A new case cannot be created without a selected member; a patient not yet enrolled may be captured as "unassigned" (name + birth date) and must later be re-assigned to a real member via patient select.	um_main/w_um_search pfc_addrow; um_ur/w_um_pre_certification dw_case::pfc_new, dw_case::buttonclicked
UMC-6	New cases default to coverage type Medical, disposition DC Plan, and N for late-notification, motor-vehicle-accident and workers-compensation flags.	um_ur/w_um_pre_certification dw_case::pfc_new; um_cm/w_um_case_management dw_case::pfc_new
UMC-7	The case manager is auto-assigned by joining user_info to user_assignments on group, user_info.control_cd = 'NURSE' and benefit_coverage_type_cd = 'UM', taking the row whose user_asgn_start_initial–user_asgn_end_initial range contains the patient's last name (the current member's, falling back to um_cases.unassigned_l_name — not the subscriber's); "Unknown" if no assignment matches.	um_ur/w_um_pre_certification ue_open
UMC-8	A case cannot be saved without: category, coverage type, overall from date (year ≠ 0000), disposition, and status; overall from ≤ thru; thru ≤ 12/31/2499.	um_ur/w_um_pre_certification dw_case::ue_validate; identical in um_cm/w_um_case_management
UMC-9	A pre-certification or admission notification has exactly one service — it must exist and cannot be deleted alone; authorizations, referrals and CM cases allow multiple services.	um_ur/w_um_pre_certification dw_service::pfc_new, pfc_deleterow, ue_validate; um_ur/w_um_admission_notification dw_service::pfc_new; um_ur/w_um_authorization dw_service::pfc_new
UMC-10	A service cannot be saved without notification type, service type and unit type; approved from/thru dates are mandatory once any rule exists; approved from ≤ approved thru; approved dates must fall inside the case overall dates.	um_ur/w_um_pre_certification dw_service::ue_validate
UMC-11	An approved-from date after the member's eligibility expiration produces a warning but does not block the save; approved dates with no rules produce a warning but save continues.	um_ur/w_um_pre_certification dw_service::ue_validate
UMC-12	Rules require the service's unit type first; each rule gets the next sequential rule number and inherits the service unit type; changing the service unit type rewrites the unit type and recomputes thru dates on all rules.	um_ur/w_um_pre_certification dw_rule_info::pfc_addrow, dw_service::itemchanged
UMC-13	Unless the rule's date-override flag is set, rule thru date = from date + Max(0, max units − 1) days for DAYS/VISITS, + trunc(units / 24) days for HOURS, and + Max(0, max units − 1) months for MONTHS. Known defect: a second, divergent copy of this derivation in dw_service::itemchanged adds the full unit count with no −1, so the thru date a rule gets depends on which field the user edited last.	um_ur/w_um_pre_certification dw_rule_info::itemchanged (authoritative), dw_service::itemchanged (divergent copy)
UMC-14	Each rule must have a rule number and a from date; rule from ≤ rule thru; rule dates must lie within the service approved dates.	um_ur/w_um_pre_certification dw_rule_info::ue_validate
UMC-15	Service totals (units allowed/used/requested) are the sums over its rules; estimated last day in hospital = latest rule thru + 1 day (or request dates + 1 when no rules); next follow-up date = estimated last day + 1 unless the service date-override flag is set; actual days stayed = discharge date − admission from date.	um_ur/w_um_pre_certification dw_service::ue_afteritemchanged; um_ur/w_um_admission_notification dw_service::ue_afteritemchanged
UMC-16	Only a UR/CM Manager may set a rule's exceed-plan-limits, exceed-lifetime-max, or apply-excess-units-to-stoploss flags (fields are protected for everyone else); all three default N.	um_ur/w_um_pre_certification ue_set_secure_fields, dw_rule_info::pfc_addrow
UMC-17	Deleting a rule deletes its medical-director reviews; deleting a case cascades to physicians, procedure/diagnosis codes and groups, provider contacts, hold rules, benefit definitions, reviews, rules, services, CM billing records and UR-generated CM potentials, in one transaction.	um_ur/w_um_pre_certification dw_rule_info::pfc_deleterow, dw_case::pfc_deleterow
UMC-18	Medical-director reviews record review type, appealer type, request/response dates, director and outcome; review/outcome codes come from um_review_types / um_review_outcomes.	um_main/w_medical_director_review; um_main/dddw_um_review_type, dddw_um_review_outcome
UMC-19	Every physician row requires a specialty and a physician type; physicians are ordered by an auto-incremented order number per case.	um_ur/w_um_pre_certification dw_physician::ue_validate, pfc_addrow
UMC-20	The first hospital contact on a service defaults to type Primary, subsequent ones to Secondary; a contact type is mandatory.	um_ur/w_um_pre_certification dw_hospital_contact_info::pfc_addrow, ue_validate
UMC-21	Diagnosis codes entered on a service are validated against the master diagnosis table; a prefix search window resolves partial codes; unvalidated codes are flagged not-OK.	um_ur/w_um_pre_certification dw_diagnosis_info::buttonclicked/itemchanged; um_main/w_um_diagnosis_cd_select
UMC-22	A servicing provider's network affiliation is derived from provider contracts and the member's plan package as of the service date.	um_main/u_urcm_sql of_get_provider_network
UMC-23	A UR-generated CM potential requires the member's Medical plan package to name a CM firm; the potential is created with generator UR, status Normal, procedure status Proposed, and links back to the generating case.	um_ur/w_um_pre_certification cb_cm_potential::clicked; um_cm/w_um_cm_potential_create; um_main/u_urcm_sql of_get_cm_firm
UMC-24	A CM potential's resolution is one of CaseOpened, No Case, or unresolved (null); creating a CM case from a potential auto-resolves it to CaseOpened and stamps the case link, resolving user and date.	um_cm/w_cm_potential_resolution dw_resolution::constructor; um_cm/w_um_case_management (UPDATE cm_potentials)
UMC-25	CM potentials are queried by generator (UR joins to um_cases via generator_link; Claim joins to claims), company, group, member, create-date range, resolution and status.	um_cm/w_um_cm_potentials_report ue_retrieve
UMC-26	Opening a CM case starts a time clock; leaving it writes a cm_billing record with elapsed minutes, the status at close, and billing type: Consult when the case status is Consult, else Billable for UM-department users and Non-Bill for all others.	um_cm/w_um_case_management wf_start_billing, wf_stop_billing, wf_determine_time_type
UMC-27	Non-manager users may only see their own CM billing records; managers see all; records can be filtered by billed status, time type, member, group (resolved to master group via the group hierarchy), user and date range.	um_cm/w_cm_billing wf_retrieve
UMC-28	Every hold rule needs a hold message; new hold rules default to always-hold Y; hold scope lists (benefit definitions, diagnosis codes, procedure codes, providers, specialties) are edited per hold rule in a child window.	um_cm/w_um_case_management dw_hold_rules::pfc_addrow, ue_validate; um_main/w_um_hold_rule_child
UMC-29	Adjudication applies a claim line to a CM case only when the case is category CM with status ServOpen, the case/service dates cover the line, the line's benefit definition belongs to the service, and the line's proc or diag code matches the service's UM codes; matched usage increments rule units_used, or soft_savings for dollar-based rules (units requested 0/null).	clmsproc/d_adj_open_service; clmsproc/n_claim_adjudication
UMC-30	Re-adjudicating or returning a claim to corrections first reverses that claim's contribution to rule units_used/soft_savings and removes its um_case_mgt_claims rows.	clmsproc/n_claim_adjudication (remove-claim-from-service datastores); clmshare/n_cst_return_claim_to_corrections
UMC-31	Benefit-plan rule selection honors UM indicators: a rule requiring (or forbidding) authorization, pre-certification, pre-admission notification, or referral is skipped unless a claim-line link to a UM case of the matching category exists (or is absent) — enabling penalty benefit tiers for missed pre-certification.	clmsproc/n_claim_adjudication "Check UM Indicators" block; clmsproc/d_adjd_claim_line_um_rules
UMC-32	The follow-up worklist shows cases whose status is not Closed and not a Serv… status, excluding referrals, restricted to the user's group hierarchy, ordered by next follow-up date.	um_main/d_um_follow_up; um_main/w_um_follow_up
UMC-33	Opening a member in UM search always evaluates warnings: member-not-active as of the as-of date; per-plan-package warnings of the assigned UR and CM firms (suppressible per entity); "Utilization Review Not Done" / "Case Management Not Done" when a plan package names no UR/CM firm.	um_main/w_um_warning_display wf_warning_display; um_main/d_warning_master, d_warning_detail; um_maint/w_um_entity_maintenance (suppress_warning_ind)
UMC-34	UM entities are typed UR, UR/CM or CM; entity type, name and warning-suppression flag are mandatory; a CM-type entity must have a CM trigger set assigned.	um_maint/d_um_entity_maintenance (value list); um_maint/w_um_entity_maintenance ue_validate
UMC-35	A CM trigger set is a named list of diagnosis codes and procedure codes, each row optionally scoped by network affiliation, dollar threshold and inpatient/outpatient/all; codes can be copied between the diag and proc tabs.	um_maint/w_cm_trigger_maintenance; um_maint/d_cm_trigger_diag_codes, d_cm_trigger_proc_codes
UMC-36	Internal-CM fee claims are identified by claim ids beginning KUMC; dedicated reports list such claims on the fund register, unpaid, and with open messages.	um_main/d_umclaims_on_fund_register, d_umclaims_unpaid, d_umclaims_open_messages; um_main/w_umclaim_rpts
UMC-37	The "possible CM cases" report lists claims recorded in um_cm_possible_case_claim in a create-date range, with the claim's diagnosis, member and claimed amount.	um_main/d_cm_possible_rpt; um_main/w_cm_possible_rpt
UMC-38	Case notes and member notes are surfaced automatically to UM users on every case open/select (entity types CASE and MEMBER).	um_ur/w_um_pre_certification ue_postopen, dw_case::ue_retrieve; um_main/w_um_search dw_history_record::clicked
UMC-39	Manual claim-to-CM attachment validates the claim line, warns when only similar (±2 months, different benefit definition) open services exist, books the line against the chosen rule, and posts a claim message; a recalculate function rebuilds a case's rule usage from its attached claims.	claims/w_add_claim_to_internal_cm ue_add_to_case, ue_recalculate

Required behavior documented only in the user guide (UMC-40 …)

UMC-1 … UMC-39 above are derived from the extracted PowerBuilder client and describe current behavior. The rules below come from the user guide and describe required behavior; most of them live in the nightly batch, in the database, or in screens the extracted client does not contain, so each row says where it was expected to run and whether client code for it was found.

ID	Rule	Where it runs	Source
UMC-40	The system must prevent UM records of the same category (pre-notification, authorization, referral, …) being written for the same patient with overlapping dates.	Data entry	User Guide ch. 19 — no such check found in the case windows (client-lacks)
UMC-41	A claim detail line matches a UM rule only when the line's dates fall wholly (inclusive) inside one rule's dates. Partial overlap must message the claim "the claim/UR rule needs review, or the line should be split"; falling inside more than one dated rule of a case must message "a single UM rule could not be identified"; and a claim must not be processed at all when rules from more than one case of the same category match one line.	Nightly adjudication	User Guide ch. 19
UMC-42	Claim-to-case matching uses a different key set per category: Authorization = patient + claim type + provider + procedure codes/groups + diagnosis codes/groups + benefit definitions + approved dates; Pre-Certification = patient + claim type + provider + diagnosis + procedure + dates; Referral = patient + claim type + referring physician + diagnosis codes/groups + dates; Admission Notification = patient + claim type + facility + dates only; Case Management = patient + provider + procedure + diagnosis + benefit definitions + dates. Diagnosis and procedure codes stored on an admission notification must NEVER be used to match claims (stated twice, emphatically). Pre-Determination records are never matched for payment.	Nightly adjudication	User Guide ch. 19
UMC-43	Diagnosis-code matching between a claim and a UM record uses only the three digits to the right of the decimal point.	Nightly adjudication	User Guide ch. 19
UMC-44	CM negotiated rates take precedence over standard pricing: the batch prices every line with CM rates first and falls back to plan pricing for the rest; manual pricing done by an examiner always wins, even where UM pricing applies; and where the plan/package resolves to a health-care network that forbids us repricing, the network price is used and an informational message records that a CM case was found but network pricing was used. Claimed-amount limits are not applied when CM says limits may be exceeded.	Nightly adjudication	User Guide ch. 19; consumer not present in extracted clmsproc (client-lacks)
UMC-45	Rent-to-own: during limit processing the batch runs all normal plan limits, then accumulates whatever escaped into amt_toward_purchase up to purchase_price; everything above that is denied with a limit message.	Nightly adjudication	User Guide ch. 19
UMC-46	no_alt_pricing_ind = N (the default) means a claim processing against a UM rule that finds no pricing information must be held with a message that UM pricing was not available; Y suppresses that hold.	Nightly adjudication	User Guide ch. 19
UMC-47	Entering a CM/authorization exclusion exception (a benefit definition that overrides a plan exclusion) must automatically create a matching benefit-definition hold rule carrying a hold message stating the claim was held due to a UM Exclusion Exception — so an examiner always reviews those lines.	Data entry	User Guide ch. 19 — not implemented in the case windows (client-lacks)
UMC-48	A UM record that the system has already matched to a claim cannot be deleted.	Data entry	User Guide ch. 19 — the windows' cascade delete (UMC-17) applies no such check (client-lacks)
UMC-49	A database trigger attempts to match unassigned ("dummy") patient cases to real members: when a member is added, it looks for dummy cases in the family and ties the case to the new member when name and birth date agree; when they do not, it sets a column on the case so the case appears on the nurses' follow-up report for manual assignment, and that indicator must be clearable when the new member turns out not to be the dummy's patient.	Database trigger	User Guide ch. 19 — the client has only the manual re-assign path (UMC-5)
UMC-50	A provider is mandatory before most UM records can be saved. When the provider cannot be found, the nurse may add a temporary provider from the search criteria: it is saved as its own vendor, flagged not "live", and is visible only from the UM record that created it until the provider department completes or consolidates it. Providers added this way display with a yellow background and network affiliation Unknown.	Data entry	User Guide ch. 19
UMC-51	Subrogation hand-off: if a UM record (or the claim) indicates workers' compensation, the batch rejects the entire claim; if it indicates a motor vehicle accident, it messages the examiner and holds the claim. Setting MVA on a case must pop the accident-table maintenance screen for the nurse.	Nightly adjudication + data entry	User Guide ch. 19
UMC-52	Medical-necessity gating: procedure-code groups are flagged for necessity review in Plan Design. For a claim line carrying such a code, adjudication honours a matching Pre-Determination record's status first, then a matching Medical Necessity record's status — approving, rejecting, or messaging "pending", "referred to Medical Director" or "holding for appeal" accordingly — and the line cannot progress until one of those records reads Approved or Rejected. With neither record present the examiner is messaged "medical necessity must be reviewed" and must either reject the line or create a valid medical-necessity record. A pre-determination record carrying its own error messages always holds the claim.	Nightly adjudication	User Guide ch. 19 — both case types are disabled in the client (client-lacks)
UMC-53	Any COB record created or modified by UM is automatically set to carrier status Unknown, which means research is required; all claims for a member with an Unknown COB record are held, and the examiner is notified so the research can happen before claims arrive.	Data entry + nightly adjudication	User Guide ch. 19
UMC-54	CM time is billed in 15-minute intervals per access — two one-minute visits to a case on the same day bill two intervals. A case whose status is Void was opened in error and must never be billed. The department needs a monthly outstanding-CM report totalled by member, division and master group showing actual versus billable time, a manual maintenance screen for the manager to adjust hours and time categories, and a process that generates medical claims against the outstanding amounts using the CM Rates benefit definition with Medillume III as vendor, starting in ready-for-adjudication status.	Client timer + batch	User Guide ch. 19; the client captures elapsed minutes but does not round to 15-minute intervals (UMC-26) and has no claim-generation process (client-lacks)
UMC-55	For CM services whose unit type is not Days, the next-follow-up date is user-entered, and setting "follow-up done" while the case status is not Closed must reset follow-up-done to No and push the next follow-up date 30 days later — so nurses must close the case before ticking follow-up done.	Data entry	User Guide ch. 19 — not implemented (client-lacks)
UMC-56	Admission-notification follow-up practice: the requested-from date is the admit date and the requested-through date is the requested discharge date, not the actual one; the next-follow-up date defaults to the day after the estimated last covered day and is entered by hand only for retroactive reviews or when unauthorized days surround authorized ones (then two days after the last rule through date); "follow-up done" is set only once all dates are accounted for and the member is discharged. The follow-up worklist shows only services whose follow-up-done switch is unset, sorted by case manager then follow-up date, with past-due rows highlighted and unassigned "dummy" cases flagged.	Data entry	User Guide ch. 19
UMC-57	UM notes are a distinct note entity visible only to UM/CM nurses (confidentiality and URAC), are immutable once saved — nobody, including the author, may type over them — and use three search keys: Case Summary (short description, the one printed on client reports), Case Detail (narrative: history, surgical intervention, current treatment) and Plan of Treatment (CM goals and the plan to reach them).	Data entry	User Guide ch. 19
UMC-58	A letter must accompany every authorization entered, carrying a disclaimer that providers may not be reimbursed for authorized amounts above the plan's limit, in one of three flavors: the plan's benefits are being extended; the service is not normally covered but is allowed this once; or the approval may exceed plan limits and will not be paid.	Print subsystem	User Guide ch. 19 — no generator found (client-lacks)
UMC-59	When a medical-director or independent review outcome is Denial, a system-generated letter must reach the provider, the PCP and the member by 5:00 PM the next business day (a URAC requirement), faxable once faxing exists. The guide records this as explicitly out of scope for the first release, with the table fields already in place.	Print subsystem	User Guide ch. 19 (deferred by design)
UMC-60	Potentials may never be created free-hand or deleted from the work queue — only claim adjudication and the UM maintenance screens create them, which guarantees a valid claim id or UM record key in every row. A claim-generated potential and its claim message close each other, and the claim message auto-closes when a nurse creates the UM/CM record that removes the trigger condition. UR-generated potentials must be closed manually (no claim exists to close them), and closing one must update the status field of the generating UM record. Examiners may close messages on negative responses; nurses must answer positive responses by creating the record.	Nightly adjudication + data entry	User Guide ch. 19; the client's report offers no create/delete (consistent) but implements no mutual close and no write-back to the generating case (client-lacks)
UMC-61	A CM potential's status is a delivery priority — Urgent, Priority or Normal — not a workflow state; claim-generated rows always start Normal, users may change it at any time, and the claim message raised alongside the potential must carry the priority so case managers work them in order. A person must be assigned to chase outstanding, unanswered potentials.	Nightly adjudication + data entry	User Guide ch. 19
UMC-62	Users may never delete UM entities or warnings (MIS does it on request), and may delete individual trigger lines but not trigger sets. Entities, warnings and medical directors are maintained by Client Maintenance; the CM/UM manager owns the trigger data. The warning window is not destroyed when closed — it stays reachable from the Window menu while the nurse works the case, and is destroyed only when the user leaves the case or selects a new member.	Data entry	User Guide ch. 19; the client's maintenance windows do allow deletes — discrepancy for SME confirmation
UMC-63	Package ordering resolves the UR/package circularity: packages are browsed in a client-defined order until the provider's network is found or the lowest-ranked (out-of-network/basic) package is reached; UR is tested against the package found; and once UR has been checked it is not re-checked after a penalty package switch. The override package must lie within the benefit plan already determined for the line.	Nightly adjudication	User Guide ch. 19
UMC-64	CM overrides the plan's own rule sets: CM exclusion exceptions are checked before the plan's normal exclusion rules and bypass them for the service's date range; and when a CM or UR record exists for a claim line's date range, the limits in those records are evaluated and applied instead of the normal benefit-package quantity-limit rules. Units used across all lines falling into a service may not exceed the units authorized for it, and the plan-limit accumulators are always updated regardless.	Nightly adjudication	User Guide ch. 19

Letters / notifications

• The case header stores a response_printed_dt ("response printed" date) on every case DataWindow (um_ur/d_um_pc_case, d_um_auth_case, d_um_an_case, d_um_ref_case), implying a printed determination/response letter, but no letter-generation window or print DataWindow for it exists in the four UM libraries. Per the user guide the field belongs to the Pre-Determination and Medical Necessity form letter — "most recent date that a form letter was printed, this is system updated here" — which is why it appears on case types that never print anything: those two categories were never built (User Guide ch. 19). See Open questions 4.
• The guide's full letter inventory, none of it found in the extracted code: the URAC denial letter to provider, PCP and member by 5:00 PM the next business day on a Denial review outcome, explicitly deferred past the first release (UMC-59); the authorization letter with its reimbursement disclaimer, required with every authorization (UMC-58); the pre-determination form letter to the subscriber and requesting physician, carrying the manually entered deductible / coinsurance / maximums / CC block; a referral denial notification to the referring provider, the referred-to provider and the patient; and an automatically generated letter to check COB when enough conflicting information has been gathered (listed under future enhancements) (User Guide ch. 19).
• Outbound paper that was specified as reports rather than letters: the one-page Outside Case Management Report and Outside Utilization Review Report sent to the firm performing CM/UR, each generated from a button on the corresponding potential maintenance window and each stamping report_dt on the potential. Neither window nor report exists in the extracted client — see Open questions 8 and 13 (User Guide ch. 19).
• Claim-side messaging is used instead of letters for CM attachment: attaching a claim to a case writes claim_messages rows (claims/w_add_claim_to_internal_cm).
• Report outputs that leave the department: CM billing detail/summary (internal and external formats) for invoicing CM time (um_cm/w_cm_billing), the management cases report for clients (um_cm/w_um_management_cases / d_um_management_cases, which folds in COB existence, CM involvements and unassigned-dependent cases), the entities report (um_main/w_um_entities_report) and CM trigger codes report (um_maint/d_cm_trigger_codes_report).

Vendor interfaces (um_maint)

File-based extracts for external CM / disease-management vendors, all launched from the frame menu (homersys/m_sys_frame):

• Matria enrollment and claims dumps with control files (um_maint/w_matria_enrollment_dump, w_matria_claim_dump, d_matria_*_control_file).
• HCRM enrollment and claims transfers (w_hcrm_enrollment_transfer, w_hcrm_claims_transfer).
• Springbuk enrollment and claims transfers (w_springbuk_*_transfer).
• Generic disease-management dumps driven by a DM entity registry (d_dmentities), producing text files named <prefix><type><MMDDYYhhmm>.TXT for prefixes dmqual / dmhcs, for both enrollment and claims (w_dm_enrollment_dump).
• Transfer-format DataWindows for Bluebook eligibility and Principle enrollment (d_bluebook_eligibility_transfer, d_principle_enrollment_transfer) — no dedicated window found in these libraries.

Migration notes

• Category-scoped code tables. Statuses, notification types, physician types and service types are filtered by case category; the target system needs per-case-type status vocabularies, not one global list (um_main/dddw_um_record_statuses).
• Magic status values. Behavior hangs on specific status strings: ServOpen (claims can attach), Serv% prefix (excluded from worklists/reports), Closed (off the follow-up list), Consult (time typed Consult). These must be modeled as explicit state flags, not display text (clmsproc/d_adj_open_service, um_main/d_um_follow_up, um_cm/w_um_case_management wf_determine_time_type).
• Composite, meaning-bearing case ids (user prefix + Julian date + sequence) are foreign keys from claims (claim_lines.case_sys_key, um_case_mgt_claims); preserve them or map them durably (UMC-2).
• Pessimistic case locking via lock_seq_no should be replaced with a concurrency strategy; the lock is also re-acquired after every save (um_ur/w_um_pre_certification ue_save). Note that the client reads lock_user_id / lock_dt but never writes them, so whatever populates those columns is a database-side artefact that must be found before the locking behavior can be reproduced or retired (UMC-3).
• Derived-date business logic (rule thru from units; follow-up date chains) lives in client-side events and must be re-implemented server-side (UMC-13/15). Re-implement it once: the thru-date derivation currently exists in two copies that disagree by a day (dw_rule_info::itemchanged subtracts 1 from the unit count, dw_service::itemchanged does not), so historic um_rules rows may carry either convention and should be profiled before any date-sensitive migration of authorized units.
• Dynamic SQL: the potentials report and CM billing build SQL by string concatenation with user input (um_cm/w_um_cm_potentials_report ue_retrieve, um_cm/w_cm_billing wf_retrieve) — re-specify as parameterized queries.
• Hard-coded schema owner SFPIDBA appears inside report SQL (um_cm/d_um_management_cases).
• Cascade deletes are hand-coded in each window and differ slightly per window; move to declarative referential actions (UMC-17).
• Hidden producers: claim-generated cm_potentials, um_cm_possible_case_claim and claim_line_um_rules rows are consumed but never created in the extracted client code — locate the database procedures/batch jobs before migration. The user guide confirms all three are written by the nightly claims batch (CM trigger evaluation happens in the Audit step, once per claim detail line) and that claim_line_um_rules is the record of "how a claim was processed" — case/service/rule assigned, pricing method, new allowed amount, units allowed (User Guide ch. 19).
• Database- and batch-implemented behavior to recover before migration (all User Guide ch. 19): claim-to-case matching per category (UMC-42); hold-rule enforcement and the exclusion of held claims from the nightly run; CM negotiated pricing and rent-to-own accumulation (UMC-44/45); UM indicator checks and penalty-package switching with the "UR checked once" rule (UMC-63); CM exclusion exceptions and CM/UR quantity limits displacing plan limit rules (UMC-64); the medical-necessity gate (UMC-52); MVA/workers-comp subrogation reactions (UMC-51); the COB Unknown hold (UMC-53); the mutual close of claim messages and potentials (UMC-60); and a database trigger that matches unassigned "dummy" patient cases to newly enrolled members (UMC-49). A further "background task must run to …" for Case Management Provider Processing is named in the guide but the sentence is never finished.
• Rounding rule lost. CM time was specified as billable in 15-minute intervals per access (UMC-54); the client stores raw elapsed minutes. Decide whether the target system rounds, and whether historic cm_billing rows need restating.
• Notes immutability. UM notes are specified as append-only and UM/CM-visible only (UMC-57); enforce that in the target rather than by convention.
• Disabled case types (dental/medical pre-determination, medical necessity) exist in the UI but have no implementation; confirm whether to carry them forward (um_main/w_um_new_case).
• Timer-based billing assumes a single open case window per user; a web target needs an explicit or event-based time-capture design (UMC-26).

Open questions

Resolved by the user guide

1. Who writes claim-generated CM potentials and um_cm_possible_case_claim? Resolved — the nightly claims batch, in the Audit step. For clients whose plan package requires CM, the nightly run first tries to match the claim to existing CM cases, then to Medical Necessity / Pre-Determination data, and only then evaluates the CM entity's assigned trigger set; on a hit it writes both a claim message to the nurses and a cm_potentials row, once per claim detail line, always with status Normal. A developer aside places the trigger evaluation in Audit rather than Adjudication proper (User Guide ch. 19). The database code implementing this is still to be recovered; the guide confirms it is batch/DB-side and never client-side.
2. Where are um_hold_rules enforced? Resolved — in the nightly automated adjudication batch. Any claim detail line falling into a hold rule with always-hold Y is held for the case managers with the user-defined hold reason; the remaining hold rules are still evaluated for that line, then the rest of the automated adjudication logic is bypassed for it, and claims in Hold status are excluded from the nightly run until released (User Guide ch. 19). um_cases.apply_to_adjudication_ind is likewise a batch switch — "if no, do not match incoming claims to the Case". The case-level deductible / coinsurance / maximum / CC block is not an adjudication override at all: it is Predetermination Letter Information, typed by hand because the provider (and therefore the real package terms) is unknown when the call is taken, and printed on the form letter to the subscriber and requesting physician (User Guide ch. 19).
3. Who populates claim_line_um_rules? Resolved — the nightly adjudication batch. "We will use the claim rules table to store information regarding how a claim was processed": which case / service / rule was assigned to the claim, the pricing method used, the new allowed amount and the units allowed (User Guide ch. 19). Recovery of the batch SQL is still outstanding.
4. Determination letters. Resolved — deliberately deferred out of the first release. Two letter obligations are specified. (a) On a medical-director or independent review whose outcome is Denial, a letter must go to the provider, the PCP and the member by 5:00 PM the next business day — a URAC requirement, "system generated", faxable later; the guide then states plainly that this letter "is not a requirement of the first version of Homer" and that all the table fields for it already exist. (b) Pre-Determination and Medical Necessity cases print a form letter to the subscriber and requesting physician, and that is what stamps response_printed_dt — which is why the field exists on every case DataWindow while the only case types that would print it are the disabled ones (User Guide ch. 19). Every authorization was also supposed to be accompanied by a letter carrying a reimbursement disclaimer (UMC-58). Confirm with the SME whether any of these were ever built in the mail/print subsystem.
5. Exact status vocabularies. Resolved for the design intent — see Status & disposition vocabularies above for the per-category lists, dispositions, resolutions, review types and outcomes. The production um_record_statuses table remains authoritative: the code-bearing values ServOpen / Serv… appear nowhere in the guide and are later additions, and the 12/1999 training copy had already trimmed the admission-notification list (dropping the two Holding statuses and Void from the dropdown, marking Consult "not using at present"). Void survives as a real status regardless — it is the flag that a case was opened in error and must never be billed.
6. cm_potentials.procedure_status_cd lifecycle. Resolved — nobody advances it automatically. It is a two-value field (Proposed / Done) "manually entered and maintained by users" on the CM potential maintenance window (User Guide ch. 19). The same is true of total_claims_paid_amt ("total claims paid to date for this and related diagnoses"), which the guide notes is usually filled in by claim examiners rather than nurses.
7. Stop-loss linkage. Resolved in intent — apply_excess_units_to_stoploss means "any charges allowed exceeding Plan Limits, because of CM Quantity Limits, is applied to Stop Loss accumulators", consumed during the batch's limit processing; it is supervisor-only and defaults No (User Guide ch. 19). Separately, for certain clients the CM billable amount itself applies to specific and aggregate stop-loss deductible, to be handled by 100% benefit rules on the CM Rates benefit definition. Still confirm the consumer with the Stop-loss module.
8. cm_record_link, followed_up_by/followed_up_dt, report_dt, total_claims_paid_amt on cm_potentials. Resolved — they belong to a CM Potential maintenance window that the extracted client does not have. The guide specifies a full maintenance window with one follow-up slot (follower initials + date, both manual), a Report_Date stamped every time the Generate Outside Case Management Report button is pressed, and a Generate CM button that creates the CM case and writes its key into cm_record_link (erroring if already populated). The extracted client offers only the potentials report plus a three-value resolution response window. Guide-describes / client-lacks — see Discrepancies below.
9. Medical necessity / pre-determination case types. Resolved — fully designed, never built. Pre-Determination records "are never required to pay claims", are usually entered by examiners rather than nurses, print a form letter, and are matched to claims only to decide whether a questionable line must be held. Medical Necessity is driven by procedure-code groups flagged for necessity review in Plan Design; adjudication honours the pre-determination record's status first, then the medical-necessity record's status, and a claim cannot progress until one of them reads Approved or Rejected — otherwise the examiner gets "medical necessity must be reviewed" (User Guide ch. 19). See UMC-52. Confirm whether any statuses were ever configured for these categories in um_record_statuses before deciding to carry them forward.

Still open

10. Vendor extract population — Matria/HCRM/Springbuk formats embed field layouts in DataWindows; confirm which interfaces are still active before porting them. (The guide documents only the Matria procedure, as a monthly manual run — see the administration screen catalog.)
11. Recover the batch/DB code itself. The guide settles what runs in the nightly batch (questions 1–3 above) but not where it lives. The Oracle procedures/triggers behind claim-generated potentials, hold-rule enforcement, claim_line_um_rules, CM negotiated pricing and the "dummy" patient matcher (UMC-49) are all still to be extracted from the database.
12. Preferred suppliers' file. Chapter 18's own contents list a "Preferred Suppliers' File" topic for Case Management, but the guide never describes it — the phrase appears twice in the whole corpus (the chapter-18 heading and the table of contents) with no body text, no fields, no table and no screen. No such code exists in the extracted client either. The nearest functional analogues are CM negotiated pricing per provider and the rent-to-own purchase accumulator (UMC-44/45). Guide-mentions-only / client-lacks — ask the SME whether a preferred-supplier catalogue ever existed (User Guide ch. 18).
13. UR potentials. The guide specifies a UR_Potential table with its own list window, maintenance window and Outside UR Report, parallel to but separate from CM potentials (see Discrepancies). Nothing in the extracted client references it. Did it ever ship, and does the table exist in the production schema?

Discrepancies for SME confirmation

• UR potentials do not exist in the client. The guide describes a complete UR_Potential mechanism — generated only by claim adjudication (never by hand), so that every row is guaranteed a valid claim id; a list window filtered by member / UR entity / client and by open/closed/all; a maintenance window with follow-up and resolution blocks (Open a UM Record, Decline to Open a UM Record, No Response); and a one-page Outside Utilization Review Report for the firm doing UR. The extracted client implements the CM half of this design only (cm_potentials), with no UR counterpart anywhere. The user guide (ch. 19) states UR potentials are required — discrepancy for SME confirmation.
• CM potential resolution vocabulary. The code offers CaseOpened / No Case / unresolved (UMC-24). The user guide (ch. 19) states the list is Open a Case, Decline to Open a Case, No Response, paired with a free-text "Resolved By", a resolution date and a resolution user id, and that if any resolution field is filled all of them must be — discrepancy for SME confirmation.
• A third generator, Examiner. The code observes only UR and Claim (UMC-25). The user guide (ch. 19) describes a third Generator value Examiner for a potential raised directly by a claims examiner, with the report leaving the physician/diagnosis/procedure block blank in that case — discrepancy for SME confirmation.
• Automatic CM-case generation from a potential. The code creates a CM case from a potential through the potentials report and auto-resolves it on save (UMC-24). The user guide (ch. 19) states the button must resolve the generating UM record's type first and default as much of the new case as possible from it, must refuse to run when cm_record_link is already populated, and must be unavailable for claim-generated potentials — the extracted client applies none of these three restrictions — discrepancy for SME confirmation.
• Three UM switches versus four indicators. Already noted under Interaction with benefit rules: the code checks four independent indicators, the guide models three switches with a mutual-exclusion rule.
• Notification-number format. The code generates 3 user characters + yyyyddd + a 6-digit sequence (UMC-2). The user guide (ch. 19) states the number is "system generated using userid, Julian date, and 5 digit number reset to 1 each day", with all UM record types drawing from one generator so no two types share a number — discrepancy for SME confirmation (the "one generator for all types" property does hold in the code).
• Discharge confirmed-by list. The code's value list is Hospital / Insured//Family / Doctor's Office / Outside Case Mgt. The user guide (ch. 19) lists only Hospital, Insured/Family and Doctor's Office — the fourth value is a later addition; discrepancy for SME confirmation.
• Unit types. The code's arithmetic supports DAYS, VISITS, HOURS and MONTHS (UMC-13). The user guide (ch. 19) lists "Hours, Visits, Days, Purchase, Months" for pre-certification, authorization and CM, and "Days (default), Visits, Weeks, Months" for admission notifications — neither Purchase nor Weeks has arithmetic in the extracted code; discrepancy for SME confirmation.