What tables have you defined for recording this data?
How are they related?
Do you have a date or time stamp field in at least one of these records?
In general terms, you are describing a summary report where you find all records dated with either today's date (daily summary) or a range of dates (Weekly summary), but the details in how you set this up depend on the structure of your tables and their relationships.
I should add that
1. I am using FMPro11 Adv
2. this database will be bound into a runtime solution and used by others, so the daily summary will be one that is used by a number of users.
Note that run time solutions cannot be shared over a network and it appears that this is something that you would want to do with this solution.
There are 2 tables that a number of layouts are associated with. The first has all the fields needed for all layouts. the second has only fields necessary to set up conditional vlue lists. These 2 tables are related only to help with the CVLs
All layouts have date and time fields. The main layout has a Date associated with a calculation for age when DOB is inputted. The other layouts- one has to input date using a dropdown cal and time.
The runtime solution is planned in the hope that this databse will be downloaded from a server/ website for different users, not shared across a network.
Hope the above makes sense
dowloaded as a standalone programme that is..
Seems like you would need more tables for this. At the very least, a table for patients, a table for doctors and one or more tables for logging the data you want to summarize for each patient.
In any case, you might check out this link on Summary Reports and see if it gives you some ideas in how to procede: Creating Filemaker Pro summary reports--Tutorial
Is it better to have more tables ?
It's a matter of having the right tables and relationships to efficiently do what you need to do with storing multiple copies of the same information in multiple locations.
You know much better than I what you want to do here. I'm just speculating that you will need several more related tables.
Each patient will have certain info such as Name, age and gender that should only be recorded once, but you will likely record other information about this patient several times--each time documenting a different stage in their treatment. THus, you would set up a patients table to record their basic information and a treatments table to document each stage of their treatment. You would then link the two tables by a patient ID field so that your database can correctly match up each treatment record to the correct patient.
I agree that I had too much in one layout! I am separating them into different tables. I suppose I will have to relate them using patient identifiers, ie name and ID no for each layout and match these common fields. Is that right?
I will not have copies of the same information. I will have copies of the databse used by different different people to enter different patients' details.
"but you will likely record other information about this patient several times--each time documenting a different stage in their treatment" - true. I should maybe have a different table for each stage (about 10 in all)? The fields will be the same as the parameters for assessing patients will be repeated. Should these tables also be related? Should I match each field to field or would matching the patient identifier, ie No and DOB be enough?
Be careful not to confuse Layouts with Tables. You can create any number of different layouts that all display data from the same table.
You might not have two much on one layout at all though it sounds like you had too much data in one record of your table. I'm picturing a portal to a related table on your patient layout for logging each detail of their on going treatment.
I suppose I will have to relate them using patient identifiers, ie name and ID no for each layout and match these common fields. Is that right?
Do match them by a PatientID number defined as an auto-entered serial number in the patient table. Don't relate them by patient name or an ID number supplied by an external system. Patient Names are not unique, and could, I suppose, even change during the course of a patient's treatment. (At least I've read about cases where people got married in a hospital ) Externally produced ID numbers could be used, but it's better not to use them to define a relationship. If the externally produced ID should get entered/imported incorrectly, trying to correct the error without loosing the connection to any related records is a hassle you can avoid by sticking with the auto-entered serial number. If you have such an externally produced ID, do deifne a field for it in the patient table so that users can search for a patient record by ID, just don't use it to link a patient record to related records in other tables.
Thanks again. I'm working on other tables to take some of the weight off my original one.
The Hospital ID number is important as is generally used with care. This databse is for reference and audit and will not alter treatment plans or such. Maybe I should also have an autogenerated serial number.
Another issue- I have a separate layout for each of 10 daily assessments, all linked to one table called 'Assessments'. This means that for each parameter (eg. blood pressure) for each day, I need to identify one field. Now this means making 10 x 10 fields to get each parameter for each of the 10 days. Also some patients maybe in hospital for 3 days and some for 15. I don't know how many layouts I'll need but any number may be insufficient.
I'm sure there's an easier way. Can you suggest??
I'm not saying to not have a field for your Hospital ID, but I do recommend that you make it a simple data field and rely on an auto-entered serial number to link your records to other tables. This is much safer and if the Hospital suddenly changes the format of their IDs, you can adjust to the change without having any issues with your database relatioships.
Make a single assessment record with date and time fields to record when the assessment was made. (you can also use a single timestamp field to record date and time in one field if you want.) If possible, add a field for identifying the type of assessment (ie. "blood pressure") and then add the data fields needed for recording your assessment data.
You can display these records on a patient layout and record any number and type of assessments.
Your 10 x 10 blood pressure fields then becomes 100 individual records. And the same table can still record other assessments--such as blood sugar, white count, etc.
Frustrating! I have separated the fields into different tables. I used common fields like patient identifiers- forename, surname, serial numbers and hospital ID number for each table and related the tables (all 4 tables with each other) using these common idetifiers. I then made layouts using these separate tables and linked the different layouts using buttons. Now when I make a new record in browse mode, fill in details, and go to the next lyout to input the next lot of data for that same patient, the related data like hospital number, surname and don't automatically appear on that layout as I expect they should. When all the fields were in one table, this was the case..
I used common fields like patient identifiers- forename, surname, serial numbers and hospital ID number for each table.
Please delete those common fields from all but the Patient table. You don't need them.
Simply add these fields from the patient field to your detail layouts where needed. As long as you have a valid PatientID serial number in your detail records, the relationship between it and the Patient table will match to the correct record and you'll be able to see patient name, HospitalID etc from that table.
Being able to store this data in only one record of only one table is one of the key reasons for setting up your database in this fashion.