OO Design Question

[Rathtap]

I am writing an assembly that calculates an expected payment based on
a patient's diagnosis and service lines performed in the hospital and
the contract set up for the payer -- all this info is retrieved from
the database. The calculation class has to be able to process multiple
claims at the same time so that I do not have to reload contract data
for each payer (insurance) into memory since they will be the same for
all the claims being processed in the batch. After calculating, the
expected payment has to be written back into the same table that holds
the service information. Based on the type of service (at present
there are 20), calculations are done differently.
My questions are on design.
1. Should I have separate Claim, Claims and Calculation Classes?
2. How should I declare services that are performed on the patient?
Should it be a class by itself or an updateable Dataset in the Claim
class. Payment is calculated on each service line and there is an epay
column in the Services table that needs to be updated once payment for
that line is calculated. An overall Expected Payment is also stored in
the Master Patient Table.
3. Overall scenario that I envision is:
a) A Calculation class that receives a batch of claims that need
calculating. It will have a number of methods that will actually do
the calculations.
b) A Claims class (collection?, properties?, methods?)
c) A Claim class (collection?, properties?, methods?)
d) Some means of retrieving and updating info in the database.

Thanks for the help.

 

[Howard Swope]

Some thoughts are listed in the original:

I am writing an assembly that calculates an expected payment based on
a patient's diagnosis and service lines performed in the hospital and
the contract set up for the payer -- all this info is retrieved from
the database. The calculation class has to be able to process multiple
claims at the same time so that I do not have to reload contract data
for each payer (insurance) into memory since they will be the same for
all the claims being processed in the batch.

I don't understand why this would require the claims to be processed in a
batch. You could load the payer information into memory when the application
starts and then only reload that information if their is a change to the
payer information. I can't really say, but it sounds to me like these claims
could be queued up and processed by a thread pool tweaked according to
machine resources or distributed accross machines if required.

After calculating, the
expected payment has to be written back into the same table that holds
the service information.

Sounds like your tables need further normalization.

Based on the type of service (at present

there are 20), calculations are done differently.
My questions are on design.

1. Should I have separate Claim, Claims and Calculation Classes?

As a rule of thumb you want your objects to most closely resemble the way
they actually exist in the problem space. However, it also makes sense to
separate your business logic since it will certainly change and evolve. You
will probably calculate claims one way and then need to change that. You
will probably also enter into an instance of specialized calculation given
some circumstance, so you may want to allow for that fact.

In terms of a Claims class, I would say yes. I favor a hierarchical object
model consisting of trees of collections, but the more tightly coupled your
objects are the less versatile your system will be. Say you want to be able
to throw those claim objects around for processing, if they are tightly
coupled to a collection class, it might make things difficult. On the other
hand it is always nice to be able to iterate through an object tree.