Database proposal

Proposal

Abstract

Database systems provide organizations with a wide range of benefits including faster storage and retrieval of information, business intelligence and compliance with information security policies. Despite these numerous benefits, there are challenges that organizations face during the design phase. This proposal presents a database design proposal for a typical healthcare organization to handle events like storage of patient records, physicians, track finances, store medical examinations and treatment and ensure efficient booking of appointment by patients (Doukas, Pliakas, & Maglogiannis, 2010). The proposal will present a conceptual design that includes an ERD model.

Introduction

Manual maintenance of information is becoming difficult and obsolete as healthcare technology advances. In the healthcare industry, the storage of medical records is electronic hence requiring a healthcare organization to store information in a database and access them through a database management system. Currently, healthcare industry faces a challenge of slow information processing, loss of medical records, breaching of information security, massive consumption of papers due to manual storage and inaccuracy in analyzing data. This project aims at addressing these issues through a design of healthcare database using Entity-Relationship modeling. An Entity-Relationship model is a high-level design of the database that shows database entities, attributes, and the relationship between the entities (Earp & Bagui, 2012). Entities are real objects like patients, physicians, and hospitals while attributes are elements that give the objects its characteristics. Attributes include race, age, size, and address.

Solution

Despite the numerous benefits associated with database storage, there are challenges that organizations face during the design phase. However, this solution aims at developing a database design for a typical healthcare organization to handle events like storage of patient records, physicians, track finances, store medical examinations and treatment and ensure efficient booking of appointment by patients. The proposal will present a conceptual, logical and physical design through an Entity-Relationship model. The proposed database will also include a relational schema of the database to allow generation of results based on the desired queries developed in SQL (Al-Masree, 2015).

The project will be limited to design process of the database to yield deliverables like an ERD diagram, list of entities and attributes, a data dictionary, and description of the database design. The steps required to accomplish this objective will begin with the identification of entities and attributes, setting the relationships, presenting the entities in an ERD diagram and developing a data dictionary. A data dictionary will help map the project to a database design.

Resources

This project requires both human resources, financial capital, software components and hardware components. The human resource required include a graphic designer, database administrator, business requirements analysis, and a software engineer. Software requirements for the project include a relational database system like MS Access and SQL server and graphic design software like Adobe suite and Illustrator. Hardware components for the project are five Dell personal computers.

Budget

The table below shows a high-level budget estimation for the project:

Resource Item

Estimated Cost

Human Resource

$21, 000

Software Components

$1,250

Hardware components

$2,500

Total

$23,750

Users

Physicians: these are the database users with a strong knowledge in medical practice. However, these users have a limited experience in database management but can handle basic computer operations including running queries, reading from a database and creating useful information to the database system.

Patients: this includes a group of users with a mixed level of knowledge and competencies. They include computer experts and individuals with physical or technical disabilities. This group include the average users of the database but seeking medical advice from a healthcare facility. They also include family members of individuals seeking medical advice (Doukas et al., 2010).

Conclusion

Conclusively, the healthcare database design is highly recommended because it eliminates the vast expenses of using paper-based records. The design is also affordable because it does not include many stakeholders hence reduced disagreements during execution. Additionally, the design will help in improving the accuracy, security, and usability of the medical database. Upon successful implementation of the project, the project will result in improved return of investment for the hospital organization due to minimal operating costs and optimum delivery of services.

Reference

Al-Masree, H. K. (2015). Extracting Entity Relationship Diagram ( ERD ) From Relational Database Schema. International Journal of Database Theory and Application, 8(3), 15–26.

Doukas, C., Pliakas, T., & Maglogiannis, I. (2010). Mobile healthcare information management utilizing Cloud Computing and Android OS. In 2010 Annual International Conference of the IEEE Engineering in Medicine and Biology Society, EMBC’10 (pp. 1037–1040). https://doi.org/10.1109/IEMBS.2010.5628061

Earp, R., & Bagui, S. (2012). Database Design Using Entity-Relationship Diagrams. Library (Vol. 2012). https://doi.org/10.1201/9780203486054

Database Schema

The Database identified on module 1 will include the following five major entities and their relationships:

1. Physician: the physician entity has a one-to-many relationship with the treatment entity.

1. Patient: this entity has a one-to-many relationship with the appointment entity. Patient entity has a one-to-one relationship with a treatment entity.

1. Appointments: this entity has a one-to-many relationship with the patient entity. A patient will make an appointment (Bracci, Corradi, & Foschini, 2012).

1. Invoice: this entity has a one-to-many relationship with the treatment entity.

1. Treatment: this entity has a one-to-many relationship with the physician entity but a one-to-one relationship with an invoice entity.

Database Diagram

The diagram below shows the Entity Relationship of the database design:

erdplus-diagram

Database Schema

Data Dictionary

The table below shows the data dictionary for the Entity Relationship diagram designed:

Entity

Description

Attributes

Constraints

Physician

This entity will record all the personal and professional information about the physicians in the healthcare center.

Physician id, address, phone, age, degree, gender, shift

Primary key: Physician id

Patient

This entity will store information regarding the patients that can help in identifying them and offering best medical services.

Patient id, name, address, phone, age, gender

Primary key: Patient id

Appointments

An entity that will store the patients’ appointments and services they seek.

Appointment id, date, treatment id, physician id,

Primary key: appointment id,

Foreign key: physician id

Invoice

A financial entity that will store information about the billing for specific customers based on the treatment they receive.

Invoice id, patient id, amount due, invoice date, treatment id,

Primary key: invoice id,

Foreign key: patient id, treatment id

Treatment

This entity will record all the medical services that the entity offers to specific patients and the description of the services.

Treatment Id, patient Id, treatment, treatment cost, date,

Primary key: treatment id

Foreign key: patient id,

Areas of Difficulty

Identifying the database entities was challenging because it requires an interpretation of business requirements to identify the objects. At first, there were numerous entities identified that could lead to enormous database design. However, with closer consideration of the normal routine of a patient-physician healthcare visit, it was possible to determine the relevant entities and eliminate the irrelevant entities.

Developing the Entity Relationship diagram was also difficult because I was not familiar with the development tool. After implementing the first entity, adding attributes and inserting an appropriate relationship, it was easier to complete demonstrating and transfer them to this report.

Reference

Bracci, F., Corradi, A., & Foschini, L. (2012). Database security management for healthcare SaaS in the Amazon AWS Cloud. In Proceedings - IEEE Symposium on Computers and Communications (pp. 000812–000819). https://doi.org/10.1109/ISCC.2012.6249401

Database Schema

Shttps://documents.lucidchart.com/documents/1530cfbc-48bd-4198-9e27-ba190ca9997a/pages/0_0?a=2097&x=-72&y=-46&w=1332&h=753&store=1&accept=image%2F*&auth=LCA%20e5cb4c6bdad1f555b8d8f4e86a953316c32549ec-ts%3D1508976857

SQL Statement

Physician_Tbl

CREATE TABLE < PHYSICIAN_TBL> (

PhysicianID char (8) not null,

FirstName varchar (26) not null,

LastName varchar (66) not null,

Address varchar (28) not null,

TreatmentID varchar(12) not null,

PRIMARY KEY (PhysicianID)

):

Patient_Tbl

INSERT INTO PATIENT_TBL

(‘PatientID’, ‘FirstName’,’LastName’, ’Address’, ‘Phone’, ‘Dateofbirth’, ‘Gender’)

VALUE

(‘274659’, ‘Jack’, ‘Deal’, ‘543 Michael Street’, ‘Cleveland’, ‘OH’. ‘2206894563’, 1962-03-12’, ‘male’)

(‘274660’, ‘Rabbit’, ‘Jackie’, ‘1440 Delaware Avenue’, ‘Cleveland’, ‘OH’, ‘2207534628’, ‘1961-04-10’. ‘female’)

(‘275462’, ‘Howell’, ‘Nicole’, ‘6235 Jeff Street’, ‘Cleveland’, ‘OH’, ‘2206431274’, ‘1974-05-09’,’female’)

(‘284536’, ‘Galloway’, ‘Lisa’, ‘764 Avon Road’, ‘Cleveland’, ‘OH’, ‘2206427845’, ‘1942-03-07’, ‘female’)

Appointment_Tbl

INSERT INTO APPOINTMENT_TBL

(‘AppointmentID’, ‘Description’, ‘Patient_ID’, ‘Appointment_Date’, ‘Treatment_ID’)

VALUE

(‘6278’, ‘Skin Check’,’274660’, ‘2017-05-03’, ‘275469’)

(‘5432’, ‘Mole Check’,’275462’, ‘2017-08-04’, ‘345147’)

(‘2578’, ‘Ear Evaluation’, ‘274659’, ‘2017-08-04, ‘543127’)

(‘3254’, ‘Eye Screen’, ‘284536’, ‘2017-05-03’, ‘454532’)

Treatment_Tbl

CREATE TABLE (

Treatment_date charter (8) not null,

Physician_ID varchar (50) not null,

Appointment_ID varchar (50) not null,

Description varchar (500) not null

Invoice_Tbl

(‘InvoiceID’, ‘Amount_Due’, ‘Treatment_ID’, Appointment_ID)

VALUE

(‘2542’, ’2500’, ‘275469’, ‘6278’)

(‘2674’, ’2000’, ‘345147’, ‘5432’)

(‘2843’, ’3200’, ‘54127’, ‘2578’)

(‘2242’, ‘5000’, ‘454532’, ‘3254’)

Delete Data

Delete Data represent information that can be removed from the various records or rows from the tables without deleting the entire structure. For example, in the Patient Table I could remove and update patient last name if the patient was a female and her last name changed, also, the phone number or address could change on any patient record. The information that can be deleted and updated in the Appointment Table would be the appointment date if the patient or physician would have to change the appointment date, Treatment ID incase the physician noted additional treatment was needed for evaluation. The other table should update as the information in the two tables update (Larsen, 2010)

Delete Column Markers versus Table Delete

Using a marker-column for deletion, allows and individual to hide a column and restore it at a later time. For example, marking a column for delete permits the column to be invisible and inactive leaving it to be later retrieved. For example, if the user accidentally deletes a row and if the row were never marked, it would be eliminated. However, if it is marked as delete, the user can inform IT serves, and the administrator can recover it. Another example of actually deleting a file is if the wrong information is placed in a patient file it would be necessary to permanently delete the data so it would not be part of a permanent record. Forever removing data for security reasons or for personal information such as an old Power of Attorney that is no longer accurate should be deleted to prevent litigation (Martineau, 2003).

Reference

Grand Canyon University, (n.d.). Table creation. Lecture 4. Retrieved from https://lc- grad3.gcu.edu/learningPlatform/user/users.html?operation=loggedIn#/learningPlatform/loudBooks/loudbooks.html?viewPage=past&operation=innerPage¤tTopicname=Database Creation and Data Manipulation With SQL&topicMaterialId=dab24800-dbbf-44b9-be7c-d1fc39fa04d5&contentId=626ee921-16df-4af0-9761-3059794bd404&

Martineau, D. (2003). DB2 universal database v8 application development certification guide. (2nd ed.). Upper Saddle River, NJ: Pearson Education, Inc.

Larsen, G. (2010). SQL server column considerations and column placement. Database Journal. Retrieved from http://www.databasejournal.com/features/mssql/article.php/3866881/SQL-Server-Column-Considerations-and-Column-Placement.htm