The purpose of this document is to specify and perceive the goals and features of this system named Hospital Management Service. It also states the various constraints which the system will be abide to. This document further leads to clear vision of the software requirements, specification and capabilities which are to be exposed to the development, testing team and end users of the software.

1.2 Scope

The system being described generally provides management of all activities among the hospital staff and the patients. The system proposes solution for the current public health care institutions in Republic of Macedonia, but could be used in any hospital, clinic, dispensary or pathology laboratory which needs computerized process, or if already has one - to improve it.
The current system in use in Macedonian public health facilities is a paper-based system. It is too slow and cannot provide updated lists of patients' data within a reasonable time frame. By using our system the over-time pay would be reduced and the number of patients that can be treated accurately would be increased.
Requirements statements in this document are both functional and non-functional.

1.3 Definitions, Acronyms and Abbreviations

Institution - referencing the institution which is using our system, it can be any health care institution, facility (like Hospital or Ministry of Health) that has bought a licence to use the system.

Patient - institution's patient can be any citizen of any age who is regulated as a patient in the institution according to the laws and its policy.

Appointment is an arrangement to meet someone at a particular time and place. In this context we are going to use it for meeting a doctor when a patient has health issues.

Appointment request is a request for scheduling an appointment (visit to the doctor), after which the patient chooses one of the offered time slots in order to have made an appointment.

GP is an abbreviation for General Practitioner, that is a doctor that implies prevention, education, care of the diseases and traumas that do not require a specialist, and orientate the patients towards a specialist when necessary. Each patient must have one GP.

Available time slot is the slot when a patient can get a scheduled appointment for their GP. It has to be free time slot when no other patients have scheduled appointments at the same GP. The average time expected would be 15 minutes, but it is going to be regulated by the system administrator, according to the institution's policy.

PIN - personal identification number, it is a unique identifier for each citizen.

Specialization - something that a doctor-specialist has studied for. He is expert for this and works only in this field.

1.4 References

Linked Open Drug Data from the Health Insurance Fund of Macedonia published in April 2013 as a conference paper from representatives from the Faculty of Computer Science and Engineering - Skopje, about which more information can be found at the following link: https://www.researchgate.net/figure/236273564_fig1_Figure-1-The-LOD-Cloud.

1.5 Overview

In the further part of the document will be given explanation of the current problems and needs of the system's users and stakeholders along with their detailed description (all users and stakeholders profiles), then our proposed solution for them is given. In the middle can be found the objectives of the system, what are the benefits of using it, but also alternative solutions are considered. In the second half, the description of the environment for which this system is built is specified, functional and non-functional requirements, as well as guides for end users.

2. Positioning

2.1 Business Opportunity

The feasibility of the project is analysed in this phase and business proposal is put forth with a very general plan for the project and some cost estimates. During system analysis the feasibility study of the proposed system is to be carried out. This is to ensure that the proposed system is not a burden to the institution using the system. For feasibility analysis, some understanding of the major requirements for the system are essential.

2.2 Problem Statement

The problem of	affects	the impact of which is	a successful solution would be
Not having computerized all patients' and institution's details	staff, patients	slow access to patients' data and not having good overview of their health progress, neither having a good overview of the available institution's rooms and its available personnel at a given time	keeping all the data into the system which makes it be kept up to date and available anytime by few clicks.
Not having fast access to available time slots	doctors, patients	cannot find easily what time is convenient for both the patient and the doctor	patient makes appointment request after which the system according to doctor's schedule will offer available time slots out of which the patient can choose one.
Not having a full list of all available drugs	pharmacists	not being able to compare the drugs among each other and give the best adequate replacement if a drug is missing	providing a list of all drugs available in the Linked Open Drug Data from the Health Insurance Fund of Macedonia along with details for each, as well as having updated status for each in the medical stock.
Not easy handling test reports of the patients conducted in the pathology laboratory of the institution	laboratory assistants, doctors, patients	long waiting until the results are provided from the laboratory to the doctor or the patient	using the system, immediate results will become available to either the doctor or patient right away when they are completed.

2.3 Product Position Statement

For	the management of the institution, its current employees and patients
Who	need real time access to patients' records and test results, available rooms, available staff and drugs in the medical stock
Hospital Management Service	is a web application
That	is available online
Unlike	the current paper-based system
Our product	offers fast access to all the information required for following patient's health progress, available rooms and staff in the institution, as well as available drugs and real time test analysis results.

3. Stakeholder and User Descriptions

3.1 Market Demographics

The system is intended for health institutions. It should be a part of the process for organizing patients' appointments and having overview of their diagnosis, therapy and health progress in one place. The number of users is limited to the number of employees in the institution using the system, as well as the patients that are under its auspices.

3.2 Stakeholder Summary

Name	Represents	Role
System administrator	As an administrator the user is responsible for supervising and maintaining the system, as well as taking care the system to have all the data updated.	As system admin the user is able to review the reports regarding the hospital activities, update the type of rooms and departments that are needed, keep track of what type of doctors specialists are missing in the hospital staff etc.
Doctors	A doctor in the system can become any person that gets employed on the position doctor in the institution using this system.	Doctors will be able to add new patients and to update the appointments, as well as review the appointments. They can write recipes, add diagnoses and place/dismiss a patient.
Nurses	The nurses help the doctors.	They can list all the patients and update information for the patients' appointments.
Patients	Patients are the people that need health care. Who can become a patient in the institution is regulated with its policy which is outside the concern of the system.	They can view their appointments already made and the ones that are scheduled in the future, as well as reports for the appointments.
Responsible institutions	The responsible institutions are the sponsors for this system's development and the ones that are going to use it later on for their purposes. It could be the Ministry of Health or the institution itself.	/
System developers	System developers are those who are responsible for having the system completed successfully within the stipulated deadline (designers, coders, testers).	Maintain the system.

3.3 User Summary

Name	Description	Stakeholder
Not technically skilled	These are small amount of users and are usually older people with very little technical knowledge or not at all. They will gain help from other people.	Patients
Standard users	The largest percentage of system users are going to be technically skilled people. They have no difficulty in adapting to more complex systems and are likely to actively use the system.	Doctors, Nurses, Patients, System administrator
Employees	All the institution's staff. They will use the system for help in human resources management.	Doctors, Nurses
Patients	Patients that are going to visit the doctor according to the time slot that has been thrown out by the system.	Patients

3.4 User Environment

The number of people included in one task will be mostly two - one patient and one doctor, but it can happen the nurses to help (like in emergency cases and similar).

The users can use the system from any device that has internet connection.

3.5 Stakeholder Profiles

3.5.1 <Users>

Representative	Doctors, Nurses, Patients
Description	The users will be able to make appointments and review them according to their type as explained under 3.2
Type	Doctors, Nurses, Patients
Responsibilities	The employees and patients to be on time at their working places and to do their job.
Success Criteria	Coming to the doctor on time and give the patient appropriate medicament.
Involvement
Deliverables
Comments / Issues	Unavailability of the system

3.5.2 <System administrator>

Representative
Description	The system administrator will supervise and maintain the system. He will keep a track if the rooms that are offered by the system are indeed free and will take care of staff's absences and replacements within the system.
Type
Responsibilities	Taking care of the system, maintain it and solve problems and inconsistencies.
Success Criteria	The system is available when it should be and its state is consistent with the institution's state (same number of rooms available etc.)
Involvement
Deliverables
Comments / Issues

3.5.3 <Institution using the system>

Representative
Description	They are going to be sponsors of the development of the system and then are going to use it for their own needs.
Type	Health institutions
Responsibilities	Finance the development of the system
Success Criteria	Successful integration of the system in institution's working
Involvement
Deliverables
Comments / Issues

3.5.4 <System developers>

Representative
Description	System developers are those who are responsible for developing the system (designers, coders, testers).
Type	Developers
Responsibilities	Designing, coding and testing the system.
Success Criteria	Successful completion within the stipulated deadline.
Involvement
Deliverables
Comments / Issues

3.6 User Profiles

3.6.1 < Неприлагодени на технологијата >

Representative	Small amount of users, but equally important as the others.
Description	They have difficulties to adapt to the technology. Small amount of the users, usually people of older age.
Type	Patients
Responsibilities	Make an appointment
Success Criteria	Online help
Involvement
Deliverables
Comments / Issues	The institution could hire employee intended to help these users.

3.6.2 <Стандардни корисници>

Representative	Biggest percentage of the users.
Description	They can easily use the system and most probably will become active users (according to their needs, of course).
Type	Doctors, Nurses, Patients
Responsibilities
Success Criteria	Easy to use and available withing working hours at least.
Involvement
Deliverables
Comments / Issues

3.7 Key Stakeholder / User Needs

Need	Priority	Concerns	Current Solution	Proposed Solutions
Системот треба да има дозвола на студентот да им одговори да праќаат пораки до предавачите	Must		Може да им праќаат пораки на меил или приватни пораки на courses.
Системот треба да им дозволи на предавачите да им одговараат на студентите	Must		Може да им одговараат на меил, преку приватни пораки на courses или лично за време на консултации.
Системот треба да овозможи приватност во комуникацијата студент- предавач	Must		Пораките на меил и приватните пораки на courses се невидливи за другите.
Системот треба да овозможи поставување на пораки од предавачите кои ќе бидат достапни за сите студенти	Must		Ова е овозможено со форумите кои постојат за секој курс и преку соопштенија што може предавачите да ги поставуваат на курсот.
Системот треба да овозможи креирање на јавни дискусии на некои теми	Should		Ова е овозможено со форумите кои постојат за секој курс.
Системот треба да овозможи некакво класифицирање на пораките по некаои критериуми	Could		Не е овозможено.
Системот со секоја поставена порака треба да асоцира дата на поставување и личност која ја поставила	Must		Овозможено како на форумите така и на приватните пораки.
Системот треба да овозможи архивирање на сите пораки и нивна достапност до соодветните корисници	Should		Овозможено е и за пораките пратени на форумите и приватните пораки.

3.8 Alternatives and Competition

3.8.1 Current system for making appointments

This system which is in current use is available only for the institutions using it. Disadvantage is not having all the patients' records in one place, as well as the patients not being able to review their reports by them selves anytime.

4. Product Overview

4.1 Product Perspective

The application will be windows-based, self contained and independent software product. It is necessary all employees and the management of the institution which uses it to have access to it and credentials provided. Only the current employees have access to system as the type of user they are. For instance if a doctor stops working in a hospital, they lose the credentials for the system and can no longer access it.

4.2 Summary of Capabilities

Customer Support System

Customer Benefit	Supporting Features
Easy to use.	Will be made simple so it can be used by ordinary citizens who have only basic technology knowledge.
Available in English with possibility to be upgraded with translations in another languages.	/
Available during the working hours of the institution, plus 99% of the remaining time.	Patients will be able to make an appointment request anytime.
The system must archive all the appointments made and the reports along with them.	For each appointment save its date, the patient, diagnosis and medication.
The system should be protected from unauthorized and unauthenticated access.	Each patient has access only to their respective data, and each doctor has access only to their patients' data.

4.3 Assumptions and Dependencies

The patients of the system once registered will remain constant, unless they change the institution and the employees accounts will be changed along with the employees current status because the system can be used only by the institution's current employees and patients.

4.4 Cost and Pricing

4.5 Licensing and Installation

5. Product Features

Системот треба да овозможи креирање на јавни дискусии на некои теми.

Системот со секоја поставена порака треба да асоцира дата на поставување и личност која ја поставила.

Системот треба да овозможи некакво класифицирање на пораките по некаои критериуми.

Системот треба да овозможи поставување на пораки од предавачите кои ќе бидат достапни за сите студенти.

Системот треба да овозможи архивирање на сите пораки и нивна достапност до соодветните корисници.

Системот треба да овозможи приватност во комуникацијата студент- предавач.

Системот треба да им дозволи на студентите да праќаат пораки до предавачите.

6. Constraints

The system should be protected for access by unauthorized people. Only logged in users can see the details that they are supposed to.

7. Quality Ranges

The system needs to be easy to use. The system should be available in English with a possibility to be upgraded with new languages in future.

The system should be available online all the time within the hospital working hours.

The system should archive all appointments made, along with the reports for each of them.

8. Precedence and Priority

The most important feature is that the system should provide the list of appointments all the time during the hospital's working hours.

9. Other Product Requirements

9.1 Applicable Standards

Regarding the fact that the system will be used within the hospital environment, it needs to be easily maintainable and portable if needed.

9.2 System Requirements

There mustn't be limitation of the number of users who are online at the same time.

There mustn't be limitation of the number of appointment requests send by a patient.

The user must make an appointment only to the doctor who is user's GP.

9.3 Performance Requirements

The number of patients in a certain period of time intended for appointment must be limited to maximum one. If it is noted that there is big demand for appointments (for example in winter during some flu period) then the system will provide the institution to be able to notice the frequency, so they will know that they should hire new employees (for example doctors).

9.4 Environmental Requirements

If users need some help (they have technical problems or they don't know how to do what they want) they can use the Online Help.

10. Documentation Requirements

10.1 User Manual

All current employees of the institution using the system will get username and password. Of course the password can be changed later on. The patients will be able to create new account - to register.

10.2 Online Help

It is predicted the system to offer online help. It means that there will be a page where will be written some general guidelines for using the system, there will be a part FAQ (frequently asked questions), and for more complex problems like not being able to login and similar technical problems will be intervened by system administrators.

10.3 Installation Guides, Configuration, Read Me File

The system for the user will represent a webpage where with its username and password can login and use it from any browser (Firefox, Opera, Chrome etc.).

10.4 Labeling and Packaging

11. Appendix 1 - Feature Attributes

11.1 Status

Proposed	The system must be available online. The system has to response to the patient with an available slot. The system must allow the doctors to have a review of their appointments. The system has to sort the patients' records by date.
Approved	The system has to be protected from unauthorized and unauthenticated access. Each slot must be unique for each patient at 1 doctor. The system has to allow the patients to send appointment request. The system has to keep a track of the date when an appointment has been made. The system must be easy to use for people of all ages. The system must provide option for upgrading it in another language for those who are not familiar with English language.
Incorporated	/

11.2 Benefit

Critical	The system must be available online. The system has to response to the patient with an available slot. Each slot must be unique for each patient at 1 doctor. The system must allow the doctors to have a review of their appointments. The system has to be protected from unauthorized and unauthenticated access.
Important	The system has to allow the patients to send appointment request. The system has to keep a track of the date when an appointment has been made. The system must be easy to use for people of all ages. The system must provide option for upgrading it in another language for those who are not familiar with English language.
Useful	The system has to sort the patients' records by date.

11.3 Effort

The team consists of two students who are developing this project as a part of course curriculum supervised by one professor.

11.4 Risk

The risk is the system to be developed but never be used by some institutions.

11.5 Stability

The development of the system should not contain major concessions because we have our goals specified in the first phase and we us team will give our best to accomplish all the initial ideas and agreements given in the documents which are made during the first phase of software development.

11.6 Target Release

It is expected this system to have its first initial release, with basic requirements done in January 2018.

11.7 Assigned To

We will divide the tasks, clearly specifying what is expected of us to do, what are the allowed concessions, and to what extent and for how long it is planned the task to be finished. In consultation with each other, as well as with the supervising authority, each problem will be overcome.

11.8 Reason

The reason for the development of this system, as mentioned before, is the simplification of the whole process of making appointments, perspicuous schedule of any doctor at a certain time period. That will help in avoiding unnecessary waiting for appointments, help staff have a better review of a patient's illness, given therapy and health progress.

Note: See TracWiki for help on using the wiki.

Download in other formats:

Plain Text

Context Navigation

Hospital Management Service

Revision History

Table of Contents

Vision

Download in other formats: