Navigation Model

Source: homersys library (w_sfpi_frame, w_system_tree_menu, w_system_menu, d_system_menu_datawindow, m_sys_frame, u_member_search, f_useraccess), inventory.json (window opens_windows links), HOMER.INI.

Overall shell

HOMER is a multiple-document-interface (MDI) application. A single frame window (homersys/w_sfpi_frame, comment: "Frame window for the SFPI Homer application") hosts every business screen as a sheet. The frame provides:

• A status bar showing the logged-in user, the connected database, the active window's internal name (win_id), and a clock refreshed on a timer (w_sfpi_frame open/activate events; HOMER.INI [SETTINGS] timerinterval, timerformat).
• The connection banner in the microhelp line: "User <id> connected to: <database>" (w_sfpi_frame line ~128).
• Status-bar indicators for member notes (none / notes found / VIP notes found) updated by the active sheet (w_sfpi_frame wf_notes_found, wf_no_notes, wf_vip_notes_found).
• The main menu bar m_sys_frame, whose items are security-filtered at frame open by gnv_menu_security.of_applymenusecurity(this.menuid) — see Security Model (w_sfpi_frame line ~215).

Primary navigator: the tree menu

At frame open, if the per-user INI setting [SETTINGS] sys_menu is TRUE (default TRUE; the workstation HOMER.INI ships sys_menu=tRUE), the frame opens the navigator sheet w_system_tree_menu ("System menu - tree structure") (w_sfpi_frame line ~219).

Mechanics (homersys/w_system_tree_menu):

• The tree is built from the frame menu itself: ue_load walks the m_functions branch of m_sys_frame and creates one tree node per menu item, storing the live menu object in the node's data (str_menu_item with menu_object, program, enabled, level).
• Selecting a leaf and launching it calls wf_launchprogram, which simply triggers the underlying menu item's Clicked event — so the tree and the menu bar are two views of one function catalog. If the menu item was disabled by menu security, the user gets "Access Denied - You do not have the proper security authorization to run this program."
• Per-user personalization is stored as rows in a user-INI table (datastore ids_user_ini, section MENU): a Home position (wf_sethome, key HOME) and a Favorites list shown in a listview (wf_setfavorite / wf_loadfavorites, keys FAVORITEnn); favorites accept only program leaves, not folders ("You can only add programs as favorites").
• Node icons come from workstation image files (C:\homer\folder.gif, menu_item.gif — tv_system_menu.picturename[]).

The frame can also (re)open the tree menu on demand: w_sfpi_frame event ue_system_menu executes OpenSheetWithParm(..., "w_system_tree_menu", ...) (line ~41), and m_sys_frame line ~1887 opens it from the menu bar.

Secondary navigator: the data-driven icon menu

homersys/w_system_menu ("Window providing navigator 'buttons' for all the functions for Homer") is an earlier, table-driven navigator that still exists in the code:

• Its DataWindow d_system_menu_datawindow retrieves from the system_menu table: SELECT :picture_path||picture_name, sys_menu_option, window_to_open, display_order, menu, parameter FROM system_menu WHERE menu = :menu_name ORDER BY display_order — a self-referencing hierarchy where each row belongs to a named menu level and either opens a window or names a child menu level. Rows render as a grid of up to 10 picture buttons per band.
• The root level is retrieved with argument "Main" (pfc_postopen, is_retrieveargs = "Main"); the picture path prefix comes from the application manager (gnv_app.of_get_pict_path) (pfc_retrieve).
• Clicking/double-clicking a tile inspects window_to_open (dw_menu_selection::doubleclicked):
  • prefix w — a sheet window: access is verified with f_useraccess(ls_obj) (homersys/f_useraccess.srf); on success the sheet is opened with OpenSheet, or OpenSheetWithParm when the row's parameter column is non-empty, so the system_menu table can pre-parameterize a target screen. On failure: "Invalid Request - You do not currently have access...".
  • prefix r — a response (modal) window: the prefix is rewritten to w and the window is opened with Open after the same f_useraccess check.
  • prefix x (or shift-click) — navigate back one menu level (ue_return_level, which looks up the parent level in system_menu).
  • anything else — treated as a child menu name: the breadcrumb title (st_1.text) is extended with " - <option>" and the DataWindow is re-retrieved for that level; the Exit option closes the application.
• Window-level security is also applied on open via gnv_app.inv_security.of_SetSecurity(This) (open event) — see Security Model.
• The system_menu table has its own security maintenance screen (app_sec/w_system_menu_security).

Member-search-centric entry points

Most day-to-day work starts from a member (subscriber/patient) lookup rather than from a record browser:

• homersys/u_member_search is a reusable search panel (criteria DataWindow d_member_search_criteria, results d_member_search). Its ue_postconstructor registers the search fields with a shared member-search service (inv_MemberSearch.of_Register(... 'ssn', 'last_name', 'first_name', 'middle_name', 'member_id', 'group_id', 'group_name', 'patient_syskey', 'sub_member_sys_key', ...)), and ue_search/ue_clear drive it.
• homersys/w_member_search ("Generic Member Search window") wraps the panel in a modal response window so any screen can prompt for a member.
• The panel is embedded directly in 11 windows across business areas, e.g. claims/w_eob_selection, claims/w_audit_members_selection, claims/w_claims_member_accum, cob/w_cob_select, enroll/w_hipaa_dead_file, enroll/w_enroll_custom_term_add_members, enroll/w_enroll_hipaa_add_members, stoploss/w_sl_spec_clm_listing, stoploss/w_sl_variable_clm_listing, clmrpt/w_rpt_member_accum_rulemax (grep of u_member_search across _re/src).
• Menu-bar handlers in m_sys_frame implement the "select first, then open" pattern: they open a selection sheet with parameters, e.g. w_enroll_member_selection, w_group_member_select, w_group_hb1_member_select, w_quick_enroll_main, w_homer_id_req, w_drugplan_member_maint (all via OpenSheetWithParm, m_sys_frame lines ~3976-4293).
• A user preference directtomember (HOMER.INI [APP PREFERENCES], maintained by system/u_app_preference and enroll/w_enroll_member_selection) makes member selection jump straight to the member instead of an intermediate list.

Window-to-window flow highlights

From analysis/inventory.json (opens_windows links, 546 windows):

• Hub screens that fan out: um_ur/w_um_authorization opens 10 other windows; um_cm/w_um_case_management and um_ur/w_um_pre_certification open 7 each; enroll/w_group_hb1_member_select and enroll/w_group_member_select open 6 each; enroll/w_enrollment_maintenance, provider/w_provider_maintenance, um_ur/w_um_admission_notification, um_ur/w_um_referral open 5 each; claims/w_claim_editor and enroll/w_quick_enroll_main open 4 each.
• Shared picker/response windows reached from many places: w_group_response_selection (opened by 12 windows), w_provider_vendor_select and w_pricing_plan_maintenance_single (6 each), w_um_diagnosis_cd_select, w_um_case_patient_select, w_um_procedure_cd_select (5-6 each), w_member_select_by_last_name, w_enrollment_maintenance, w_enrollment_cob_maint (3 each).

The pattern is consistent: maintenance/worklist sheets open small modal selection windows (group, provider, member, diagnosis/procedure code) and receive the chosen key back, rather than embedding lookups inline.

Guide-documented menu semantics and navigation rules

(User Guide ch. 22, "Menu definitions", "Navigation rules", "Department/Function list") — the guide records the intended standard behavior behind the menu items the code wires up.

Standard menu-item semantics (uniform across maintenance screens):

Menu item	Defined behavior
File Close	Close current window and save current data
File Exit	Exit application (prompt "Save current data Y/N?")
File Menu	Return to previous menu
File New	Enter Add mode and save any current data
File Open	Open another window instance
File Save	Save current data
Edit Cancel	Reverse changes to all current data
Edit Clear	Clear all data fields on current window
Edit Copy / Cut / Paste / Select	Standard clipboard actions
Edit Delete	Delete selected data (privilege varies window to window)
Edit Find	Enter Query mode and save current data
Edit Undo	Reverse changes to current field only

Add/Query screen life cycle: launching a function opens a blank sheet in Query mode; the user enters criteria and presses Enter to query, or File New to enter Add mode. Query results: a unique match populates the window and enters Update mode; multiple matches show a pick list whose selected row populates the window; no match shows an error message box. From either mode, Close/Exit/Find/New all save current data first and then close / exit / re-enter Query mode / enter Add mode.

When updates occur: at Exit (with Save Y/N prompt), File Save, File Close (Save Y/N), on change to another record, and on adding a new record — i.e. implicit save on record navigation, not an explicit-save-only model.

Query result limits: queries must be limited to reasonable result sizes; if a query would return more than the allowed number of rows the user is asked to refine the criteria. Documented limits: Group 100, Member 100, SSN 100, Name 100.

Department/function organization: the guide's function catalog groups the system as Enrollment (Enrollment, COBRA), Accounting (Billing A/R, Funding, Commissions), Claims (Claims Entry, Adjudication, Auditing), Administrative (Marketing/Sales Support, Forms Processing/Claims Output, Global: e-mail, client service log, printing), Plan (Client Maintenance, Plan Design, Managed Care, Stoploss), Providers (Provider Maintenance, Capitation), and UR/CM (Utilization Review, Case Management) — the intended top level of the menu hierarchy that the system_menu table implements.

Note: these sections predate the current PFC-based screens; where a screen's observed behavior differs (e.g. explicit save via pfc_save), code wins — treat the guide as the design intent that most maintenance sheets still follow.

Requirements

• NAV-1 The application shall present all business functions inside a single main window (MDI shell) with a status area showing the logged-in user, the connected environment, and the active screen's identity (homersys/w_sfpi_frame).
• NAV-2 The primary navigator shall present the security-filtered function catalog as a hierarchical tree; launching a leaf shall invoke exactly the same action as the corresponding menu-bar item, and security-disabled items shall refuse to launch with an explanatory message (homersys/w_system_tree_menu::wf_launchprogram).
• NAV-3 Users shall be able to personalize navigation with a saved "home" position and a favorites list of function shortcuts, persisted per user in the database, restored at next logon (homersys/w_system_tree_menu::wf_sethome/wf_setfavorite/wf_loadfavorites).
• NAV-4 The system shall support a data-driven menu hierarchy stored in a database table (system_menu) where each entry defines its parent level, display order, display caption, icon, target screen, and an optional launch parameter passed to the target (homersys/d_system_menu_datawindow, w_system_menu::doubleclicked — OpenSheetWithParm).
• NAV-5 Every navigation-initiated screen open shall be preceded by a per-user access check on the target screen name, with a uniform denial message directing the user to the system administrator (homersys/w_system_menu — f_useraccess; see Security Model).
• NAV-6 Whether the navigator opens automatically at logon shall be a per-user preference (sys_menu setting; homersys/w_sfpi_frame line ~219).
• NAV-7 A reusable member search component (criteria: SSN, name, member ID, group) shall be available both embedded in business screens and as a modal prompt, returning the selected member's keys to the caller (homersys/u_member_search, homersys/w_member_search).
• NAV-8 Business screens shall obtain foreign keys (group, member, provider, diagnosis/procedure code, vendor) through shared modal selection windows rather than free-text entry (inventory.json opens_windows: w_group_response_selection reached from 12 windows, etc.).
• NAV-9 A per-user "direct to member" preference shall let member selection bypass intermediate result lists (system/u_app_preference, HOMER.INI [APP PREFERENCES] directtomember).
• NAV-10 Maintenance screens shall follow the standard menu semantics: File Close saves and closes, File New saves then enters Add mode, Edit Find saves then enters Query mode, Edit Cancel reverts all pending changes, and Edit Undo reverts the current field only (User Guide ch. 22, "Menu definitions").
• NAV-11 Add/Query screens shall open in Query mode; a unique query match shall populate the screen in Update mode, multiple matches shall present a pick list, and no match shall report an error; pending data shall be saved before any mode transition or close (User Guide ch. 22, "Navigation rules").
• NAV-12 Search queries shall enforce a maximum result count (100 for group, member, SSN and name searches) and ask the user to refine the criteria when exceeded (User Guide ch. 22, "Navigation rules").

Open questions

• The system_menu table's actual contents (the live menu hierarchy and which rows carry parameter values) are data, not code, and were not available to this analysis; the migrated navigation catalog must be extracted from the production table. The user guide's Department/Function list (see above) gives the intended top-level hierarchy and can serve as a checklist when validating the extracted table (User Guide ch. 22).
• Both navigators coexist. w_system_tree_menu is what the frame opens at logon; w_system_menu (icon grid) appears to be the older generation (much of its handler code is commented out) but is still referenced by app_sec/w_system_menu_security. Confirm with users whether the icon-grid navigator is still reachable/used before carrying it forward.
• Navigator icons and pictures are loose files on each workstation (C:\homer\*.gif, picture_path prefix from the application manager) — a deployment concern, not a data concern, in the target platform.