H o s p i t a l d a t a b a s e m a n a g e m e n t

International University FINAL REPORT HOSPITAL DATA MANAGEMENT Course: Principles of Database Management Lecturer: Nguyễn Thị Thúy Loan Team: Semester 02, 2021 – 2022 (Spring 2022) 2|Hospital Database Management CONTENTS Project’s Member Topic: Descriptions and Requirements 3 Analyzing core data-classes 4 Core data classes: Attributes Relationship Rule ER Diagram & Relational Model Prototyping Implementation 8 References - - - 3|Hospital Database Management Project’s Member Table 1: The name and contact information of all project members No Full Name ID Contact Occupation Nguyễn Quỳnh Mai Thanh Nguyễn Phúc Khang ITITIU20309 ITITIU20009 0839085354 0913324868 Leader Member Nguyễn Gia Bảo Phạm Hoàng Minh Nguyễn Huy Minh ITITIU18016 ITITIU19031 ITITIU19158 0378044394 0377359021 0896494284 Member Member Member Table 2: The contribution of all project members in the HDM-Dev Team No Full Name Nguyễn Quỳnh Mai Thanh Nguyễn Phúc Khang Nguyễn Gia Bảo Contribution - Phạm Hoàng Minh Nguyễn Huy Minh Writing the documents at all three times submission (80%) - Design the logic between data/classes - Lead other members to follow strictly the schedule Topic: Descriptions and Requirements TOPIC 05: Hospital Data Management Hospitals have unique data requirements Not only they have to maintain the medical records of their patients, but they also have to manage their staff and its multiple departments You can solve the data-related problems of hospitals by creating a DBMS solution First, you should assign unique IDs to the patients and store the relevant information under the same You’ll have to add the patient’s name, personal details, contact number, disease name, and the treatment the patient is going through You’ll also have to mention under which hospital department the patient is (such as cardiac, gastro, etc.) After that, you should add information about the hospital’s doctors A doctor can treat multiple patients, and he/she would have a unique ID as well Doctors would also be classified into different departments Patients would get admitted into rooms, so you’ll need to add that information to your database too Apart from that, there would be distinct rooms (ICUs and Operation Theaters) in the hospital Then, you’d have to add the information of ward boys and nurses working in the hospital and assigned to different rooms 4|Hospital Database Management You can start with a small hospital and expand it as you move on Make sure that the data is easily understandable and accessible Analyzing core data-classes According to the question topic, three main data/classes could be found in the database, which is Patient, Medico (Doctor/Nurse), and Treatment (Although the real-world hospital may have different under-the-neath architecture) In the three first paragraphs, there is the involvement of an object named Department, but according to the topic rule, it was a controlled Enum class The information of Sickness is also recorded and it is strongly related to the Treatment and Patient as, during entry, the patient can suffer multiple diseases at the same time Also, the type of Treatment is recorded by the notion of hospital department “(such as cardiac, gastro, etc.)” In the second last paragraph, there is the involvement of Room which have two different functionalities: PatientRoom and MedicoRoom In the PatientRoom class, a room can have multiple beds, which handled multiple patients at a time In the MedicoRoom class, a room is usually controlled by either one or two medicos at the same time What the topic did not cover is its extensively detailed information hidden per each Treatment, but since the relationship was similarly covered by the relationship between Patient and Room (where we distributed an amount to be in use in Treatment), this was ignored (for example, the availability of medicines used) There are also some rare (hidden) cases where the department controls the room (which can be individual or shared possession) but since this scenario is not mentioned, we discarded this relationship Core data classes: Attributes According to the topic requirement and Section 3, we would have two types of relations which are the data (using the ID as the primary key) and the Enum (using the code as the primary key) In this Section, we would only describe the following objects However, we only cover our data to have a fully compatible view rather than displaying every possible attribute - Patient (Data): First name, Last name, Sex (Gender), Phone number, Address, Email, SSN (Citizen Code), etc - Medico (Data): First name, Last name, Sex (Gender), Phone number, Address, Email, SSN (Citizen Code), etc + Department Code - Department (Enum): Department Name, etc - Sickness (Enum): Sickness Name, etc - Treatment (Data): Patient.ID, Creation-Date, Creation-Time, Description 5|Hospital Database Management - Room (Data): (ID is the Room-Code), Room Description, Room Type (See this attribute in Section 5) Relationship Rule We extrapolate these rules by the following relationship: - Patient-Treatment: This is a combination relationship 1-1 and 1-N as one patient can experience many treatments in the same hospital, but only one patient is recorded in the Treatment Thus, the Patient.ID is stored as to be the reference key in the Treatment table - Medico-Treatment: This is a pure relationship 1-N where a medico can work on many Treatments in this life work Thus, we would need a table that maps these two together (mapping the key only) - Sickness-Treatment: Similar to the “Medico-Treatment” relationship, a patient can have and be detected with many sicknesses on one Treatment only Thus, we would need a table that maps these two together (mapping the key only) - Department-Medico: This is a combination relationship 1-1 and 1-N as a medico can only belong in one department only while the department has to take care of many medicos per time Thus, the Department.Code is stored as to be the reference key in the Medico table - Treatment-Functional Room: (Functional Room is the room where the medico worked, not the place for the patient to rest) This is, in fact, strongly dependent on the hospital’s regulation However, to keep this simple, this is similar to the “Patient-Treatment” relationship as one functional room can implement many Treatments while the Treatment should be done and ‘closed’ in one room only Thus, the FRoom.Code is stored as to be the reference key in the Treatment table - Patient-Room (Patient Room): This is also a combination relationship 1-1 and 1-N as one patient can take place in one room only and the room can have many beds for the patient But since we should not capture this information inside the Patient, not only because we focused on the highest level of database normalization but it significantly wastes memory and reduces performance for most other patients (even the for the null) Moreover, storing the Room.Code inside the Patient does not satisfy the ideology in this table as well as to keep the compatibility with the MedicoRoom (See below_ Thus, a new table named PatientRoom was made to link the information between Rooms.Code and Patient.ID (In some scenarios, some imposing rules allocate patients of the same gender, but it is heavily dependent on the business regulation; thus, this issue is skipped.) - Medico-Room (MedicoRoom): This is a combination relationship 1-1 and 1-N as a medico can control many rooms at the same time, while the room is maintained by one (responsible) medico only There are situations where there is more than one medico working on a particular due to the hospital’s regulation, but these medicos are just optional Also, there are some rooms in the 6|Hospital Database Management hospital that is not controlled by the medicos but by the other staff in different departments such as the Finance However, since you can set these “staffs” into a different table for better data management, a new table named MedicoRoom was made to link the information between Room.Code and Medico.ID ER Diagram & Relational Model In this model, we only visualize the important attributes and left non-important attributes for a different purpose In the first relationship between Patient, Room, and Medico, there are two possible designs for this model, especially on the “F.Room” attribute stored in the Room class where it denoted whether the room can be used as a resting place for patients Currently, while we can set it on the DB management tool, it is relatively hard to visualize on the diagram Figure ER Diagram for the Patient-Room-Medico relationship Figure Relational Model for the Patient-Room-Medico relationship 7|Hospital Database Management The second relationship was described between Patient, Treatment, and Medico as the core pillar Based on what we discussed in Section 4, this is how the data is distributed Figure ER Diagram for the Patient-Treatment-Medico relationship Figure Relational Model for the Patient-Treatment-Medico relationship 8|Hospital Database Management Prototyping Implementation Tables and Relationships: As can be seen in Figures 1, 2, 3, and 4, our deployed model can be understanded by the Figure 5, which is a collection of CREATE query to call out the table The data of the table can be found under the folder named “data” There are some minor changes compared to the previous (theoretical) model above First one is the introduction of Job (an Enum class), which supported the primary role of the Medico Although up till now, we are only aware of two main responsibilities (Doctor and Nurse), but there are many particular roles for a Medico to handle However, the main relationship is relatively similar of what we have discussed right now; moreover, we did not add many business logic here so the use of its internal meaning can be seen as redundancy (and left there for future development) The second one is related to the enrichment of data, especially on the Medico and Patient As preiously discussed, we cannot embed every attributes or fields in the visualized model above because it does not support any significant relationship towards different data fields Figure 5: The SQL query to generate the tables, including the primary key and the reference key, and several constraint to enforce better rule set 9|Hospital Database Management 10 | H o s p i t a l D a t a b a s e M a n a g e m e n t Setting (How to run our program) To let our program runnable, we have to set up our database and then reconfig in the Java code (We are so sorry that our program did not fully cover the automatic setting here due to the unproficient in Java programming, especially the UI) Download and unzip the source code https://github.com/mtnguyenquynh/PDM_HospitalDataManagement at here: 11 | H o s p i t a l D a t a b a s e M a n a g e m e n t Open the MS-SQL and load the database which can be found in the project: “/data/HospitalData.bak(.lnk)” which directly moved to “/src/UI/database/HospitalData.bak” If you successfully load the backup of the data, move to step Otherwise, create the database named “HospitalData” and open two “.sql” files that named “Create Tables” and “Load Data” and run the “Create Tables” first In the second SQL, you have to re-initialize all folder For example in the table DepartmentEnum are called from this file “D:\Minh\Books\Academic Curriculum\Study Year 2021 - 2022\Principles of Database Management\Project\Code\Data\new\My_Data\DepartmentEnum.csv” to “/data/DepartmentEnum.csv” Replace all folder name and run the SQL file Then you have to setup a new user (for example: myproject) with the password (for example: sa) in the MS-SQL, and activate the account (See the laboratory 05, 06 for more information) Open the “/src/UI/HospitalQueryApp.java” and re-initalize the database by finding the variable “String connectionUrl = …” Choose the port (i.e 1433 or 1434) with the databaseName (above), the username and password Then compile and run the project (The project is constructed under the VS Code) Sample Result Figure 6: Load first ten treatment records 12 | H o s p i t a l D a t a b a s e M a n a g e m e n t Figure 7: Load first ten rooms who take responsibility of any given room Figure 8: Load all the medico’s name who take responsibility of any given room 13 | H o s p i t a l D a t a b a s e M a n a g e m e n t References Entity-relationship model - Wikipedia En.wikipedia.org (2022) Retrieved March 2022, from https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model ER diagram with some specific conditions (n.d.) Stack Overflow https://stackoverflow.com/questions/35305809/er-diagram-with-some-specific-conditions The citation rule is APA (7th Edition) using the tools on https://citefast.com - END - ... the Patient-Treatment-Medico relationship Figure Relational Model for the Patient-Treatment-Medico relationship 8|Hospital Database Management Prototyping Implementation Tables and Relationships:... hard to visualize on the diagram Figure ER Diagram for the Patient-Room-Medico relationship Figure Relational Model for the Patient-Room-Medico relationship 7|Hospital Database Management The second... in this table as well as to keep the compatibility with the MedicoRoom (See below_ Thus, a new table named PatientRoom was made to link the information between Rooms.Code and Patient.ID (In some