The Scenario—you want to show a value list of Billing Codes for a therapist to use during a visit with a client. Visits are designated as different Types, which determine which insurance company will pay for the visit. The therapist may be fulfilling one of several roles during the visit and may or may not be designated as a Team Lead for the particular visit. The Billing Codes you are going to present to the therapist to select from are dependent on the Visit Type, the Role and whether or not the therapist is acting as a Team Lead.

In the Visit layout, we’re providing a radio button set to select the role, and a checkbox set (using a value list of 1 and 0) for the Team Lead.

The tricky part is that some billing codes depend on the Type and Role, but a few of them need to be added to the Billing Code value list only when the therapist is acting as Team Lead.

The table for the Billing Codes is named client_visit_BILLINGCODES_vl.
The table for the Visit is named client_VISIT.

In the Manage Value List dialog box, we have chosen the “Use values from field” option and then made the sections as indicated in the graphic below.

This means that the Billing Code value list is entirely dependent upon the relationship between the two tables.

The relationship between the Visit and Billing Code is defined as:
Visit::Type = Billing Code::Type
AND Visit::Role = Billing Code::Role
AND Visit::Team Lead = Billing Code::Team Lead

In both the Visit and Billing Code tables, the Type and Role are text fields. Each Visit will be of a single type, which make matching those two fields very simple.

For the Role, the Billing Code may have multiple roles to which it applies. This is addressed by using the Role field as a value list, with the options entered in the same field with a return separating the different values. In the Visit layout, the Role is a radio button set, allowing the user to choose only one role. If the role selected is one of the items listed in the Billing Code table’s Role field, it qualifies as a match for the relationship.

The Team Lead is a number field, and this is where the potential matching problem lies. In the Billing Code table, we can set the Team Lead value for our special codes as 1 and mark all of the other codes as 0 (zero). So in the Billing Code table, we’re basically treating Team Lead as a boolean (the value is either 1 or 0).

The trick to this is how you set the Team Lead field for the Visit. If the Visit’s Team Lead field is empty, the value list will be empty as well because an empty field does not match the number 0 (zero). We want to show all the normal Billing Codes (those where Team Lead is 0) if the Visit and Role fields match, and still be included when the Visit’s Team Lead field is checked.

This means that the Visit’s Team Lead field cannot be treated as a Boolean. If we change the Visit’s Team Lead value to 1, then our Billing Code value list will contain those codes with Team Lead marked as 1 in the Billing Code table, but it will lose all the codes marked as 0.

The solution to this is to offer the Team Lead field in the Visit layout as a Checkbox Set with values of 1 and 0, but make the field small enough to only let the 1 option be visible. Give the field an Auto-Entry option that calculates its value to 0. Don’t use any sort of script to change the field’s value from 1 to 0 (like you might do to control a normal boolean use), just allow the user to click on the 1 checkbox. The 0 value for the field (which is hidden) will always remain checked.

So when the Team Lead field is checked on the Visit layout, its value will be 1 AND 0, and the Billing Code value list will add the Billing Codes where the Team Lead value is 1, while keeping those marked as 0. When it is unchecked, the 0 codes will still remain and the 1 codes will disappear.

The post Empty Fields in Relationships appeared first on dbhq.net.