Hospital Management System Design
VerifiedAdded on 2023/03/31
|20
|3117
|271
AI Summary
This report discusses the design of a hospital management system, including critical use cases, context level diagram, level 0 DFD, ERD, CRUD diagram, prototype interface, architecture diagram, and details of individual group members.
Contribute Materials
Your contribution can guide someone’s learning journey. Share your
documents today.
Running head: HOSPITAL MANAGEMENT SYSTEM DESIGN
Hospital Management System Design
Name of the Student
Name of the University
Author’s note:
Hospital Management System Design
Name of the Student
Name of the University
Author’s note:
Secure Best Marks with AI Grader
Need help grading? Try our AI Grader for instant feedback on your assignments.
1HOSPITAL MANAGEMENT SYSTEM DESIGN
Table of Contents
Introduction:....................................................................................................................................2
Critical Use Cases:...........................................................................................................................2
Context Level Diagram:..................................................................................................................3
Level 0 DFD:...................................................................................................................................5
Draw ERD:......................................................................................................................................8
CRUD Diagram:............................................................................................................................10
Prototype and Architecture Diagram:............................................................................................11
Details of Individual Group Members:..........................................................................................15
Conclusion:....................................................................................................................................15
Bibliography:.................................................................................................................................17
Table of Contents
Introduction:....................................................................................................................................2
Critical Use Cases:...........................................................................................................................2
Context Level Diagram:..................................................................................................................3
Level 0 DFD:...................................................................................................................................5
Draw ERD:......................................................................................................................................8
CRUD Diagram:............................................................................................................................10
Prototype and Architecture Diagram:............................................................................................11
Details of Individual Group Members:..........................................................................................15
Conclusion:....................................................................................................................................15
Bibliography:.................................................................................................................................17
2HOSPITAL MANAGEMENT SYSTEM DESIGN
Introduction:
The information system is defined as the application which assists in handling and
evaluating data. The information system has database that is used for recording data. The system
can retrieve data from the database for completing various user requests or process it for
generating information. The information system is developed with the purpose of converting raw
data into essential information and knowledge that can assist the user and management take
various decisions. Different types of information system are available such as executive
information system, management information system, decision support system and transaction
processing system. The hospital management system is a management information system that is
deployed in a hospital’s environment. Information systems depends on the users and various
input devices to get data from real world. The systems also integrate user management which
serves as the basis of authentication and authorization.
The report consists of the system analysis and design of driver assistance application.
This report will represent the critical use case of the application. These critical use cases are the
core interaction of the application. The context level diagram will provide the basic foundation
of the system. The idea behind the context level diagram will be elaborated in the level 0
diagram. The ERD will show the database structure. A prototype diagram will be implemented to
show the user interface of application which the patient will be using to book appointment. The
architecture of the application will provide a high level representation of the system. The
environment of deployment will also be shared through the architecture.
Critical Use Cases:
The critical use cases of the Hospital Management System are as following.
Introduction:
The information system is defined as the application which assists in handling and
evaluating data. The information system has database that is used for recording data. The system
can retrieve data from the database for completing various user requests or process it for
generating information. The information system is developed with the purpose of converting raw
data into essential information and knowledge that can assist the user and management take
various decisions. Different types of information system are available such as executive
information system, management information system, decision support system and transaction
processing system. The hospital management system is a management information system that is
deployed in a hospital’s environment. Information systems depends on the users and various
input devices to get data from real world. The systems also integrate user management which
serves as the basis of authentication and authorization.
The report consists of the system analysis and design of driver assistance application.
This report will represent the critical use case of the application. These critical use cases are the
core interaction of the application. The context level diagram will provide the basic foundation
of the system. The idea behind the context level diagram will be elaborated in the level 0
diagram. The ERD will show the database structure. A prototype diagram will be implemented to
show the user interface of application which the patient will be using to book appointment. The
architecture of the application will provide a high level representation of the system. The
environment of deployment will also be shared through the architecture.
Critical Use Cases:
The critical use cases of the Hospital Management System are as following.
3HOSPITAL MANAGEMENT SYSTEM DESIGN
i. Registration/Login: Each user will be registered into the system. The system will
not allow any non-authenticated user. The registration will have two categories
such as staff and customer registration. The customer will use the application to
submit the registration form. The same email and password used in the
registration will be used for login.
ii. Schedule Appointment: The patient can schedule appointment. The patient will
use the system to submit the appointment form. The patient will provide email,
date of appointment along with time, preferred doctor and details of illness. The
system will store the request and update the information in system.
iii. Payment: The patient will make payment for the treatment they got from the
hospital. Based on the illness, the system will categorize the appointment. Based
on specialization of doctor, the system will apply charge to the appointment. The
patient can pay the charge through digital wallet or card.
iv. Appointment Briefing: After the appointment is over, the doctor will update the
actual illness of patient, given medicines and other treatment related information.
To do this, the doctor will get an interface terminal.
Context Level Diagram:
Data flow diagram (DFD) represents the flow of data or process in an information
system. This is a simplified graphical representation of the system that provides a detailed
structure of the system and the data flows from the entities and the processes used. The data flow
diagram does not contain any loops or decision rules. There are basic symbols that are used to
represent the data flows, processes and the sources. Basic symbol to represent a process is a
i. Registration/Login: Each user will be registered into the system. The system will
not allow any non-authenticated user. The registration will have two categories
such as staff and customer registration. The customer will use the application to
submit the registration form. The same email and password used in the
registration will be used for login.
ii. Schedule Appointment: The patient can schedule appointment. The patient will
use the system to submit the appointment form. The patient will provide email,
date of appointment along with time, preferred doctor and details of illness. The
system will store the request and update the information in system.
iii. Payment: The patient will make payment for the treatment they got from the
hospital. Based on the illness, the system will categorize the appointment. Based
on specialization of doctor, the system will apply charge to the appointment. The
patient can pay the charge through digital wallet or card.
iv. Appointment Briefing: After the appointment is over, the doctor will update the
actual illness of patient, given medicines and other treatment related information.
To do this, the doctor will get an interface terminal.
Context Level Diagram:
Data flow diagram (DFD) represents the flow of data or process in an information
system. This is a simplified graphical representation of the system that provides a detailed
structure of the system and the data flows from the entities and the processes used. The data flow
diagram does not contain any loops or decision rules. There are basic symbols that are used to
represent the data flows, processes and the sources. Basic symbol to represent a process is a
Paraphrase This Document
Need a fresh take? Get an instant paraphrase of this document with our AI Paraphraser
4HOSPITAL MANAGEMENT SYSTEM DESIGN
circle and to indicate a source is a rectangular box and the data flows are represented using arrow
symbols.
Figure 1: Context Level Diagram
(Source: Created by Author)
Context diagram is the most simplified Data flow diagram also known as level 0. This
type of DFD’s contains only one process giving a generalized view of the entire system with
relation to the external entities. The whole system is represented as a single process. The level 0
circle and to indicate a source is a rectangular box and the data flows are represented using arrow
symbols.
Figure 1: Context Level Diagram
(Source: Created by Author)
Context diagram is the most simplified Data flow diagram also known as level 0. This
type of DFD’s contains only one process giving a generalized view of the entire system with
relation to the external entities. The whole system is represented as a single process. The level 0
5HOSPITAL MANAGEMENT SYSTEM DESIGN
diagram shows the different sub-systems or the different processes which will again deal with a
single or more data flows from some external agent, in result will represent the complete system.
The level 0 Data flow diagram of hospital information system (HIS) used in this report
represents the whole system with a single process. The main process is represented as the circle
in the middle surrounded by four sources or sinks. The four sources shown in the diagram are
patient, receptionist, administrator and the doctor. The data flows are represented using the
arrows emerging and pointing to the sources or at the central process. Reports of the patient,
doctor and health are stored in the central system so that the administration can retrieve the files
when required. The health condition reports of the patients are forwarded to the system by the
doctors and they can access those files when needed. The main system stores the availability of
the doctor database which is used by the receptionist to distribute the information amongst the
patients. The patients can drop a request for appointment with some particular doctor and the
receptionist can check the availability of the doctor and inform the patient. The health reports
stored in the main system can be retrieved by the patients as per their convenience.
Level 0 DFD:
The level 1 DFD is a more detailed structure diagram of the information system then the
level 0. In this level, the main sources or systems are divided into sub-systems or sub-processes
which are explained in more details.
diagram shows the different sub-systems or the different processes which will again deal with a
single or more data flows from some external agent, in result will represent the complete system.
The level 0 Data flow diagram of hospital information system (HIS) used in this report
represents the whole system with a single process. The main process is represented as the circle
in the middle surrounded by four sources or sinks. The four sources shown in the diagram are
patient, receptionist, administrator and the doctor. The data flows are represented using the
arrows emerging and pointing to the sources or at the central process. Reports of the patient,
doctor and health are stored in the central system so that the administration can retrieve the files
when required. The health condition reports of the patients are forwarded to the system by the
doctors and they can access those files when needed. The main system stores the availability of
the doctor database which is used by the receptionist to distribute the information amongst the
patients. The patients can drop a request for appointment with some particular doctor and the
receptionist can check the availability of the doctor and inform the patient. The health reports
stored in the main system can be retrieved by the patients as per their convenience.
Level 0 DFD:
The level 1 DFD is a more detailed structure diagram of the information system then the
level 0. In this level, the main sources or systems are divided into sub-systems or sub-processes
which are explained in more details.
6HOSPITAL MANAGEMENT SYSTEM DESIGN
Figure 2: Level 0 DFD Diagram
(Source: Created by Author)
The level 1 diagram of the Hospital information system contains external entities which
are patient and doctor which are represented by a single rectangular box. The external entities are
outside systems that operate within the system. These might be organizations or persons and in
this case these external entities are mainly person as a patient and a doctor could not be an
organization. These entities are drawn at the edges. The processes are represented using rounded
corner shaped boxes with the labelling of 1D, 2D and 3D respectively. The three main processes
used in this report are authenticate, book appointment, and treatment. A process is usually a step
when the data in the system are altered and some output is generated. The process authenticate
Figure 2: Level 0 DFD Diagram
(Source: Created by Author)
The level 1 diagram of the Hospital information system contains external entities which
are patient and doctor which are represented by a single rectangular box. The external entities are
outside systems that operate within the system. These might be organizations or persons and in
this case these external entities are mainly person as a patient and a doctor could not be an
organization. These entities are drawn at the edges. The processes are represented using rounded
corner shaped boxes with the labelling of 1D, 2D and 3D respectively. The three main processes
used in this report are authenticate, book appointment, and treatment. A process is usually a step
when the data in the system are altered and some output is generated. The process authenticate
Secure Best Marks with AI Grader
Need help grading? Try our AI Grader for instant feedback on your assignments.
7HOSPITAL MANAGEMENT SYSTEM DESIGN
helps a patient to authenticate their identity and log in to the hospital system by providing their
personal details like email and password. Every patient is assigned with a unique patient ID also
known as UHID (Unique health identifier) to log in to the system and check their appointment
details. Book appointment is a process to book an appointment with a doctor.
There are three data stores used in this diagram which are patient, appointment, doctor
and health. The data stores are represented using a divided rectangular box. These data stores
represent the files or information about the entities which are patient, appointment, doctor and
health stored in the hospital information system. While booking an appointment the repositories
of patient, appointment and doctor are used. The lines represents the data flows. The treatment
process uses the appointment database and health repositories. The doctor retrieves the patient
ID, Doctor ID and the appointment status using the treatment process and this data is retrieved
from the appointment directories and health data stores. After the process of authentication an
appointment request is forwarded to the book appointment process to book an appointment.
helps a patient to authenticate their identity and log in to the hospital system by providing their
personal details like email and password. Every patient is assigned with a unique patient ID also
known as UHID (Unique health identifier) to log in to the system and check their appointment
details. Book appointment is a process to book an appointment with a doctor.
There are three data stores used in this diagram which are patient, appointment, doctor
and health. The data stores are represented using a divided rectangular box. These data stores
represent the files or information about the entities which are patient, appointment, doctor and
health stored in the hospital information system. While booking an appointment the repositories
of patient, appointment and doctor are used. The lines represents the data flows. The treatment
process uses the appointment database and health repositories. The doctor retrieves the patient
ID, Doctor ID and the appointment status using the treatment process and this data is retrieved
from the appointment directories and health data stores. After the process of authentication an
appointment request is forwarded to the book appointment process to book an appointment.
8HOSPITAL MANAGEMENT SYSTEM DESIGN
Draw ERD:
Figure 3: Entity Relationship Diagram
(Source: Created by Author)
An integral part of any information system is the database. Entity relationship diagram is
a way to represent the database in a simplified way. It is commonly known as ERD or ER
Diagram. The ER diagram represents the major entities and the inter-relationships within these
entities. An entity is defined as a thing which is present in a system, a person or an object in an
ERD can be some examples of an entity. The entities are represented using a rectangular box or a
rounded rectangular box with the name or the entity at the top and their attributes listed below.
An attribute is defined as the properties or the characteristics of the entity. Usually an attribute is
represented using a name and the type of the data it holds. Primary Key also known as PK, is a
unique key that identifies a record.
Draw ERD:
Figure 3: Entity Relationship Diagram
(Source: Created by Author)
An integral part of any information system is the database. Entity relationship diagram is
a way to represent the database in a simplified way. It is commonly known as ERD or ER
Diagram. The ER diagram represents the major entities and the inter-relationships within these
entities. An entity is defined as a thing which is present in a system, a person or an object in an
ERD can be some examples of an entity. The entities are represented using a rectangular box or a
rounded rectangular box with the name or the entity at the top and their attributes listed below.
An attribute is defined as the properties or the characteristics of the entity. Usually an attribute is
represented using a name and the type of the data it holds. Primary Key also known as PK, is a
unique key that identifies a record.
9HOSPITAL MANAGEMENT SYSTEM DESIGN
There is only one primary key for each entry in the database. Foreign key also known as
FK, is basically used to for referencing a primary key. Foreign keys are not unique like primary
key and there can be multiple records that share the same foreign key. Relationship shows the
relationship between two entities and these relationships are shown using a connector.
Cardinality shows the occurrence of one entity which might be associated with other entities.
There are three type of cardinal relationships namely one-to-one, one-to-many and many-to-
many. Cardinality is represented by a crow’s foot symbol. One-to-one relationship is usually
used to split an entity into two parts to provide more information about that entity. One-to-many
cardinality is used to show a link between two entities.
The Entity Relationship Diagram of the hospital management system consists of five
entities which are labelled as Patient, Appointment, Qualification, Doctor and Payment. The
patient entity have the attributes of patientID, fullName, email, address, contact, and
emergencyContact, where the patientID is the primary key as every patient will be having their
own unique identification key. The patient entity will store the full name of the patient, their
unique ID, the email address and two contact numbers, one for emergency purpose. The patient
entity is associated with the appointment entity with one to many cardinality relationship because
the appointment entity also contains the patient Id. The attributes of appointment are
appointmentID, patientID, doctorID, appointmentDate, appointmentTime, status and briefings.
The properties appointmentID serves as the primary key for this entity, and the patientID and
doctorID serves as the foreign key. The doctor entity is also related to the appointment entity
with one-to-many cardinality relationship. As the doctorID is present in both the entities. The
properties of doctor entity are doctorID, fullName which contains the full name of the doctor,
email which will store the email ids of the doctor, address will contain the present address of the
There is only one primary key for each entry in the database. Foreign key also known as
FK, is basically used to for referencing a primary key. Foreign keys are not unique like primary
key and there can be multiple records that share the same foreign key. Relationship shows the
relationship between two entities and these relationships are shown using a connector.
Cardinality shows the occurrence of one entity which might be associated with other entities.
There are three type of cardinal relationships namely one-to-one, one-to-many and many-to-
many. Cardinality is represented by a crow’s foot symbol. One-to-one relationship is usually
used to split an entity into two parts to provide more information about that entity. One-to-many
cardinality is used to show a link between two entities.
The Entity Relationship Diagram of the hospital management system consists of five
entities which are labelled as Patient, Appointment, Qualification, Doctor and Payment. The
patient entity have the attributes of patientID, fullName, email, address, contact, and
emergencyContact, where the patientID is the primary key as every patient will be having their
own unique identification key. The patient entity will store the full name of the patient, their
unique ID, the email address and two contact numbers, one for emergency purpose. The patient
entity is associated with the appointment entity with one to many cardinality relationship because
the appointment entity also contains the patient Id. The attributes of appointment are
appointmentID, patientID, doctorID, appointmentDate, appointmentTime, status and briefings.
The properties appointmentID serves as the primary key for this entity, and the patientID and
doctorID serves as the foreign key. The doctor entity is also related to the appointment entity
with one-to-many cardinality relationship. As the doctorID is present in both the entities. The
properties of doctor entity are doctorID, fullName which contains the full name of the doctor,
email which will store the email ids of the doctor, address will contain the present address of the
Paraphrase This Document
Need a fresh take? Get an instant paraphrase of this document with our AI Paraphraser
10HOSPITAL MANAGEMENT SYSTEM DESIGN
doctor, contact contains the contact number of the doctor and the salary and specialization
attributes will contain the salary and the specialization of the doctor respectively. The
qualification entity is again related to the doctor entity with one-to-many cardinal relation. The
qualification entity is used to store the qualification details of the doctor.
The main components of the qualification entity are doctorID which acts as the primary
key and the foreign key as well in this case, name which stores the name of the doctor,
University attribute stores the name of the university the doctor graduated from, pasingDate
stores the year of graduation of the doctor, duration contain the time for which the doctor was in
University and lastly the aggregate contains the aggregate score of the doctor. In the payment
entity the appointmentID serves both for the primary key and the foreign key and is related to the
appointment entity with one-to-many cardinal relation. The payment entity contains the
components paymentDate, methodOfPayment, totalAmount and status. The payment entity will
basically contain the details of the payment made by the patient. It will contain the details of the
date the payment was made, mode of the payment, the total amount paid and the payment status.
CRUD Diagram:
Patient Appointment Doctor Qualification Payment
Register C C C
Login R R
Appointmen
t Schedule
R C R R
Appointmen
t briefing
R RU R
doctor, contact contains the contact number of the doctor and the salary and specialization
attributes will contain the salary and the specialization of the doctor respectively. The
qualification entity is again related to the doctor entity with one-to-many cardinal relation. The
qualification entity is used to store the qualification details of the doctor.
The main components of the qualification entity are doctorID which acts as the primary
key and the foreign key as well in this case, name which stores the name of the doctor,
University attribute stores the name of the university the doctor graduated from, pasingDate
stores the year of graduation of the doctor, duration contain the time for which the doctor was in
University and lastly the aggregate contains the aggregate score of the doctor. In the payment
entity the appointmentID serves both for the primary key and the foreign key and is related to the
appointment entity with one-to-many cardinal relation. The payment entity contains the
components paymentDate, methodOfPayment, totalAmount and status. The payment entity will
basically contain the details of the payment made by the patient. It will contain the details of the
date the payment was made, mode of the payment, the total amount paid and the payment status.
CRUD Diagram:
Patient Appointment Doctor Qualification Payment
Register C C C
Login R R
Appointmen
t Schedule
R C R R
Appointmen
t briefing
R RU R
11HOSPITAL MANAGEMENT SYSTEM DESIGN
Payment R R R C
Prototype and Architecture Diagram:
Payment R R R C
Prototype and Architecture Diagram:
12HOSPITAL MANAGEMENT SYSTEM DESIGN
Secure Best Marks with AI Grader
Need help grading? Try our AI Grader for instant feedback on your assignments.
13HOSPITAL MANAGEMENT SYSTEM DESIGN
Figure 4: Prototype Interface Diagram
(Source: Created by Author)
The mobile interface is used to book an appointment with a doctor. The databases are
connected with the servers so that the patient can retrieve the list of doctors while choosing an
appointment. A patient needs to provide their personal email, their full name and set the date and
time with the doctor to proceed. The submit button is the conformation button and the clear form
button will clear all responses in the form.
Figure 4: Prototype Interface Diagram
(Source: Created by Author)
The mobile interface is used to book an appointment with a doctor. The databases are
connected with the servers so that the patient can retrieve the list of doctors while choosing an
appointment. A patient needs to provide their personal email, their full name and set the date and
time with the doctor to proceed. The submit button is the conformation button and the clear form
button will clear all responses in the form.
14HOSPITAL MANAGEMENT SYSTEM DESIGN
Figure 5: Architecture Diagram
(Source: Created by Author)
The architecture of the hospital management system provided in the diagram shows that
it will be hosted in the cloud. The cloud environment will allow the organization to access the
system remotely. The architecture shows that the system will integrate the customer and staff
operations in a single server. This means that this system will handle both the doctor and patient
requests. The architecture also represent that system can be accessed through open internet
connection. The patient can access the system through the mobile device as well as desktop.
However, the doctor cannot access the system through the mobile device. A printer will be
connected to the server so that doctor can print the prescription using the printer. The printer will
be a network printer which can support direct connection with the system server.
Figure 5: Architecture Diagram
(Source: Created by Author)
The architecture of the hospital management system provided in the diagram shows that
it will be hosted in the cloud. The cloud environment will allow the organization to access the
system remotely. The architecture shows that the system will integrate the customer and staff
operations in a single server. This means that this system will handle both the doctor and patient
requests. The architecture also represent that system can be accessed through open internet
connection. The patient can access the system through the mobile device as well as desktop.
However, the doctor cannot access the system through the mobile device. A printer will be
connected to the server so that doctor can print the prescription using the printer. The printer will
be a network printer which can support direct connection with the system server.
15HOSPITAL MANAGEMENT SYSTEM DESIGN
Details of Individual Group Members:
First Member: I have done the report structure, collected data regarding the hospital
management system. I made the decision of limiting the proposed application to appointment
scheduling. I collected data from various resources like articles and various blogs. In order to
collect the data from the internet I concentrated on being specific about the appointment. I wrote
the introduction and conclusion of the system.
Second Member: As a member of the team I have created the system requirements based
on the data collected by first member. I created the context, level 0 dfd and ERD and CRUD Of
the application. I have cross referenced my findings with various other solutions available in the
internet to find the gaps. After finding the gaps, I re-created the diagrams. This allowed to
developing solid idea of how the appointment process works in hospital management system.
Third Member: My work was to be develop the architecture and interface of the hospital
management system. I use the information from both the first and second member. In order to
design the architecture, I analyse both the in-house and cloud environment. After analysing the
advantages and disadvantages of both the environment I chose the cloud environment. To create
the interface I took reference from various real world mobile applications.
Conclusion:
From the above report it can be concluded that the system will provide extended support
to the hospital. The system can allow the organization to make the appointment related back
processes automatic. The patient does not need to call or directly approach the hospital to get an
appointment. The patient can simple submit the form and book an appointment. The doctors can
see their appointment from the PC installed in their cabin. They will not manually create the
Details of Individual Group Members:
First Member: I have done the report structure, collected data regarding the hospital
management system. I made the decision of limiting the proposed application to appointment
scheduling. I collected data from various resources like articles and various blogs. In order to
collect the data from the internet I concentrated on being specific about the appointment. I wrote
the introduction and conclusion of the system.
Second Member: As a member of the team I have created the system requirements based
on the data collected by first member. I created the context, level 0 dfd and ERD and CRUD Of
the application. I have cross referenced my findings with various other solutions available in the
internet to find the gaps. After finding the gaps, I re-created the diagrams. This allowed to
developing solid idea of how the appointment process works in hospital management system.
Third Member: My work was to be develop the architecture and interface of the hospital
management system. I use the information from both the first and second member. In order to
design the architecture, I analyse both the in-house and cloud environment. After analysing the
advantages and disadvantages of both the environment I chose the cloud environment. To create
the interface I took reference from various real world mobile applications.
Conclusion:
From the above report it can be concluded that the system will provide extended support
to the hospital. The system can allow the organization to make the appointment related back
processes automatic. The patient does not need to call or directly approach the hospital to get an
appointment. The patient can simple submit the form and book an appointment. The doctors can
see their appointment from the PC installed in their cabin. They will not manually create the
Paraphrase This Document
Need a fresh take? Get an instant paraphrase of this document with our AI Paraphraser
16HOSPITAL MANAGEMENT SYSTEM DESIGN
prescription on paper, rather they will ask the system to generate and print it. The system will
handle all the back-office processes which is very useful as staff can concentrate on their core
works. The operations will be more efficient and effective.
prescription on paper, rather they will ask the system to generate and print it. The system will
handle all the back-office processes which is very useful as staff can concentrate on their core
works. The operations will be more efficient and effective.
17HOSPITAL MANAGEMENT SYSTEM DESIGN
Bibliography:
Balaraman, P. and Kosalram, K., 2013. E-hospital management & hospital information systems-
changing trends. International Journal of Information Engineering and Electronic
Business, 5(1), p.50.
Braha, D. and Bar-Yam, Y., 2004. Information flow structure in large-scale product development
organizational networks. Journal of Information Technology, 19(4), pp.244-253.
Chen, P.P.S., 1976. The entity-relationship model—toward a unified view of data. ACM
Transactions on Database Systems (TODS), 1(1), pp.9-36.
Chen, P.P.S., 1977, June. The entity-relationship model: a basis for the enterprise view of data.
In Proceedings of the June 13-16, 1977, national computer conference (pp. 77-84). ACM.
DeMarco, T., 1979. Structure analysis and system specification. In Pioneers and Their
Contributions to Software Engineering (pp. 255-288). Springer, Berlin, Heidelberg.
Haag, S., Cummings, M. and Dawkins, J., 1998. Management information systems. Multimedia
systems, 279, pp.280-297.
Haszlinna Mustaffa, N. and Potter, A., 2009. Healthcare supply chain management in Malaysia:
a case study. Supply Chain Management: An International Journal, 14(3), pp.234-243.
Hovenga, E.J. and Grain, H., 2013. Health information systems.
Ismail, N.I., Abdullah, N.H., Shamsudin, A. and Ariffin, N.A.N., 2013. Implementation
differences of Hospital Information System (HIS) in Malaysian public hospitals. International
Journal of Social Science and Humanity, 3(2), p.115.
Bibliography:
Balaraman, P. and Kosalram, K., 2013. E-hospital management & hospital information systems-
changing trends. International Journal of Information Engineering and Electronic
Business, 5(1), p.50.
Braha, D. and Bar-Yam, Y., 2004. Information flow structure in large-scale product development
organizational networks. Journal of Information Technology, 19(4), pp.244-253.
Chen, P.P.S., 1976. The entity-relationship model—toward a unified view of data. ACM
Transactions on Database Systems (TODS), 1(1), pp.9-36.
Chen, P.P.S., 1977, June. The entity-relationship model: a basis for the enterprise view of data.
In Proceedings of the June 13-16, 1977, national computer conference (pp. 77-84). ACM.
DeMarco, T., 1979. Structure analysis and system specification. In Pioneers and Their
Contributions to Software Engineering (pp. 255-288). Springer, Berlin, Heidelberg.
Haag, S., Cummings, M. and Dawkins, J., 1998. Management information systems. Multimedia
systems, 279, pp.280-297.
Haszlinna Mustaffa, N. and Potter, A., 2009. Healthcare supply chain management in Malaysia:
a case study. Supply Chain Management: An International Journal, 14(3), pp.234-243.
Hovenga, E.J. and Grain, H., 2013. Health information systems.
Ismail, N.I., Abdullah, N.H., Shamsudin, A. and Ariffin, N.A.N., 2013. Implementation
differences of Hospital Information System (HIS) in Malaysian public hospitals. International
Journal of Social Science and Humanity, 3(2), p.115.
18HOSPITAL MANAGEMENT SYSTEM DESIGN
Kendall, K.E., Kendall, J.E., Kendall, E.J. and Kendall, J.A., 1992. Systems analysis and
design (Vol. 4). Englewood Cliffs, NJ: Prentice Hall.
Landry, S. and Beaulieu, M., 2013. The challenges of hospital supply chain management, from
central stores to nursing units. In Handbook of healthcare operations management (pp. 465-482).
Springer, New York, NY.
Madathil, K.C., Koikkara, R., Obeid, J., Greenstein, J.S., Sanderson, I.C., Fryar, K., Moskowitz,
J. and Gramopadhye, A.K., 2013. An investigation of the efficacy of electronic consenting
interfaces of research permissions management system in a hospital setting. International
journal of medical informatics, 82(9), pp.854-863.
Maylawati, D.S., Darmalaksana, W. and Ramdhani, M.A., 2018, January. Systematic Design of
Expert System Using Unified Modelling Language. In IOP Conference Series: Materials
Science and Engineering (Vol. 288, No. 1, p. 012047). IOP Publishing.
Obenshain, M.K., 2004. Application of data mining techniques to healthcare data. Infection
Control & Hospital Epidemiology, 25(8), pp.690-695.
Park, Y., Shankar, M., Park, B.H. and Ghosh, J., 2014, March. Graph databases for large-scale
healthcare systems: A framework for efficient data management and data services. In 2014 IEEE
30th International Conference on Data Engineering Workshops (pp. 12-19). IEEE.
Petre, M., 2013, May. UML in practice. In 2013 35th International Conference on Software
Engineering (ICSE) (pp. 722-731). IEEE.
Westbrook, J.I., Gospodarevskaya, E., Li, L., Richardson, K.L., Roffe, D., Heywood, M., Day,
R.O. and Graves, N., 2015. Cost-effectiveness analysis of a hospital electronic medication
Kendall, K.E., Kendall, J.E., Kendall, E.J. and Kendall, J.A., 1992. Systems analysis and
design (Vol. 4). Englewood Cliffs, NJ: Prentice Hall.
Landry, S. and Beaulieu, M., 2013. The challenges of hospital supply chain management, from
central stores to nursing units. In Handbook of healthcare operations management (pp. 465-482).
Springer, New York, NY.
Madathil, K.C., Koikkara, R., Obeid, J., Greenstein, J.S., Sanderson, I.C., Fryar, K., Moskowitz,
J. and Gramopadhye, A.K., 2013. An investigation of the efficacy of electronic consenting
interfaces of research permissions management system in a hospital setting. International
journal of medical informatics, 82(9), pp.854-863.
Maylawati, D.S., Darmalaksana, W. and Ramdhani, M.A., 2018, January. Systematic Design of
Expert System Using Unified Modelling Language. In IOP Conference Series: Materials
Science and Engineering (Vol. 288, No. 1, p. 012047). IOP Publishing.
Obenshain, M.K., 2004. Application of data mining techniques to healthcare data. Infection
Control & Hospital Epidemiology, 25(8), pp.690-695.
Park, Y., Shankar, M., Park, B.H. and Ghosh, J., 2014, March. Graph databases for large-scale
healthcare systems: A framework for efficient data management and data services. In 2014 IEEE
30th International Conference on Data Engineering Workshops (pp. 12-19). IEEE.
Petre, M., 2013, May. UML in practice. In 2013 35th International Conference on Software
Engineering (ICSE) (pp. 722-731). IEEE.
Westbrook, J.I., Gospodarevskaya, E., Li, L., Richardson, K.L., Roffe, D., Heywood, M., Day,
R.O. and Graves, N., 2015. Cost-effectiveness analysis of a hospital electronic medication
Secure Best Marks with AI Grader
Need help grading? Try our AI Grader for instant feedback on your assignments.
19HOSPITAL MANAGEMENT SYSTEM DESIGN
management system. Journal of the American Medical Informatics Association, 22(4), pp.784-
793.
Westbrook, J.I., Li, L., Georgiou, A., Paoloni, R. and Cullen, J., 2013. Impact of an electronic
medication management system on hospital doctors' and nurses' work: a controlled pre–post,
time and motion study. Journal of the American Medical Informatics Association, 20(6),
pp.1150-1158.
Yeh, D., Li, Y. and Chu, W., 2008. Extracting entity-relationship diagram from a table-based
legacy database. Journal of Systems and Software, 81(5), pp.764-771.
management system. Journal of the American Medical Informatics Association, 22(4), pp.784-
793.
Westbrook, J.I., Li, L., Georgiou, A., Paoloni, R. and Cullen, J., 2013. Impact of an electronic
medication management system on hospital doctors' and nurses' work: a controlled pre–post,
time and motion study. Journal of the American Medical Informatics Association, 20(6),
pp.1150-1158.
Yeh, D., Li, Y. and Chu, W., 2008. Extracting entity-relationship diagram from a table-based
legacy database. Journal of Systems and Software, 81(5), pp.764-771.
1 out of 20
Related Documents
Your All-in-One AI-Powered Toolkit for Academic Success.
+13062052269
info@desklib.com
Available 24*7 on WhatsApp / Email
Unlock your academic potential
© 2024 | Zucol Services PVT LTD | All rights reserved.