Coordination of Benefits & Pre-Existing Conditions

Libraries: cob (2 windows, 7 DataWindows), preex (3 windows, 4 DataWindows). Closely coupled logic also lives in enroll (the actual COB editor window and quick-enroll COB capture), clmentry (claim-level other-insurance capture), clmsproc (COB application during adjudication), enrolaud (COB audit trail), um_cm/um_ur (COB shortcuts from case/utilization management), enrolrpt (Medicare COB census), homersys (member deletion cascade) and mailobj (address reference counting). Broader claims adjudication is documented in the Claims module; this page covers only the COB/pre-ex specific behavior.

Purpose

• Record, per covered member, every other insurance coverage the member holds (carrier, policy, effective/expiration dates, order-of-benefit status, coverage type, plan type, other-insured and employer contact details) in the coord_of_bens table (cob/d_cob_detail, enroll/d_qe_cob_detail).
• Use that enrollment-level COB information, together with explanation-of-benefit (EOB) detail captured on the claim, to reduce the plan's payable amount on claim lines during adjudication (clmsproc/n_claim_adjudication, function of_ApplyCOB).
• Capture the other insurance block of the claim form itself (claim_other_ins_infos) during claim entry so it can be referenced and reprinted (clmentry/d_claim_other_ins_info_hcfa1500 and form-specific variants, clmprint claim print DataWindows).
• Record the outcome of pre-existing condition investigations per member, eligibility period and diagnosis code in pre_existing_conditions (preex/w_preex_maint, preex/d_preex_conditions).

Both entry points are launched from the Claims menu of the application frame: "Coordination of Benefits" opens w_cob_select and "Pre-Existing Conditions" opens w_preex_maint (homersys/m_sys_frame).

Key workflows

Other-insurance capture (enrollment-level COB)

1. The operator opens COB Select (cob/w_cob_select) from the Claims menu (homersys/m_sys_frame) or via the Create COB / Edit COB button on the utilization-management and case-management screens, which pass the member id in (um_cm/w_um_case_management, um_ur/w_um_pre_certification, um_ur/w_um_referral, um_ur/w_um_admission_notification, um_ur/w_um_authorization).
2. A member search (u_member_search) retrieves the subscriber's whole family; the selection list (cob/d_cob_header) outer-joins family and members to coord_of_bens so every family member appears, with the literal ** NO COB ** shown when a member has no COB record. Pseudo-rows carrying ** NO COB ** are discarded before any update so they are never written to coord_of_bens (cob/w_cob_select event pfc_preupdate).
3. Double-clicking a ** NO COB ** row adds a new record; double-clicking an existing row opens the registered edit window w_enrollment_cob_maint through the edit service (cob/w_cob_select, dw_selection::constructor and doubleclicked).
4. In the editor (enroll/w_enrollment_cob_maint, DataWindow enroll/d_qe_cob_detail) the operator records carrier, policy number, effective/expiration dates, status, status reason, coverage type, plan type, plan phone, employer/school, other-insured name and phone, and up to three addresses (plan, employer, other subscriber; cob/d_cob_address over the shared addresses table). On save the record is validated (see COB-02 to COB-06) and each modified address is standardized through the external mailers service before the address key is stored on the COB record (enroll/w_enrollment_cob_maint wf_stand_addr; the same pattern exists in the unused cob/w_cob_maintenance).
5. COB rows can also be created during quick enrollment (legacy window enroll/w_quick_enroll_cob, marked "** OLD **") and viewed on the enrollment maintenance dependent tab, although that tab's COB DataWindow (enroll/d_enroll_dependent_coord_of_bens) is commented out in the current source (enroll/w_enrollment_maintenance).
6. All inserts/updates/deletes on coord_of_bens are visible in the enrollment audit-trail viewer, which unions current rows ("Insert") with audit rows (enrolaud/w_enrollment_log, enrolaud/d_audit_trail_cob).

Claim-level other-insurance capture

During claim entry, each claim form type has an "other insurance information" tab section writing to claim_other_ins_infos keyed by claim_id + seqno: other carrier name/address, other subscriber identity (name, id, DOB, gender, policy group), employer, patient relationship, payer, authorization code, provider number, signature indicators, prepaid amount and balance due (clmentry/d_claim_other_ins_info_hcfa1500, ..._ub92a/b/c, ..._sfpi_dental, ..._sfpi_vision, ..._infoa; registered against the claims controller in clmentry/u_claims_tab_hcfa, u_claims_tab_ub92, u_claims_tab_sfpi_dental, u_claims_tab_drug). The same table is read by the claim print DataWindows (clmprint/d_claim_print_hcfa1500 and variants). This is descriptive data from the submitted claim; the adjudication engine coordinates dollar amounts from the EOB detail table claim_eob_info_details, not from claim_other_ins_infos (clmsproc/n_claim_adjudication of_ApplyCOB).

COB application on claims (adjudication)

clmsproc/n_claim_adjudication loads two supporting datastores per batch: active primary/unknown COB rows for the patients being processed (clmsproc/d_adjd_coord_of_bens) and ESRD claims lacking an ESRD COB record (clmsproc/d_adjd_esrd_without_cob).

COB is applied once per claim line, immediately before the first PAID-type benefit rule (or at the end of rule processing if no PAID rule fired); the line's payable amount is replaced only when the function returns a non-negative amount (clmsproc/n_claim_adjudication, of_AdjudicateManual rule loop and of_ApplyCOB).

Pre-existing condition investigation

1. The operator opens Pre-Existing Conditions (preex/w_preex_maint) from the Claims menu (homersys/m_sys_frame).
2. Member search by SSN, group id, last name, member id or group name; results are restricted to groups the user is authorized for via the security tables (preex/w_preex_maint cb_member_search::clicked, using preex/d_preex_count then preex/d_preex_member_select). Multiple matches open a picker (preex/w_preex_member_select).
3. The screen shows the member's HIPAA waiting periods (d_enroll_wait_pd from the enroll library) with a Start Periods button that opens a read-only viewer of all waiting periods (preex/w_preex_view_wait_period, inherited from enroll/w_enroll_view_wait_period).
4. The operator selects one of the member's eligibility periods (preex/d_preex_eligibility_periods over member_eligibilities); the conditions grid retrieves rows for that period (preex/d_preex_conditions).
5. For each investigated diagnosis code the operator records whether it is pre-existing (Yes/No) and the end date of the pre-existing limitation; rows are stamped with the creating user and date (preex/w_preex_maint dw_preex_cond::pfc_addrow, pfc_preupdate).

Business rules

Coordination of benefits

#	Rule	Source
COB-01	A COB record is identified by dependent member, subscriber member, carrier, coverage type and effective date; one member may hold multiple COB records over time and across coverage types.	cob/d_cob_detail, enroll/d_qe_cob_detail (key columns, update key in place)
COB-02	Carrier, effective date, status and coverage type are mandatory on every COB record; the save is blocked with a specific message when any is missing.	enroll/w_enrollment_cob_maint wf_validate; required-field marks in cob/d_cob_detail
COB-03	COB status values come from the COBSTATUS code table (observed values in logic: Primary, Unknown; adjudication sorts "status" ascending to put Primary first). Status reason values come from COBREASON; coverage type from TYPEOCLAIM; plan type from COBTYPE.	cob/dddw_cob_status_cd, cob/dddw_cob_reason_cd, cob/dddw_typeoclaim, cob/dddw_cob_type_cd; clmsproc/n_claim_adjudication of_ApplyCOB
COB-04	Within any one coverage type, a member may have only one COB record of a given status (e.g. one Primary) for any overlapping date range; overlap comparison treats a missing expiration date as open-ended.	enroll/w_enrollment_cob_maint wf_validate (RULE1), wf_checkforduplicates, of_comparedates
COB-05	Within any one coverage type and status, only one record per plan type may exist for an overlapping date range, except plan type Medicare, which is exempt from the plan-type duplication check.	enroll/w_enrollment_cob_maint wf_validate (RULE2)
COB-06	If the status is Unknown, the duplication rules COB-04/COB-05 are not applied.	enroll/w_enrollment_cob_maint wf_validate
COB-07	Each of the three COB addresses (plan, employer, other subscriber) that was added or modified is standardized through the mailers address service before saving; the returned address number is stored on the COB record. If an address is referenced by more than one record, the user chooses whether to update all references or create a new address.	enroll/w_enrollment_cob_maint wf_stand_addr; cob/w_cob_maintenance wf_stand_addr, pfc_save; reference counting in mailobj/nvo_mailers
COB-08	Quick-enroll COB capture defaults the status of a new COB record to Unknown.	enroll/d_qe_cob_detail (status initial value)
COB-09	An earlier window-level duplicate/date-range validation was retired in favor of a database trigger performing the same checks (comment dated 3/13/00); the window code was kept but disabled.	cob/w_cob_maintenance wf_validate_rules
COB-10	Adjudication considers only COB rows with status Primary or Unknown, and ignores rows whose carrier begins with NOI (no other insurance) or **.	clmsproc/d_adjd_coord_of_bens (retrieval WHERE clause)
COB-11	COB is evaluated for a claim line only when the member's benefit plan defines a COB method code; otherwise the line is paid without COB.	clmsproc/n_claim_adjudication of_ApplyCOB (COB_method_cd null check)
COB-12	A COB record applies to a claim line when it matches subscriber and dependent keys, its effective date is on or before the line's from-date, its expiration date is null or on/after the from-date, and its coverage type equals the claim's type of claim.	clmsproc/n_claim_adjudication of_ApplyCOB (filter strings)
COB-13	When EOB detail rows are attached, each row's submitted amount must equal the claim line's claimed amount, and a non-zero allowed amount must equal submitted minus write-off; violations log EOB error messages and prevent COB reduction for that line.	clmsproc/n_claim_adjudication of_ApplyCOB (submitted/allowed validation)
COB-14	With a valid EOB and matching COB record, the payable amount is reduced according to the plan's COB method: NORMAL pays the lesser of the current benefit amount or claimed minus (other-payer paid plus the larger of other-payer write-off or the line's own claimed-minus-allowed); CARVEOUT subtracts the other-payer paid amount from the benefit amount (floor zero); REDUCECLM makes no further reduction because the claimed amount was already reduced; PAYBALANCE pays the remaining balance (benefit minus other-payer paid).	clmsproc/n_claim_adjudication of_ApplyCOB (choose case on COB method)
COB-15	If EOB detail is attached to the line but the member has no matching COB record, the line is messaged "EOB without COB" (message id 141) and no COB reduction is applied.	clmsproc/n_claim_adjudication of_ApplyCOB (il_eob_without_cob=141)
COB-16	If the member has an applicable Primary/Unknown COB record but no EOB is attached: when the primary plan type is INTERNAL the line is messaged that the primary plan is administered in-house (message id 143); otherwise it is messaged that a primary-carrier EOB is expected (message id 142).	clmsproc/n_claim_adjudication of_ApplyCOB (il_cob_without_eob=142, il_cob_without_eob_internal=143)
COB-17	Exception: a drug-form claim whose applicable COB carrier is MEDICARE is not messaged for a missing EOB; COB is treated as not applicable.	clmsproc/n_claim_adjudication of_ApplyCOB (Medicare/drug carve-out)
COB-18	Every claim containing an ESRD diagnosis (a diagnosis code belonging to a diagnosis group flagged esrd_ind = 'Y') must have a COB record with status reason ESRD for the patient; otherwise the claim is messaged (message id 210).	clmsproc/d_adjd_esrd_without_cob; clmsproc/n_claim_adjudication (il_esrd_without_cob=210, ESRD check)
COB-19	COB-related exception messages are automatically closed when their condition no longer applies on reprocessing.	clmsproc/n_claim_adjudication of_ApplyCOB (of_close_message calls), ESRD block
COB-20	COB is applied at most once per claim line, before PAID-type benefit rules (or after the rule loop if no PAID rule was reached); the payable amount is overwritten only when COB returns a non-negative amount.	clmsproc/n_claim_adjudication (rule loop, lb_cob_checked)
COB-21	Claim entry stores the claim form's other-insurance block per claim and sequence number (other carrier, other subscriber identity, employer, patient relationship, payer, signatures, prepaid amount, balance due); this data is reprinted on claim forms.	clmentry/d_claim_other_ins_info_hcfa1500 (and form variants), clmprint/d_claim_print_hcfa1500
COB-22	Deleting a member deletes the member's coord_of_bens rows within the same transaction, before the family record is removed.	homersys/n_delete_member (of_del_coord_of_bens)
COB-23	Utilization/case-management screens surface COB: the button label toggles between "Create COB" and "Edit COB" based on whether any COB rows exist for the member, and clicking opens the COB Select screen for that member.	um_cm/w_um_case_management (wf_countcob, cb_cob::clicked), um_ur/w_um_pre_certification, um_ur/w_um_referral, um_ur/w_um_admission_notification, um_ur/w_um_authorization
COB-24	Case-management case searches can filter to cases with (or without) a COB record whose dates overlap the case period.	um_cm/d_um_management_cases (exists / not exists subqueries on coord_of_bens)
COB-25	The Medicare census report selects members with an active COB record whose status reason is Medicare as of the report date (null expiration treated as open-ended).	enrolrpt/d_census_medicare_with_cob
COB-26	All changes to COB records are auditable; the enrollment log shows current rows as "Insert" plus historical audit rows for a subscriber's family.	enrolaud/w_enrollment_log (wf_set_cob), enrolaud/d_audit_trail_cob

Pre-existing conditions

#	Rule	Source
PRE-01	A pre-existing condition record is identified by dependent member, subscriber member, eligibility-period effective date and a 3-character diagnosis code.	preex/d_preex_conditions (key columns)
PRE-02	The diagnosis code entered must exist in the diagnosis-code table; the save is rejected naming the invalid code.	preex/w_preex_maint pfc_preupdate (SELECT against diagnosis_codes)
PRE-03	If a condition is marked pre-existing (pre_ex_ind = 'Y'), an end date for the limitation is mandatory.	preex/w_preex_maint pfc_preupdate
PRE-04	The pre-existing indicator is a Yes/No choice that starts unset on a new row; the user must decide it explicitly.	preex/d_preex_conditions (pre_ex_ind values), preex/w_preex_maint dw_preex_cond::pfc_addrow (comment)
PRE-05	New condition rows are stamped with the creating user id and creation timestamp and tied to the currently selected eligibility period's effective date.	preex/w_preex_maint dw_preex_cond::pfc_addrow
PRE-06	Conditions are tracked per eligibility period: selecting a different period of the member re-retrieves the conditions for that period's effective date.	preex/w_preex_maint dw_eligibility_periods::clicked; preex/d_preex_eligibility_periods
PRE-07	Member search results are limited to members in groups the current user is authorized to see (security user-class tables).	preex/w_preex_maint cb_member_search::clicked
PRE-08	The member's HIPAA waiting periods are viewable from the pre-ex screen in read-only mode.	preex/w_preex_view_wait_period (dw_wait_period.Modify("DataWindow.ReadOnly = Yes")), preex/w_preex_maint cb_all_wait_periods
PRE-09	Saving pre-ex conditions commits the transaction and re-retrieves so diagnosis descriptions display; failures roll back with a "could not be saved" message.	preex/w_preex_maint pfc_save

Data and CRUD

Table	Purpose	Create	Read	Update	Delete
coord_of_bens	One row per member/carrier/coverage-type/effective-date other-insurance coverage: dates, carrier, policy no, phones, status, status reason, plan type, coverage type, other-insured name, employer, three address keys.	enroll/w_enrollment_cob_maint (via d_qe_cob_detail), enroll/w_quick_enroll_cob (legacy), cob/w_cob_maintenance (unused)	cob/d_cob_header, cob/d_cob_detail, enroll/d_qe_cob_header, enroll/d_qe_cob_detail, enroll/d_enroll_dependent_coord_of_bens, clmsproc/d_adjd_coord_of_bens, clmsproc/d_adjd_esrd_without_cob (not-exists), um_cm/um_ur count queries, enrolrpt/d_census_medicare_with_cob, enrolaud/d_audit_trail_cob, mailobj/nvo_mailers (address reference counts)	same editor windows	editor delete row (enroll/w_enrollment_cob_maint pfc_deleterow); member deletion cascade homersys/n_delete_member
claim_other_ins_infos	Other-insurance block of a submitted claim, keyed claim_id + seqno.	claim entry tabs (clmentry/u_claims_tab_hcfa etc. via d_claim_other_ins_info_*)	claim entry, claim print (clmprint/d_claim_print_*)	claim entry	claim entry (with claim)
pre_existing_conditions	Investigation outcome per member pair, eligibility period and diagnosis code: indicator, end date, create stamp.	preex/w_preex_maint	preex/d_preex_conditions	preex/w_preex_maint	row delete in preex/w_preex_maint (right-mouse table menu)
claim_eob_info_details	Other-payer EOB amounts per claim line (submitted, allowed, write-off, payable); the dollar input to COB reduction. Maintained by claims module; read here.	(claims module)	clmsproc/n_claim_adjudication of_ApplyCOB	(claims module)	(claims module)
addresses	Shared address rows referenced by the three COB address keys.	via mailers save (mailobj/nvo_mailers)	cob/d_cob_address	via mailers	(address module)
codes	Code sets COBSTATUS, COBREASON, COBTYPE, TYPEOCLAIM drive the COB drop-downs.	—	cob/dddw_cob_status_cd, dddw_cob_reason_cd, dddw_cob_type_cd, dddw_typeoclaim	—	—
diagnosis_codes, diagnosis_groups, diagnosis_code_groups	Diagnosis validation for pre-ex; ESRD diagnosis grouping (esrd_ind) for COB-18.	—	preex/w_preex_maint, clmsproc/d_adjd_esrd_without_cob	—	—
member_eligibilities	Member eligibility periods that scope pre-ex investigations.	—	preex/d_preex_eligibility_periods	—	—

Migration notes

• The registered COB editor lives in the enroll library. cob/w_cob_maintenance is explicitly commented "Unused - w_enrollment_cob_maintenance is actual window" (cob/w_cob_maintenance header comment); the edit service in cob/w_cob_select opens w_enrollment_cob_maint. Migrate the enroll-library editor's validation (COB-02..COB-07), not the dead window's.
• A database trigger owns part of the COB validation. The in-window date-range duplicate checks were replaced by a trigger in 2000 (cob/w_cob_maintenance wf_validate_rules comment). The trigger source is not in the PowerBuilder export; its logic must be recovered from the database before migration (see open questions).
• Two different "other insurance" stores exist. Enrollment-level coord_of_bens drives adjudication; claim-level claim_other_ins_infos is descriptive form data. A target design should keep the distinction or define an explicit reconciliation, since today nothing links them (clmsproc/n_claim_adjudication reads only coord_of_bens and claim_eob_info_details).
• COB order determination is minimal. The system stores an order-of-benefit status per record and validates uniqueness (COB-04), but there is no birthday-rule or employment-based order calculation in source; primacy is a data-entry decision, with Unknown as an allowed unresolved state. Sorting in adjudication merely puts Primary before Unknown alphabetically (clmsproc/n_claim_adjudication of_ApplyCOB).
• COB savings math is method-driven per plan (COB_method_cd with values NORMAL, CARVEOUT, REDUCECLM, PAYBALANCE); the NORMAL formula embeds 2008-era fixes layered over commented-out older formulas — migrate the final expression, and validate it against historical claims (COB-14).
• Message-driven pend workflow. COB exceptions do not auto-deny; they log numbered messages (141, 142, 143, 210) that examiners work and that auto-close on reprocessing (COB-15..COB-19). The target system needs an equivalent work-queue concept.
• Pre-ex is capture-only in source. pre_existing_conditions is written and read only by the preex library; no adjudication code references it. Whether claims were pended/denied for pre-ex manually, via DB objects, or not at all must be confirmed with SMEs. HIPAA-era pre-existing limitation rules are themselves obsolete under later regulation; confirm whether this function needs migrating at all.
• Address standardization is a hard external dependency (mailers DLL/server) for COB address entry, including multi-reference address update prompts (mailobj/nvo_mailers, enroll/w_enrollment_cob_maint wf_stand_addr).
• Diagnosis codes are char(3) in pre_existing_conditions.diag_cd (preex/d_preex_conditions), reflecting truncated ICD-9 categories; any migration must decide how to map to full current diagnosis coding.

Open questions

1. What is the definition of the database trigger that replaced wf_validate_rules for COB duplicate/date-range checking (cob/w_cob_maintenance comment, 3/13/00)? Are COB-04/COB-05 enforced identically at the database level?
2. The full value lists for COBSTATUS, COBREASON, COBTYPE and TYPEOCLAIM live in the codes table, not in source (cob/dddw_cob_status_cd etc.). Code logic references Primary, Unknown, Medicare, INTERNAL, ESRD; window comments also mention secondary/tertiary (enroll/w_enrollment_cob_maint wf_validate RULE1 comment). Export needed.
3. How are message ids 141 (EOB without COB), 142 (COB without EOB), 143 (internal primary) and 210 (ESRD without COB) worded and routed, and what examiner actions resolve them? The text lives outside the exported source (clmsproc/n_claim_adjudication instance variables only give the numbers).
4. Is any pre-existing-condition enforcement applied to claims (pend/deny) via database objects or manual procedure? Source shows capture only (preex library is the sole consumer of pre_existing_conditions).
5. preex/w_preex_maint contains an unfinished branch: when a dependent has more than one subscriber, the code comments "open a window so they can pick up one" but selects nothing (cb_member_search::clicked). Confirm intended behavior for members appearing under multiple subscribers.
6. The COB selection list registers eff_dt, cob (carrier) and benefit_coverage_type_cd as edit-service key columns but the editor retrieves by five keys including subscriber (cob/w_cob_select dw_selection::constructor vs enroll/d_qe_cob_detail arguments). Confirm whether carrier+coverage+date uniquely identify a record per member in practice.
7. enroll/w_enrollment_cob_maint is marked "NOT REGISTERED" in its export comment yet is opened by name from cob/w_cob_select; confirm which window version was deployed in production.
8. The Medicare/drug exemption (COB-17) implies pharmacy claims coordinate with Medicare outside this logic. Where is Medicare Part D / drug COB handled?
9. coord_of_bens.status sorting relies on alphabetical order to rank statuses (Primary < Unknown); if secondary/tertiary values exist in data, ordering would be Primary, Secondary, Tertiary, Unknown alphabetically — confirm this is the intended precedence for picking Object.plan_type[1] (clmsproc/n_claim_adjudication of_ApplyCOB).