Newbie: creating linked forms / data

  • Thread starter Thread starter DRBE
  • Start date Start date
D

DRBE

I'd be grateful for any advice for a very inexeperienced newbie to databases:
I am busy trying to create a database to store data in sub sections, and
eventually spit it all out into a report, with some invoicing and
appointments facilities.
because it is a lot to capture I am trying to separate each section of data
into separate tables with relevant forms. It would be too bukly and
cumbersome to keep track having all fields in 1 table / form
so would be 1 client with unique reference
1)Form 1 / table 1 initial client data with option to click through to the
next form
2)form 2 / table 2 ideally should already know which client I am now
capturing for, rather than having to refill in the unique reference
and so for about 13 forms / tables.

when I tried to do this, I used the "command" : open form
however this does not remeber which client I was busy with. How do I carry
over which client. Same applies to creating invoice, would want the form to
already "know" which client I am dealing with based on click through from a
click through button on the main client form.

I'd be grateful for any advice, as I am trying to get started, and finding
it a bit of a brain strain trying to get my head around all the info.

thanks
Bruce
 
Bruce,

For DB structure questions (which this one is) you need to describe the
information/process that you are trying to database. Other than saying it
somehow involves clients, you didn't tell us anything about that. Instead,
99% of your post is just telling us how you (unsuccessfully) tried to do it.

Hope this helps.

Fred
 
Sorry if I didn't include enough information.
basically what I am trying to achieve is:
I am a Dr and provide medial reports for companies, and I want to be able to
capture information on patients , using drop down menus in pre-formated
forms, while they are with me. These responses could be saved into tables (
I had envisaged separate tables for each aspect of the examination. )

so 1 client / patient would have +- 13 tables which store the info from 13
forms, with a unique ID to act as a reference linking them.

The idea being to, at the end, be able to then process all these tables
into a single predefined report, that just needs the blanks filling based on
the responses.

So the current step I can't seem to figure is how to move from 1 form to the
next (eg examination of neck to examination of chest), in a way where the
form knows I am still dealing with the same client.

The same applies when I'm in the form for collecting client data eg address
etc. I want to be able to click on an icon on the form to link to another
form that will collect the invoice data, but once again, the form already
know which client the invoice is for, rather than having to type in the
invoice number.

Is it better to store it all in 1 supersized tables so that 1 client = 1
record, (but then looking at 100+ fields!)
 
No need to say "sorry" , being new at DB's means also being new at describing
the process being databased (and the mission) which can be even harder. If
you want to force yourself to be 100%, describe the process and you goals
without using any databased terminology.

Now, you've provided a lot more info on the process. In this case the info
informs me enough to ask one unanswered fundamental question. Is your
practice one of tracking just one of these visits (e.g. doing employment
physicals) or of tracking patients long term / over many of these visits
(e.g. a family physician)

Your mentioning "invoice" opens another universe of questions, and so let's
temporarily ignore that "invoice" word.

You have a lot a flexibility in designing the forms, that's for later. To
start with you need the right table structure.

If your scenerio is one-patient-one-visit , then one big "visits" table
would probably the your best structure. But you could make a "visits" table
(PK = VisitNumber) and then an "exam elements" table linked to it, and such
will prevent having to change the table structure under likely changes.
You can even separate the non-visit-related patient data into a seperate
"Patients" table, PK = PatientID.

If you have multiple visits per patient, then the above-described
separation/creation of a "Patients" table becomes necessary rather than
optional.

Well, that's a foundation for accomplishing the rest of what you describe.

Hope that helps a little.

Fred

PS: The usual HIPAA sermon I see on some of these post responses would make
me sound cool but such is not germane to a tool-use discussion.
 
Back
Top