Reports Catalog

Source: report windows across all libraries (inventory.json window titles and comments), the dedicated report libraries clmrpt, cobrarpt, enrolrpt, the reporting subsystem in reprint (n_cst_reportobject, w_reprint*), and the report_hist table writers.

Operational model (User Guide ch. 13)

The user guide describes how reporting actually ran day to day:

• Two output methods. Most output is printed immediately by the requesting user. Four output classes are requested during the day but printed later: check registers, EOB/RA, claim letters, and ID cards (User Guide ch. 13).
• Nightly cycle. The nightly batch process runs as two conceptual pieces: first the check run, then the reports requested during the day, driven by a report request table holding program, report ID, and parameters. Reports produced at night are always placed in the print queue in held status and must be released by a user; because everyone prints locally, the destination printer is chosen through the queue manager (User Guide ch. 13). (Portions of this section read as design intent — e.g. "Are we going to use Crystal Reports?" — so treat details as the plan the system grew from, verified where code corroborates them.)
• Print queue access tiers. What a user can see and manipulate in the queue is security-driven: most users only their own print requests; department managers all requests from their department plus their own; MIS staff everything (User Guide ch. 13).
• Queue manager operations. View queued data; release held output; re-queue and hold released output (as long as it has not finished printing); delete held output; edit held output (only in some cases); set number of copies; set collate/stack options; route held output to an available printer; attach held output to e-mail. The queue is reached via Tools > Reporting (not available on every window) (User Guide ch. 13).
• Queue is transient. Once output has been released and has completely printed it is no longer present in the print queue; "other methods must be employed to recover output that has previously been printed. These methods may not always be successful" (User Guide ch. 13) — i.e., the durable reprint path is the report-history mechanism below, not the queue.
• Font standards. Printed reports default to Arial; reports specific to Self-Funded Plans Inc. (not used by Medillume III) use Times New Roman; screen fonts for reports may remain Sans Serif 8pt (User Guide ch. 13).

Reporting subsystem: how report history works

The report object and report_hist

reprint/n_cst_reportobject ("Master object for loading reports into the report_hist table") is the shared engine for durable, reprintable output:

• A report is a DataWindow object plus up to 20 retrieval parameters (of_setdataobject, of_setparms, ue_retrieve).
• of_insert_into_report_hist inserts a REPORT_HIST row carrying: report_sys_key, report_type_cd, report_desc, report_data (blob), orig_run_dt, requesting user and request date, group_id, check_number, worksheet_number, payee_sys_key, recipient id/type, batch_id, dw_object (the layout name needed to re-render), format_type, and reissue_days.
• The stored blob is either the rendered report (PSR format, of_convertpsrtoblob) or just the data rows (DATA format, of_convertdatatoblob), selected by of_converttoblob(..., as_Format) — with DATA, the saved dw_object re-renders the rows on reprint.
• A parallel of_insert_into_claim_letters_hist records claim letters in claim_letters_hist; claims/n_reportobject_claims_letters specializes the object for claims letters.

Sequence keys come from the database (report_hist_seq.nextval — e.g. enroll/w_enroll_hipaa_generate line ~502). Some producers write the row and then UPDATEBLOB report_hist SET report_data = ... in a second step (HIPAA and custom termination letter generation).

Print queue and reprint

• reprint/w_reprint ("print queue manager", DataWindow d_reprint over report_hist joined to user_info) prints queued output; reprint/n_cst_reprint_func re-instantiates stored blobs via a temp file and prints them (of_printpsr, of_printdata).
• reprint/w_reprint_maintenance searches REPORT_HIST with a dynamically built filter (report type wildcard, internal vs. external payee, group, check number) and retrieves the blob for view/reprint (lines ~200-256).
• After printing, producers set prt_flg = 'Y' on the row (e.g. enroll/w_enroll_hipaa_print line ~346), so "unprinted only" filters work.
• Check/EOB re-prints use the chkrundw library DataWindows (d_checkrun_eob*, d_checkrun_claim_lines, d_checkrun_claim_pricing) via clmprint/n_check_copy and reprint/w_reprint_maintenance; reprint/w_reprint_check_recon covers check reconciliation output.
• Group-specific print distribution (how many copies of what go to which recipient) is maintained in reprint/w_group_print_distribution.
• system/w_letter_on_cd retrieves archived claims letters "stored on CD" via the same reprint objects.

Billing report queue (separate store)

Billing runs write their outputs to a dedicated bill_reports table; users view/print them from billing/w_bill_queue ("Billing Reports View and Print", d_bill_bill_reports_list, with an unprinted-only checkbox and per-run delete DELETE FROM bill_reports WHERE bill_def_sys_key = ... AND bill_run_sys_key = ...).

Batch report registry

homersys/w_batch_reports maintains the batch_reports table: report_cd, report_name, report_dw, report_parameter_window, report_type, allow_run_events, allow_times (homersys/d_batch_reports). This is a registry of reports that can be run by a batch mechanism with event- or time-based permissions; reprint/w_parameterwindow is the "Generic parameter window for use with n_cst_reportobject" that such registered reports name.

The user guide documents this screen ("Batch Reporting Maintenance") with the banner "Note that this function is currently under construction" and states: "Window used to define reports and report objects that would be available to a batch report scheduler. Functionality of the Batch Report Scheduler is currently incomplete" (User Guide ch. 13). So batch_reports is the registry for a scheduler that was planned (the nightly-cycle design above) but not completed in the client application — consistent with no runner being found in source. One concrete scheduled job did exist operationally: the Claims Entry Daily Report "is run automatically every Monday morning" (User Guide ch. 13), implying a server-side or operations-run mechanism outside the client source.

Report blob storage and archival (n_report_data)

Distinct from report_hist, the guide documents a second, generalized storage engine, n_report_data, writing two tables (User Guide ch. 13, "Report Object"):

• REPORT_DATA holds report metadata — type, description, and "information regarding archival and disposition".
• REPORT_OBJECT holds the report blob itself (PSR supported at the time; PDF and others anticipated), with a sequence number so one logical report can span multiple stored files.
• Each consuming application creates its own search/link table (e.g. a CLAIM_REPORTS table with group, date range, description, status, and a report_data_sys_key foreign key) with whatever indexed columns users need to find the report.
• Retention/archival design: upon archival, REPORT_OBJECT rows (the blobs) can be deleted while the REPORT_DATA row remains, recording where the objects were archived (User Guide ch. 13).
• Mechanics: blobs cannot be inserted directly from PowerBuilder, so the object stages temporary RPTTMPxx.PSR files on the user's C: drive, inserts rows, then UPDATEBLOBs them; the caller owns commit/rollback and must call of_DestroyReportData to clean up the temp files.

How n_report_data/REPORT_DATA relates to n_cst_reportobject/REPORT_HIST (predecessor, parallel store, or abandoned design) is a discrepancy for SME confirmation — the extracted reprint screens read report_hist, and no REPORT_DATA writers were catalogued in this pass.

Client-based report wizard and the report_info registry

The guide documents the sales/client-based reporting interface (sales/w_sales_report_sheet, w_sales_report_wizard, n_cst_sales_report_wizard, n_cst_sales_reportobject) in detail (User Guide ch. 13, "Reporting Interface for Client Based Reports"):

• Reports are registered in a report_info table: report_type_cd, report_cd, description, report_object, report_dw (display layout), report_dw2 (save layout), parameter_mask, allow_ext_view, plus audit columns.
• parameter_mask is a bitflag sum enabling parameter fields on the wizard's parameter screen: 1 = Coverages, 2 = Paid From, 4 = Paid Through, 8 = Incurred From, 16 = Incurred Through, 32 = As-of Date (e.g. 25 = Coverages + both incurred dates).
• allow_ext_view marks whether a report may be shown/run "outside of the company" — the report sheet is opened with a flag selecting externally viewable reports only, or all reports.
• Reports take up to 20 parameters; when the group-selection screen is used the first parameter is always the selected-groups array; the wizard can run one combined report or a separate report per group.
• All client-based reports are landscape for uniform presentation, and share the common parameter set (groups, coverages, incurred/paid ranges, as-of date) (User Guide ch. 13).

Distribution practice (User Guide ch. 13)

• Restricted runners. The Daily (check-run) Stoploss report could be run by only one named user; the Yearly Claims Savings report is run once a year by a named individual (it "uses an extreme amount of system resources") who places the results on the network for sales staff.
• Reviewed before release. UM/Case Management reports must not be given out without UM-department review of each client's cases first ("There is a large margin for miscommunication in UM data").
• Separate secured application. Management reports live in an application separate from Homer with added per-user security; unauthorized users get a warning.
• Data extracts ship with instructions. The Export Eligibility and Accumulator Report client-data extracts are files (not printed) and must never be sent without the file-layout instruction documents kept on a network share.
• Auto-routing. The Specific Stoploss Summary has no print icon and routes automatically to the user's default printer on completion.
• Screen-print fallback. Some reports do not print at all (Members Claims Affecting Accumulators, UM Follow Up) — users are told to Alt+PrintScreen into Word/Wordpad.

Balancing rules between reports (User Guide ch. 13)

The guide records which client-based reports reconcile to which — operational knowledge worth preserving for parallel-run validation during migration:

• Claimant Register balances to the Payments report.
• Payments Detail/Summary balance to the Claimant Register.
• Check Listing does not balance to the Claimant Register or Payments (it excludes voids, adjustments, and WDI tax payments).
• HCN Summary balances only to the Provider Summary (not to Savings Summary or Coverage Analysis; it does not count rejected or duplicate lines).
• Claims by Plan balances to the Coverage Analysis report.
• Savings pulls claims by first payment date, giving it a unique claim set other paid-date reports will not match.
• The Moon internal reconciliation is balanced against prior Moon Negotiated Savings By Month reports; the PHCS Summary is balanced to the PHCS Detail and the previous month's employer bills.

Catalog by business area

Names below are the window objects (the operative report definitions are the DataWindows each window retrieves). Purposes are taken from source comments and window titles; where blank in source, the name is descriptive enough.

Claims (clmrpt, plus clmforms, sales)

Report window	Purpose / title	Key selection criteria
w_rpt_group_claim_bendefs	Detailed Claims Listing by Benefit Definition	group, benefit definition
w_rpt_group_claim_benrules	Detailed Claims Listing by Benefit Rule Type	group, rule type
w_rpt_group_selected_accums	Accumulators by Member	group, accumulator selection
w_rpt_member_accum_rulemax	Member Accumulators by Benefit Rule	member (embedded member search)
w_clmrpt_accum_rpt	Member Accumulator Listing for groups	group
w_clmrpt_member_accum_search	Member accumulator display by member criteria	member criteria
w_claimrpt_large_claim_report	Large claim report	thresholds
w_clm_claimed_amt_morethan	Claims with claimed amount above a threshold	amount threshold
w_clmrpt_claims_older_than_90_days	Claims older than 90 days	group or all
w_clmrpt_open_messages	Claims with open messages	status
w_clm_message_status_summary	Claim message status summary	—
w_clmrpt_status_count	Count of claims in each status	—
w_clmrpt_outstanding_adjustments	Claims with outstanding adjustments	group
w_clmrpt_outstanding_refunds	Outstanding refunds	group or all
w_clmrpt_outbound_aging_tv	Claims - Outbound Aging (treeview)	age
w_clmrpt_outbound_edi_older_than_10_days	Outbound EDI claims with no response after 10 days	age threshold
w_no_group_id_fix	Claims with no Group ID assigned	—
w_nobs_group_rpt	Group report (NOBS)	group
w_cigna_p4p	Cigna Pay for Performance reporting	—
w_ppaca_letters	PPACA letters (report picked from drop-down, per claim)	report name, claim id
w_state_report (homersys)	Members and claims for specified states over time	states, date range
clmforms/w_claim_status_listing	Claim status listing	—
sales/w_sales_rpt_group_claim_detail	Detailed Claims Listing by group, claim type, paid dates	group, claim type, paid dates
sales/w_sales_report_wizard / w_sales_report_sheet	Reporting wizard (parameterized report family)	wizard-driven

Enrollment / membership (enrolrpt, enroll, enrollutils)

Report window	Purpose / title	Key selection criteria
w_annlstmt	Annual employee benefit statement generation	group, member
w_annlstmt_option_maintenance	Maintain annual statement options	—
w_census_rpt_args_sheet / w_census_rpt_display	Census reports	census parameters
w_enrollrpt_deps_over_age	Dependents over age NN	age
w_enrollrpt_error_rpts	Enrollment error reports (e.g. single member with multi-person coverage)	error type
w_hb1_report	HB1 Member Report	—
w_dep_audit	Dependent Eligibility Audit (also creates Matria claim files)	group
w_mmo_audit	MMO audit	—
enroll/w_hipaa_cert_report	Run/print HIPAA certificate report	member/date
enroll/w_notes_hipaa_report_view	HIPAA notes report	—
enrollutils/w_fsa_notices	Flexible Spending Account notices and summary listings	plan year
enrollutils/w_fsa_depcare_tax_statements	FSA dependent-care tax statements	year
client/w_client_census_rpt_args_sheet / _display	Client census reports	client

COBRA (cobrarpt, cobra)

Report window	Purpose / title	Key selection criteria
w_cobrarpt_select_criteria / w_cobrarpt_display	COBRA Reports (criteria then display)	report type, criteria
w_cobra_printlabel_select	COBRA mailing label selection	—
cobra/w_cobra_printqueue	Main print queue for COBRA letters	letter type, group
cobra/w_cobra_letter_errors	COBRA letter generation errors	—

Funding / banking (funding)

Report window	Purpose / title	Key selection criteria
w_fund_funding_status	Funding Status Report	group, period
w_fund_fund_page_listing	Fund Page Listing Report (setup completeness)	—
w_fund_negative_balance	Negative balance report (screen version)	—
w_fund_reconcile_report	Bank Reconciliation report	account, period
w_fund_outstanding_checks	Outstanding checks	account
w_fund_check_process_err_rpt	Fund check processing error report	run
w_fund_wdi_period_rpt / w_fund_wdi_period_as_modified_rpt	WDI period reports (as billed / as modified)	period
w_fund_delinquent_claims_summary / _detail	Delinquent claims funding	group
w_withholding_reports	Withholding claims and census reports by state	states, date range

Billing (billing)

Report window	Purpose / title	Key selection criteria
w_bill_queue	Billing Reports View and Print (bill run outputs)	bill definition, run, unprinted flag
w_bill_reports	Billing Exception Report	run
w_billrpt_flex_charges	Flex Charge Billing report	period
w_billprt_disbursement_division_summary	Disbursement division summary	run

The billfunc library holds the d_billprt_* print DataWindow family (charge summaries, disbursement summaries, mailing pages, rate details).

Utilization / case management (um_cm, um_main)

Report window	Purpose / title	Key selection criteria
um_cm/w_um_cm_potentials_report	CM Potentials Report	criteria
um_cm/w_um_management_cases	UM management cases report	—
um_cm/w_cm_billing	CM billing reports and maintenance	period
um_main/w_cm_possible_rpt	Possible CM claim report	—
um_main/w_um_entities_report	Entity report	entity
um_main/w_umclaim_rpts	UM claim reports	—

Stop-loss (stoploss)

Report window	Purpose / title	Key selection criteria
w_sl_spec_clm_listing	Specific Stoploss Claims Listing	member (embedded search), contract
w_sl_variable_clm_listing	Variable date-range stop-loss claims listing	member, date range
w_sl_specific_rpt	Specific stop-loss report	contract

Provider / network (provider), system and security

Report window	Purpose / title	Key selection criteria
provider/w_provider_rpt_hcn_pricing_methods	HCN pricing methods report	network
provider/w_hms_report / w_hms_reporting / w_hms2	HMS reporting extracts	period
homersys/w_edi_report	EDI submitted by group	group
homersys/w_pridecare_bill_data	Pridecare bill data report	—
homersys/w_release_notes	Release notes viewer	version
app_sec/w_sec_report1	Security report	—
idcard/w_enroll_idcard_usfhp	USFHP ID card request listing and letters	request batch

Requirements

• RPT-1 Reports and printed documents that may need reissue (checks, EOBs, worksheets, letters, statements) shall be persisted at generation time as a report-history record holding the rendered output (or its data plus the layout identifier), report type, description, original run date, requesting user, and business keys (group, check number, worksheet number, payee, recipient, batch) (reprint/n_cst_reportobject::of_insert_into_report_hist).
• RPT-2 Persisted output shall support two storage formats — fully rendered, and data-only re-rendered through the saved layout — chosen per report (n_cst_reportobject::of_converttoblob — PSR vs DATA).
• RPT-3 Users shall be able to search report history by report type, group, check number, payee class (internal/external) and date, preview the stored output, and reprint it (reprint/w_reprint_maintenance, reprint/w_reprint).
• RPT-4 Each history record shall track whether it has been printed (prt_flg), and print queues shall support an "unprinted only" view (enroll/w_enroll_hipaa_print, billing/w_bill_queue).
• RPT-5 Claim letters shall additionally be recorded in a claim-letter history keyed to the claim (n_cst_reportobject::of_insert_into_claim_letters_hist, claims/n_reportobject_claims_letters).
• RPT-6 Billing-run outputs shall be queued in a billing report store and be viewable, printable, and deletable per bill definition and run (billing/w_bill_queue).
• RPT-7 The system shall keep a maintainable registry of batch-runnable reports naming the report code, layout, parameter-collection screen, type, and whether event-triggered and/or time-triggered execution is allowed (homersys/w_batch_reports, batch_reports table).
• RPT-8 Per-group print distribution rules (recipients/copies) shall be maintainable and honored when printing report batches (reprint/w_group_print_distribution).
• RPT-9 Deferred output classes — check registers, EOB/RA, claim letters, and ID cards — shall be requested during the day and produced by the nightly cycle (check run first, then requested reports), entering the print queue in held status until a user releases them to a locally chosen printer. (User Guide ch. 13)
• RPT-10 Print-queue visibility and manipulation shall be tiered by security: requesters see their own output, department managers their department's, and MIS/administrators everything. (User Guide ch. 13)
• RPT-11 The print-queue manager shall support: viewing queued output; releasing held output; re-queuing/holding released output until printing has finished; deleting held output; editing held output where permitted; setting copy counts and collate/stack options; routing to a chosen printer; and attaching held output to e-mail. (User Guide ch. 13 — design-era statement; verify against reprint/w_reprint capabilities before carrying each item forward*)*
• RPT-12 Printed output that has left the queue shall remain recoverable only through the report-history store (RPT-1/RPT-3); the queue itself is transient. (User Guide ch. 13; reprint/w_reprint_maintenance)
• RPT-13 Client-based/sales reports shall be driven by a report registry (report_info) naming the display and save layouts, a parameter-enable mask (coverages, paid range, incurred range, as-of date), and an external-visibility flag restricting which reports can be run or viewed outside the company. (User Guide ch. 13; sales/w_sales_report_wizard)
• RPT-14 Stored report blobs shall support archival: the blob rows may be purged to archive media while the metadata row is retained and records the archive location. (User Guide ch. 13, REPORT_DATA/REPORT_OBJECT design; see the SME item on how this relates to report_hist)
• RPT-15 Sensitive report families shall carry distribution controls: management reports restricted per user in a separate secured application, UM reports gated behind departmental review before client release, and client-data extracts accompanied by their file-layout instructions. (User Guide ch. 13)

Open questions

• The full report inventory ultimately lives in DataWindow objects (2,110 in analysis/datawindows.json); the tables above list the user-facing report windows. A per-DataWindow layout inventory should be generated per module during migration. The user guide (ch. 13) is now the best available source of per-report purposes, parameters, columns, totals, and claims-selection rules for the census, claims, COBRA, stop-loss, funding, sales/client-based, Moon, and management report families — use it as the layout-inventory companion.
• Batch scheduler — RESOLVED. batch_reports.allow_run_events / allow_times belong to a Batch Report Scheduler the guide describes as "currently under construction" / "currently incomplete"; the registry screen existed ahead of the runner, and the intended design was the nightly cycle's report request table (program, report ID, parameters) (User Guide ch. 13). No client-side runner should be expected in source; only the Monday-morning Claims Entry Daily Report is documented as actually running automatically (see Batch Processing).
• Several report windows have neither title nor comment; the guide resolves some purposes (e.g. most census variants, State Report, WDI period reports) but clmrpt/w_nobs_group_rpt and enrolrpt/w_mmo_audit appear in neither source comments nor the guide — purposes still need user confirmation.
• system/w_letter_on_cd implies an offline letter archive on optical media; confirm whether that archive must be readable post-migration. Related: the guide's REPORT_DATA/REPORT_OBJECT design allows blob purge-to-archive with metadata retained (RPT-14) — confirm with the DBA which store the CD archive and any purge jobs actually used, and what retention report_hist has in practice (no in-code purge of report_hist was found; the guide is silent on a retention period).
• Two report-storage engines. The guide documents n_report_data writing REPORT_DATA/REPORT_OBJECT; the extracted reprint subsystem uses n_cst_reportobject writing REPORT_HIST. Whether the former is a predecessor, a parallel store for specific applications, or an abandoned design is a discrepancy for SME confirmation.
• The guide's queue-manager feature list (edit held output, e-mail attachment, collate/stack) exceeds what the extracted reprint/w_reprint screens evidence; parts of ch. 13's front matter are design-era text. Code wins for behavior — treat the extra capabilities as unverified intent (RPT-11 note).