>A third solution would use three tables. The first is a 'header' table with columns for all common data. A second table contains the columns for operations and a third table contains the columns for A/R. This design complicates reporting and seems a little wierd because the second and third tables have a one-to-one relationship to the header table.

I've had similar situation with only two tables - patient's master record, and patient's detail record. Though, reporting was weird and I actually had a function where all the detail fields (about thirty logicals, two memos and couple of character fields) were translated into a long string with intelligible text, or an empty string if the checkmark "HasDetails" in the master table was unchecked, and used this function for reporting.

This grossly sped up the operation on this table - but then I never needed details on more than one master record at a time. The table size was also greatly reduced (roughly 3:1), because only about 1% of patients really had detail record.