ID Cards

Source library: idcard (4 windows, 8 DataWindows, 2 global functions, 1 structure, 2 menus)

Purpose

The ID Cards domain queues and produces member identification cards. It has two halves:

1. Request capture — staff (or the enrollment module automatically) place ID-card requests for a member/coverage combination into a request queue table (ID_CARD_REQ) (idcard/w_homer_id_req, idcard/f_mem_id_card_req, idcard/f_submit_mem_id_req).
2. Card production — a production screen works the queue for the US Family Health Plan (USFHP) program: it retrieves pending requests, validates that the data needed on a card is present, exports a delimited card file for the card printer/vendor, prints a request listing and an accompanying welcome letter, and marks requests complete (idcard/w_enroll_idcard_usfhp).

The extracted production screen is USFHP-specific (its retrieval is hard-wired to the group hierarchy rooted at group 516-769); the request queue itself is generic and is also read by the stop-loss and system libraries (_re/analysis/schema.json, id_card_req.used_by).

Actors

Actor	Responsibility
Enrollment clerk	Answers the post-save prompt that queues card requests for new or modified coverages (IDC-9)
ID-card requester	Works the ID Request Screen directly for individual or whole-group requests, including replacements (IDC-4 to IDC-8)
SFPI/M3 card production staff	Drain the queue on a periodic "ID card run", design the cards with each client, and print and distribute them (User Guide ch. 1)
USFHP operator	Runs the one extracted production screen: retrieve, validate, export the card file, print listing and welcome letters (IDC-10 to IDC-16)

Group retrieval is restricted to groups the signed-on user may access (IDC-7).

Screen catalog

Object	Type	Title / role	Evidence
w_homer_id_req	Sheet window	"ID Request Screen" — submit ID card requests for individuals or groups	idcard/w_homer_id_req
w_enroll_idcard_usfhp	Sheet window	"ID Cards - US Family Health Plan" — retrieve requests, create card file, print listing/letters	idcard/w_enroll_idcard_usfhp
w_enroll_idcard_usfhp_retrieve_response	Response dialog	"Retrieve IDCards" — choose Currently Requested vs Previous Date	idcard/w_enroll_idcard_usfhp_retrieve_response
w_enroll_idcard_usfhp_print_response	Response dialog	"Print Listing/Letters" — checkboxes Print Listing / Print Letters	idcard/w_enroll_idcard_usfhp_print_response
m_id_req	Menu	Menu for w_homer_id_req: Retrieve Members, Submit Request, Select All / Select None	idcard/m_id_req
m_enroll_idcard_usfhp	Menu	Menu for the USFHP window: Save, Print, Retrieve toolbar items; Preferences > Set Default File	idcard/m_enroll_idcard_usfhp
d_indiv_id_req_parms	DataWindow (external)	Individual request criteria: Social Sec # (9-digit mask), Member ID (mask #########!a), Coverage Type drop-down (Medical / Dental / Vision)	idcard/d_indiv_id_req_parms
d_group_id_req_parms	DataWindow (external)	Group request criteria: Group ID (upper-cased, required), Coverage Type drop-down	idcard/d_group_id_req_parms
d_individual_subs	DataWindow	Subscriber listing by SSN or member ID with latest election per coverage type	idcard/d_individual_subs
d_group_subs	DataWindow	Subscriber listing for a group and all its leaf descendant groups	idcard/d_group_subs
d_enroll_idcard_usfhp	DataWindow	USFHP request-queue display grid (updateable against ID_CARD_REQ)	idcard/d_enroll_idcard_usfhp
d_enroll_idcard_usfhp_rpt	DataWindow	Printable listing of the same result set (shares data with the display grid)	idcard/d_enroll_idcard_usfhp_rpt, idcard/w_enroll_idcard_usfhp pfc_postopen
d_enroll_idcard_usfhp_letter	DataWindow (rich text)	Welcome letter that accompanies USFHP cards; one letter per valid request	idcard/d_enroll_idcard_usfhp_letter
dddw_provider_ids	Drop-down DataWindow	Provider ID + name lookup; no reference found in any extracted window — apparently unused	idcard/dddw_provider_ids
f_mem_id_card_req	Global function	Upsert of one request row into ID_CARD_REQ	idcard/f_mem_id_card_req
f_submit_mem_id_req	Global function	Queues requests for every coverage of one subscriber; called from enrollment	idcard/f_submit_mem_id_req
s_mem_idcard	Structure	Carrier for member/coverage data passed to f_mem_id_card_req	idcard/s_mem_idcard

Workflow

Request capture (single or batch)

• The ID Request Screen is opened from the application frame menu under Enrollment > ID Cards (homersys/m_sys_frame.srm, m_idcards.clicked opens w_homer_id_req).
• A Request For radio group toggles between Individual (default) and Group modes; each mode shows its own criteria and listing DataWindow (idcard/w_homer_id_req, rb_individual / rb_group clicked events).
• Retrieve Members (menu, toolbar, or Enter key) populates the listing; the user multi-selects rows and Submit Request writes one queue row per selected member/coverage (idcard/w_homer_id_req, ue_retrievemem / ue_submitreq; idcard/m_id_req).
• Closing the window with unsent selections prompts "Would you like to submit an ID card request for the selected members before closing?" (idcard/w_homer_id_req, close event).
• Enrollment maintenance and quick-enroll call f_submit_mem_id_req when coverage changes may require new cards, after asking the user "Would you like to request new ID Cards for New/Modified Coverages?" (enroll/w_enrollment_maintenance, enroll/w_quick_enroll_main; idcard/f_submit_mem_id_req).

Card production (USFHP)

• Retrieve List opens a dialog offering Currently Requested (open requests) or Previous Date (a prior production day, defaulting to yesterday) (idcard/w_enroll_idcard_usfhp dw_id.pfc_retrieve, idcard/w_enroll_idcard_usfhp_retrieve_response).
• After a successful retrieve, valid rows not yet complete are flagged complete in the on-screen buffer (req_complete_ind = 'Y', req_complete_dt = now); the flags are only persisted when the card file is saved (idcard/w_enroll_idcard_usfhp, dw_id.pfc_retrieve and pfc_save).
• Create Card File prompts for a target text file, but writes to the user INI path APP PREFERENCES / idcard_file (fallback C:\IDCARD.TXT, also settable via Preferences > Set Default File) regardless of what the dialog returns — see migration notes. It writes one delimited record per valid row, then updates ID_CARD_REQ to mark those requests complete — with commit/rollback and user-facing error messages (idcard/w_enroll_idcard_usfhp pfc_save, ue_defaultfile; idcard/m_enroll_idcard_usfhp).
• Print List/Letters opens a dialog with two checkboxes and prints the request listing and/or the letters (idcard/w_enroll_idcard_usfhp pfc_print, idcard/w_enroll_idcard_usfhp_print_response).

How cards were actually produced

The user guide answers, partly, the question the source could not: cards are an in-house SFPI/M3 operation, not a vendor service. "ID cards are designed by SFPI/M3 in conjunction with each client, and are created and distributed by SFPI/M3" (User Guide ch. 1). Requests are deliberately decoupled from production — "ID cards are not produced at the time that they are requested" — and the system "will produce ID cards when the next ID card run is executed" (User Guide ch. 1). That confirms the ID_CARD_REQ queue is worked by a periodic production run rather than by the requesting screen.

The card-printing step itself is documented outside the design document: the user guide's table of contents lists the ID Cards topic as "ID Cards - Using Horizon Printer", hyperlinked to a separate PowerPoint How_to_Horizon_printer.ppt (User Guide table of contents, ch. 1). No copy of that deck is present in the extracted guide text, and the word "Horizon" appears nowhere in the chapter bodies. The working conclusion is therefore: non-USFHP cards were printed on a Horizon card printer operated by SFPI/M3 staff, driven by a procedure that lives only in that deck — which should be recovered from the client before the card-production interface is specified. The USFHP-specific <<field>> file export documented below is a second, parallel path for that one program.

Requirements

Each statement below is testable and cites the extracted source that evidences it.

• IDC-1 (Request queue upsert). Submitting a request for a member/coverage that is not yet queued must insert a new ID_CARD_REQ row; submitting for one already queued must update the existing row and clear its completion date so the request is re-opened. The queue key is member system key + benefit coverage type code. (idcard/f_mem_id_card_req)
• IDC-2 (Copy quantity default). A request with no copy quantity (null or zero) must default to 1 copy. (idcard/f_mem_id_card_req)
• IDC-3 (Batch id assignment). Each request carries a batch id. For individual requests the default is E, for group requests G; when the member's master group has a group option IDBATCHMEM (individual) or IDBATCHGRP (group) in GROUP_OPTION_VALS, that option value overrides the default, and any lookup failure falls back to the mode letter. Only the ID Request Screen implements both modes; the enrollment-triggered path is individual-only and consults IDBATCHMEM alone. (idcard/w_homer_id_req ue_submitreq; idcard/f_submit_mem_id_req)
• IDC-4 (Individual lookup). Individual requests must find subscribers by Social Security number or member ID, restricted to the requested coverage type, and return only the latest election per coverage type (no later-effective election exists). A 9-character member ID entry is auto-suffixed with the letter A before lookup. (idcard/d_individual_subs, idcard/w_homer_id_req ue_retrievemem and dw_parms_indiv.itemchanged)
• IDC-5 (Individual validation). An entered SSN or member ID that matches no subscriber eligibility must be rejected with an "Invalid Social" / "Invalid Member ID" message. (idcard/w_homer_id_req, dw_parms_indiv.itemchanged)
• IDC-6 (Group lookup). Group requests must expand the entered group to all its descendant groups that have no child groups (leaf groups), and list subscribers with unexpired eligibility and the latest unexpired election of the requested coverage type. (idcard/d_group_subs)
• IDC-7 (Group security). A user may only retrieve members of a group they have access to; otherwise a "Security / You do not have access to group" message is shown and the criteria are cleared. (idcard/w_homer_id_req ue_retrievemem, via uf_user_group_access)
• IDC-8 (Selection-based submission). Only listing rows the user selected are submitted; the submit routine reports the count of members submitted successfully and reports per-member errors without aborting the loop. (idcard/w_homer_id_req ue_submitreq)
• IDC-9 (Automatic request on coverage change). When enrollment saves new/modified coverage, the system must offer to queue ID-card requests and, on acceptance, queue one request per coverage row of the subscriber (member data must already be saved). (idcard/f_submit_mem_id_req; callers enroll/w_enrollment_maintenance, enroll/w_quick_enroll_main.) The guide claims quick enrollment "automatically generates a request for an ID card", but annotates its own claim "Is this True?" — in the extracted code the request is prompted, never automatic. (User Guide ch. 1)
• IDC-10 (Production retrieval modes). Card production must support retrieving (a) all open requests (req_complete_ind = 'N') and (b) all requests completed on a chosen prior date (completion timestamp within that calendar day); an invalid date entry is rejected. (idcard/d_enroll_idcard_usfhp retrieval arguments as_current / adt_date; idcard/w_enroll_idcard_usfhp_retrieve_response)
• IDC-11 (Row validity check). A retrieved request row is valid only when all of the following are present: an assigned primary-care provider (PCP), the PCP's address, the PCP contact phone number, the member's SSN, and the drug plan carrier code. All five are outer-joined, so any one may be null; the flag is their product. Invalid rows are visually highlighted, and the grid footer shows Valid: (the sum of the flag) and Errors: (the remainder). (idcard/d_enroll_idcard_usfhp, error_flg expression and footer computes.) Naming trap: error_flg = 1 means valid, not in error — invert the name when porting.
• IDC-12 (Card file export). The card file must contain one record per valid row, each field wrapped as <<value>> and followed by a single space (including the last field), and the record terminated by the literal <EOL> — single angle brackets, unlike the field delimiters. Field order: group id, member id, member name, coverage effective date, physician name, physician phone, Rx group, Rx id, copay line 1, line 2, line 3. Invalid rows are excluded. (idcard/w_enroll_idcard_usfhp pfc_save)
• IDC-13 (Completion bookkeeping). Saving the card file must persist the completion flags to ID_CARD_REQ in one transaction; on failure the update is rolled back and the user is told no requests could be marked completed. (idcard/w_enroll_idcard_usfhp pfc_save)
• IDC-14 (Accompanying letter). Letters retrieve the same request rows as the grid but are filtered to valid rows only (error_flg = 1); each letter merges the member's name, up to three address lines (collapsing blank address lines), and member ID into a fixed welcome-letter template. (idcard/d_enroll_idcard_usfhp_letter, filter and addr_line1..3 computes)
• IDC-15 (Listing print). The printable listing shares its data with the display grid (retrieved once, printed with print-preview enabled). (idcard/w_enroll_idcard_usfhp pfc_postopen ShareData, dw_rpt.constructor)
• IDC-16 (USFHP scope of production query). The production retrieval restricts to requests whose group belongs to the hierarchy rooted at group 516-769, joining member, address, eligibility, election, PCP, provider, provider address/contact and drug-plan extension data as of the later of today and the request's coverage effective date. (idcard/d_enroll_idcard_usfhp retrieval SQL)
• IDC-17 (Universal issue). Every person enrolled in the system is issued a medical identification card, and cards are generated for all members when they are first added to the system. (User Guide ch. 1)
• IDC-18 (Card quantity by coverage level). If a subscriber's coverage level is single, one card is issued; otherwise two cards are issued. (User Guide ch. 1) — Discrepancy. The extracted code defaults copy_qty to 1 regardless of coverage level (IDC-2) and the USFHP export writes exactly one record per valid request (IDC-12), so the quantity rule may have lived in the card-printing step rather than in HOMER. See Open question 4.
• IDC-19 (Issue events). Cards are issued when: a new group is established; a change occurs in a group; a new person is added to a group; or a replacement card is requested. The system must prompt the user to request cards when names, addresses or coverage elections change for existing members. (User Guide ch. 1) — Discrepancy. The coverage-change half of this is implemented (IDC-9); no name- or address-change prompt exists in the extracted source.
• IDC-20 (Group request convention). To request cards for a whole group the operator enters the group number, an asterisk * under member, and the coverage, then uses Select All. (User Guide ch. 1) — the extracted group screen instead expands the entered group to its leaf groups and lists every subscriber with no wildcard entry (IDC-6); the * convention appears to be the older (WANG-era) interface. Discrepancy for SME confirmation.
• IDC-21 (Last-selected stamp). Submitting a request sets "the date last ID card selected" to the current date for every selected member — the ID_CARD_REQ.id_card_chg_dt column. (User Guide ch. 1) The queue function itself only persists whatever date the caller supplies; the two callers disagree on the clock — the enrollment-triggered path stamps database time (gnv_app.inv_sql.uf_today(), idcard/f_submit_mem_id_req) while the ID Request Screen stamps workstation time (today(), idcard/w_homer_id_req). Pick one clock on migration.
• IDC-22 (Number of sets). The operator may update a "# of Sets" field per member to control how many cards are printed for that member. (User Guide ch. 1) — Discrepancy. The column still exists in the listing layout, but the code that let users set it is commented out and the export ignores it (IDC-12, migration notes). See Open question 4.
• IDC-23 (Proof of Good Health precondition). "Persons requiring proof of good health should have all coverage(s) in accepted status before ID cards are requested." The guide itself flags this with "Is this still accurate?", and POGH was retired in July 1998 when HIPAA took effect, so this precondition is almost certainly obsolete and is recorded for history only. (User Guide ch. 1)

Card layout contents

Fields carried per card record, as produced by the retrieval SQL (idcard/d_enroll_idcard_usfhp) and exported in the card file (idcard/w_enroll_idcard_usfhp pfc_save):

Field	Derivation (evidence: idcard/d_enroll_idcard_usfhp unless noted)
Group ID	Member eligibility group id (trimmed)
Member ID	MEMBERS.MEMBER_ID (trimmed)
Member name	First + middle + last name concatenation
Effective date	Election effective date, MM/DD/YYYY
Physician name	PCP's company name, else person name + educational degree, init-capped
Physician phone	PCP contact phone formatted by length (11/10/7 digits with dashes)
Rx group	Drug plan PCS_CARRIER_CD + PCS_PLAN_ID
Rx ID	Member SSN formatted as 9 digits ('099999990' mask)
Copay line 1	"MEDICAL VISITS: ..." — hard-coded per sub-group 516-769A (no copay), 516-769B ($12 per visit), 516-769C (no copay)
Copay line 2	"OUTPATIENT SURGERY /E.R. VISITS: ..." — same sub-group decode ($25 / $30 for 516-769B)
Copay line 3	"MENTAL HEALTH VISITS: ..." — same sub-group decode ($25/Individual $17/Group for 516-769B)
Member address	Addr1, Addr2, City/State/Zip (zip+4 formatting) — retrieved with the row; used on the letter and shown in the grid, not written to the card file

The letter text itself (welcome wording, other-health-insurance and Medicare guidance, Member Services phone numbers, signature block) is embedded as a rich-text template in idcard/d_enroll_idcard_usfhp_letter.

Triggers

• Coverage change during enrollment — enrollment maintenance and quick enroll ask the user whether to request new cards and call f_submit_mem_id_req (enroll/w_enrollment_maintenance, enroll/w_quick_enroll_main, idcard/f_submit_mem_id_req).
• Manual request — the ID Request Screen, from the frame menu Enrollment > ID Cards (homersys/m_sys_frame.srm, idcard/w_homer_id_req).
• Note on the memberidletter INI flag: the working hypothesis that this flag makes letters accompany cards is not supported by the source. The preference APP PREFERENCES / memberidletter (default NO) controls "whether or not to default a letter on the end of the Member Id if one is not entered" — i.e., a member-ID suffix letter convention (see also the automatic A suffix in IDC-4), toggled from the quick-enroll Preferences menu (system/u_app_preference.sru of_set_memid_letter_default/save routine; enroll/w_quick_enroll_main wf_toggle_mem_id_letter). Letters that accompany USFHP cards are instead an explicit print option on the production screen (IDC-14).

Data

Tables written:

• ID_CARD_REQ — the request queue. Columns evidenced in inserts/updates: member_sys_key, group_id, member_id, soc_sec_no, l_name, f_name, m_name, benefit_coverage_cd, benefit_coverage_type_cd, coverage_level_cd, covr_eff_dt, cobra_flg, group_name, id_req_batch_id, id_card_chg_dt, copy_qty, req_complete_ind, req_complete_dt (idcard/f_mem_id_card_req, idcard/d_enroll_idcard_usfhp). Older commented-out code also wrote member and claim address columns — no longer populated (idcard/f_mem_id_card_req).

Tables read: MEMBERS, ADDRESSES, MEMBER_ELIGIBILITIES, ELECTIONS, GROUPS, GROUP_OPTION_VALS, MEMBER_PCPS, PROVIDERS, PROVIDER_ADDRESSES, PM_CONTACTS, DRUG_PLAN_EXTS (idcard/d_enroll_idcard_usfhp, idcard/d_group_subs, idcard/d_individual_subs, idcard/f_submit_mem_id_req, idcard/w_homer_id_req).

File output: delimited card text file at a user-configured path (INI APP PREFERENCES / idcard_file) (idcard/w_enroll_idcard_usfhp).

Migration notes

• Hard-coded program data. Group 516-769 and the three copay text lines per sub-group (A/B/C) are embedded in the retrieval SQL of three DataWindows (idcard/d_enroll_idcard_usfhp, _rpt, _letter). A replacement should drive card scope and copay text from configuration, not code.
• Triplicated query. The display, report, and letter DataWindows each carry a near-identical ~100-line SQL statement; the report shares the display's data at run time but the letter re-retrieves. Consolidate into one query/service.
• File-drop integration. Card production is a manual save of a <<field>> delimited text file to a local path; the downstream consumer (card print vendor or device) is not identified in source. Replace with a defined interface.
• Completion semantics. Requests are marked complete when the file is saved, and the "previous date" retrieval exists to re-produce a prior day's file — reproduce this reprint capability.
• Client-side state. Default file path and letter-suffix preference live in per-user INI files (idcard/w_enroll_idcard_usfhp ue_defaultfile, system/u_app_preference.sru); migrate to per-user settings storage.
• A queue report was specified but never built. The user guide lists an "ID Card report" — "Currently Not Available - Report showing all members in the ID card table by group and coverage" — among enrollment reporting, and repeats it under Future Enhancements (User Guide ch. 1). Nothing in idcard or enrolrpt implements it; a replacement system should provide queue visibility as a first-class feature.
• Per-row commits. f_mem_id_card_req commits after every inserted/updated request row and returns -1 without rolling back on error, so a failed batch submission leaves earlier rows committed (idcard/f_mem_id_card_req).
• The Save-As dialog is decorative. Create Card File calls GetFileSaveName but uses its return value only as a "user didn't cancel" test: the file actually opened is the INI path (APP PREFERENCES / idcard_file), so the filename and folder the operator picks are discarded and every run overwrites the same file (idcard/w_enroll_idcard_usfhp pfc_save). A replacement must either honour the chosen path or stop offering the choice.
• Legacy quirks to drop or decide on: the unused dddw_provider_ids lookup; the d_group_subs/d_individual_subs result sets carry seven literal-NULL placeholder columns plus a copies column that is retrieved as NULL and defaulted to 1 at save (idcard/d_group_subs, idcard/f_mem_id_card_req); the "# of Sets" (copies) column is present in the listing layout but the code that let users set it is commented out (idcard/w_homer_id_req ue_submitreq).

Open questions

1. Who opens w_enroll_idcard_usfhp? No menu or window in the extracted source opens the USFHP production window (searched all .srm/.srw); the only openers found are for w_homer_id_req. Is the USFHP screen launched from a library not extracted, run as a separate target, or retired?
2. Card production for non-USFHP groups — partially resolved. Cards are designed, created and distributed by SFPI/M3 itself, and are produced by a periodic "ID card run" that drains the request queue rather than at request time (User Guide ch. 1); the printing procedure is documented in a separate deck, How_to_Horizon_printer.ppt, referenced from the guide's contents page and not present in the extracted material (see "How cards were actually produced"). Still open: recover that deck; identify the program or report that feeds the Horizon printer from ID_CARD_REQ; and confirm what consumes id_req_batch_id (E/G/group-option routing, IDC-3), which ch. 1 never mentions.
3. Card file consumer. What system consumes the <<field>>-delimited file, and is the exact field order/format a contract that must be preserved? (Ch. 1 does not describe the USFHP file at all.)
4. Copy quantity — conflicting evidence. copy_qty is stored (default 1), the UI for entering "# of Sets" is commented out and the export writes one record regardless, yet the user guide documents both a user-updatable "# of Sets" field (IDC-22) and an automatic one-card/two-card rule driven by coverage level (IDC-18). Confirm with SMEs whether quantity was decided in HOMER, at the printer, or clerically.
5. Coverage type list. The request criteria drop-downs offer Medical, Dental, Vision only (idcard/d_indiv_id_req_parms, idcard/d_group_id_req_parms), while the production query joins Drug elections separately — confirm the full set of coverage types that can carry cards.
6. ID_CARD_REQ also used by stoploss and homersys (_re/analysis/schema.json) — confirm those touchpoints before changing the table's contract.
7. Effective-date logic. The individual criteria compute a coverage date from the member's latest eligibility (idcard/w_homer_id_req dw_parms_indiv.itemchanged sets idt_covr_dt) but the submitted request uses the election effective date from the listing row (ue_submitreq); idt_covr_dt appears unused after being set — confirm intended behavior.