UM & CM Screen Catalog — Search, Case Workspaces, Worklists

Windows the UR nurses and case managers use day to day: the search hub, the five case-maintenance workspaces, the response windows they open, and the follow-up worklist. Reference-data and reporting screens are in Screen Catalog — Administration & Reports.

Search & entry (um_main)

UM Search (um_main/w_um_search)

• Launch: frame menu (homersys/m_sys_frame opens w_um_search); MDI sheet with menu m_um_search.
• Purpose: the hub of the domain — locate a member or a case, review history and warnings, and open/create cases.
• Field groups:
  • Search criteria: Last Name, Soc Sec No, Member ID, Group ID, From/Through date, As-of Date, and Notification No (direct case-number lookup) (sle_notification_no, criteria labels at the search pane).
  • Group banner: division Group ID and name, Examiner + extension, Stop Loss Carrier (dddw um_main/dddw_um_stoploss_carrier from carriers + group_stoploss_parms), Confidential Contact + phone — the contact is walked up the group hierarchy until found, else "Unknown" (wf_urcm_search).
  • Family member list (um_main/d_um_member_list) with the searched member highlighted.
  • Tabs: UM Record History (um_main/d_um_record_list — case number, category, status, disposition, overall dates, case manager, lock info, by subscriber + patient set + date range) and Demographics (um_main/d_um_demographics, member address/phone DataWindows), plus COBRA info.
• Validations / rules: per-group security check against security_user_class_user before showing anything; notification numbers not on file are rejected ("is not in the system") (wf_urcm_search_notification).
• Actions:
  • Search populates family, history, group info and pops the warnings window (below), and checks member notes (n_notes, entity MEMBER).
  • Clicking a history row surfaces case notes (entity CASE); double-click opens the case's maintenance window by category (dw_history_record::doubleclicked → wf_record_maintenance).
  • New (pfc_addrow) requires a selected member, opens the case-type chooser and then the proper workspace with the full member/group context passed along (dw_history_record::pfc_addrow).
• Windows opened: w_um_warning_display, w_um_new_case, w_um_admission_notification, w_um_case_management, w_um_referral, w_um_pre_certification, w_um_authorization.
• Guide semantics (User Guide ch. 19) — the intended search behaviour, partly visible in the code and partly not:
  • Member search exists to resolve a single member key; a Member/Family radio button chooses between that member's own history and the whole family's, and entering only a group number ignores the radio and returns history for everyone in the group. Where the criteria cannot resolve to one member, the standard Enrollment member-selection window is reused and the user must pick one before anything else happens; the family button is still honoured afterwards by walking to the subscriber and back down to all dependents.
  • Only records matching all entered criteria are returned, with an error message when none are.
  • Notification number is the universal case-number field: it is the admission-notification number, pre-certification number, authorization number, referral number, pre-determination number, medical-necessity number or case-management number, depending on the record. Entering one bypasses the history screen and goes straight through the warning screen to that category's maintenance window. For admission notifications, pre-certifications, referrals, pre-determinations and medical-necessity records the number is the case key; for authorizations and case management it is a service key, so the system must resolve the owning case first and then position the cursor on the right tab and service row.
  • The warning screen is a gate: the user passes through it to reach history, and it is not destroyed until a new member is selected (see below).
  • History is displayed newest-first, re-sortable by clicking column headings, with UM and CM records deliberately commingled — "there is no need to visually segregate UM records and CM records", the category column tells them apart, because UR and CM nurses routinely need to see each other's records.
  • If the member or subscriber cannot be identified at all, the training copy's instruction to the nurse is to refer the call to Enrollment.

New Case chooser (um_main/w_um_new_case)

• Response window "Select New Case Type": radio buttons for Admission Notification Pre/Post, Authorization, Case Management, Certification Pre/Post-Occurrence, Referral; Dental Pre-Determination, Medical Necessity and Medical Pre-Determination are present but disabled. Returns the chosen type string to w_um_search.

Warning display (um_main/w_um_warning_display)

• Hidden sheet opened alongside search; shown whenever a member is selected.
• Master list: one row per Medical plan package election (plan description, network, UR firm, CM firm — um_main/d_warning_master); detail list: the warnings attached to those UR/CM entities (um_main/d_warning_detail on um_entity_warnings/um_warnings).
• Synthesizes system warnings: "Member not active as of <date>" (from members.mbr_term_dt), "Utilization Review Not Done" (no UR firm on the plan package), "Case Management Not Done" (no CM firm) (wf_warning_display).
• Why it exists (User Guide ch. 19): warnings must pop as soon as possible after the member is identified, because the nurse needs to know immediately when Medillume III is not providing some or all of the authorization services — so the member can be referred to whoever does provide it, or told the service is not required at all. The warnings also flag categories UR may not handle, such as mental and nervous or alcohol and substance abuse.
• Entity resolution scheme (User Guide ch. 19): select the member → find the most recent eligibility period → locate the plan for the most recent medical election in that period → inspect every package in the plan → list the warnings for each distinct entity assigned to those packages. One tab per package, with system-generated warnings above the entity-related ones; it is expressly possible for each package in a plan to name a different entity.
• The window is never destroyed on close. The nurse closes it to proceed but must be able to bring it back from the Window menu while working the case; it is destroyed only on leaving the case or selecting a new member. The guide is equally explicit that the nurse is always allowed to proceed whatever the warnings say — they may legitimately be looking at historical cases for a terminated group or member, or a member in the COBRA gap between termination and election (User Guide ch. 19). UMC-62.
• Header content per the guide: group name and id, termination date of the member if terminated, and the system messages ("Member not active", "Group not active", "UR not done for group", "CM not done for group"). Group effective and termination dates were specified and then dropped as unreliable. Each package tab shows the entity display name, address, phone, fax, e-mail and contact — shown only when the entity is not suppressed — followed by its warning texts.
• Three package-level fields drive all of this (User Guide ch. 19): the CM entity, the UR entity, and "Always show UM Warnings", which overrides the entity's own suppress flag and defaults to yes on new plan/package records. It exists because a client may have CM done by Medillume III but not UR, and the UM warning must still appear; until the field was built, a warning was added to the CM warning list telling the nurse that MIII does not do UR and to check the UM warning for the entity. The extracted client honours suppress_warning_ind on the entity (UMC-33) — whether the package-level override was ever built is a question for the Plan Design module.
• Sample warning texts (User Guide ch. 19) — UR: "Mental & Nervous UR not done by MIII", "Alcohol and Substance Abuse not done by MIII", "Pre-Certification not required on Medicare primary members", "Is the nearest in-network provider less than 50 miles from the patient?"; CM: "Contact Employer for Case Management" (the nurse then uses the confidential contact and phone in the screen banner), "Convalescent Care not done by MIII", "Medicare Primary", "UR is done by another source", and the same 50-mile question.

Demographics

The Demographics tab of search — and the demographics button on each maintenance screen — is specified as a read-only briefing for the nurse on the patient and their family, oriented to whichever family member has focus (User Guide ch. 19). Content: member address; member phone, the single updatable field (Enrollment did not collect it — the nurses were to maintain it); medical coverage history newest-first with eligibility from/to, coverage, plan option, coverage from/to and termination reason; COBRA status, eligible-through, paid-to and term dates; the HCN for the package behind the focused coverage line, with type (PPO, HMO) and its contacts; and space reserved for PCP/PCL name and date range. COBRA status resolution has its own precedence when several election letters match: prefer Elected, else Open, else Declined, else leave blank. PCP/PCL and COBRA paid-to were listed under future enhancements and never populated — reserve-space fields.

Member / patient / code select responses (um_main)

Small response windows used by the workspaces:

Window	Purpose
um_main/w_um_member_select	"UM Member Select window" — member pick list.
um_main/w_um_case_patient_select	Pick the patient "from members of current family" — used to assign a real member to an unassigned-patient case (w_um_pre_certification dw_case::buttonclicked).
um_main/w_um_diagnosis_cd_select	Resolve a diagnosis-code prefix to a full code + description; sets the OK flag on return (w_um_pre_certification dw_diagnosis_info::buttonclicked).
um_main/w_um_procedure_cd_select	Same pattern for procedure codes.
um_main/w_um_diag_group_cd_select, w_um_proc_group_cd_select	Select diagnosis / procedure group codes for services that are coded at group level (referral/authorization group DataWindows um_ur/d_um_ref_diag_groups, d_um_auth_proc_groups).
um_main/w_um_benefit_def_select	Select benefit definitions to scope a service (um_cm/d_um_cm_service_benefit_defs, um_ur/d_um_auth_service_benefit_defs).
um_main/w_um_hold_rule_child	Edit one hold rule's scope list — the same window serves PROC, DIAG, BENEFIT, PROVIDER and SPECIALTY child lists, parameterized by type (w_um_hold_rule_child case branches).
um_main/w_medical_director_review	Rule-level reviews grid (shared-data with the parent's review DataWindow d_um_medical_director_review): review type, appealer type, request/response dates, director, outcome; add generates the review key from the sequence.

Case workspaces (um_ur / um_cm)

All five share one blueprint (documented once here, differences noted per window): an MDI sheet opened with the member/group context from search; group banner + family list + stop-loss carrier at the top; a tab folder with Case, Service (with nested panes or sub-tabs) and Physicians; buttons Create/Edit COB (opens w_cob_select for the member — see the COB module) and, on UR windows, Create/Edit Potential CM. Case numbering, locking, defaults, validations and cascade deletes are the business rules UMC-2..UMC-17 (see module page); the per-category dropdown retrieval is wf_retrieve_dddw.

Conventions the guide applies to every maintenance screen (User Guide ch. 19):

• The member banner at the top is display-only and frozen: the user cannot change family-member focus from a maintenance screen and must go back to the history screen to do so.
• Coverage for Case is picked from the patient's coverages whose date range contains today, defaulting to Medical when the patient has it.
• The standard note symbol appears in the bottom corner whenever UM notes exist for the member on the record or for the record itself, newest first (UMC-57).
• Provider search / add. Blank search fields are excluded from the search; criteria are provider name, HCN provider id, TIN, city, state, specialty and type, and the user must be conscious of which provider segment they are searching. Multiple hits reuse the Provider Maintenance selection window. If the provider genuinely cannot be found, the same criteria seed a temporary provider add (company/provider name and lookup name mandatory, plus specialty, type, HCN id, UPIN, TIN, EIN/SSN, address and a contact) which is saved as its own vendor, flagged not "live", and visible only from the UM record that created it until the provider department completes or consolidates it. Temporary providers display with a yellow background and network affiliation Unknown. A provider is mandatory before most UM records may be saved. UMC-50.
• Network affiliation is derived and stored each time the service's provider changes: find the patient's plan option for the case coverage as of today → resolve the plan → check the HCN on every package in that plan → if the provider holds a contract with any of them they are In, and the matching HCN's name is displayed. This is the guide's statement of UMC-22.
• COB button. Admission notifications, pre-certifications and authorizations reach COB through a button that opens the same COB window Enrollment and Claims use. UM watches for discrepancies and fills gaps only; Claims corrects the permanent file. Any COB record UM creates or modifies is set to carrier status Unknown, which flags research and holds the member's claims, and the examiner is notified so the research can be done before claims arrive (UMC-53).
• Case numbering per the guide is userid + Julian date + a 5-digit number reset daily, from one generator shared by all record types so no two categories ever share a number — see the numbering discrepancy in the module Open questions.

Pre-Certification (um_ur/w_um_pre_certification)

• Serves categories: Pre-Cert, Post-Cert (both radio choices open this window; the category dddw is restricted to those two — dw_case::constructor).
• Case tab (um_ur/d_um_pc_case): patient/subscriber names, unassigned patient block (name + birth date + Select Patient button), category, coverage type (member's actual elections retrieved into the dddw; default Medical), overall from/thru dates, status (per-category), disposition (default DC Plan), case manager, notified-by code/name, requestor (name/phone/member-flag), late-notification, motor-vehicle-accident and workers-compensation flags, case-level benefit terms (deductible, coinsurance pct/limit, lifetime/yearly maximums, apply-to-adjudication), CC names, response-printed date, savings totals.
• Service tab — single service (um_ur/d_um_pc_service) plus panes:
  • Service pane: request and approved date ranges, notification type, service type, unit type (UMSRVCUNIT codes), criteria/guideline units, unit totals (computed from rules), estimated last day in hospital, next follow-up date (+ override flag), follow-up done flag, discharge confirmed-by/date, actual days stayed, service resolution, claim type.
  • Provider pane (um_ur/d_um_pc_service_provider) with provider search (n_provider_search) and derived network affiliation (UMC-22).
  • Hospital contacts (um_main/d_um_hospital_contacts) — Primary/Secondary (UMC-20).
  • Diagnosis codes (um_main/d_um_diag_codes) and procedure codes (um_main/d_um_proc_codes) with master-table validation and prefix-search buttons (UMC-21).
  • Rules grid (um_ur/d_um_pc_rules) with per-row buttons: Reviews (opens w_medical_director_review filtered to the rule), Pricing (opens w_pricing_plan_maintenance_single and stores the returned pricing plan key), Exclusions ("function not available") (dw_rule_info::buttonclicked).
  • Review grid (hidden holder for all rules' reviews, um_main/d_um_medical_director_review).
• Physicians tab (um_main/d_um_physicians): ordered physician list — name, phone, type (per-category dddw), specialty (UMC-19).
• CM Potential: hidden shared DataWindow (um_cm/d_um_cm_potential_create) behind the Create/Edit Potential CM button (UMC-23).
• Save: validates every pane in order (case, potential, physicians, service, contacts, diagnoses, procedures, rules, reviews), deletes reviews of deleted rules, updates all panes in one transaction, commits, re-locks the case (ue_save).
• Windows opened: w_medical_director_review, w_pricing_plan_maintenance_single, w_um_diagnosis_cd_select, w_um_procedure_cd_select, w_um_case_patient_select, w_um_cm_potential_create, w_cob_select.
• Guide notes (User Guide ch. 19): the criteria that decide whether a pre-certification is required are procedures, diagnosis, place of service (facility type), inpatient/outpatient, in/out of network and specialty, and those rules live in the benefit definitions, not here. This screen also serves outpatient pre-certification. A post-occurrence certification carries the late-notification flag: N means adjudication must not apply a late penalty, Y means it must. Claim type defaults to All; unit type is a real choice (Hours / Visits / Days / Purchase / Months). The provider recorded is the rendering provider, and it is one of the claim-matching keys (UMC-42).

Authorization (um_ur/w_um_authorization)

• Serves category: Auth. Largest of the workspaces (6,200 lines).
• Differences from pre-certification:
  • Multiple services with First/Last/Next/Previous page navigation over a rownum filter (dw_service::pfc_new and the paging events).
  • Service sub-tabs: Rules (um_ur/d_um_auth_rules + reviews), Diagnosis/ Benefit Defs (d_um_auth_diag_codes, d_um_auth_service_benefit_defs, d_um_auth_diag_groups), Procedures (d_um_auth_proc_code, d_um_auth_proc_groups), Hold Rules (d_um_auth_hold_rules with child holds for diagnosis, procedure, benefit definition, provider and specialty — d_um_auth_specialty_holds), Contacts/Provider (d_um_auth_service_provider, hospital contacts).
  • Case/service hard- and soft-savings totals roll up from the rules' computed sums (c_total_hard_savings / c_total_soft_savings).
• Rule columns are identical across all four UR case types (d_um_pc_rules = d_um_auth_rules = d_um_an_rules; d_um_ref_rules lacks only the reviews count column).
• Guide notes (User Guide ch. 19): an authorization "is like case management" — a period of time with subsets of date ranges dictating different pricing rules and review information. It can be expressed as a total authorized amount, authorized days, authorized visits or authorized specific services, and must be able to hold or deny an unauthorized claim line when the plan says so. The criteria deciding whether an authorization is required are procedures, diagnosis, place of service, inpatient/outpatient, provider, network and specialty, and they live in the package rules.
  • Nurses deliberately create multiple rules with adjacent date ranges to set up tiered per diem — that is what the min/max approved split is for.
  • The rule-level blocks the guide specifies here and on CM, beyond what the module page covers: exclusion exceptions entered as benefit definitions to override a plan's exclusion rules, which must auto-create a matching benefit-definition hold (UMC-47); No Alt. Pricing (UMC-46); negotiated pricing, one pricing plan per rule, created for that rule only and marked so it never appears in the plan-pricing list; and rent-to-own list price / purchase price / amount toward purchase (UMC-45).
  • Manager-only fields carry the guide's own emphasis — "ONLY A CM SUPERVISOR MAY UPDATE THIS FIELD" on exceed-plan-limits, exceed-lifetime-maximum and apply-excess-units-to-stop-loss (UMC-16).
  • Hold rules exist to stop claims that matched a UM record from being automatically adjudicated — the guide's one-line statement of their purpose. A hold rule combines the always-hold switch, a reason drawn from the hold-message list, a date range inside the approved service dates, and the provider / specialty / procedure / diagnosis / benefit-definition scope lists plus claimed-amount less-than and greater-than thresholds. Both the design draft and the training copy flag this area as unfinished — "WE NEED FURTHER EXPLANATION HERE REGARDING HOW THE SEARCH AND MAINTENANCE FOR THIS WILL WORK".
  • Every authorization was to be accompanied by a letter carrying a reimbursement disclaimer (UMC-58).

Admission Notification (um_ur/w_um_admission_notification)

• Serves categories: Pre-Adm, Post-Adm.
• Single service ("Only one Service may be created for Admission Notifications" — dw_service::pfc_new); case DataWindow um_ur/d_um_an_case, service d_um_an_service, rules d_um_an_rules.
• Emphasis on the stay: estimated last day in hospital derived from rules, next-follow-up chaining, discharge confirmation (value list Hospital / Insured//Family / Doctor's Office / Outside Case Mgt — d_um_an_service), actual days stayed computed from admission to discharge (dw_service::ue_afteritemchanged).
• Includes hold rules with specialty holds (deletes um_specialty_holds in its save path) and the Create Potential CM button.
• Guide notes (User Guide ch. 19) — this screen is flagged in the design draft as "most important and must be coded, tested, and finished first", and it is the only UR maintenance screen the 12/1999 training copy still documents.
  • Its purpose is to determine the approved length of stay. Data from this screen and the demographics tab feed the published clinical criteria the nurses use to approve an initial LOS plus extensions — M&R and InterQual in the design draft, HCIA by the 1999 training copy, where the criteria-derived LOS is described as appearing in the criteria_guideline_units field. InterQual survives there only as the source of the reason for an extension, copied into the notes.
  • Date discipline, stated emphatically: the requested-from date is the admit date; the requested-through date is the date they request for discharge, not the discharge date. If the admission date later changes, the actual date is typed over the original and the first date is lost.
  • Rule #1 is the initial length-of-stay line; every later rule is an extension. "Estimated length of stay requested" is entered in days as described by the provider, "assigned LOS" in days as decided by the nurse, and min/max units approved are split to allow per-diem pricing.
  • Follow-up practice and the recalculation chain are UMC-56; the estimated last day in hospital and next follow-up date must be recomputed whenever the approved-from date or any rule's min/max approved units change.
  • Diagnosis and procedure codes entered here must never be used to match claims — the guide says so twice (UMC-42).
  • Claim type defaults to Inpatient here (it defaults to All elsewhere), and unit type is display-only, always Days.
  • Field values in the training copy: statuses Open / Closed / Consult (not using at present) / Pending / Future Admission; type of admission Transfer, Emergent/Urgent, Doctor Direct, Scheduled; type of service Maternity, Mental Nervous, Alcohol/Substance Abuse, Acute Rehab, Transplant, Acute Inpatient; disposition defaulting to Discharge Planning in Progress. The full lists are on the module page.
  • Late-notification, MVA and workers-comp flags all default No; setting MVA is supposed to pop the accident-table maintenance screen, and workers-comp is a three-value Yes/No/Maybe (UMC-51). Training-copy practice: on an accident, go to COB and enter the potential guarantor; on workers' comp, record it in COB with the case number in the policy-number area.
  • Newborns and new spouses are entered as dependents attached to the subscriber and entered as pending, with the subscriber holding eligibility for the coverage dates (UMC-5, UMC-49).

Referral (um_ur/w_um_referral)

• Serves category: Referral.
• Case um_ur/d_um_ref_case, service d_um_ref_service, rules d_um_ref_rules, provider d_um_ref_service_provider; codes panes use diagnosis codes plus diagnosis groups (d_um_ref_diag_groups); hospital contacts and physicians as elsewhere; CM potential button present.
• Referral cases are excluded from the follow-up worklist and can be excluded from the management report (um_main/d_um_follow_up; um_cm/d_um_management_cases filter show_referral).
• Guide notes (User Guide ch. 19): a referral records the permission a member's PCP grants for treatment by another provider, so it is only meaningful for managed-care networks; the screen was modelled on the MedSouth referral form. The referral rules live in the package rules — a rule needing a referral makes the claim look for one before it can be allowed.
  • The service carries two providers: the referring physician (typed PCP / PCL / Other) and the referred-to physician; only the referring physician is a claim-matching key, together with patient, claim type, diagnosis codes/groups and the referral valid-from/to dates (UMC-42).
  • The system was to validate that the referring provider is the patient's PCP, and where it is not — or the referral is denied for any other reason — the referring provider, the referred-to provider and the patient must all be notified. PCP/PCL data was never tied to member data, so the referring physician type is specified as present but greyed out and unpopulated; the guide flags getting PCP data attached as urgent.
  • Referral chains: some groups do not require an authorization when the referring physician is in network, and the system needs to check whether a referral is coming from a specialist — a specialist must themselves have been referred by the PCP first (the guide's example: an orthopedist ordering physical therapy needs their own PCP referral first). Not implemented.
  • Referral cases have no Future Admit status (see the status table).

Case Management (um_cm/w_um_case_management)

• Serves category: CM; menu m_um_case_management_case (with service and physician variants swapped per tab).
• Case tab (um_cm/d_um_cm_case) plus a side grid of CM involvements (um_cm/d_um_cm_case_involvements over cm_case_involvements / cm_involvements) retrieved per case.
• Service tab with sub-tabs: Rules (d_um_cm_rule + medical director reviews), Diag/Proc/Defs (d_um_cm_diag_codes, d_um_cm_proc_code_no_resolution, d_um_cm_service_benefit_defs), Hold Rules (d_um_cm_hold_rules with diagnosis / procedure / benefit / provider child holds and per-rule counts; scope lists edited via w_um_hold_rule_child), Contacts/Provider (d_um_cm_service_provider, d_um_cm_hospital_contacts). Multiple services supported (page navigation events pfc_firstpage … pfc_previouspage).
• Physicians tab as in the UR windows.
• Time capture: opening/retrieving a case calls wf_start_billing (timestamp), and leaving the case (new case, close, delete) calls wf_stop_billing, which creates/updates the cm_billing record with elapsed minutes, status-at-close and time type (UMC-26). Deleted cases delete their billing rows first.
• From a potential: when opened from the potentials report with a potential key, saving the new case stamps the potential resolved CaseOpened with the case link (UMC-24).
• Validations: same case-header rules as the UR windows (UMC-8); hold rules need hold messages (UMC-28); diagnosis codes validated against the master table.
• Guide notes (User Guide ch. 19):
  • The timer is meant to be visible. "A button or clock symbol should be visible somewhere on the screen and flash until it is clicked to start the time"; a second click stops it, and leaving the member in case management stops it by default. Billing is per 15-minute interval per access (UMC-54). The extracted client starts and stops the clock automatically with no visible control.
  • Apply to Adjudication (Y/N) — "if no, do not match incoming claims to the Case". Consumed by the nightly batch, not by client code.
  • Case status is only open / consult / closed, and Consult is selectable only on a new record. Consult is what makes the captured time type Consult (UMC-26).
  • Validation against UR records on add: when a CM record is created the system should look for UM records for the same member where the provider matches and the CM service date range falls wholly inside the UM date range. The guide leaves the consequence unresolved — "Is this right? What to do after match is found?" — and no such check exists in the client.
  • When a CM case is created from a potential, the physician block and the rendering-provider block should be defaulted from the generating pre-certification or admission notification, editable by the case manager. The extracted client defaults neither.
  • The service pane should display the generating potential's fields read-only: origin of case (blank meaning the case came from a phone call to the nurses), date referred to case management, referred status, procedure status, and total claims paid to date for this and related diagnoses.
  • CM follow-up is driven by each rule's to date: the entry appears the next business day after that date, grouped by rendering provider under the case manager's name, and stays on the list until the case status is Closed (UMC-55).
  • Notes are where the clinical record lives — Case Summary, Case Detail and Plan of Treatment (UMC-57).

Designed but never built: Pre-Determination and Medical Necessity

The new-case chooser disables Dental Pre-Determination, Medical Pre-Determination and Medical Necessity, and no window exists for them. The guide specifies both screens completely (User Guide ch. 19), and they are worth recording because their fields are already carried on the shipped case DataWindows:

• Pre-Determination of Medical Necessity — titled that on screen, with the category chosen as Dental or Medical Pre-Determination. It lives with the UM data but is "usually entered by Examiners". Statuses are Approved / Rejected / Pending / Holding Referred to Medical Director / Holding For Appeal / Void. It carries a requestor block (member Y/N, and when not a member, the requestor's name, address and telephone) and the Predetermination Letter Information block — deductible amount and type, coinsurance percentage / upper limit / percentage after limit met, lifetime and yearly maximums, and a comma-separated CC list — all typed by hand because the provider is unknown when the nurse takes the call. A button prints the form letter to the subscriber and the requesting physician and stamps the response-printed date. One service only; procedure codes carry a billed amount, a second-opinion flag and a resolution. No rule-level data is shown, though a rule must exist in the data to hang medical-director reviews from. These are the case-level benefit-term fields on um_ur/d_um_pc_case that our code never reads.
• Medical Necessity — same statuses and requestor block, one service, a service date range and procedure codes with resolutions, no visible rules. Its role in adjudication is UMC-52. Practice: nurses forward questionable procedure calls to examiners, who request more information and, if they cannot determine necessity themselves, ask a UR nurse, a medical director or an outside source — "this is a fluid type arrangement such that it is not clear who to send requests to… the system will provide no assistance here". Where an examiner forwards to an internal nurse, the nurse creates the record. For a newborn, look for a pre-determination filed against the subscriber with no patient entered before starting the review.

Both categories were dropped from the 12/1999 training copy along with the pre-certification, authorization and referral screen specifications — by then only Admission Notification and Case Management were documented for training.

Worklists (um_main)

Follow-Up (um_main/w_um_follow_up)

• Launch: frame menu (homersys/m_sys_frame).
• Content: worklist of open cases (um_main/d_um_follow_up): case number, category, status, disposition, case manager, service type, next follow-up date, provider, patient (including unassigned names), sorted by master group, follow-up date, case number. Filter: status not Closed and not Serv%, category not Referral, member's master group within the group tree of the entered group id.
• Actions: double-click loads the member context (group banner, stop-loss carrier, examiner, confidential contact — same helpers as search) and opens the case in its category window (wf_get_case_member_info and the OpenSheetWithParm branch).
• Windows opened: all five case workspaces.
• Guide specification (User Guide ch. 19) — the worklist was scoped to admission notification and case management cases, showing one entry for every service whose follow-up-done switch is not set, sorted by case manager then next follow-up date, with entries whose follow-up date has passed shown on a yellow background and unassigned "dummy" cases carrying an indicator. Columns: notification number, UM category, provider, next follow-up date, service type, nurse, case disposition, case status, dummy-record indicator. The shipped worklist instead filters on case status (not Closed, not Serv%) and excludes referrals, and has no dummy-record column — the code is authoritative for current behavior; the user guide (ch. 19) states the driver is the follow-up-done switch and that unassigned dummy cases must be flagged with a way to clear the indicator when the newly added member turns out not to be that patient — discrepancy for SME confirmation.
• The date-derivation and 30-day reset rules behind this list are UMC-55 and UMC-56; the guide's capitalised warning applies here — nurses must set the case status to Closed before ticking follow-up done, or the system pushes the case back onto the list 30 days later.
• The guide also asks for a second, unbuilt worklist: a suspend list of outstanding medical-director reviews and appeals across all UM categories, showing notification number, member SSN, facility name, the doctor or outside reviewer, the date sent and the category, with rows dropping off once the physician responds. No such window exists in the extracted client (client-lacks).