UM & CM Screen Catalog — Reference Data, Reports, Vendor Extracts

Screens used by supervisors and administrators: CM potentials and billing, reports, UM reference-data maintenance, and the external vendor extract jobs. All are launched from the application frame menu (homersys/m_sys_frame) unless noted. The day-to-day case screens are in Screen Catalog — Case Work.

Case management operations (um_cm)

CM Potentials Report (um_cm/w_um_cm_potentials_report)

• Purpose: the CM identification work queue — list, resolve, and convert CM potentials.
• Criteria: CM company (entity dddw um_cm/dddw_um_entities, restricted to um_entity_type_cd = 'CM'), Group ID, Member ID, create-date From/Thru, Resolution (CaseOpened / No Case / Unresolved = null / all), Status (codes CMPOTNTLST), Generator (UR / Claim / all). The SQL is assembled dynamically and unions the UR branch (joined to um_cases + first UM diagnosis) with the Claim branch (joined to claims + first claim-entry diagnosis) (ue_retrieve).
• Columns: CM firm display name, generator, generating case/claim link, creator and dates, member, primary diagnosis + description, group, resolution fields, claim status (claim branch), linked CM case (um_cm/d_um_cm_potentials_report; print variant d_um_cm_potentials_report_print).
• Actions: open the generating case (any category) or the linked CM case (wf_open_case), create a new CM case from the potential (wf_create_cm_case — passes the potential key so the case save resolves it CaseOpened), resolve a potential directly (w_cm_potential_resolution), notes.
• Windows opened: all five case workspaces, w_cm_potential_resolution.
• What the guide expected here (User Guide ch. 19) — the design splits this into a list window and a maintenance window, and the shipped client has only the list (as a report) plus a small resolution response window:
  • List window: filtered by member, CM entity and SFPI client, and narrowed to open / closed / all. Columns group, member name, SSN, entity, generator, status, create date, follow-up, resolution, notification number. Crucially it must offer no add and no delete — new potentials may only come from the UM maintenance screens and claim adjudication, so that every row is guaranteed a valid claim id or UM record key (UMC-60). The shipped report honours this.
  • Maintenance window (not built): display-only group / member / SSN / create id / create date / CM entity / generator; the generator-specific identity block (UR record type and notification number, or claim number, or blank for an examiner-raised potential); a status delivery priority (Urgent / Priority / Normal — UMC-61); a follow-up block (followed-up-by initials and date, both manual, with the guide noting only one follow-up fits for now and a second table may be needed later); procedure status (Proposed / Done, manual); total claims paid to date for this and related diagnoses (manual, usually filled in by claim examiners rather than nurses); free-form comments; a resolution block (resolution, resolved-by free text, resolution date, resolution user id) where filling any field obliges all of them; a Generate Outside Case Management Report button stamping report_dt each time; and a Generate CM button. These are the cm_potentials columns our code never writes — module Open questions 8.
  • Generate CM button (not built): resolve the potential's UM key back to a record type, open that category's maintenance screen with as much defaulted as possible, require the user to enter the case number manually, then on save return here and close the potential with resolution "Open a Case", today's date and the current user. It must refuse to run when cm_record_link is already populated, and must be unavailable for claim-generated potentials. The shipped wf_create_cm_case applies none of those three rules — see the module discrepancies.

UR Potentials — specified, never built

The guide describes a UR_Potential mechanism parallel to the CM one, with its own list window, maintenance window and outside report, and nothing in the extracted client references it (User Guide ch. 19). Recording it because the production table may still exist (module Open questions 13):

• Rows are created only by claim adjudication — never by hand — so that every row carries a valid claim id; the list offers no add and no delete.
• Columns: group, member name, SSN, claim number, UR entity, create date, follow-up, resolution, and the notification number of the UM record created in answer to the potential (manually entered by the user).
• Resolution vocabulary: Open a UM Record / Decline to Open a UM Record / No Response, with resolved-by, resolution date and resolution user id.
• A Generate Outside Utilization Review Report button produces a one-page report for the firm doing UR — the UR twin of the CM potential report below — and stamps report_dt.
• Purpose: in-house the claim message alone is enough to alert the nurses, but out-of-house UR firms do not dial into HOMER, so the potential record is the tracking system for possible UM issues. "At first this will be manual, but later will be automated."

Outside potential reports — specified, never built

Both potential maintenance windows were to print a single-page report to the firm performing CM (or UR) for the member, on paper or electronically — SAFECO is the guide's worked example (User Guide ch. 19). Contents: the CM/UR company display name, create date, status, the nurse or examiner who generated it, client name and account number, the client's confidential contact name, phone and fax, plan year, stop-loss carrier (CM report only), employee name and SSN, patient name, date of birth, address and phone, the claim number or UM notification number depending on generator, the attending physician and office phone, the diagnosis and procedure codes (from the UM record's selection criteria when UR-generated, from the claim's entry diagnoses and line procedure codes when claim-generated, blank when examiner-raised), procedure status, total claims paid to date, and comments. The client fax number is noted as a column that did not yet exist on group_contacts.

CM Potential Create (um_cm/w_um_cm_potential_create)

• Response window opened from the UR workspaces' "Create/Edit Potential CM" button; shares the caller's hidden potential DataWindow (d_um_cm_potential_create).
• On first create: key from sequence; CM firm entity from the plan package; entity_generator_cd = 'UR'; generator link = case number; generating user; status_cd = 'Normal'; procedure_status_cd = 'Proposed'; free-form comments. Display-only context: category, member name, SSN, entity name, group.
• Guide notes (User Guide ch. 19): while doing UR a nurse may decide CM is appropriate for a member and a specific service; these potentials are tied to the UM record rather than to a claim, which is what the Generator column distinguishes. Once created, the new potential's key should be stored on the service (um_services, "CM Potential Sys_key") and the button should change colour to show a potential already exists, and change again once it has been closed; clicking it thereafter just reopens the populated potential window. UR-generated potentials must be closed manually — there is no claim to close them — and closing one must write back to the generating UM record's status field (UMC-60). Neither the colour states nor the write-back exists in the extracted client.
• The purpose of the priority field is delivery order: notifications "need to get to case management and be handled in the order of priority: Urgent, Priority, or Normal", and where CM is done outside, the system generates the outside report instead — the client-level field decides who, if anyone, does CM (UMC-61).

CM Potential Resolution (um_cm/w_cm_potential_resolution)

• Response window sharing the selected potential row (d_um_cm_potentials_resolution); resolution dropdown is hard-coded: CaseOpened ("Case Opened"), No Case, null ("Unresolved") (dw_resolution::constructor).
• The user guide (ch. 19) states the resolution list is Open a Case / Decline to Open a Case / No Response, accompanied by a free-text "resolved by", a resolution date and a resolution user id, with an all-or-nothing rule across those fields (waived only when the potential is closed automatically by CM record generation) — discrepancy for SME confirmation. The guide also assigns responsibility: examiners may close potentials when a negative response comes back, while nurses must answer positive responses by creating the needed UM/CM record and then closing the potential, and somebody must be named to chase potentials that get no answer at all (UMC-60, UMC-61).

CM Billing (um_cm/w_cm_billing)

• Purpose: review, report and bill the automatically captured CM time.
• Criteria: date range, Group ID (validated; division ids are resolved up to the master group), Member ID, user id prefix, time type (codes UMTIMETYPE; captured values are Consult, Billable, Non-Bill), billed status (codes UMBILLSTTS; "Y" filters unbilled = null). Non-managers see only their own records (wf_retrieve).
• Content: editable grid of billing records (d_cm_billing_records: start time, elapsed minutes, type, case status at capture, user, case, billed status) grouped with computed totals; print composites for external and internal detail/summary formats (d_cm_billing_composite, d_cm_billing_composite_internal, d_cm_billing_report_*).
• Actions: update billing status (save), print the selected format.
• Why CM time is captured at all (User Guide ch. 19): Medillume III bills its clients for case management on the time nurses spend on a member's case. The billing unit is a 15-minute interval per access — a one-minute visit in the morning and another in the afternoon bill two intervals — and the clock runs from opening a CM member history record to closing it (UMC-54). A case in Void status was opened in error and must never be billed. The three time types are Consult (any user, whenever the case status is CONSULT), Billable (CM nurses and CM managers) and Non-Billable (everyone else) — the client implements this as UM-department membership (UMC-26).
• Three things the guide asks for that the extracted client does not have:
  • a monthly outstanding-CM report covering all member records for a month, broken and totalled by member, division and master group, showing actual time spent alongside billable time calculated;
  • a process to generate claims against the outstanding CM amounts for every member worked — medical claims on the default CM Rates benefit definition, with Medillume III as vendor, created in ready-for-adjudication status. This is almost certainly the origin of the KUMC% internal-CM fee claims the UM Claim Reports below select on (UMC-36) — confirm with the SME whether the generator still runs;
  • explicit 15-minute rounding (the client stores raw elapsed minutes).
• Stop-loss wrinkle: for certain clients the CM billable amount applies to specific and aggregate stop-loss deductible, to be handled by setting up 100% benefit rules for the CM Rates benefit definition. Flagged in the guide as an open problem.
• CM billing notes were to be attached to the billing records eventually; in the meantime they are member notes with search key CM.

Management Cases Report (um_cm/w_um_management_cases)

• Purpose: client-facing UM/CM caseload report.
• Criteria: master group list, case-date overlap range, show-id / show-name / show-referral toggles.
• Content: um_cm/d_um_management_cases — a five-branch UNION over um_cases/um_services with up to two diagnoses per service, patient age/gender, other-coverage flag (COB existence during the case window), CM involvement descriptions, and cases for unassigned dependents (patient_sys_key = -1 reported under the subscriber with an ND suffix); service-status (Serv%) records are excluded. Retrieval is guarded by the View > Retrieve menu enablement.
• Official name and access path (User Guide ch. 19): the Utilization Management Cases Report, reached from Application Functions → CM → Reports → Stoploss Report. It shows every case open during the requested date range for the requested group; entering a master group includes all its divisions, entering a division includes only that division. It returns to screen and can be printed or saved to disk as data.
• How to read the saved file — the guide's instructions, which decode the five-branch UNION:
  • There is one record per CM involvement recorded on a case, and one per service; the union divider column says which — 1 = service record, 2 = involvement record.
  • Units are the units allowed by the case manager, not the units used — claim data must be reviewed to find out what was actually consumed.
  • A case with two diagnosis codes produces two complete records, one per code, so units must never be summed blindly. The diag order column distinguishes them: 0 = involvement, 1 = primary diagnosis record, 2 = secondary diagnosis record, blank = service record with no diagnosis. To total units allowed for a case, count only rows whose diag order is 1 or blank.

Reports (um_main)

UM Claim Reports (um_main/w_umclaim_rpts)

• Sheet "UM Claim Reports" (menu m_umclaim_rpts) with a report dropdown:
  • UM Claims On Fund Register (d_umclaims_on_fund_register) — internal-CM claims (claim id like KUMC%) joined to fund register / fund transactions with check number and cleared date.
  • UM Claims Unpaid (d_umclaims_unpaid) — KUMC% claims not in PAID status.
  • UM Claims With Open Messages (d_umclaims_open_messages) — KUMC% unpaid claims having open claim messages.

Possible CM Claim Report (um_main/w_cm_possible_rpt)

• Lists claims flagged as possible CM cases in a create-date range: diagnosis + description, group, subscriber and patient (name, SSN), total claimed amount, message sequence (um_main/d_cm_possible_rpt over um_cm_possible_case_claim joined to claims/members/diagnoses). The rows are produced outside the client application (see module Open questions).

UM Entities Report (um_main/w_um_entities_report)

• Prints the UR/CM entity registry by type (um_main/d_um_entities_report).

Reference-data maintenance (um_maint)

UM Entity Maintenance (um_maint/w_um_entity_maintenance)

• Purpose: maintain UR/CM firms (um_entities), the warnings shown for them, and their medical directors. Menu set m_um_entity_maintenance_menu (+ director/warning variants).
• Field groups (Entity tab, d_um_entity_maintenance): entity type (value list UR, UR/CM, CM), names (name, display name, entity display name), contact person, phone/fax/e-mail, address number, suppress-warning flag, CM trigger assignment (select via w_cm_trigger_select).
• Validations: entity type, name and suppress-warning flag required; a CM entity must have a CM trigger set; changing the entity type of an existing entity warns that all attached warnings will be removed and deletes them on confirmation; the trigger-select button refuses non-CM entities ("CM Trigger Only applies to CM Entities") (ue_validate, itemchanged, buttonclicked).
• Warnings tab (d_um_entity_warnings): attach warnings from the catalog (pick via w_um_warning_select).
• Directors tab (d_um_entity_directors): attach medical directors (pick via w_medical_director_select, typed via dddw_medical_director_types).
• Guide notes (User Guide ch. 19): entities exist because Medillume III is not the only firm doing UR and CM. They are defined once, reusable across packages, and attached to a plan/package as that package is defined — each package in a plan may name a different entity. The expected population was small (about ten), which is why the design is a selection window with double-click edit and right-click add. Users may never delete an entity — "MIS will delete entities for the users should the need ever arise" (UMC-62); the extracted window does permit deletes, a discrepancy for SME confirmation.
  • Naming convention: standard SFPI Basic and M3 Basic entities cover most of the client base; clients needing special warnings get their own (SFPI/Group), and outside entities always get their own. Access was to be through the Plan menu, not the UR/CM menu.
  • Ownership: the Director of UM creates entities, warnings and medical directors and maintains them until the data is trustworthy, after which Client Maintenance takes over entities, warnings and directors. Client Maintenance selects the trigger appropriate for a CM entity but never creates or maintains trigger data — that stays with the CM/UM manager.
  • The entity record carries address, phone, fax, e-mail and contact person as well as name and display name; the display name is what appears on the warning screen and on the outside potential reports. The CM trigger link is suppressed unless the entity type is CM — matching the shipped validation.

Warning Maintenance (um_maint/w_warning_maintenance)

• Catalog editor for um_warnings (warning, type, message — d_warning_maintenance); menu m_warning_maintenance. These warnings appear in the search-time warning display when attached to a member's UR/CM firm.
• Guide notes (User Guide ch. 19): warning type is UR or CM, chosen from a dropdown, and the type is what decides which warnings a given entity may carry. Warnings are deliberately reusable — the design is two list boxes with an arrow to move the wanted ones onto an entity — and the expected population was fewer than ten. As with entities, users may never delete a warning; MIS does it on request (UMC-62). Changing an entity's type removes its warnings, which the shipped window confirms before doing. Sample UR and CM warning texts are listed with the warning display screen.

Medical Director Maintenance (um_maint/w_medical_director_maintenance)

• Registry editor for medical_directors with type codes (d_medical_director, dddw_medical_director_types); duplicate-name lookup helper um_main/u_urcm_sql of_count_medical_directors. Select popup: w_medical_director_select ("pick medical director for um_entity_medical_directors").
• Guide notes (User Guide ch. 19): the type dropdown is "Medical Director" or "Independent Reviewer", and it is what filters the reviewer list on a rule's review record — Medical Director for review types "Medical Director" and "Medical Director Appeal", Independent Reviewer for "Independent Review" and "Independent Review Appeal" (UMC-18). Specialty is to be validated against the provider specialty codes, and the record carries address, phone, fax and e-mail. Directors are tied to entities through entity maintenance; this window was to hang off the UR/CM menu while entity setup hung off the Plan menu. Worked examples in the guide: Dr. Sheldon and Dr. Davidson as medical directors; Professional Peer Review, Concentra and Innovative Health as independent reviewers.
• Medical directors also need note access — to read and to write — which the guide repeats in every category's review section and suggests handling in a separate window. Whether the shipped w_medical_director_review satisfies that is worth an SME check, given UM notes are restricted to UM/CM users (UMC-57).

CM Trigger Maintenance (um_maint/w_cm_trigger_maintenance)

• Purpose: maintain named CM trigger sets (cm_triggers) and their diagnosis-code and procedure-code lists.
• Content: trigger header (name, description — d_cm_trigger), diag-code tab (d_cm_trigger_diag_codes) and proc-code tab (d_cm_trigger_proc_codes), each row carrying network affiliation, dollar threshold and Inpatient/Outpatient/All scope; new rows default the threshold to 0; a refresh copy function mirrors codes between tabs; codes report (d_cm_trigger_codes_report) printable. Select popup: w_cm_trigger_select.
• Trigger sets are assigned to CM entities (entity maintenance) and drive the claim-side identification of CM candidates.
• What the triggers are for (User Guide ch. 19): for each CM entity the system needs "triggers" — selection criteria defining which claims may need case-management attention. The nightly batch evaluates them in the Audit step, after failing to match the claim to an existing CM case and then to medical-necessity data, and on a hit raises both a claim message to the nurses and a cm_potentials row, once per claim detail line (module Open questions 1).
• Four trigger forms are named, each with a claimed-dollar threshold: a HCPCS code, an ICD-9 code, a benefit definition, and "a UR record indicating CM exists". The extracted maintenance window supports the first two (diagnosis and procedure code tabs) — benefit-definition triggers and the UR-record trigger have no maintenance UI; the user guide (ch. 19) states all four should exist — discrepancy for SME confirmation.
• Priority per code. Every trigger code was to carry a priority level — Urgent, Priority or Normal — and the claim message raised by it must include that level (UMC-61). The shipped cm_trigger_* rows carry network affiliation, dollar threshold and inpatient/outpatient scope but no priority column, and claim-generated potentials always come out Normal — discrepancy for SME confirmation.
• Provenance of the rule set: the original triggers were transcribed from the rules in the legacy "Case Management Alert" report; the design anticipated alternate rule sets assigned per benefit package during Plan Design.
• Maintenance rules: each trigger set is defined once and reusable across entities; users may delete individual lines but not trigger sets (UMC-62); the codes are validated against the valid-codes and code-type tables; and the window belongs on the Case Management branch of the UR/CM menu, owned by the CM manager rather than Client Maintenance.

Vendor extract jobs (um_maint)

File-generation windows for external CM / disease-management vendors; each takes a date range and target file names, retrieves an extract DataWindow and writes fixed-format text files:

Window	Purpose
um_maint/w_matria_enrollment_dump	"Create Matria Enrollment Files" — enrollment data file + control file (d_matria_enrollment_dump, d_matria_enrollment_control_file); menu m_matria_dumps.
um_maint/w_matria_claim_dump	Matria claims data + control file (d_matria_claims_dump, d_matria_claims_control_file).
um_maint/w_hcrm_enrollment_transfer, w_hcrm_claims_transfer	HCRM enrollment / claims transfer files (d_hcrm_enrollment_transfer, d_hcrm_claims_transfer, d_hcrm_claims_dump).
um_maint/w_springbuk_enrollment_transfer, w_springbuk_claims_transfer	Springbuk enrollment / claims transfer files (d_springbuk_enrollment_transfer, d_springbuk_claims_transfer).
um_maint/w_dm_enrollment_dump	Generic disease-management dump, opened twice from the menu with parameter "Enrollment" or "Claims"; vendor chosen from the DM entity registry (d_dmentities, d_dmentities_dump_select); writes <prefix><type><MMDDYYhhmm>.TXT for prefixes dmqual / dmhcs (wf_generic_enrollment_export / wf_generic_claims_export), with an "Executing Oracle Procedure..." progress state.
(DataWindows only)	d_bluebook_eligibility_transfer, d_principle_enrollment_transfer — transfer formats with no host window in these libraries.

Matria: the documented operating procedure (User Guide ch. 19)

Matria is the only vendor interface the guide writes up, and it does so as a monthly manual runbook rather than a scheduled job — worth capturing because it establishes the cadence and the hand-off:

• Burns Consulting connected OME-RESA with Matria for case management; to let Matria do that work, SFPI transfers eligibility and claims data monthly, with the prior month's files shipped before the 15th of the current month.
• Menu path UR/CM → Matria, two options (Enrollment Transfer, Claims Transfer); both must be run, and each produces a data file and a control file. The operator enters the date range — the file names embed the dates and update as the dates change — clicks Run, then Save, and answers a save prompt per file. Default directory Nurse\Matria.
• The four files are zipped in pairs as <yyyy>_<monthname>_eligibility.zip and <yyyy>_<monthname>_claims.zip, then uploaded to a third-party file-sharing site, after which the loose text files are deleted and the zips filed under Nurse\Matria\Claims or Nurse\Matria\Eligibility.
• Nothing equivalent is documented for HCRM, Springbuk, the generic DM dumps, Bluebook or Principle — see module Open questions 10.

Credentials in the source document

The guide text spells out a shared account username and plaintext password for that upload site. They are deliberately not reproduced here. Treat them as compromised, and do not carry the shared-account pattern into the target system — replace it with per-user credentials or an automated, authenticated transfer.