User Guide Reconciliation

This page reconciles the official HOMER user guide — 28 chapters plus a table of contents, recovered from Documentation/*.DOC and extracted to _re/userguide/*.txt — against the reverse-engineered client source (_re/src/, 3,284 objects across 53 PBLs) and the inferred database schema (_re/analysis/schema.json, 456 tables).

Its purpose is migration scoping. Two questions are answered: which guide chapters are already covered by this documentation set, and — the part that actually changes a migration estimate — which chapters name functionality for which no implementation exists in the recovered client binaries.

Guide vintage — code citations win

The guide is a layered document assembled over roughly 25 years. CONTENTS.DOC still prints a 5/12/98 footer and hyperlinks the original 1998 chapter layout. Individual chapter files were last saved between 2009-08-28 (a bulk copy event that touched 16 of the 29 files) and 2022-11-08. Internal page footers lag further still: Chapter 27 is stamped 7/20/98, Chapter 12 is stamped 12/9/99, Chapter 4 is stamped 4/5/00.

Several "chapters" are not user documentation at all — they are 1995–98 meeting minutes, work-request lists, and MIS wishlists pasted under a chapter heading, and five chapters are title pages with no body. Chapter 4 opens with the author's own disclaimer: "Highlighted text indicates it was changed but not reviewed."

Where the guide and the extracted source disagree, the source governs. Treat guide prose as statement of intent at some past date, not as a description of current behaviour.

Chapter-by-chapter coverage map

"Owning page" is where that chapter's material lives (or would live) in this documentation set. Dates are the .DOC file modification date; where a different date is printed in the chapter's own page footer it is given in parentheses, because the footer is usually much older than the file.

Ch.	Guide title	Guide date	Owning docs page	Status
1	Enrollment/Eligibility	2010-03 (footer 3/12/2010)	modules/enrollment (plus modules/cob-preex, modules/drug-plans, modules/id-cards)	Integrated
2	Client Maintenance	2010-03	modules/groups-plans/screens-client	Integrated
3	COBRA Administration	2009-08	modules/cobra	Integrated
4	Billing (A/R)	2009-08 (footer 4/5/00)	modules/billing	Integrated
5	Funding	2010-04	modules/funding	Integrated
6	Plan Design	2013-11	modules/groups-plans/screens-benplans	Integrated
7	Provider Maintenance	2022-11 (newest chapter)	modules/providers/screens-provider	Integrated
8	Commissions	2009-08 (body is 1996–98 meeting notes)	modules/billing (nearest owner; see deep dive)	No client implementation found
9	Client Service Log System – Notes	2009-08 (footer 8/28/00)	modules/service-log	Integrated
10	Claims Entry	2010-03	modules/claims/screens-entry	Integrated
11	Adjudication	2010-03	modules/claims (index and screens-entry)	Integrated
12	Repricing Rules	2009-08 (footer 12/9/99)	modules/providers/screens-pricing-moon	Integrated
13	Reporting	2012-07	cross-cutting/reports	Integrated
14	Claims Output	2009-08	modules/claims/screens-reports	Integrated
15	Capitation	2009-08 (footer 1/13/98)	— (see deep dive)	Empty file — and no client implementation found
16	Auditing	2009-08 (footer 7/23/04)	modules/claims/screens-management	Integrated
17	Stoploss	2009-08	modules/stoploss	Integrated
18	Case Management	2009-08 (footer 1/13/98)	modules/um	Partially integrated — 1995–98 notes, superseded by ch. 19
19	Utilization Review/Case Management	2010-02	modules/um	Integrated
20	Sales Support	2009-08 (footer 1/13/98; body is a 2/96 wishlist)	modules/groups-plans/screens-client (Client and Sales)	Partially integrated — reporting only
21	Managed Care (Budgeting)	2009-08 (footer 1/13/98)	— (see deep dive)	Empty file — and no client implementation found
22	Miscellaneous	2009-08 (footer 06/04/2008)	cross-cutting/batch-processing, cross-cutting/integrations, cross-cutting/navigation, architecture/as-is-architecture	Integrated
23	Programming Standards	2010-06	architecture/as-is-architecture	Integrated
24	SFPI AP	2009-08 (footer 1/13/98)	modules/funding (nearest owner; see deep dive)	Empty file — external back office
25	SFPI HR	2009-08 (footer 1/13/98)	— (see deep dive)	Empty file — no client implementation found
26	SFPI AR	2009-08 (footer 1/13/98)	modules/billing (nearest owner; see deep dive)	Empty file — external back office
27	Glossary	2009-08 (footer 7/20/98)	overview/glossary	Integrated
28	Security	2009-08	cross-cutting/security-model	Integrated

The five empty chapters

Chapter 26 is not the only title-only file. Verified by line count and full read, five chapter files contain nothing but a heading and a footer:

File	Bytes	Lines	Entire content
chaptr15.txt	64	9	"CHAPTER 15 / Capitation" + footer 1/13/98
chaptr21.txt	77	10	"CHAPTER 21 / Managed Care / Budgeting" + footer 1/13/98
chaptr24.txt	59	7	"CHAPTER 24 / SFPI AP" + footer 1/13/98
chaptr25.txt	58	6	"CHAPTER 25 / SFPI HR" + footer 1/13/98
chaptr26.txt	58	6	"CHAPTER 26 / SFPI AR" + footer 1/13/98

All five carry the same 1/13/98 footer: they were reserved in the original 1998 table of contents and never written, then carried forward untouched through every later revision of the guide. Two further chapters (8 Commissions, 1,375 bytes after the heading, and 20 Sales Support, 2,819 bytes) have bodies but those bodies are 1996–98 requirement notes, not descriptions of built software.

Deep dives: chapters with no obvious code

Chapter 15 — Capitation

What the guide describes. Nothing. The chapter is a title page (see table above).

Verification against the extract.

• Menu. homersys/m_sys_frame.srm declares m_capitation under the Providers menu with caption "&Capitation". Its create event sets this.tag = "For future use", this.visible = false, this.enabled = false, and the item has no clicked event — a dead, hidden placeholder. Every library that inherits the frame menu carries a copy of this declaration, which is why a naive grep for "capitation" hits roughly twenty files.
• The one functional trace. provider/d_contracts.srd carries a "Capitation Vendor:" label, a display column dummy_cap_vendor, and stores the selection in contracts.vendor_sys_key; provider/w_provider_contract_maintenance.srw implements cb_capitation_vendor_search, a vendor lookup button. A provider contract can therefore record which vendor is capitated. Nothing reads it back.
• False friend — check this before trusting a grep. The cap_rate hits in provider/d_contracts.srd and pricing/d_pricing_plan_methods.srd are not capitation. The underlying columns are contracts.drg_cap_rate and pricing_methods.default_drg_cap_rate — DRG payment caps, part of the repricing engine documented in modules/providers/screens-pricing-moon.
• Schema. Of 456 tables, none is named for capitation, and no column anywhere holds a capitation rate, a per-member-per-month amount, or a capitation payment. "pmpm" appears nowhere in the source.
• Inventory. 0 of 3,284 objects have "capit" in their name.

Verdict: (c) no trace in the client — never built. Capitated arrangements, if the TPA had any, were administered outside HOMER. Migration scope: exclude, but preserve contracts.vendor_sys_key as a data attribute.

Chapter 21 — Managed Care (Budgeting)

What the guide describes. Nothing — title page only, footer 1/13/98.

Verification against the extract.

• Menu. homersys/m_sys_frame.srm declares m_managedcare under the Plan menu (m_plan) with the identical dead-placeholder signature: tag = "For future use", visible = false, enabled = false, no clicked event.
• Source. The string "budget" occurs in exactly two files — cobradw/d_cobradw_notification.srd and cobradw/d_cobradw_notification_arra.srd — where it is part of the statute name "Consolidated Omnibus Budget Reconciliation Act" printed in COBRA letter text. There is no budgeting logic anywhere in the client.
• Schema and inventory. No budget or managed-care tables; 0 matching objects.

Note the distinction: managed-care clinical work (utilization review, case management, authorizations, referrals) is thoroughly implemented and is documented in modules/um from Chapters 18 and 19. The budgeting feature this chapter reserved is what never appeared.

Verdict: (c) no trace in the client — never built. Migration scope: exclude.

Chapter 25 — SFPI HR

What the guide describes. Nothing — title page only, footer 1/13/98.

Verification against the extract.

• No HR, payroll, personnel, or employee-administration objects exist in any of the 53 libraries: 0 of 3,284 objects and 0 of 456 tables match hr/payroll/personnel naming. The strings "payroll" and "broker" do not occur in the source at all.
• "SFPI" does occur heavily, but never as an HR module. It appears 1,469 times as the Oracle schema owner sfpidba in embedded SQL (for example the stored-procedure calls in clmsproc/n_claim_adjudication.sru), and 16 times as the batch user id SFPIBACK — for example clmentry/d_claim_history.srd, which renders create_user_id = 'SFPIBACK' as the display value "System".

Verdict: (c) no trace in the client. This chapter reserved space for the TPA's internal HR back office — an external system, or an intention, that was never part of the HOMER client. Migration scope: exclude.

Chapters 24 and 26 — SFPI AP and SFPI AR

What the guide describes. Nothing — both are title pages footed 1/13/98.

Verification against the extract. HOMER contains the TPA-operational halves of payables and receivables, and only those:

• Receivables — group and individual billing, documented in modules/billing. Chapter 4 is itself titled "Billing (A/R)".
• Payables — the funding and check-run machinery documented in modules/funding: the funding library, the vendor, vendors, vendor_addresses, vendor_contacts, vendor_holds, provider_address_vendors and consolidated_vendors tables, and 1099 printing.

What is absent is any corporate ledger: no general ledger, no journals, no chart of accounts, no corporate AP or AR objects among the 3,284 extracted, and no such tables among the 456. The corporate books lived in the TPA's separate back-office environment. The client's own batch counterpart, SFPIBACK, is likewise still unrecovered — see migration/considerations.

Verdict: (c) no trace in the client — external system. Migration scope: exclude corporate AP/AR ledgers; modules/billing and modules/funding cover everything HOMER actually did.

Chapter 8 — Commissions

What the guide describes (1,375 bytes of body, all of it requirements rather than documentation): calculation and payment of outside broker commissions. The agreement is struck at point of sale; the money is collected through Billing but disbursed here, outside the check run; Accounting maintains this part of HOMER. The body is verbatim minutes from a 2/96 MIS Programming Wishlist and meetings of 1/7/98 and 4/17/98 — brokers are also called agents; they are paid only after the client's bill is paid; a case may have multiple brokers with a split formula, or none (about one third of cases had none); policy numbers tie a group to a carrier, with Medicare-supplement policies tying at member or election level; most brokers are paid monthly; a commissions report is wanted showing client, date, dollars, plan year, broker code and client number. The chapter ends with six unresolved questions, including how to void checks and what to issue 1099s for.

Verification against the extract.

• Menu. m_commissions is declared under the Accounting menu in homersys/m_sys_frame.srm, caption "&Commissions". Unlike the capitation item it is visible and enabled, and it does have a clicked event — which calls OpenSheetWithParm on w_construct. That window (homersys/w_construct.srw) has the title "Under Development" and one static text: "Sorry, This area is under construction. Please try back again later." The only other control is an Exit button.
• Objects. 0 of 3,284 match "commis"; 0 match "broker" or "agent". The word "broker" does not appear anywhere in the extracted source.
• Schema — one real trace. No table is named for commissions, but two tables do carry a commission rate: group_stoploss_coverages.commission_pct and group_ancillary_coverages.commission_pct, edited on the client screens client/d_stoploss_acoverages.srd, client/d_stoploss_scoverages.srd and client/d_anc_coverages.srd. So the rate a broker earns on a stop-loss or ancillary coverage is captured at client setup. Nothing calculates or pays from it.

Verdict: (c) no trace in the client — planned, menu reserved, requirements minuted in 1996–98, never built. A user who clicks Accounting then Commissions in the shipping application gets an "Under Development" window. Broker commissions were administered outside HOMER. Migration scope: exclude from parity; carry the two commission_pct columns as data; treat the 1996–98 notes as historical intent only.

Chapter 20 — Sales Support

What the guide describes (2,819 bytes, again a 2/96 wishlist from misrqst.1): proposals, case flows, underwriting, and census in electronic and paper form; marketing activity reports; preparing requests for quote for new and renewal cases; faxing or electronically submitting RFQs to carriers; automated creation of presentations; monitoring of sales submissions. It closes with a mapping of each proposal data item to its source — company name and effective date from the billing file, employee counts from the census, stop-loss parameters from the billing file, annual claims experience and large-claim information from the aggregate stop-loss report, and so on.

Verification against the extract — this one is genuinely partial.

• What exists. A dedicated sales library of 48 objects, reachable from the frame menu: m_salessupport ("Sales &Support") sits under the Administrative menu, and its child "Benefit Catagories" opens w_sales_benefit_category_maintenance. The library implements the claims-experience reporting a sales and underwriting team needs at renewal — a report wizard (w_sales_report_wizard, n_cst_sales_report_wizard, u_sales_wizard_rpt_select, u_sales_wizard_group_select), client-based IBNR reports (n_cst_sales_clntbased_ibnr, d_sales_clntbased_ibnr), lag triangles (n_cst_sales_clntbased_lag_triangle, d_sales_clntbased_lag_incurred), paid-claim and claims-by-month reports, claimant registers (d_sales_clmnt_reg), HCN summaries, and group claim detail and line-data reports including a "confidential" variant — all organised by user-maintained benefit categories. These screens are catalogued in modules/groups-plans/screens-client.
• A dangling second item. The other child of Sales Support, "Detail Claim Report" (m_detailclaimreport), has a clicked event that opens w_sales_claim_detail_report — but that window does not exist in the extract, and the menu item is created with visible = false and enabled = false. The reference is unreachable and unresolvable.
• Census exists, but elsewhere. 47 census objects live in the client and enrolrpt libraries — d_client_census_group_coverages, d_client_census_rpt_select, d_census_sales_summary, d_census_sales_summary_corporate and so on, reached from the Census item under Enrollment Reporting. See modules/enrollment/screens-utilities-audit-reports and modules/groups-plans/screens-client.
• What is absent. 0 objects and 0 tables match proposal, quote, RFQ, underwrit, or case-flow naming. No carrier submission, no rating, no presentation generation.

Verdict: (b) partially implemented. The experience-reporting and census outputs listed as inputs to the wishlist were built; the sales-automation workflow the wishlist actually asked for was not. Migration scope: carry the sales reporting wizard and the census reports; exclude proposal, quoting, underwriting and RFQ automation.

Related finding: the five "For future use" menu items

homersys/m_sys_frame.srm contains exactly five menu items created with tag = "For future use", visible = false and enabled = false, none of which has a clicked event:

Menu item	Parent menu	Guide chapter
m_benefitriders	Plan Design	none — never given a chapter
m_managedcare	Plan	21 (empty)
m_claimwaivers	Stoploss	none — never given a chapter
m_capitation	Providers	15 (empty)
m_userfunctionassgn	Security	none

Three of the five line up exactly with empty guide chapters, which is good corroboration that the empty chapters are unbuilt features rather than lost text. Benefit Riders, Claim Waivers and User Function Assignment never even received a reserved chapter number. None belongs in migration scope.

Note the contrast in signalling: a hidden disabled item means "never started", whereas the visible-and-enabled Commissions item wired to the "Under Development" window means "promised to users and still unbuilt at the last compile".

Guide describes, client lacks

The migration-scoping payoff. Functionality named in the guide's table of contents for which the recovered client binaries contain no implementation:

1. Capitation (ch. 15) — hidden disabled menu item plus a capitation-vendor reference field on provider contracts. No rates, no calculation, no payment run. Beware drg_cap_rate, which is DRG payment capping and unrelated.
2. Broker commissions (ch. 8) — the Accounting menu item opens an "Under Development" window. Zero commission or broker objects; the only persisted data is commission_pct on stop-loss and ancillary coverages.
3. Managed Care budgeting (ch. 21) — hidden disabled menu item; zero budgeting code. ("budget" appears only inside COBRA statute text.)
4. Sales proposals, quoting, underwriting, RFQ submission and case flows (ch. 20, in part) — only the experience-reporting and census slices exist. Plus one dangling window reference, w_sales_claim_detail_report, behind a disabled menu item.
5. SFPI corporate AP, HR and AR (ch. 24, 25, 26) — external back-office systems. HOMER carries only TPA-operational A/R (group billing) and disbursement (funding, checks, 1099s).
6. Benefit Riders, Claim Waivers, User Function Assignment — placeholder menu items with no chapters and no code.
7. QMCSO letters (ch. 1) — the guide specifies seven letters and four declination reasons, printed from a request table by the nightly production cycle. The QMCSO maintenance screens exist (enroll/w_enroll_qmcso_maint, w_enroll_qmcso_select, w_qmcso_member_detail); the request table and the print job do not.
8. "Produce Free Form HIPAA Certificate" (ch. 1) — a visible, enabled menu item that opens homersys/w_construct, whose window title is literally "Under Development". The same signalling as Commissions: promised to users, unbuilt at the last compile.
9. CMS Section 111 / MMSEA reporting (ch. 1) — described by the guide as operating against a persistent Oracle table (back up, apply, reload; the response load emits INSERT and UPDATE activity), but a sweep of all 53 libraries returns zero Section 111, MMSEA, MSP, TIN-reference or CMS-response objects. The only CMS string in the entire source is static text on enroll/d_hipaa_form. Unlike items 1–8 this is a federal compliance obligation, not an unbuilt convenience, and it must not be descoped on the strength of its absence from the client — see Migration Considerations §6 and OQ-8.

A separate and larger gap runs the other way — behaviour the client clearly depends on that is also absent from the binaries: the background executables that run under the SFPIBACK identity, the Oracle stored procedures and triggers under sfpidba, the host crontab, and configuration held as data. Those are open questions rather than descoped features; see Migration Considerations.

One loose end worth recording while reconciling QMCSO: enroll/d_enroll_qmcso_entry is an orphaned DataWindow. It defines a form over the qmcso_guardians table but is referenced by no window in any of the 53 libraries — a fragment of an entry path that was either removed or never finished. qmcso_guardians itself appears nowhere else in the extracted source, so the table's production contents (if any) should be inspected before deciding whether guardian data is in migration scope.

How to read this page against the guide

• Chapters 8, 18 and 20 are 1995–98 meeting minutes and work-request lists under a chapter heading, not descriptions of shipped software. Chapter 18 (Case Management, 1998 notes) is superseded by Chapter 19 (Utilization Review/Case Management, 2010), which does match the implemented UM module; Chapter 18's unique remaining content is WANG-era history.
• Only Chapter 7 (Provider Maintenance, 2022-11) was revised in the last decade, and Chapters 6 (2013-11) and 13 (2012-07) in the decade before. The rest of the guide reflects the system as of 2009–2010 at the newest.
• Where the guide asserts a behaviour, confirm it in the module pages of this site before writing it into a migration requirement. The extracted source is the authority on what the system does; the guide is the authority only on what someone once wanted it to do.