Forms with new and 'looked up' data

[kconlon]

I am creating a db that tracks our infusion pumps. I have tables for the pumps, Facility Demographics, Maintanance, History but I need to create a form that allows for 2 different scenarios to get the patient information into the history.
1. Pt is at a Facility (Facility Name, Address, Phone) are not needed to be added, information 'pops up' in respective fields, user just enter patients name. I have these field locked so users can not alter facility information
2. Private residence patient where you need to enter all of the demographics . I don't want this info entered into the Facility Table
This demographic information woud go into the history table.
[This I have created]
Then you would enter the serial number of the pump which pulls the pump info (make, model) from pump table and the most recent Maintance service due (from the Maint. History)

Also, is there a way to make a print out of the Field Names for the tables?

Thanks all
and Blue Skies
Kevin

 

[LittleSmudge]

Greetings Kevin and welcome to Tek-tips.

Your last item is easy enough to deal with.

Open the database and go to the database window.

From the Tools menu select Analyse > Documenter

Click on the Tables tab and select the tables that you want from the list.

Then click on the Option... button

DEselect all three tick boxes in the first "Include for Table" section

Select the middle one of the three radio buttons "Names, Data types and sizes" in the second "Include for Fields" section

Select the first radio button "Nothing" in the final "Include or Indexes" section

Then Okay, and okay on the main dialog box.

THEN WAIT
because this process 'can' take an age.


MSAccess then produces an output as you want in the form of a report.

Click File menu, Expert and in the File of Type select "Text Files (.rtf)" and you can export the results into somehing that MSWord can read - if you need to.



'ope-that-'elps.



G LS
spsinkNOJUNK@yahoo.co.uk
Remove the NOJUNK to use.

 

[willir]

Kevin

Can you help us and add a little clarity to your problem?

What are you trying to track with this database, and what are your specific problems?

From your post, I gather...

You have a table for Infusion Pumps (Make, Model, serial number)

You have a Maintenance table for the pumps.

You have a mechanism or table for capturing demographics. (I understand you probably want to maintain animinity for some patients) But how do you caputre this data?

You have a Facility table (Facility Name, Address, Phone)

You dont want to track personal information for residences, but still need the demographic information. Perhaps here, a simple solution is to use a "patient" called "N/A" or something similar. This way, you can use the specific table to caculate the demographics with jeprodizing the confidentiality.

I am not sure, but I suspect

Pt is at a Facility

refers to patients. Can you use the personal information here?

This way, you can actually use one table to track facility patients and residences, and still maintain confidentiality.

On question you have not answered which is pretty important form my perspective is what is the relationship between patients and pumps? Is this...
- One-to-one (1:1). A patient only has one patient, and a pump only has one patient.
- One-to-many (1:M). A patient can have many pumps but a pump can only have one patient. OR A pump can have many patients but a patient can only have one pump.
- Many-to-many (M:M). A patient can have many pumps. A pump can have many patients.

I suspect you have a M:M since a pump can be removed from service (or the patient requires a different pump) so a patient can have more than one pump. And a pump can be used on another patient after it has been returned to service, or the current patient no longer needs the pump.

Assuming a M:M, you would have someing a long the lines of...

PatientTbl
PatientID - primary key
PatientLN - last name
PatientFN - first name
+ other info
+ demographics
Note: where anaminity is required, "N/A" or like can be used. BUT you need still need this table to properly track your pumps.

PumpTbl
PumpID - primary key
SerialNo - text
Make
Model
CurrentStatus

Why use a PumpID for the primary key instead of the serial number? I work with computers and such, and serial numbers is a royal pain - much easier to use an asset number, or the like.

PatientPumpTbl
PatientID - foreign key to patient
PumpID - foreign key to pump
StartDate
EndDate
+ other info when assigning a pump to a patient

Primary key = PatientID + PumpID + StartDate
(Assuming a pump is assigned for atleast one day, otherwise you would have to add StartTime)

In a sense, this table would track both your history, and current location of a pump.

Your maintenance table could something like...

MaintenanceTbl
MaintenanceID
PumpID
StartDate
EndDate
Activity

Note that you can also create a patient called "Maintenance" when a pump is assigned to maintenance.

If you use the Maintenance and N/A codes for patients, you will have to exclude their data from demographic calculations.

Richard