Skip to main content

HOMER System Requirements Documentation

This site is the reverse-engineered requirements documentation for HOMER, a PowerBuilder-based third-party administration (TPA) system for self-funded health benefit plans operated for "SFPI". It was produced by extracting and analyzing the complete application source from its 53 PowerBuilder libraries (3,284 objects, including 546 screens and 2,110 DataWindows) and reconstructing the Oracle data model from the SQL embedded in them.

Its purpose is to serve as the requirements baseline for migrating HOMER to a new platform. The requirements are written technology-agnostically: they describe what the system does, not how it should be rebuilt.

Start here​

If you are…Read
New to HOMERSystem Overview, then the Glossary
Scoping or estimating the migrationMigration Considerations — the single most important page
Designing the replacement's data layerData Model and the CRUD matrix
Specifying one business areaThe relevant module page

How to read this site​

The sidebar follows the order in which the system makes sense: what HOMER is → how it is built → what the data looks like → what each module does → what spans all of them → what migration must handle → evidence.

  • Overview — what HOMER is, the business it supports, and a domain glossary.
  • Architecture (As-Is) — the current technical shape: PowerBuilder client, Oracle backend, PFC framework, configuration, and the substantial server-side layer that is not in the codebase.
  • Data Model — the reconstructed database schema by subject area, with inferred relationships and a module↔table CRUD matrix.
  • Modules — the core of the site: functional requirements per business domain (claims, enrollment, billing, COBRA, funding, utilization management, …). Each documents the screens, business rules, workflows, and data of one domain, with source references for traceability.
  • Cross-Cutting Concerns — security, navigation, EDI/integrations, reports, and batch processing that span modules.
  • Migration Considerations — what must carry over, what is missing from the codebase, the conversion traps, and the open-questions register for SME review.
  • Appendix — the complete object inventory, the screen→DataWindow→table traceability matrix, the user-guide reconciliation, and the Coverage Audit proving what is covered and listing what is missing.

The functional content is expressed as 792 uniquely numbered, source-cited requirements (CLM-1, ENR-14, …) across 19 domains, each traceable to the object it was derived from. About 150 open questions are recorded rather than guessed at.

Provenance

Content derives from two sources: (1) static analysis of the application binaries (source recovered from the PBLs — see _re/ next to the site), cited like claims/w_claim_editor; and (2) the official HOMER user guide (28 Word chapters, 2009–2022 vintage, converted to text in _re/userguide/), cited like (User Guide ch. 11). Code citations are authoritative for current behavior; the user guide for business intent and operational practice — disagreements are flagged as discrepancies. Facts confirmed by neither are open questions, not guesses. See the User Guide Reconciliation for chapter-by-chapter mapping.