Jump to content
Claris Engage 2025 - March 25-26 Austin Texas ×
The Claris Museum: The Vault of FileMaker Antiquities at Claris Engage 2025! ×

This topic is 6582 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Posted (edited)

I am trying to set up my first FM database to help with medical recordkeeping. I have 6 tables:

CAMR- main page to find existing patients and add new patients on name, dob and date of exam.

HPI- Contains fields for history of present illness

PMSH- Fields for past medical and surgical history

ROS-Fields for what is called review of systems

Exam-Fields for exam

I/P- Fields for the doctor's impression and plan.

I have worked hard to create a layout for each of the 6 tables. However, I cannot figure out how to set up the necessary relationships so that as I progress from CAMR to HPI to PMSH to ROS to Exam to I/P that the appropriate patient's name, DOB and exam date carry through. Instead, when I go from one layout to the next, I see that data from another patient (that last one I worked on).

Any help would be greatly appreciated.

camr.zip

Edited by Guest
Posted

IMHO, your relationships are set up incorrectly. Try setting up, in your CAMR table, a PatientID which is a number field and check serial number in the auto enter area. Then set up a corresponding field in each of your other tables "fk_PatientID." Also add a serial number field for each of the other tables, e.g. HPI_ID, PMSH_ID, etc. This way, when you need to relate those tables the id's are already there. This way you do not have to worry about two patients with the same name like John Smith and John Smith Jr., which could be entered as John Smith. Anyway, you get the picture.

I would also suggest that you be more descriptive in your naming techniques. It will save you hours in the long run when the inevitable bug happens.

You do not need Name and DOB fields in any table but CAMR. When you have the tables properly related add those fields (Actually change them) and the related data will be there for you.

In you relationship graph set the relationships to CAMR::PatientID=Othertable::fk_PatientID and check "Allow creation of new record"

Set up your "Begin" Button as a script and have a dialog box that asks User if they want to create a new record or go to existing HPI record.

Once you get that set up the rest should start falling into place.

Also, before going any further I would suggest you read:

White Papers for Novices @

http://www.foundationdbs.com/Downloads/WhitePaperForFMPNovices.pdf

and

Anchor Buoy Techniques @

http://www.kevinfrank.com/demo-files-user-group.html

These will be a tremendous help to you.

HTH

Al

Posted

I would agree with aldipalo for the most part. There is one real problem however:

CAMR- main page to find existing patients and add new patients on name, dob and date of exam.

You cannot create a PatientID with an auto-enter serial ID in a table which has the date of exam; for the simple reason that there can be multiple exams for 1 patient (correct?).

So you either need an explicit Patients table, above CAMR. Or you need to move the Date of Exam further down the relational line, likely to the Exam table. I do not know whether the other tables are above Exam in the relational line, or whether they are independent of it. The latter seems likely. Each would have the PatientID and the creation date; so that would correlate them sufficiently, if you wanted to see when they happened (as long as each is begun on the same day).

I don't know if the cryptic names are a problem for you. It seems not, as everything is cryptic (fields also). Personally, if I have to choose between an abbreviaton (which I understand) and a long name, I will use the abbreviation. Because long names are actually harder for me to follow when troubleshooting complex routines. A good short name is the ideal, but one doesn't always have that choice. The abbreviation must be recognizable however, both now and a year from now.

Posted

The CAMR file is the patient table. (I do believe the table needs a little more info, but that's not for me to say.) The exam dates are in each of the examination files. The exam date field in the CAMR file is redundant and the way beavis has it set up does not carry over to the HPI or exam tables or any other table, but, I agree it should not be in the CAMR table at all.

I got the impression that beavis works for this medical firm. If that's the case and he/she should leave and another person tries to pick up and expand the DB or fix it they will have a hell of a time trying to figure out what all the abbreviations are. I don't know, but, I always figured that spelling out Company_Address as a field name is a lot easier to remember than C_Add or some other non descriptive field and table name. But, I guess if I were developing for many clients it is a good way to make sure they come back to me. The problem is at my age short term memory starts becoming a real problem. :) And, if I have to document what all my abbreviations are I might as well spell it out to begin with. But, as I stated my original post it is my humble opinion and if I have learned nothing else on this forum it's that there are lots of varying opinions. So, although I may not agree with you if it works for you than who's to say it's good or bad, IMHO.

Posted

I think the problem here goes deeper than just naming conventions. Reading the original description, it looks like the solution is structured to mimic some paper forms, instead of representing real entities (such as Patient, Exam, Ilness, etc.).

For example, "past medical and surgical history" is an attribute of Patient and does not warrant a separate table (unless it's for multiple related "history items").

Posted

You're probably right on that. After playing with the app you can clearly see that. You could have the following tables:

Patient

Current Exam

Patient History

These tables could handle all the necessary fields

and could easily show all through tabs on the Patient layout. It would be a lot cleaner and easier to deal with and just one layout per patient. You may then have a few report layouts to print out patient history to be sent to other physicians or the insurance companies, etc.

But, again that's not what beavis is asking for.

Posted

it looks like the solution is structured to mimic some paper forms, instead of representing real entities

How eloquently put, what usually is wrong when a questioner can't get the relations right!

:thumbup::thumbup::thumbup::thumbup::thumbup:

--sd

This topic is 6582 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.