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_assignments where control_cd = 'NURSE' and benefit_coverage_type_cd = 'UM', matched to the subscriber'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).

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).

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).

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; the producer is not in the extracted client source — 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.

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 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); no consumer of apply_to_adjudication_ind was found in the extracted source (see Open questions).

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 (see Open questions).

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 + 6-digit sequence; service numbers use the same scheme.	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: an atomic lock-latch update on um_cases.lock_seq_no guards entry; a case locked by another user cannot be opened and the holder and lock time are shown.	um_main/u_urcm_sql of_lock_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 from the nurse assignment table by group and the alphabetical range containing the subscriber's last name (control code NURSE, coverage type UM); "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 units − 1) for DAYS/VISITS, + trunc(units/24) for HOURS, and month-arithmetic for MONTHS.	um_ur/w_um_pre_certification dw_rule_info::itemchanged
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

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 — see Open questions.
• 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).
• 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).
• 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.
• 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

1. Who writes claim-generated CM potentials and um_cm_possible_case_claim? cm_potentials rows with entity_generator_cd = 'Claim' and all um_cm_possible_case_claim rows are read (um_cm/w_um_cm_potentials_report, um_main/w_cm_possible_rpt) but never inserted in the extracted source. Presumably a database trigger/procedure evaluates the CM trigger sets (cm_triggers + code lists with dollar thresholds) against claims — the actual evaluation code must be recovered from the database.
2. Where are um_hold_rules enforced? The UM windows maintain hold rules and scope lists in detail, and um_hold_messages exist, but no claims-side reader was found in clmsproc/clmentry/claims. Same question for um_cases.apply_to_adjudication_ind and the case-level deductible/coinsurance/ maximum fields (um_ur/d_um_pc_case).
3. Who populates claim_line_um_rules (the claim-line ↔ UM case link that the adjudication indicator checks rely on)? Only reads exist (clmsproc/d_adjd_claim_line_um_rules).
4. Determination letters. um_cases.response_printed_dt implies a printed response; no letter generation was found in the UM libraries. Is it produced by the mail/print subsystem, an external tool, or dead?
5. Exact status vocabularies. um_record_statuses is data-driven per category; only Closed, ServOpen/Serv% and Consult are visible in code. The full status list and any implied transition order need to come from the production table.
6. cm_potentials.procedure_status_cd lifecycle — set to Proposed at creation and filterable via code table CMPOTNTLST(status) but no code moves it; who advances it?
7. Stop-loss linkage. Rules can flag apply_excess_units_to_stoploss; no consumer found in the stop-loss library from this domain's reading — confirm with the Stop-loss module.
8. cm_record_link, followed_up_by/followed_up_dt, report_dt, total_claims_paid_amt on cm_potentials appear in the schema but were not observed being set in these windows — verify usage in the database.
9. Medical necessity / pre-determination case types are stubbed in the UI — are they used anywhere (e.g., statuses configured for them in um_record_statuses)?
10. Vendor extract population — Matria/HCRM/Springbuk formats embed field layouts in DataWindows; confirm which interfaces are still active before porting them.