I think that you are using "visit" to mean two different things, and to start
treating them separately.
1. The smallest division of work in your Protocol/Budget/Visit
pyramid/heirarchy, and also the smallest unit of billing. Your post also
implies that it has a fixed price.
2. An instance of a patient doing #1
So, continue to use your Protocol/Budget/Visit pyramid to define those
items.
Now make a PatientEvents table which records #2's (each instance of a
patient doing a #1) with prices, plus paymenets received from them (of the
opposite sign) . Include a field which says what it is. It's linked to
#1 and to a patient table. I think that everything you want can be obtained
from that structure.
> I am creating a clinical research database and I am having trouble with some
> of the design logic.
[quoted text clipped - 17 lines]
> are the same for each patient other than completion date.) Is there a less
> labor intensive method?
kathy b - 30 Apr 2008 19:09 GMT
Thanks! I wasn't seeing the forest for the trees! The PatientEvent table
should solve the problem.
> I think that you are using "visit" to mean two different things, and to start
> treating them separately.
[quoted text clipped - 37 lines]
> > are the same for each patient other than completion date.) Is there a less
> > labor intensive method?