Hi All,
I am trying to help a friend create a database for a rehab hospital. When Patients are admitted they run a series of exams on them and when they are discharged they run the same exams. The same Patient could come back multiple times, so each time they come back ("Episode of Care") they would get an Admission exam and Discharge exam. Eventually, they would like to be able to run reports where they could compare discharge exam scores to the corresponding admission exam scores filtering on things like Patient age, gender, etc.
I have come up with a couple of different possibilities of how to set up the data and the relationships and have included them in the attached zip file. I just put in a sample data structure to try and convey the different options, the final database will have many more exams and data points.
In Db1, I have an EpisodesOfCare table that has an AdmissionExamID and DischargeExamID as foreign keys into an Exams table (one to one relationship). In Db2, I removed the AdmissionExamID and DischargeExamID from the EpisodesOfCare table and instead put an EpisodeOfCareID and ExamTypeID (Admission or Discharge) into the Exams table.
Is there another (better) way to organize this data? What is the preferred option and why? How does one decide between the different options available?
Note, I also broke up the exams table into subexams, because there is going to be a fair bit of data for each of these subexams (when they do the exam, they do break it down into different types of subexams). So even though there is a one to one relationship between the exams table and the subexams, it seemed like putting all that data into one main exams table would be too much and harder to keep track of in the future. Is that a reasonable way of breaking things up? In Db1 I had SubExamIDs in each subexam table, but in Db2 I realized I could just use the ExamID as the primary key in each subexam. Is that a better way to relate the tables? Any drawbacks to that?
Thank you for any advice and help you can provide.
I am trying to help a friend create a database for a rehab hospital. When Patients are admitted they run a series of exams on them and when they are discharged they run the same exams. The same Patient could come back multiple times, so each time they come back ("Episode of Care") they would get an Admission exam and Discharge exam. Eventually, they would like to be able to run reports where they could compare discharge exam scores to the corresponding admission exam scores filtering on things like Patient age, gender, etc.
I have come up with a couple of different possibilities of how to set up the data and the relationships and have included them in the attached zip file. I just put in a sample data structure to try and convey the different options, the final database will have many more exams and data points.
In Db1, I have an EpisodesOfCare table that has an AdmissionExamID and DischargeExamID as foreign keys into an Exams table (one to one relationship). In Db2, I removed the AdmissionExamID and DischargeExamID from the EpisodesOfCare table and instead put an EpisodeOfCareID and ExamTypeID (Admission or Discharge) into the Exams table.
Is there another (better) way to organize this data? What is the preferred option and why? How does one decide between the different options available?
Note, I also broke up the exams table into subexams, because there is going to be a fair bit of data for each of these subexams (when they do the exam, they do break it down into different types of subexams). So even though there is a one to one relationship between the exams table and the subexams, it seemed like putting all that data into one main exams table would be too much and harder to keep track of in the future. Is that a reasonable way of breaking things up? In Db1 I had SubExamIDs in each subexam table, but in Db2 I realized I could just use the ExamID as the primary key in each subexam. Is that a better way to relate the tables? Any drawbacks to that?
Thank you for any advice and help you can provide.
Attachments
Last edited: