Detailed System Design Report: GP Practice Management System Analysis

This report provides a comprehensive system design analysis for a GP Practice Management System. It begins with an introduction to system design principles and then identifies key architectural components and subsystems, including patient management, doctor management, receptionist management, and practice manager management systems. The report selects the patient management subsystem as the core and explores two commercial open-source systems: Empress and Softclinic. It then delves into the logical system architecture, detailing the interactions between different user interfaces (doctors, receptionists, patients, and practice managers) and a centralized database. The report also includes a deployment architecture, mapping the logical architecture to a physical environment, including web servers, data servers, firewalls, and LAN setups. The conclusion emphasizes the importance of system design in meeting business requirements and the trade-offs between custom-built and commercial off-the-shelf systems. The report highlights the significance of security, cost considerations, and the ability to adapt to specific organizational needs.

System Design

Table of Contents
Introduction......................................................................................................................................3
Identification of architectural components..................................................................................3
Selection of one subsystem as well as identification of two commercial open source systems. .6
Logical system architecture along with its documentation..........................................................8
Deployment architecture..............................................................................................................9
Conclusion.....................................................................................................................................10
References......................................................................................................................................12

Introduction
System design refers to process related with defining components of a system such as
their modules, architecture, interface and information for it depending upon peculiar
requirements. Basically, it is a process which is being utilized for defining, development as well
as designing of systems that are responsible for satisfying peculiar requirements and needs of
business (Ahmadi-Javid and Hoseinpour, 2019). For doing this different modeling languages are
being used like UML, flowchart, system modeling and business process modeling notation. This
report is based on GP Practice Management System which is liable for recording as well as
scheduling appointments of patients with doctors. They are being utilized by practice manager,
receptionists and doctors. The practice comprises of around 15 doctors and numbers of patients
are near about 300 per day. This report comprises of the major architectural subsystems and
making use of one of them for satisfaction of requirements. Furthermore, this also comprises of
logical as well as deployment architecture for entire system.
Identification of architectural components
Subsystem refers to system object which comprises information that is liable for
illustrating characteristics of respective operating environment that is controlled by system. They
are the model elements that comprises of semantics of a class (which has its own behavior) and
package (comprises of model elements). The subsystem is dependent on either one or more
interfaces that are liable for defining their behavior (Ahmadi-Javid and Hoseinpour, 2019). It is
necessary that each part of a system that is subsystem must be an independent entity. In context
of GP Practice Management, some subsystems have been specified below:
Patient Management Subsystems
Responsibilities Collaborators
Book appointment
Confirm appointment
Cancel appointment
Messaging
Medication subsystem
Receptionist Management Subsystem

Responsibilities Collaborators
Booking appointment
Validation of patient identity
Cancel appointment
Booking subsystem
Messaging subsystem
Booking Subsystem
Responsibilities Collaborators
Making appointments
Schedules as well as area of
appointment (Specification of doctor)
Reminder of an appointment
Administration subsystem
Receptionist subsystem
Patient management subsystem
Messaging subsystem
Responsibilities Collaborators
Confirmation of appointment
Cancelation of scheduled time
Receptionist subsystem
Booking subsystem
Medication subsystem
Responsibilities Collaborators
Treatment notes
Prescription by doctor
Appointment approval
Doctor management subsystem
Booking subsystem
Receptionist subsystem

Practice Manager Management Subsystem
Responsibilities Collaborators
Auditing of report Messaging subsystem
Booking subsystem
Prescription Subsystem
Responsibilities Collaborators
Record of prescription given by
doctor
Medication subsystem
Booking subsystem
With respect to GP Practice Management System, they have four crucial subsystems that
comprises of doctor management system, practice manager, receptionist and patient management
system. They all have independent roles which they have to do (AL Abbas and et. al, 2019).
These subsystems are further elaborated below:
Doctor management system: This is crucial aspect within the system and has wide range of
liabilities which comprises of looking for available appointments, checking out treatment notes,
making alterations within them as per requirements, instructions for medications, looking for
performance of medical methods and finally checking history of patients (to have overview of
health issues faced by them in past).
Practice manager management system: This subsystem is liable for furnishing adequate
reports to doctors, patients and receptionist (Aldossary and et. al, 2019). For an instance test
reports will be furnished to doctor management system, in case there is any application form in
emergency then it will be given to receptionist and patients will be furnished with their reports as
per prescription of doctor. This also includes payment subsystem which is being utilised by
making use of web.

Receptionist management system: It is another subsystem and also an important aspect as it
comprises of wide range of liabilities. They will enter the details of new patients when they will
visit for the first time, schedule appointment via online applications (Farzandipour and et. al,
2020). Receptionist also have access appointments made by different patients, they can also be
found within system register, cancel the schedule of particular patient. Furthermore, it will also
record the entry of patients and system will also provide them with an option for making
payments to receptionist. If any slot is vacant then they will update it.
Patient management system: This is responsible for providing new patients with an option
to sign up into it which are being included within register. In addition to this, system will furnish
them with an option through which they can make appointments on the basis of time slot which
is being available. Furthermore, when appointment will be confirmed person will be furnished
with its confirmation (Hamilton, 2020). Along with this, a reminder will also be sent 48 hours
before the relevant time. Along with this, they are also provided an option to cancel their
appointment due to any reason. This option will save the crucial time of doctors and particular
time slot can be taken up by someone else and have adequate treatment.
Selection of one subsystem as well as identification of two commercial open source systems
By identifying as well as analyzing different subsystems in above sections, it has been
found that patient management subsystem is core within GP Practice Management System. The
reason behind this is that they are the individuals around whom entire system revolves around.
Basically, they are essential assets within the entire system. Commercial off-the-shelf implies
hardware or software products which have already been developed and can be utilized by
businesses as per their requirements either by making some payments or free of cost. In this
context and with reference to GP Practice management system, there are many off-shelf systems
such as empress patient management system and soft clinic management systems. The
management can utilize these by buying them from Amazon (Hastuti, Setyaningsih and Adi,
2020).
Empress patient management system: It furnishes end to end database management
software for peculiar website or web application. This is being supported by different operating
system (Kotoulas and et. al, 2019). This is liable for integrating all the activities of health care
like registration, billing, appointment booking and many other.

Softclinic management systems: It implies a scalable hospital and clinic management
system which comprises of electronic health records. This is a desktop application which can be
installed within the system. Basically, it is end to end software which will aid physicians for
making their practice paperless by digitalizing all the basic management as well as record
keeping activities.
These are the systems which render similar functionalities as per operations which are
being carried out by GP Practice Management. The easiest option is to buy these systems and
utilize them but certain factors has to be considered before this is being done. They have two
options and one can be considered from them, they are building own subsystem or buying a
customized system. For this, all the requirements of subsystem must be identified in an adequate
manner and factors such as cost, building, time required for doing this and business values must
be taken into account (Li and et. al, 2019). The major disadvantage related with customized
system is that they may fail to acknowledge needs of system of organization. Along with this,
they are also expensive and it may take time within installation as well as learning them (in terms
of their usage). The system which is particularly designed for peculiar organization or purpose
will have more value as compared to commercial off-the-shelf systems.
It is recommended that, GP Practice Management must develop their own system as it
will be more secure. The primary responsibility of each organization is that they must maintain
privacy, confidentiality and integrity of their patients. The third party software or system may
have vulnerabilities through which intruder can have access to their entire system. The second
reason is that cost involved within lending system will be expensive as this comprises of
upgradation and licensing fees. But if system is developed then these costs will be eliminated.
Third aspect for this is that each firm have their peculiar requirements and in-build or off-shelf
systems might not be able to accomplish all the requirements of organizations as they are not
formulated by taking into consideration one peculiar group (Ni and et. al, 2019). There may be
some features that may not be applicable for GP Practice Management. While bringing in
innovation within their processe it will be difficult for organization to makes changes within the
system but in case it is being build then as per the needs alterations can be made. This also
denotes that, firm will have to change the system instead of depending on existing system which
will be more costly to them (Ramli, 2019).

Logical system architecture along with its documentation
The structural design which furnishes all the crucial details of a system is referred to as
logical system architecture. Here, system is decomposed into logical components by which their
functionalities can be acknowledged. This will enable all the subsystem to have a distinguished
applications as well as domain layer (Yang and et. al, 2019). For an instance, receptionist will be
given different platform where they can confirm or cancel booking and similarly patients are
provided with interface in which they can check schedules and make an appointment. They will
be separate entities but are being connected with a centralized database that enables them to
carry out their responsibilities accordingly. This implies that application and domain layers are
different and can be accessed within entire system. The access channels comprise of mobile
devices as well those which are generic infrastructure subsystem. It will enable system developer
within validating proposed architecture with respect to non-functional requirements that have
been identified through the usage of architectural drivers.
The logical style is liable for translating into three-tier architecture where user interface
(UI) layer is executed on either virtual machine or different device from domain as well as
technical layer modules. Normally, they are being executed on one or more servers which furnish
them with enhanced scalability as well as reliability within the system. This implies that their-tier
is found within database management that is accessed via a technical service layer deployed
within other node. The logical design shows the entire system which is being accessed by doctor,
receptionist, patients and practice manager. The other layer shows that each have different
subsystem which they can access by making use of their credentials. The last layer illustrates
operations that will be carried out by them (Ahmadi-Javid and Hoseinpour, 2019). These will be
stored within the database of system through which updated information can be attained by each
subsystem. For an instance, if doctor is available for particular time slot then its details will also
be with receptionist subsystem and patient subsystem so that they can formulate appointments
and have services accordingly.

Illustration 1: Logical System Architecture
Deployment architecture
The mapping of logical architecture within physical environment is defined as
deployment architecture. This comprises of technical system requirements which required
computing nodes in an internet environment, storage devices, memory and many other hardware
as well as networking devices (AL Abbas and et. al, 2019). With reference to GP Practice
Management, to acknowledge the request of their patients web server and webdata server will be
installed which are connected with a Ethernet adapter as well as they both will connected via hub
to a firewall and a router. Firewall is used so that any third person does not get access to network
or system of management. Furthermore, in local area network (LAN), there will be a mail server
and client data server for sending as well as storing emails of patients and other people or
stakeholders of organization. Again these are connected with hub by making use of two Ethernet
adaptors. Then this will be connected with centralized firewall. These are the servers which will
be used within the subsystem of GP Practice management for ensuring that there entire system
works as per desired standards and they attain adequate results.

Illustration 2: Deployment Architecture
Here, DMZ network is being utilized for making sure that confidentiality and privacy of
organization is not hampered by third person (Farzandipour and et. al, 2020). DMZ denotes a
secured approach for creation of a network that is dual-firewall configured in between them.
Conclusion
From above, it can be concluded that system design refers to systematic approach that is
used for designing a system in which either top-down or bottom-approach can be taken up. It
defines different elements which are liable for satisfying peculiar requirements of a system by
furnishing well running and coherent system. Firm have different options either making use of
in-built software or developing their own system as per their requirements. This enables them to

ensure that all the requirements all being accomplished. Furthermore, logical system architecture
furnishes different layers through which each subsystem can furnish there operations
appropriately.

References
Books and Journal
Ahmadi-Javid, A. and Hoseinpour, P., 2019. Service system design for managing interruption
risks: A backup-service risk-mitigation strategy. European Journal of Operational
Research, 274(2), pp.417-431.
AL Abbas, A., and et. al, 2019. Analyzing and Implementing a System For Reporting, Follow
Up and Resolving of Complaints. ABBAS, AA, ALZAYER, K., ALKHALDI, A., ALSMADI,
MK, ALSHABANAH, M., ALRAJHI, D., ALMARASHDEH, I. & TAYFOUR, M, pp.1833-
1842.
Aldossary, S. and et. al, 2019. Analyzing, Designing And Implementing A Web-Based
Command Center System. ALDOSSARY, S., ALTHAWADI, A., ALMOTAIRY, M.,
ALSMADI, MK, ALRAJHI, D., ALSHABANAH, M., ALMARASHDEH, I., TAYFOUR, M.
& ALJAMAEEN, pp.1008-1019.
Farzandipour, M. and et. al, 2020. Technical requirements framework of hospital information
systems: design and evaluation. BMC medical informatics and decision making, 20(1),
pp.1-10.
Hamilton, D.K., 2020. Design for critical care. In Design for Health (pp. 129-145). Academic
Press.
Hastuti, D.D., Setyaningsih, Y. and Adi, K., 2020. Design of Occupational Health and Safety
Management Information System at Telogorejo Semarang Hospital. Unnes Journal of
Public Health, 9(1), pp.20-27.
Kotoulas, A. and et. al, 2019. Short-term adoption rates for a web-based portal within the intranet
of a hospital information system. BMJ health & care informatics, 26(1), pp.1-4.
Li, X. and et. al, 2019. EdgeCare: leveraging edge computing for collaborative data management
in mobile healthcare systems. IEEE Access, 7, pp.22011-22025.
Ni, Y. and et. al, 2019. A real-time automated patient screening system for clinical trials
eligibility in an emergency department: design and evaluation. JMIR medical
informatics, 7(3), p.e14185.
Ramli, A.H., 2019. PATIENT SERVICE AND SATISFACTION SYSTEMS. Business and
Entrepreneurial Review, 15(2), pp.189-200.
Yang, C.T. and et. al, 2019. Implementation of an intelligent indoor environmental monitoring
and management system in cloud. Future Generation Computer Systems, 96, pp.731-749.