Create an E-R diagram for a medical clinic, using the following business rules. Use Crow's Foot notation:

• A patient can make many appointments with one or more doctors in the clinic, and doctor can accept appointments with many patients. However, each appointment is made with only one doctor, and each appointment references a single patient.
• Emergency cases do not require an appointment. However, an emergency is entered into the appointment book as “unscheduled” for appointment management purposes.
• If kept, an appointment yields a visit with the doctor specified in the appointment. The visit yields a diagnosis and, when appropriate, treatment.
• Each visit updates the patient’s records to provide a medical history.
• Each patient visit creates a bill. Each patient visit is billed by one doctor, and each doctor can bill many patients.
• Each bill must be paid. However, a bill may be paid in many installments, and a payment may cover more than one bill.
• A patient can pay the bill directly, or the bill may be the basis for a claim submitted to an insurance company.
• If the bill is paid by an insurance company, the deductible is submitted to the patient for payment.

Does this look right or am i completely doing it wrong? Im new to databases

I had a look at this, it seems pretty good to me.

I was trying to see a way to simplify it, but I couldn't think of how, because a patient can have a visit without an appointment, although you say that they always do, and a patient can have an appointment without a visit (they forget it) The only thing that I can think of is that you might consider removing the circullar reference scheme, and making the appointment table the central table through which you imply relationship data. In other words remove the direct link between doctor and visit, and patient and visit. I can't see the need on the doctor, as the doctor would need an appointment to see you (block out time in his diary) and the patient needs an appointment to see a doctor, therefore I think they're probably not required, and simplify your model.

Payments also seems a little complicated in the area of payments and the many to many relationship there. I'd say that there could be many payments for one bill, but not many bills for one payment? That second idea complicates things - easier to have a one to many relationship unless there is a good reason to keep.

Hope that helps.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, learning, and sharing knowledge.