Designing a database

Topic

New Reply

Dear All
I want to analyze the system and a small clinic you design tables for the patients … but the question has to sometimes be booked by appointment Telephone Will I do the design table reservations or do I put the main data table bookings for patients immediately with

Reply | Quote

Replies

I don’t see how the way an appointment is done would affect table design (other than maybe an attribute to represent the way appointment was done, if that is relevant), unless you want to treat appointments differently depending on the way they are done.

Reply | Quote

it’s ok thank you my dear teacher

Reply | Quote

You want one table for Patient info, and a separate table for appointments. A one-to-many relationship between Patients and appointments (each patient can have many appointments, but not the other way around). Within the appointment table, looks like you’ll need as many optional (Nullable) columns/attributes (such as TelephoneNumber) as necessary to facilitate an appointment. Won’t matter too much, though, because the Appointment record will always tie back to the Patient table via the foreign key. What you’ll really need is a flexible search input form to make appointments, and an equally good one to search/view appointments by using multiple criteria. Hope this helps.

Reply | Quote

thank you my dear teacher

Reply | Quote

The first thing you must do in designing a database is to identify the ENTITIES. You have patients, Dr.’s and appointments to start. Each patient has a one to many relationship with appointments and also a one to many with Dr’s. Each Dr. also has a one to many relationship with both appointments and patients. Probably all of your relationships for this type of system will be on to many.
I strongly suggest that you go through the examples that came with your system. The most relevant I have seen is designing a system for video rentals. You can apply most of what you learn there to you Clinic system. Pay attention to the part of the video rentals that deals with payments. You can use that for your patient insurance entity.
Having designed one of these myself, I can tell you to be prepared for it to grow fast, and requests for additional functionality will follow.

HTH
Peter

Reply | Quote

Please identify the database system you are trying to use, perhaps I can help you, or at least verify that you are setting things up correctly.
Peter

Reply | Quote

Before you do anything, make absolutely sure you understand the full requirements for the system. Appointment systems sound simple, right? Heck, maybe you just use a standard calendar app (google, outlook, whatever) and schedule appointments that way. I can almost bet you that there are constraints to the design you don’t yet know. for instance, are you booking a patient into a time slot? What about a specific exam room? What about a specific doctor/nurse/pa? What about special equipment required for the visit? What if you need to change time, room, or medical specialist? How does your system handle unusual cases?

I’d strongly recommend you sit down and work with several of the people who handle scheduling and see what kind of issues they need to handle, THEN figure out your design.

Good luck!

Reply | Quote