RBA2000
Medical &
Dental Claims Processing Application
RBA2000
(Rules Based Adjudication) was designed with several objectives in
mind (the following are highlights, not a comprehensive list):
1. Avoid
the limitations and problems caused by flaws in database design
Applications seem to inherently suffer from
database design flaws.
These problems are not the result of programming bugs or bad data
entered by ill-trained operators; these problems are caused by how
the data is organized into tables.
Some applications require users to
re-enroll the same individual for each plan. Some systems
require individuals to provide 8-12 entries in the member table in
order to support claim processing. This causes many difficulties,
one of which is trying to match EDI claims with the correct record
in the member table.
This problem is not a program bug.
It's not caused by operators who don't know how to use the system.
Rather, it's imposed by how the data fields are organized into
tables, a flaw in the database design. Before we wrote a single line
of code we noted all the problems of other systems that we knew of.
Then we designed a system to avoid those problems.
2. Allows the benefit administrator to
implement
very sophisticated payment policies without the need for further programming
Typical
claim processing applications were designed with a specific plan in
mind. As plans and payment policies expanded and changed, the
tables and programs were patched to support the new capability.
RBA2000 was designed from the beginning to use any field on the
claim (or any field in the database for that matter) to help
determine how a benefit should be paid. What if the plan pays
differently depending on the diagnosis, or the specialty of the
provider, or the location, or the relationship to the insured? No
problem. I've even joked that RBA2000 could pay differently
depending on the last name of the provider or whether the services
were performed on the day of a high tide, and without needing a
programmer. (Well, actually we would need a programmer to create the
table of dates for high tide, but after that, the benefit
administrator could set up and administer the plan with the tools
supplied by RBA2000.)
3. Provide
scalability to accommodate an extremely large database and number of users
We wanted
a system that could potentially grow to include every man, woman, and
child in the United States. This would require several computers,
but we've designed the files in such a way that it would be
transparent to the operator.
Another
reason RBA2000 is so scalable is because we have paid particular
attention to coding efficiency. This includes caching on all
file opens.
A file is opened just before the first read of that
file. If we never use a file, it is never opened, and once it's
opened re never have to re-open it until we logoff. Since opening a
file is very time consuming, this feature alone adds greatly to the
overall efficiency of the application.
Table
reads are also cached. If we read, say, a zip code for validation,
we cache that read. The next time we need to validate that zip code
we use the cached copy. For example, when we enroll a new group,
most employees of that group live within a limited number of zip
codes. This saves an enormous amount of disk IO and thus allows the
same hardware to support more users.
