Why we recommend running Billing Rule Tests

Our opinion about running billing rules at the time of billing. Ultimately, it’s up to the customer to decide if they want to do this activity or not, but from our perspective, running the rules is a best practice for these reasons:

1. Timing of Data Entry
   Depending on the rules, the rules may be checking for things that happen well AFTER the DSP enters the data.

Examples:

• Bed checks (happen later that night)
• Auditing of Notes (happens sometime after the support is entered, maybe not even that day)

2. Completeness
   Depending on the rules, the rules may be checking for certain statuses that a DSP could easily miss.

Examples:

• Is there an active and non-expired IPOP and DSP? Is unlikely that DSPs will want to check that every day or should be expected to reliably remember those dates.

3. Overlaps
   Depending on the rules, the rules may be checking for overlaps with other support records.

• At the time the DSP makes a choice, the other supports may not be entered yet – hence there may be an overlap that is not detected until later. This is especially true for Day Services if they are not entering attendance or supports until end of day.

4. Human Error
   Depending on the rules, multiple items may need to be checked at the same time and remembered later in the day.

• When a decision involves multiple considerations (as some of these billing scenarios do), computers are more accurate and produce a more consistent and predictable result than a person, especially someone that may be at an entry level and working in the hectic environment of a I/DD program.

5. Group Size
   Depending on the rules, the timing of the performed actions can be hard to remember or plan for.

• Several of the rule sets look at total minutes of support for various group sizes. For example, a support of group size two may also roll up minutes for group size 1. When entering a support of a particular group size, the DSP may not yet know what additional group activities may be performed that day nor what the group size for those activities will be. So, they can guess at support minutes, but the accurate count will not be known until end of day after all supports are completed.

The other reason to run rules at billing is some programs (like residential) require notes to be audited. Auditing takes place later and is not done when the DSP chooses. Ultimately it's the customer's policy, but to achieve the goal of billing validation, it must take into account note audits, no overlaps, active ipops, and bedchecks... none of which has happened at the time the DSP makes their choice.

Add in the fact that running the rules is fast and easy (only a few clicks) and that it will potentially prevent billing errors that will cost a lot of time and effort to track down and correct “after the fact” (and potentially even penalties for some customers), it seems like a very simple step to run the rules. In fact – the ability to validate billing prior to submission is a benefit and part of our value-proposition to potential customers. To rely on DSP opinions when a structured approach is so readily available (even when the DSP is probably going to be right most of the time), as well as performing a daily check which may or may not catch all issues listed above depending on the dates and times when all the data was entered and when you did that check, can reduce discrepancies, but may still not account for the items mentioned above. This is ulitmately the customer's decision, but our recommendation is that before billing is created, the Billing Rules test should be run.