Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion GroupsFormsForms ProgrammingQueriesModules / DAO / VBAReports / PrintingMacrosDatabase DesignSecurityConversionImporting / LinkingSQL Server / ADPMultiuser / NetworkingReplicationSetup / ConfigurationDeveloper ToolkitsActiveX ControlsNew UsersGeneral 1General 2
Access DirectoryToolsTutorialsUser Groups
Related Topics
SQL ServerOther DB ProductsMS OfficeMore Topics ...

MS Access Forum / Database Design / April 2008

Tip: Looking for answers? Try searching our database.

Design logic

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
kathy b - 30 Apr 2008 18:30 GMT
I am creating a clinical research database and I am having trouble with some
of the design logic.

Each Protocol has a unique Budget.  Each Budget includes all the Visits
required for the study as well as which medical procedures are completed at
each visit and the corresponding fee.  These items are broken down to a per
Patient  $ amount.  Each Budget also includes overhead applied at the
Protocol level (non-patient specific).

The problem I'm having is how to track the completion and subsequent payment
for each visit for multiple Patients.

Example:  As of today, Patient X has completed Visits 1, 2, and 3 and the
corresponding fee is now due.  While Patient Y has completed only Visit 1,
with the corresponding fee now due.  etc.

Originally I created formProtocol with subformPatients with subdatasheet
Visits.  However this design requires the manual entry of the particulars for
each Visit and Medical Procedure for each Patient.  (Remember the particulars
are the same for each patient other than completion date.)  Is there a less
labor intensive method?
Fred - 30 Apr 2008 18:51 GMT
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?
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.