• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2277
  • Last Modified:

ERD diagram needs verification

Hi, I'm trying to draw an Entity Relationship Diagram for a smal General Practitioner's clinic.

A patient can see many doctors
A doctor can see many patients
A patient/doctor has 1 or more appointments
An appointment issues an invoice
A doctor prescribes a prescription
A patient has one record
A record consists of many appointments

Please can you take a look to see if I am displaying this correctly in my diagram. I am a bit unsure about how to involve the Prescription entity Erd diagram
0
graziazi
Asked:
graziazi
2 Solutions
 
ValentinoVBI ConsultantCommented:
That "Patient Record" table seems a bit weird to me.  A Patient can have multiple Appointments, right?  I think the Patient Record table should be renamed to "Patient Appointment" because it's a many-to-many relationship table, just like "Patient Doctor".

If you need to retrieve a patient's record, you would just join the Patient, Patient Appointment and Appointment tables in your queries.  Unless I'm mistaken, there's no particular need to keep a separate "Patient Record" entity.  If you do need it, for instance when a doctor wants to keep track of general notes per patient, not linked to any appointment in particular, you could add a "Patient Record" table with just a one-on-one relation to Patient.  Possibly a link to Doctor (to keep track of who made the note) is needed, all depends on the requirements.

As for Prescription, all that seems to be missing is the link between Prescription and Appointment.  You've got the Appointment_ID already, so it seems logical to put a relationship between the two tables.  After all, a Prescription is created during an Appointment.  Possibly multiple prescriptions?

Hope this helps?
0
 
ste5anSenior DeveloperCommented:
hi,

Valentino is quite right.

Your [Patient Record] entity is redundant, because you already have it implicitly in you [Patient Doctor] entity. So you have an attribute [Notes] in [Patient Doctor] for general notes and you need an additional entity [Appointment Notes] - which is quite what you had in mind for [Patient Record] - for a one-to-many relationship between [Appointment] and notes per appointment, otherwise you would get anomalies per design.

The [Invoice] entity may be correct, but at least in Germany we have some billing by case, thus you should review your requirements here.

A prescription is always a result of an appointment - also speaking for Germany only, it's a legal requirement - thus the [Prescription]  entity needs only to be in a one-to-many relationship with [Appointment]. Otherwise it is in rrelation to [Patient Doctor], but not to [Doctor] unless you are giving out prescriptions without knowing your patient.
ERD.jpg
0

Featured Post

VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now