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).

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 (default from user INI setting APP PREFERENCES / idcard_file, fallback C:\IDCARD.TXT; also settable via Preferences > Set Default File), 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).

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. (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)
• 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. Invalid rows are visually highlighted, and the grid footer shows Valid: and Errors: counts. (idcard/d_enroll_idcard_usfhp, error_flg expression and footer computes)
• IDC-12 (Card file export). The card file must contain one record per valid row, each field wrapped in <<...>> delimiters, terminated by <EOL>, in this 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)

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.
• Per-row commits. f_mem_id_card_req commits after every inserted/updated request row; batch submissions are therefore not atomic (idcard/f_mem_id_card_req).
• 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. ID_CARD_REQ is generic and enrollment queues requests for all clients, but the only production screen found is USFHP-scoped. How are cards produced for other groups (external vendor extract via the batch id E/G/group-option routing in IDC-3?), and what consumes id_req_batch_id?
3. Card file consumer. What system consumes the <<field>>-delimited file, and is the exact field order/format a contract that must be preserved?
4. Copy quantity. copy_qty is stored (default 1) but the UI for entering "# of Sets" is commented out and the export writes one record regardless — is multi-copy still a requirement?
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.