looking for help creating a relational database design for practice application in a surgical practice
Specifically what kind of help?
Whats your level of knowledge about databases and how to build software?
Whats your level of knowledge of FileMaker?
Find your local FileMaker Partner at
FileMaker Business Alliance and Business Technology | FileMaker
Choose a partner that have Certified Developers and have Platinum level för best help
How do I reply to you?
You can always go to my profile and write Message directly to me
"how do I reply to you"
Well, you just did....
But keep in mind that forums such s this are good at answering specific questions. You've asked two very broad general questions that leave us pretty much unable to say much in response. On the other hand, as you learn how to build a solution and encounter a more specific question, you can post it here and get a number of responses in short order.
We built a system many years ago in FileMaker version 6 for a doctor that specialized in skin surgery and wanted to keep referring doctors informed on the status of their patients. There were buttons for inserting the medical phrases and places to insert pictures to show the before, progress, and after. There was, of course, more to the system than that... The FileMaker platform has always been good at this type of application...even more so using the latest versions. There might be a pre-existing FileMaker solution that fits your needs, or is close to customized to fit......or you could search for a consultant here... http://developer.filemaker.com/search/ ...and pick someone to build exactly what you want. Hope that helps. Tony WhiteTel: 718-797-4175http://www.twdesigns.comhttp://FileMaker-Fanatics.com
Thanks Tony. I have an ERD that is roughly based on the invoices model starter solution. Tables are distinct for patients, procedure and operations with operations using a join table from procedures for “line items” as in invoice line item. This is because each operation may have more than one procedure. The challenge is that each operation is unique, but is built on the “platform” of the procedure. Not really sure how to do this? thanks jad
Dr. D, I have clients in medical and veterinary practices. (sort of the same, but not!)
Any Operation can have 'standard' procedures, but as you say can vary off as the need arises. The way I've handled this is to have a storage of 'standard' operations and 'standard' procedures, such that the operation is selected for the time it is performed (or prior to) and the standard procedures are then automatically set up for the day/time of the actual operation. Additional procedures can be added as needed and anything in the standard 'set' of procedures that is not actually performed, can be removed. That Operation, on that day/time then is unique, but based off the 'standard'. It's a time saver to not have to add the standard steps each time.
Thanks, I am doing that now but when there is more than one procedure in an operation (session), the relational db does not work
Yes. There is a procedures table and operations table (the pre defined values) then there is a join table to 'set up' the operation with the procedures that normally would be used. The join table is many to many. Now when a patient_operation is ordered, a selection is made from the lists in the operation table (the preset values). This triggers a script to add to a "line item" to patient_operation_procedures table from all those related (preset) procedures.
This is the line items for THAT patient for that Operation in that day/time.
The idea is to make a lookup set that can be used again and again and save time adding each patient_operation_procedure line. They will be ready but able to accept addition and changes.
Presets are basically copied when needed.
Sent from miPhone
Yes you get it, if the join table is many to many is there a different relationship that need to be built or a table that is “patient_operation_procedure”?
Beverly: "medical and veterinary practices. (sort of the same, but not!)". Round these parts? - oh, if only there were the same, or even vaguely similar...
The two-legged patients (people) don't have many "owners" and "billing responsible parties" like four-legged patients, do they?
Yes I'm talking Blue Grass breeds, son!
Otherwise similar in other ways with only the names of the entities being different.
THE SETUP (pre-set operations and procedures so that you can "pick" for a patient) relationships:
OPERATIONS::operationID - Operation_Procedures::operationID
Operation_Procedures::procedureID - PROCEDURES::procedureID
on the day of (or prior to):
THE PEOPLE THE OPERATION (on DAY/TIME) THE PROCEDURES
=========== ========================== =================
Patients::patientID - Patient_Operation::patientID
Patient_Operation::patient_operationID - Patient_Operatian_Procedures::patient_operationID
Patient_Operation::operationID (from setup)
The last table (P_O_P) can also have the patientID pushed forward, so that these "line items" end up with the patientID as well.
And the Patient_Operation has the operationID so that the related procedures can be pulled and saved as lineitems in P_O_P.
Whatever data is in the set up tables gets pulled forward when a new operation is setup for the patient. This is the "standard" operation and it's procedures. Then if there are additional procedures performed (or some not used), the this final table can be edited and the operation on that day/time for that patient is now unique.
(Actually, I was just meaning that I wish the care and treatment I receive at my Doctor's was even a vague approximation of the care my dog receives at the Vet...)
Retrieving data ...