Galutera Clinic

GALUTERA DERMATOLOGY CENTER PATIENT INFORMATION SYSTEM

A PROPOSED PATIENT INFORMATION SYSTEM FOR GALUTERA

DERMATOLOGY CENTER, BAMBANG NUEVA VIZCAYA

A Capstone Project

Presented to the Faculty of the

School of Computing Sciences and Information Technology

Saint Mary’s University

Bayombong, Nueva Vizcaya

In Partial Fulfillment of the Requirements for the

Degree of Bachelor of Science in Information Technology

Ananayo, Lenilee S.

Sepulveda, Patricia Grace

Valerio, Kevin Lord Venson

Zuzon, Marynelle

Ms. Bermelita Tagtag

Adviser


CHAPTER I

Problem and its Background

Rationale

Papers in the past decades have been very significant in the different fields. It is

where we transcribe the most important information like; the records of the

business/organization daily activities or its transactions, the data of a certain patient in

a hospital/clinic, the profile of students in school, and the documents of an employee in

a certain company.

But in our modern world today, we witnessed the major progress in the field of

Information Technology that affects everyone’s life. Computer systems took over some

role of papers in performing those works most especially in systematization of records.

The Patient Information system in a hospital is one of the manifestations of the vast

advancement of technology.

Nowadays, people have become more conscious in taking care of their skin and

faces to ensure that they have a healthy skin and a spotless face. That is why everyday;

many people come to clinic for treatment or checkups. So, as the number of patients

continuously increases, managing a clinic will also become difficult and demanding

because it is not only the doctor’s expertise or about the medicines that the patients are

satisfied with, but it is also with the quality of the clinic management.


So as researchers we would want to help the clinic in managing everyday’s

activities, therefore we considered Galutera Dermatology Center for our study.

Galutera Dermatology Center is located at 74 Heroes, Buag, Bambang, Nueva Vizcaya

at the 2nd floor of Chicboy Restaurant. It is owned by Dr. Rainier Galutera. The said

Clinic offers many different Facial and Body Treatment. As of now, the clinic has

approximately 700 patients and currently has 3 staffs.

The current process in storing information is that the patient will manually fills

up the patient form that contains the personal information, past medical history, family

medical history, personal or social history, Review of systems and dermatologic

examination.After the examination of the patient, the doctor will write down the

patient diagnosis which includes the objective, subjective, plan, examination,

assessment and etc.After every session of a certain patient, the staff will write down

the date of consultation into the form.

They keep patient’s record in a folder that will be placed in a cabinet. These

folders will be retrieved during consultation.

For paying of bills and medicines, the patient will sign up another form for the

receipt.The patient will give the payment to the staff.The staff will mark his/her

signature at the receipt and lastly the patient will again show his/her receipt for the next

appointment that was set by the doctor for verification.


Statement of the Problem

According to Doctor Galutera himself, most of the problems that they

encountered in the manual process are:

1. Time Consuming due to the following:

-filling up patient’s data form

-writing diagnosis

-writing receipt

2. Unorganized Storage of Records

The patient’s record are not sorted well when returning or putting into the

cabinet, therefore the staffs has to arrange the records manually from time

to time.

3. Difficulty in retrieving of records

The staffs manually look for the patient’s records in the cabinet.

4. Redundancy of records

Some of the patients are unconsciously signed up the forms recurrently.

5. Loss of Records

Some of the records are missing or misplaced because some of the papers

are not returned to the cabinet where the records usually placed.

6. Costly and space insufficency

The staffs needs to print more patient form and it needs a lot of paper and

at the same time, they need more space for the storing of the records.


7. Lost of Patient’s duplicate receipt

Sometimes, the copy of receipt of a certain patient misplaced and the

patient need that for the next appointment for the continual of treatment or any

other services.

8. Damage of Records

Some of records are damage due to environmental phenomenon which

sometimes we cannot avoid like: pests or fire.

Conceptual Framework:

The IPO Diagram is a visual representation of a sequence of activity. It shows

how the system would be develop by identifying all the variables needed based on the

identified process of the business organization, the methods that will be used in

building the system and the expected output. (See Appendix A for the IPO diagram)

Objectives of the Study

The researchers generally aim is to develop a computerized Patient

Information System for Galutera Dermatology Clinic Center.

Specifically, with the propose system, the researchers’ aims to:

1. Make the storing and retrieving of records easier and faster.


With the easily encoding and just checking of checkboxes, the inputting of

records will be easily stored. And with the search functions under View Records,

all records can be easily retrieved.

2. Make the records organized and systematic for easy retrieval and monitoring.

The system has a feature that will generate reports for easy retrieval in an

organized manner.

3. Avoids duplication of records that leads to inconsistency.

4. Secure records not to be misplaced or damaged. With the backup or restore

features of the system, it prevents misplacement and avoid damages.

Scope and Limitation

The proposed computerize system have the following features: The

system will be able to store the patient information including patient picture, patient

diagnosis, patient schedule, patient bills, lists of services, lists of medicines, lists of

patients and audit trail. The system is capable of storing the point of sale and inventory

of medicines.The system can add, edit and view the information or records.The system

can also add, edit, view and delete the user account.The system can also generate and

print records.

Delimitation

The study is limited for Galutera Dermatology only. In terms of security,

the staff cannot access or manage the user account and the audit trail because only the


doctor/aministrator is authorized for it. The system cannot delete the patient records.

The system can only be installed and properly used when the computer meets the

requirements (MySQL server 5.5 or higher, VB.NET Framework 3.5 or

higher)

Significance of the Study

This study is significant to the following:

1. Clinic.

The propose system will make the clinic everyday’s task simpler and can

provide better service, making it more profitable.

2. Doctor and staffs

The proposed system will make it easier for the doctor to manage the

clinic and convenient when it comes to retrieving patient records.

3. Patients

Patients are the most important assets of the clinic, and the reason why

this study conducted is to provide a better service for them by simply oragnizing

their records for convenience

4. Researchers

The researchers have developed their writing, analysis, and

interpretation skills needed to make a good research.


5. Future Researchers

This study gives them a background or overview in conducting a study

related to Patient Information System.


Chapter II

REVIEW OF RELATED LITERATURE

This chapter discusses related issues concerning to the development of the

“Galutera Dermatology Patient Information System” through the help of some

implemented studies. Moreover it gave the researcher the clearer understanding about

the proposed system including its advantages to the clients. The following related

literature and theories have been thoroughly read and reviewed to understand better

and come up to with the project.

Dermatology is the branch of medicine dealing with the hair, nails, skin and its

diseases. It is a unique specialty with both medical and surgical aspects. Dermatologic

Surgeons played a key role in the history of scientific and technological discoveries

made in skin care and repair during the 19th and 20th centuries. Exciting new

breakthroughs continue into the 21st century with innovations in skin cancer treatment

and cosmetic procedures.

Egyptians treats the skin with chemicals dates back to the ancient times, they

used arsenic on the skin to kill cancer. They also used animal oils, salt, alabaster, and

sour milk to improve the appearance of skin. Cleopatra was reputed to take milk baths,

enjoying the cosmetic benefits of lactic acid, the first alpha-hydroxyl acid, for softer,

smoother skin.

https://en.wikipedia.org/wiki/Skin_disease

https://en.wikipedia.org/wiki/Skin_disease

https://en.wikipedia.org/wiki/Skin

https://en.wikipedia.org/wiki/Nails

https://en.wikipedia.org/wiki/Hair


The Greeks and Romans used mixtures of pumice, frankincense, myrrh, and tree

resins to lighten the skin, remove freckles, and smooth wrinkles. Turkish treatments

used fire to lightly singe the skin for exfoliation. And, in India, women sought soft,

smooth skin from a mixture of urine and pumice applied to their faces.

Early dermatology was associated with urology, and later, in the early 1900s,

was involved with the treatment of syphilis and venereal diseases.

In the late 1800s, dermatologists began using a variety of chemicals to smooth

facial wrinkles and scarring. Phenol peels began to be used to treat acne scarring in the

early 1900s. By the 1950s and 1960s, trichloracetic acid peels were popular, followed

by the introduction of dermabrasion in the 1970s and 1980s, and the use of alpha-

hydroxyl acids with other chemicals in combination peeling in the 1990s.

As early as 1500 BC, Egyptian physicians were experimenting with using

sandpaper to smooth scars. By the 1900s, dermatologists began using sandpaper as

well as motorized dermabrasion for skin rejuvenation. In 1995, microdermabrasion for

mild exfoliation and resurfacing was introduced in a popular, light “polishing” facial

peel.

Cryosurgery to remove skin lesions began in 1899, with electro surgery coming

into use in 1909. Discoveries in hair transplantation and lip sculpture were made in the

early part of the century by dermatologists, with improvements and enhancements

continuing today.


Light has played an important role in the treatment of skin disease. Ancient

Egyptians used natural sunlight for treating certain skin disorders. Sunlight was also

used by many European physicians in the 18th and 19th centuries to treat psoriasis and

eczema. Soon after the development of the laser in the 1950s, dermatologists began

utilizing lasers to treat skin conditions. Dozens of laser applications were pioneered in

the 1980s and 1990s for pigmented lesions, cosmetic resurfacing, and laser hair

removal.

New breakthroughs in research continue with lasers for skin tightening, stretch

marks, laser hair transplantation, scar revision and other rejuvenation procedures.

The practice of dermatology and dermatologic surgery continues to be one of the

fastest growing specialties with incredible breakthroughs in skin care and repair. The

physicians of The Center for Dermatology Care are continuing the advancement of

rejuvenation technology with state-of-the-art medical expertise and state-of-the-heart

patient care.

Record is defined as the process of capturing data or translating information to a

recording format stored on some storage medium, which is often referred to as a record

or especially if an auditory or visual medium. It is also defined as being something that

represents proof of existence and that can be used to recreate or prove state of

existence, regardless of medium or characteristics. A record is either created or


received by an organization in pursuance of or compliance with legal obligations, or in

the transaction of business.

Records management (RM), also known as Records information

management or RIM, is the professional practice or discipline of controlling and

governing what are considered to be the most important records of an organization

throughout the records life-cycle, which includes from the time such records are

conceived through to their eventual disposal. This work includes identifying,

classifying, prioritizing, storing, securing, archiving, preserving, retrieving, tracking

and destroying of records.

Records management is part of an organization's broader activities that are

associated with the discipline or field known as Governance, risk, and compliance (or

"GRC") and is primarily concerned with the evidence of an organization's activities as

well as the reduction or mitigation of risk that may be associated with such evidence.

Record management aims to enable organizations to manage documents and records

throughout the document life-cycle, from creation to destruction.

An Electronic Document and Records Management System (EDRM) is

a computer program (or set of programs) used to track and store records. The term is

distinguished fromimaging and document management systems that specialize in paper

capture and document management respectively. ERM systems commonly provide

https://en.wikipedia.org/wiki/Document_management_system

https://en.wikipedia.org/wiki/Document_imaging

https://en.wikipedia.org/wiki/Computer_program

https://en.wikipedia.org/wiki/Electronic_Document_and_Records_Management_System

https://en.wikipedia.org/wiki/Document#Document_life_cycle

https://en.wikipedia.org/wiki/Document

https://en.wikipedia.org/wiki/Organization

https://en.wikipedia.org/wiki/Governance,_risk_management,_and_compliance

https://en.wikipedia.org/wiki/Governance,_risk_management,_and_compliance

https://en.wikipedia.org/wiki/Records_life-cycle


specialized security and auditing functionality tailored to the needs of records

managers.

The National Archives and Records Administration (NARA) has endorsed

the U.S. Department of Defense standard 5015.2 as an "adequate and appropriate basis

for addressing the basic challenges of managing records in the automated environment

that increasingly characterizes the creation and use of records. “Records Management

Vendors can be certified as compliant with the DoD 5015.2-STD after verification

from the Joint Interoperability Test Command which builds test case procedures,

writes detailed and summary final reports on 5015.2-certified products, and performs

on-site inspection of software.

The National Archives in the UK has published two sets of functional

requirements to promote the development of the electronic records management

software market (1999 and 2002). It ran a program to evaluate products against the

2002 requirements. While these requirements were initially formulated in collaboration

with central government, they have been taken up with enthusiasm by many parts of

the wider public sector in the UK and in other parts of the world. The testing program

has now closed; The National Archives is no longer accepting applications for testing.

The National Archives 2002 requirements remain current.

The European Commission has published "MoReq," the Model Requirements for

Electronic Records and Document Management in 2001. Although not a formal

https://en.wikipedia.org/wiki/MoReq2

https://en.wikipedia.org/wiki/European_Commission

https://en.wikipedia.org/wiki/The_National_Archives_(UK)

https://en.wikipedia.org/wiki/Joint_Interoperability_Test_Command

https://en.wikipedia.org/wiki/United_States_Department_of_Defense

https://en.wikipedia.org/wiki/National_Archives_and_Records_Administration


standard, it is widely regarded and referred to as a standard. This was funded by the

Commission’s IDA program, and was developed at the instigation of the DLM Forum.

A major update of MoReq, known as MoReq2, was published in February 2008. ] This

too was initiated by the DLM Forum and funded by the European Commission, on this

occasion by its IDABC program (the successor to IDA). A software testing framework

and an XML schema accompany MoReq2; a software compliance testing regime was

agreed at the DLM Forum conference in Toulouse in December 2008.

The National Archives of Australia (NAA) published the Functional

Specifications for Electronic Records Management Systems Software (ERMS), and the

associated Guidelines for Implementing the Functional Specifications for Electronic

Records Management Systems Software, as exposure drafts in February 2006.

Archives New Zealand published a 'discretionary best practice' Electronic

Recordkeeping Systems Standard (Standard 5) in June 2005, issued under the authority

of Section 27 of the Public Records Act 2005.

According to the National Archives and Records Service, in terms of its statutory

mandate, requires governmental bodies to put the necessary infrastructure, policies,

strategies, procedures and systems in place to ensure that records in all formats are

managed in an integrated manner. The National Archives and Records Service endorse

the SANS (ISO) 15489 Records Management Standard, SANS (ISO) 23081 Metadata

for Records and SANS (ISO) 15801 Trustworthiness and Reliability of Records Stored

https://en.wikipedia.org/wiki/Archives_New_Zealand

https://en.wikipedia.org/wiki/National_Archives_of_Australia

https://en.wikipedia.org/wiki/Records_management#cite_note-22

https://en.wikipedia.org/wiki/DLM_Forum


Electronically. These are benchmarking tools for sound records management. The

primary benchmark for creating and managing electronic records in office

environments which is endorsed by the National Archives and Records Service is

contained in the suite of publications Principles and Functional Requirements for

Records in Electronic Office Environments adopted by the International Council on

Archives in 2008.

The National Archives and Records Service requires governmental bodies to

implement and maintain Integrated Document and Records Management Systems that

provide as a minimum the following records management functionality: managing a

functional subject file plan according to which records are filed; managing e-mail as

records; managing web-sites as records; maintaining the relationships between records

and files, and between file series and the file plan; identifying records that are due for

disposal and managing the disposal process; associating the contextual and structural

data within a document; constructing and managing audit trails; managing record

version control; managing the integrity and reliability of records once they have been

declared as such; and managing records in all formats in an integrated manner.

Not many governmental bodies have the capacity to implement fully automated

Integrated Document and Records Management Systems. This does not however mean

that they should not manage their electronic records. If these records are created to aid

in decision-making and to perform transactions that support the governmental bodies'

activities, governmental bodies are responsible for the proper management of those

http://www.national.archives.gov.za/rms/functional_spec.htm

http://www.national.archives.gov.za/rms/functional_spec.htm


records. If records generated in such an environment are not managed properly it can

lead to the possible illegal destruction of records. To enhance their accountability,

bodies should ensure that, even without the benefit of an Integrated Document and

Records Management System, they exercise effective records management.

According to administrator of Arkansas Electric Cooperatives (AEC), it is their

job to ensure that the organization's business and operating records are being managed

so that current and accurate information is readily accessible and is in compliance with

regulatory recordkeeping requirements. With the majority of records now being created

and maintained electronically, managing those records has become increasingly

problematic.AEC needed a technology solution that would help organize business

information for easy access and quick retrieval and enable to archive important

electronic records in a secure and stable environment. Electronic Document

Management System (EDMS) seemed to be the answer. Typically, business and

operational records experience heavy use during their relatively short "active “life, then

see a sharp drop in use. Many records, in fact, are used only during a business

transaction or operation and may never be accessed again. Regulatory requirements,

however, often dictate asset period for which many of these records must be retained.

In addition, certain records might be needed for reference purposes and should be kept

in order to provide a historical perspective of the organization. Components of AEC's

comprehensive records management program, which began development in 1988,

include a retention schedule that assigns retention periods to all of the Cooperatives'


records, procedures for the systematic destruction of records that have satisfied their

retention requirements, and protection of records that provide a "permanent" record of

the organization. A vital records plan is also being developed to safeguard records that

would be required in order to continue business operations in the event of a disaster.

Together these components help systematically control business and operating records

throughout their life cycle from the time they are created, through their active life, until

they are either destroyed or archived for long-term retention. As the volume of AEC's

electronic documents and records continues to grow, we have become increasingly

dependent on the information contained in them. Meanwhile, paper records continue to

be maintained, often living on as duplication of records that are being created and

stored electronically. Compliance with records retention and disposition rules and

regulations was difficult, if not impossible. While a program for records retention and

disposition had been created for the company's records, the majority of electronic

records were not being retained in accordance with the program. It became clear that

managing this problematic electronic information would require a technology solution,

and that EDMS might provide just the tool we needed to effectively manage our

electronic documents and records throughout their life cycle.

After convincing senior management that an electronic document management

system was worth exploring, an EDMS project team was appointed. In addition to the

records system administratorand business information technology manager, the team

included representatives from each major business unit to ensure that all areas would


be represented during the analysis and selection process. Once the project team was in

place, the team selected a "work group" - a team of approximately 30 employees most

familiar with the creation and use of documents in their areas. The EDMS project

kicked off with an educational meeting for the document work group and guests.

Presentations included a word of support for the project from AEC's

President/CEO, a case studyfrom system, and an overview of the features and benefits

of EDMS.

Needs Assessment: The first step in the project was to develop a requirements

document to analyze our business processes and assess our document management

needs. The purpose of this document would be to build a business case for EDMS and

to help ensure that whatever system we selected would meet our Information

requirements. The work group was given instructions for inventorying the documents

used in each department. Through the document inventories we were able to identify

the flow of documents through business processes and determine retrieval and growth

patterns as well as storage requirements for those documents.

The Business Case the document inventory identified forty differentbusiness

processes which were creating approximately 23,000 documents per month or some

276,000 documents per year. These numbers, based on participation by twelve

departments, formed the basis for our EDMS business case. Three criteriawere used to

determine which of these fortyprocesses would benefit most from an EDMS. The


criteria and the thresholds set for each were as follows:1) Volume: Business processes

that createdmore than 300 documents per month; 2) Access:Processes utilizing

documents accessed by morethan three users; and 3) Retrieval: Business process

documents that were being retrieved more than Three times per week were flagged.

Four business processes met the thresholds set for all three criteria. These processes

became our pilot application.

The Selection: based on the information from the requirements document, the

team developed a Request for Information (RFI) and distributed it to forty EDMS

vendors. Project team members evaluated and ranked each item in the RFI in order of

importance. A matrix was then created to compare these weighted rankings to each

vendor's response and producea "score" for each product. The matrix produced a graph

showing total scores for the products and enabled the team to narrow the RFI responses

down to six vendors. Each of the six vendors was contacted and meetings were set up

to review their products and discuss our requirements with the vendors. All of the

vendors, with one exception, came onsite to demonstrate their software, review our

needs, and answer any questions the team had regarding their solutions. The project

team then reviewed the information gathered from the six vendors and the product

demonstrations and made a final selection.

The Sell: once the project team made their final decision, it was time to sell

senior management on the idea. The team developed a presentation outlining the

benefits EDMS would bring to AEC and showing how implementing the system would


positively impact our bottom line. While EDMS benefits can be difficult to quantify,

we were able to use cost avoidance figures to show a favourable return on investment

and justify the expenditure. Through a comparison of manual filing systems and

electronic document management systems, we were able to demonstrate a significant

reduction in filing, retrieval, and storage costs and show a return on our sizable

investment within two years. Following the presentation to senior management and a

question and answer session the project was approved, and we were ready to move

forward with the installation and implementation.

Installation and Implementation: Before implementation could begin our EDMS

vendor, Document Imaging Solutions (DIS), met with users from each of our four pilot

applications to develop specifications, identify document types and establish field

attributes for each. Once DIS had customized their product to fit our applications, they

were ready to install the software. We decidedto start with one application, AEC

Accounts Payable, and to get it completely up and running before moving to the next.

How EDMS Works:

EDMS is actually a combination of technologies. With the Accounts Payable

(A/P) application, for example, invoices that are received as paper documents are

scanned into the system. Checks used to pay those invoices are created on an IBM

AS400 and downloaded into EDMS. These two document types are linked together by

a unique key, in this case the combination of invoice number and vendor number. Once


EDMS finds that key in the AS400, additional index fields such as the invoice date and

check number are automatically populated with data from the AS400. Utilizing ERM

(Electronic Report Management) technology, several A/P computer reports created

from data on the AS400 are also downloaded into EDMS. These reports, which were

previously printed out in duplicate and distributed to multiple departments, are now

stored online where they can be accessed, searched, and, if necessary, a section or all

of the report can be printed on demand. Most electronic document formats such as

Worddocuments and Excel spreadsheets can also be loaded into EDMS. Board

minutes, for example, are loaded as Word documents to provide full text searching of

meeting minutes. This allows searching past minutes to quickly determine when a

specific issue was discussed or how a decision was made. Spreadsheets used to

calculate monthly power bills are loaded as supporting documents for the wholesale

power billing application. While these documents allow full text searching, EDMS

stores them as unalterable documents that cannot be edited or changed.

EDMS Benefits:

Now that EDMS is up and running and we have implemented a number of

applications, the organization is beginning to see value in this new technology. Here is

a summary of benefits that EDMS has brought to AEC: Cost Savings: As mentioned

earlier, one of the primary selling points for EDMS was cost avoidance. While this

benefit remains difficult to quantify, access and retrieval of documents is more

efficient and there have been no reported "lost" or "misfiled" documents in EDMS


since its implementation. Being able to retrieve quickly the most currentversion of a

document without leaving your desk saves time for more important things, which

means the company is getting more for its money. Access: Probably the biggest

advantage of EDMS has been its ability to provide simultaneous document access to a

number of users spread throughout the organization. Employees in remote locations

can quickly retrieve and view records they previously would have had to request from

a department who would then fax or mail a copy to them - both requiring time and

effort, not to mention more paper. Compliance: As an electric utility company AEC

must comply with a number of government rules and regulations. EDMS provides a

secure and stable environment where mandatory records can be stored for easy access

by auditors or other regulators. These records cannot be altered, and any document

access or action can be tracked through an audit history.Disaster Recovery: Recent

rules from the Rural Utilities Service have forced AEC and other electric cooperatives

to develop a business plan for disasterpreparedness and recovery. As part of

AEC'sbusiness continuity plan, vital records that would be required to resume or

continue operations in the event of a disaster are being stored in EDMS, where they are

secured and backed up daily. Being able to access these vital records through EDMS

means that business operations which depend on these records can continue during or

immediately following a disaster and that information needed to show compliance with

regulations will remain intact and accessible.


AEC continues to add applications to EDMS as users become more familiar

with this new technologyand more comfortable with its storage and retrieval

capabilities. Meanwhile, advances in technology continue to streamline and expand the

features and add functionality to our system. Our next major enhancement will be email

management functionality. This add-on will integrate with EDMS and allow the user to

drag and drop an email into a file folder inside Microsoft Outlook. This action will

store the email inside EDMS with all of its metadata (date, recipients, sender, subject,

etc.) as well as any attachments. Retention rules will be applied to the email record

once it is stored inside EDMS based on the user's folder hierarchy. This new

technology will help us manage email by preserving those that are declared as records

and removing non-record email from the organization's computer system. As we move

forward in the Twenty-First Century, it is clear that technology is playing an

increasingly important role in the way our corporate information is being created, used,

and retained. The challengefor records managers is to keep abreast of both the

technology and the recordkeeping rules and regulation.

GALUTERA DERMATOLOGY CENTERPATIENT RECORD MANAGEMENT SYSTEM

CHAPTER 3

Methodology

Research Design

For the accomplishment of this study, the researchers came to decision

to make used of Agile Methodology in constructing the Galutera Dermatology

Center Information System because it provides opportunities to assess the

direction of a project throughout the development lifecycle. Under the Agile

Software Development, the researchers used of Scrum methodology as our

framework for managing software projects and product or application

development because it is iterative and incremental.

Scrum is an iterative and incremental agile software development

framework for managing software projects and product or application

development. Its focus is on "a flexible, holistic product development strategy

where a development team works as a unit to reach a common goal" as opposed to

a "traditional, sequential approach". Scrum enables the creation of self-organizing

teams by encouraging co-location of all team members, and verbal

communication between all team members and disciplines in the project.


Descripton of Participants

User Description

Doctor/Administrator The main responsibility of this user is to

manage user accounts and view all the user

logs.

This user has the privileges in managing all

the functionalities like: Manage Patient

Information, Manage Diagnosis, Manage

Patient Schedule, Manage Patient Bill,

Manage Clinic Services, and Manage

Clinic Medicines.

Clinic Staff The main responsibility of this user is to

manage almost all the functionalities like:

Manage Patient Information, Manage

Diagnosis, Manage Patient Schedule,

Manage Patient Bill, Manage Clinic

Services, and Manage Clinic Medicines.

This user has also the privelege in

Generating and printing reports.


This user has no privelege in managing the

user accounts and viewing the audit trail.

Patient This user can request for viewing of his/her own

record.

Data Gathering Procedure

This section contains the process that the researchers undergone in following

the phases of Scrum Methodology.

1. Inception Phase

In the inception phase we gathered data by interviewing some of the personnel

on the hospital that is why we came up with the User stories. We, the researchers

conducted direct interview with our client about all the records that they maintain

in the clinic and what would they want that the system would features. We

identify possible data that would be added in the system. We also determine all

the drawbacks that they encountered in the manual processing of records, generate

project goals and objectives, conceptualize and set a possible solutions to those

problems, and compose scopes and limitations.

User Stories


User stories are used with agile software development methodologies as the

basis for defining the functions a business system must provide, and to facilitate

requirements management. (See Appendix B for the User Stories)

2. Elaboration Phase

During the Elaboration phase the project team is expected to capture a healthy

majority of the system requirements. However, the primary goals of Elaboration

are to address known risk factors and to establish and validate the system

architecture. Common processes undertaken in this phase include the creation of

use case diagrams, conceptual diagrams (class diagrams with only basic notation)

and package diagrams (architectural diagrams).

Use Case Diagram

A use case diagram at its simplest is a representation of a user's interaction

with the system and depicting the specifications of a use case. A use case diagram

can portray the different types of users of a system and the various ways that they

interact with the system. This type of diagram is typically used in conjunction with

the textual use case and will often be accompanied by other types of diagrams as

well. The researchers analyzed the data gathered in the phase 1, thus in this phase,

the researchers are going to interpret the data by the use of the use case diagram.

(See Appendix C for Use Case Diagram)

Use Case Analysis

http://en.wikipedia.org/wiki/Use_Case

http://en.wikipedia.org/wiki/Use_Case


A use case analysis is the most common technique used to identify the

requirements of a system (normally associated with software/process design) and

the information used to both define processes used and classes (which are a

collection of actors and processes) which will be used both in the use case

diagram and the overall use case in the development or redesign of a software

system or program. The use case analysis is the foundation upon which the system

will be built. (See Appendix D for use case analysis)

Use Case Specification

A document that defines what a proposed system must be capable of doing

to solve the problems of a defined set of potential users of such a system. The user

requirements specification should be completely independent of any solution-

oriented bias and must use terminology from the problem domain of the users. It

must be understandable by the intended users who must “buy in” to it. Therefore it

is most unlikely to be created using a conventional requirements-analysis method,

since these introduce solution bias, representations, and concepts that are rarely

understood by (and are irrelevant to) the users.

Based on the use case diagram that the researchers created, the researchers

come up with a complete detailed description of the process between the system

and the user. (See Appendix E for Use Case Specification)

http://en.wikipedia.org/wiki/Use_case

http://en.wikipedia.org/wiki/Use_case_diagram

http://en.wikipedia.org/wiki/Use_case_diagram


Sequence Diagram

A sequence diagram is a kind of interaction diagram that shows how

processes operate with one another and in what order. It is a construct of a Message

Sequence Chart. A sequence diagram shows object interactions arranged in time

sequence. It depicts the objects and classes involved in the scenario and the

sequence of messages exchanged between the objects needed to carry out the

functionality of the scenario. Sequence diagrams are typically associated with use

case realizations in the Logical View of the system under development. Sequence

diagrams are sometimes called event diagrams, event scenarios, and timing

diagrams. (See Appendix F for Sequence Diagram)

Activity diagram

Activity diagrams are graphical representations of workflows of stepwise

activities and actions with support for choice, iteration and concurrency. In

the Unified Modeling Language, activity diagrams are intended to model both

computational and organizational processes (i.e. workflows). Activity diagrams

show the overall flow of control. (See Appendix G for Sequence Diagram)

Class Diagram

Class Diagram is a type of static structure diagram that describes the

structure of a system by showing the system's classes, their attributes, operations (or


methods), and the relationships among objects. The class diagram is the main

building block of object oriented modeling. It is used both for general conceptual

modeling of the systematic of the application, and for detailed modeling translating

the models into programming code. Class diagrams can also be used for data

modeling. The classes in a class diagram represent both the main objects,

interactions in the application and the classes to be programmed. (See Appendix H

for Class Diagram)

Development Tools Used

For the proponents to be able to analyze the proposed system, the

proponents have made use of the Unified Modeling Language tool (UML). The

diagrams that were created would serve as a blueprint in the consrtuction phase of the

system in compliance to the methodology being followed by the proponents.

1. Microsoft Visual Studio 2010

2. MySQL Server

3. Astah Community


Appendix A

Appendix A: Input-Process-Output Diagram

INPUT

Gathered Related Variables

Patient Personal Information Basic Information

First Name Last Name Middle Name Date Of Birth Age Address Occupation Contact No. Date of Initial Consult Referred By:

Past Medical History Family Medical History Personal/Social History Review of Systems Dermatologic Examination

Patient Diagnosis Subjective Objective Assessment Plan

Patient Schedule Patient ID Patient Initial Consult Patient Next Session Time

Patient Bill Patient ID Service/Medicine Amount Actual Payment Date

Clinic Services Service Name Service Description

Clinic Medicines Medicine Name Medicine Description Medicine Prescription

User Information First name Last Name Middle Name Gender Position Status

PROCESS

Data Gathering

Direct Interview

Agile/Scrum Methodology

Inception Elaboration Construction Transition

System Tools

UML Microsoft Visual

Studio 2010 Astah MySQL

OUTPUT

GALUTERA DERMATOLOGY

CENTERPATIENT

INFORMATION SYSTEM


Appendix B

Table A: User Stories

User Story

ID

Actor Wants Goals

001 Administrator/Doctor

Clinic Staff

Wants to login

into the system.

So that I can use the

System.

002 Clinic Staff Manage Patient

Personal

Information

So that I can add

Patient Information


Personal

Information

So that I can search

Patient Information.


Personal

Information

So that I can view



Personal

Information

So that I can Edit

Patient Information



PersonalInformati

on

So that I can delete



Diagnosis

So that I can add

Patient Diagnosis.


Diagnosis


Patient Diagnosis.


diagnosis

So that I can view

Patient diagnosis.


Diagnosis

So that I can Edit

Patient Diagnosis.


Diagnosis


patient diagnosis


Schedule

So that I can add

patient Schedule.


Schedule


patient Schedule.


Schedule

So that I can view

patient schedule.


Schedule

So that I can update

patient Schedule.

016 Clinic Staff Manage Patient So that I can delete


Schedule patient Schedule


Bill

So that I can add

patient Bill

appropriately.


Bill


patient Bill.


Bill

So that I can View

Patient Bill.


Bill

So that I can update

patient bill

appropriately.

021 Clinic Staff Manage Services So that I can add

clinic services into

patient record.

022 Clinic Staff Manage Services So that I can search

clinic services.

023 Clinic Staff Manage Services So that I can view

clinic services.

024 Clinic Staff Manage Services So that I can update


patientrecord.

025 Clinic Staff Manage Services So that I can Delete



patient record.

026 Clinic Staff Manage

Medicines

So that I can add

clinic medicines into

patient record.


Medicines

So that I can Search

clinic medicines.


Medicines

So that I can View

clinic Medicines.


Medicines

So that I can edit

clinic medicines into

patient record.


Medicines


Medicines into patient

record

031 Administrator/Doctor Manage User

Account

So that I can add a

user.


Account


User accounts.


Account

So that I can view user

accounts.

034 Administrator/Doctor Manage User So that I can edit a


Account user account.


Account

So that I can delete a

user account.

036 Administrator/Doctor View Audit Trail So that I can monitor

all the activities that

was done in the

system with specific

date and time.

037 Staff Generate Reports So that I can view all

reports.

038 Staff Generate Reports So that I can print

reports.

Appendix C


Appendix C: Use Case Diagram

Appendix D


Appendix D: Use Case Analysis Diagram

Appendix E


Table B: 1.0 Use Case: Login

Use Case Number: 1.0

Use Case Name: Login

Actors: 1. Administrator/Doctor

2. Staff

Summary: The user will login to the system to have a

proper access and control.

Triggers: The Users want to log in into the system.

Preconditions: The user must be authorized and has a

user account to use.

Basic Course of Events: 1. Administrator/Doctor and Staff:

Access GDC-PRMS.

2. GDC-PRMS: Display login form.

3. Administrator/Doctor and Staff: Must

Input

a. Username

b. Password

4. GDC-PRMS: Verify and validates the

username and password.

5. Administrator/Doctor and Staff: Has


successfully login into the system.

Alternative Paths: User can click the cancel button to cancel

logging in.

Exception Paths: 1. If the user did not input the username

and password, the GDC-PRMS will warn

the user immediately and will not be able to

admit into the system yet.

2. If the user inputs wrong username and

password, the GDC-PRMS will warn the

user that it is invalid and will not be able to

admit into the system yet.

Related Business Rules: Only authorized user has the permission in

accessing the system.

Administrator/Doctor

Staff

Post Conditions: The user is already login into the system

and has now proper access.

Author: ANANAYO, Sepulveda, Valerio, Zuzon

Table B: 2.0 Use Case: Manage Patient Personal Information



Use Case Name: Manage Patient Personal Information

Actors: Staff

Summary: The staff manages the patient personal

information by means of searching,

viewing, adding, updating and deleting.

Triggers: The staff needs to search, view, add,

editand delete some patient information.

Preconditions: The staff has successfully logged in and

has a proper access into the system.

Basic Course of Events: 1. Staff: Click on Manage Patient

Personal Information

2. GDC-PRMS: Display the Manage

Patient Personal Information Module.

3. Staff: Select Desired option to execute

Search Patient Personal Information

View Patient Personal Information

Add Patient Personal Information

Update Patient Personal Information

Delete Patient Personal Information

4. GDC-PRMS: Display the UI of the


desired action.

Alternative Paths: The User can click on cancel or exit button

to cancel managing of patient information.

Exception Paths: The user can exit when encountered error.

Related Business Rules: 1. Only authorized user has the

permission in accessing the system.


Staff

2. Only patient of the said clinic are

capable to have a Patient Personal

Information.

Post Conditions: The staff has successfully managed the

Patient Personal Information.



Table B: 2.0.1 Use Case: Add Patient Personal Information

Use Case Number: 2.0.1

Use Case Name: Add Patient Personal Information

Actors: Staff

Summary: The user will input or add Patient Personal

Information into the system.

Triggers: The user needs to add a patient record into

the system.

Preconditions: The User has successfully logged in into

the system and has a proper access in

managing the records.

Basic Course of Events: 1. Staff: Click on Manage Patient Personal

Information

2. GDC-PRMS: Display the Manage Patient

Personal Information Module.

3. Staff: Click on Add Patient Personal

Information.

4. GDC-PRMS: Displays the required

Information to be answer.

Patient Picture


Basic Information

Name

Age

Address

Date of Initial Consult

Birthday

Occupation

Referred By

Contac Number

Patient Reference Number

History of Present Illness

Past Medical History

Family Medical History

Personal/Social History

Review of Systems

Dermatologic Examination

5. Staff: Fill in the required questions and

click on save.

6. GDC-PRMS: Validates entered

information.


7. GDC-PRMS: Successfully Adds patient

Personal information into the system.

Alternative Paths: The staff can click on cancel button to

cancel adding of record.

Exception Paths: 1. If one of the required fields is not filled up

the system will warn the user.

2. If the user inputs invalid data, the system

will warn the user.

Related Business Rules: 1. Only authorized user has the permission in



Staff

2. Only patient of the said clinic are capable

to have a Patient Personal Information.

Post Conditions: The user has successfully added patient

personal information into the system.



Table B: 2.0.2 Use Case: Search Patient Personal Information


Use Case Name: Search Patient Information

Actors: Staff

Summary: The staff will search Patient Personal

Information into the system.

Triggers: 1. The staffs need to search patient Record

for monitoring or verification.

2. The staffs need to search patient record for

viewing, editing and deleting.

Preconditions: The staff has successfully logged in into




Information



3. Staff: Click on Search and type desired

patient name.

4. GDC-PRMS: Display the user’s desired


output.


cancel searching records.

Exception Paths: 1. If the search textbox is empty, the system

will warn the user.

2. If the user input an invalid name, the

system will warn the user.

Related Business Rules: 1. Only authorized user has the permission in



Staff

2. Only patient of the said clinic are capable

to have a Patient Personal Information.

Post Conditions: The staff has successfully search the

patient personal information.



Table B: 2.0.3 Use Case: View Patient Personal Information


Use Case Name: View Patient Personal Information

Actors: Staff

Summary: The User will view the patient personal

information in the system.

Triggers: The user needs to view the patient personal

information in the system for monitoring.

Preconditions: The staff has successfully logged in into the

system and has a proper access in managing

the records.


Information




patient name.


output.


5. Staff: Click on the patient’s name to fully

view the record.


cancel the viewing of records.

Exception Paths: If the user input an invalid name, there will

be no output thus, the system will warn the

user.




Staff



Information.

Post Conditions: The staff has successfully view the patient

personal information.



Table B: 2.0.4 Use Case: Edit Patient Personal Information


Use Case Name: Edit Patient Personal Information

Actors: Staff

Summary: The user will edit or update Patient

Personal Information into the system.

Triggers: The user needs to update a patient

record into the system.

Preconditions: The User has successfully logged in

into the system and has a proper access

in managing the records.





3. Staff: Click on Edit button.

4. GDC-PRMS: Displays Edit Form


patient name.


output.




Information to be edited.

Patient Picture

Basic Information

Name

Age

Address

Date of Initial Consult

Birthday

Occupation

Referred By

Contac Number

Patient Reference Number

History of Present Illness

Past Medical History

Family Medical History

Personal/Social History

Review of Systems

Dermatologic Examination

9. Staff: Edit some information and click

on save button.


information.


11. GDC-PRMS: Updates patient Personal

information into the system.


cancel editing or updating of record.

Exception Paths: 1. If one of the required fields is not filled

up the system will warn the user.

2. If the user inputs invalid data, the





Staff



Information.

Post Conditions: The user has successfully updated

patient personal information into the

system.

Author: ANANAYO, Sepulveda, Valerio,

Zuzon


Table B: 2.0.5 Use Case: Delete Patient Personal Information


Use Case Name: Delete Patient Personal Information

Actors: Staff

Summary: The user will delete Patient Personal

Information from the system.

Triggers: The user needs to delete a patient record

into the system.








3. Staff: Click on Delete button.

4. GDC-PRMS: Displays Delete Form

5. Staff: Click on Search and type

desired patient name.

6. GDC-PRMS: Display the user’s

desired output.



8. GDC-PRMS: Ask the user if it is

sure to delete the patient information.

9. Staff: Click Yes Button.

10. GDC-PRMS: Delete patient

Personal information into the system and

notify the user.


cancel deleting of record.

Exception Paths: If the staff did not select patient’s name

that wants to be deleted, the system

won’t make any necessary actions.




Staff



Information.

Post Conditions: The user has successfully deleted patient

personal information into the system.



Table B: 3.0 Use Case: Manage Patient Diagnosis


Use Case Name: Manage Patient Diagnosis

Actors: Staff

Summary: The staff manages the patient

diagnosis by means of searching,

viewing, adding, editing and deleting.


edit and delete patient diagnosis.


into the system and has a proper

access in managing the records.


Diagnosis.


Patient Diagnosis Module.

3. Staff: Select Desired option to

execute

Search Patient Diagnosis

View Patient Diagnosis

Add Patient Diagnosis


Update Patient Diagnosis

Delete Patient Diagnosis

4. GDC-PRMS: Display the form of

desired output.

Alternative Paths: The User can click on cancel or exit

button to cancel managing patient

Diagnosis.

Exception Paths:




Staff


capable to have a Patient diagnosis.

Post Conditions: The staff has successfully managed

the Patient Diagnosis.


Zuzon


Table B: 3.0.1 Use Case: Add Patient Diagnosis


Use Case Name: Add Patient Diagnosis

Actors: Staff

Summary: The user will input or add Patient

Diagnosis Record into the system.

Triggers: The user needs to add a patient

diagnosis record into the system.





Diagnosis


Patient Module.

3. Staff: Click on Add Patient

Diagnosis.



Subjective

Objective

Assessment

Plan

5. Staff: Fill in the required questions

and click on save.



information.

7. GDC-PRMS: Adds patient diagnosis

into the system.



Exception Paths: 1. If one of the required fields is not

filled up the system will warn the

user.






Staff


capable to have a Patient Diagnosis

Record.

Post Conditions: The user has successfully added

Patient Diagnosis record into the

system.


Zuzon

Table B: 3.0.2 Use Case: Search Patient Diagnosis



Use Case Name: Search Patient Diagnosis

Actors: Staff

Summary: The staff will search Patient

Diagnosis into the system.

Triggers: 1. The staffs need to search patient

Record for monitoring or verification

of diagnosis.

2. The staffs need to search patient

record for viewing and editing of

diagnosis.





Diagnosis







desired output.


cancel searching patient records.

Exception Paths: 1. If the search textbox is empty, the







Staff


capable to have a Patient Diagnosis

Record.


patient Diagnosis.


Zuzon

Table B: 3.0.3 Use Case: View Patient Diagnosis



Use Case Name: View Patient Diagnosis

Actors: Staff

Summary: The User will view the patient

diagnosis record in the system.

Triggers: The user needs to view the patient

diagnosis in the system for monitoring.

Preconditions: The staff has successfully logged in




Diagnosis.






desired output.

5. Staff: Click on the patient’s name

to fully view the record.




Exception Paths: If the user input an invalid name, there

will be no output thus, the system will

warn the user.


permission in accessing and managing

the system.


Staff


capable to have a Patient Diagnosis.

Post Conditions: The staff has successfully view the

patient diagnosis.


Zuzon

Table B: 3.0.4 Use Case Edit Patient Diagnosis



Use Case Name: Edit Patient Diagnosis

Actors: Staff









Diagnosis






desired output.


6. GDC-PRMS: Displays the

required Information to be edited.

Subjective

Objective

Assessment

Plan

7. Staff: Edit some information and

click on save button.



information.

9. GDC-PRMS: Updates patient






user.






Staff




patient diagnosis into the system.


Table B: 3.0.5 Use Case: Delete Patient Diagnosis



Use Case Name: Delete Patient Diagnosis

Actors: Staff

Summary: The user will delete Patient Diagnosis

from the system.


into the system.





Diagnosis


Diagnosis Module.






desired output.



sure to delete the patient diagnosis.




diagnosis into the system and notify the

user.



Exception Paths: If the staff did not select patients’ name

that wants to be deleted, the system

won’t make any actions.




Staff



Post Conditions: The user has successfully deleted patient

diagnosis into the system.


Table B: 4.0 Use Case: Manage Patient Schedule



Use Case Name: Manage Patient Schedule

Actors: Staff

Summary: The staff manages the patient

schedule by means of searching,

viewing, adding, editing and deleting.


edit and delete patient schedule.





Schedule.


Patient Schedule Module.


execute

Search Patient Schedule

View Patient Schedule

Add Patient Schedule

Update Patient Schedule


Delete Patient Schedule


button to cancel managing patient

Schedule.

Exception Paths: The user can click cancel when

encountered errors




Staff


capable to have a schedule record.


the Patient Schedule.


Zuzon

Table B: 4.0.1 Use Case: Add Patient Schedule



Use Case Name: Add Patient Schedule

Actors: Staff

Summary: The user will input or add Patient

Schedule Record into the system.

Triggers: The user needs to add a patient

schedule record into the system.





Schedule


Patient Module.


Schedule.


required Information to be answer.

Patient ID

Date Of Initial Consult

Patient Next Session

Time


and click on save.


information.


7. GDC-PRMS: Adds patient

schedule into the system.





user.






Staff


capable to have a Patient schedule

Record.


Patient Schedule record into the

system.


Zuzon

Table B: 4.0.2 Use Case: Search Patient Schedule



Use Case Name: Search Patient Schedule

Actors: Staff

Summary: The staff will search Patient Schedule

into the system.

Triggers: 1. The staffs need to search patient


of Schedule.

2. The staffs need to search patient

record for viewing and editing of

schedule.





Schedule







desired output.


cancel searching patient records.








Staff


capable to have a Schedule.


patient Schedule.


Zuzon


Table B: 4.0.3 Use Case: View Patient Schedule


Use Case Name: View Patient Schedule

Actors: Staff

Summary: The User will view the patient

Schedule record in the system.


Schedule in the system for monitoring.





Schedule.






desired output.

5. Staff: Click on the patient’s name





Exception Paths: If the user input an invalid name, there

will be no output thus, the system will

warn the user.



the system.


Staff


capable to have a schedule.


patient schedule.


Zuzon

Table B: 4.0.4 Use Case: Edit Patient Schedule



Use Case Name: Edit Patient Schedule

Actors: Staff


Schedule







Schedule






desired output.




Patient ID

Date of Initial consult

Patient Next Session

Time





information.


schedule into the system.




filled up the system will warn the user.






Staff


capable to have a Patient Schedule.


patient schedule into the system.


Zuzon

Table B: 4.0.5 Use Case: Delete Patient Schedule



Use Case Name: Delete Patient Schedule

Actors: Staff

Summary: The user will delete Patient Schedule

from the system.

Triggers: The user needs to delete a patient






Schedule








desired output.




sure to delete the patient schedule.



schedule into the system and notify the

user.



Exception Paths: If the staff did not select patients’

name that wants to be deleted, the

system won’t make any actions.




Staff


capable to have a Patient Schedule.

Post Conditions: The user has successfully deleted

patient schedule into the system.


Zuzon

Table B: 5.0 Use Case: Manage Patient Bill



Use Case Name: Manage Patient Bill

Actors: Staff

Summary: The staff manages the patient Bill by

means of searching, viewing, adding and

updating.

Triggers: The staff needs to search, view, add and

edit patient schedule.





Bill.


Patient Bill Module.


execute

Search Patient Bill

View Patient Bill

Add Patient Bill

Update Patient Bill



button to cancel managing patient Bill.

Exception Paths: The user can cancel managing patient

when encountered an error.




Staff


capable to have a Bill record.


Patient Bill.


Table B: 5.0.1 Use Case: Add Patient Bill



Use Case Name: Add Patient Bill

Actors: Staff

Summary: The user will input or add Patient Bill

Record into the system.

Triggers: The user needs to add a patient bill





Basic Course of Events: 1. Staff: Click on Manage Patient Bill


Bill Module.

3. Staff: Click on Add Patient Bill.



Patient ID

Service/Medicine

Amount

Actual Payment

Date


and click on save.


information.


7. GDC-PRMS: Adds patient bill into

the system.










Staff


capable to have a Patient billRecord.

Post Conditions: The user has successfully added Patient

bill record into the system.


Zuzon

Table B: 5.0.2 Use Case: Search Patient Bill



Use Case Name: Search Patient Bill

Actors: Staff

Summary: The staff will search Patient bill into

the system.

Triggers: The staff needs to search patient


of Bill.




Basic Course of Events: 1. Staff: Click on Manage Patient Bill






desired output.


cancel searching patient Bill.









Staff


capable to have a Bill record.


patient Bill.


Zuzon

Table B: 5.0.3 Use Case: View Patient Bill



Use Case Name: View Patient Bill

Actors: Staff

Summary: The User will view the patient Bill

record in the system.


Bill in the system for monitoring and

verification.




Basic Course of Events: 1. Staff: Click on Manage Patient Bill.






desired output.

5. Staff: Click on the patient’s name to

fully view the record.




Exception Paths: If the user input an invalid name,

there will be no output thus, the



permission in accessing and

managing the system.


Staff


capable to have a bill record.


patient Bill and verified it.


Zuzon

Table B: 5.0.4 Use Case: Edit Patient Bill



Use Case Name: Edit Patient Bill

Actors: Staff


Bill record







Bill






desired output.




Patient ID


Service/Medicine

Amount

Actual Payment

Date




information.

9. GDC-PRMS: Updates patient bill

into the system.





user.







Staff


capable to have a Patient Bill record.


patient Bill into the system.


Zuzon

Table B: 6.0 Use Case: Manage Services



Use Case Name: Manage Services

Actors: Staff

Summary: The staff manages the Services by

means of searching, viewing, adding,

updating and deleting.


edit and delete Service.




Basic Course of Events: 1. Staff: Click on Manage Services.


Services Module.


execute

Search Services

View Services

Add Services

Update Services

Delete Services



chosen action.


button to cancel managing services

records.

Exception Paths: User can cancel when encountered

errors.



the system.


Staff


Services.


Zuzon

Table B: 6.0.1 Use Case: Add Services



Use Case Name: Add Services

Actors: Staff

Summary: The user will input or add services


Triggers: The user needs to add a service record

into the system.




Basic Course of Events: 1. Staff: Click on Manage Services

Record


Service Module.

3. Staff: Click on Add Services.



Service Name

Service Description


and click on save.



information.

7. GDC-PRMS: Adds patient services

into the system.





user.



Related Business Rules: Only authorized user has the



Staff


services record into the system.


Zuzon

Table B: 6.0.2 Use Case: Search Services



Use Case Name: Search Services

Actors: Staff

Summary: The staff will search Services into the

system.

Triggers: The staff needs to search patient


of services.






Services Module.


service.


desired output.


cancel searching services.









Staff

Post Conditions: The staff has successfully searched the

services.


Zuzon

Table B: 6.0.3 Use Case: View Services



Use Case Name: View Services

Actors: Staff

Summary: The User will view the services


Triggers: The user needs to view the services

in the system for monitoring and

verification.

Preconditions: The staff has successfully logged

in into the system and has a proper


Basic Course of Events: 1. Staff: Click on Manage

services record.

2. GDC-PRMS: Display the

Manage services Module.

3. Staff: Click on Search and

type desired services.


user’s desired output.

5. Staff: Click on the service title


Alternative Paths: The staff can click on cancel


button to cancel the viewing of

services.

Exception Paths: If the user input an invalid service

title, there will be no output thus,






Staff


services and verified it.


Zuzon

Table B: 6.0.4 Use Case: Edit Services



Use Case Name: Edit Services

Actors: Staff

Summary: The user will edit or update Services

record

Triggers: The user needs to update services record

into the system.





record


Services Module.


desired services title.


desired output.




Service Name

Service Description





information.

9. GDC-PRMS: Successfully

updated service record.







Related Business Rules: Only authorized user has the permission

in accessing the system.


Staff


Service record into the system.


Zuzon

Table B: 6.0.5 Use Case: Delete Services



Use Case Name: Delete Service

Actors: Staff

Summary: The user will delete Service from the

system.


into the system.




Basic Course of Events: 1. Staff: Click on Manage services


Patient Service Module.






desired output.



sure to delete the patient service.


10. GDC-PRMS: Delete service into

the system and notify the user.




Exception Paths: If the staff did not select service that

wants to be deleted, the system won’t

make any actions.




Staff


capable to have a Service Record.

Post Conditions: The user has successfully deleted service

into the system.


Table B: 7.0 Use Case: Manage Medicine



Use Case Name: Manage Medicines

Actors: Staff

Summary: The staff manages the Medicines by

means of searching, viewing, adding,

updating and deleting.

Triggers: The staff needs to search, view, add, edit

and delete Medicines.




Basic Course of Events: 1. Staff: Click on Manage Medicines.


Medicines Module.


execute

Search Medicine

View Medicine

Add Medicine

Update Medicine

Delete Medicines

4. GDC-PRMS: Displays the UI of the


chosen action.


button to cancel managing Medicine

records.

Exception Paths: The user can cancel when encountered

errors.

Related Business Rules: Only authorized user has the permission

in accessing the system.


Staff


Medicine Records.


Table B: 7.0.1 Use Case: Add Medicine




Use Case Name: Add Medicine Record

Actors: Staff

Summary: The user will input or add Medicine


Triggers: The user needs to add the

prescribed medicine bill record into

the patient record system.





Medicines


Manage Medicine Module.


Medicine.

4. GDC-PRMS: Display Add

patient form

5. Staff: Search for Patient name

and click.



required Information to be answer.

Medicine Name

Medicine Description

Medicine Prescription

7. Staff: Fill in the required

questions and click on save.

8. GDC-PRMS: Validates

entered information.

9. GDC-PRMS: Successfully

Adds patient medicine into the

system.

Alternative Paths: The staff can click on cancel button

to cancel adding of record.

Exception Paths: 1. If one of the required fields is

not filled up the system will warn

the user.

2. If the user inputs invalid data,






Staff


Patient medicine record into the

system.


Zuzon

Table B: 7.0.2 Use Case: Search Medicine



Use Case Name: Search Patient Medicine

Actors: Staff

Summary: The staff will search Medicine into

the system.

Triggers: The staff needs to search Medicine

for monitoring or verification.





Medicine Record


Manage Medicine Record Module.


type Medicine name.




to cancel searching Medicine

record.


Exception Paths: 1. If the search textbox is empty,


2. If the user input did not input

medicine name, the system will

warn the user.




Staff

Post Conditions: The staff has successfully search

the medicine record.


Zuzon

Table B: 7.0.3 Use Case: View Medicine



Use Case Name: View Medicine Record

Actors: Staff

Summary: The User will view the Medicine


Triggers: The user needs to view the

medicine record in the system for

monitoring and verification.

Preconditions: The staff has successfully logged



Basic Course of Events: 1. Staff: Click on Manage medicines

record.


Medicines Module.


desired medicine’s name.


desired output.

5. Staff: Click on the medicine’s

name to fully view the record and

for further actions.



button to cancel the viewing of

medicines.

Exception Paths: If the user did not input medicine

name, there will be no output thus,






Staff


Medicine record and verified it.


Zuzon

Table B: 7.0.4 Use Case: Edit Medicine



Use Case Name: Edit Medicine Record

Actors: Staff

Summary: The user will edit or update

Patient Medicine record


medicine record into the system.

Preconditions: The User has successfully logged

in into the system and has a

proper access in managing the

records.


Patient Medicine


Manage Medicine record Module.

3. Staff: Click on Edit Medicine

record button.

4. GDC-PRMS: Display Edit

Form.

5. Staff: Search Patient name

and click.




Medicine Name

Medicine Description

Medicine Prescription

7. Staff: Edit some information

and click on save button.

8. GDC-PRMS: Validates

entered information.


medicine record into the system.


button to cancel editing or

updating of record.



user.




permission in accessing the


system.


Staff


capable to have a Patient

medicine record.


patient medicine record into the

system.


Zuzon

Table B: 7.0.5 Use Case: Delete Medicine



Use Case Name: Delete Medicine

Actors: Staff

Summary: The user will delete Medicine

from the system.

Triggers: The user needs to delete a patient


Preconditions: The User has successfully logged

in into the system and has a

proper access in managing the

records.


Patient Medicine


Manage Patient Medicine.


4. GDC-PRMS: Displays Delete

Form


type desired patient name.





8. GDC-PRMS: Ask the user if

it is sure to delete the patient

medicine.


10. GDC-PRMS: Delete medicine

into the system and notify the

user.


button to cancel deleting of

record.

Exception Paths: If the staff did not select medicine

that wants to be deleted, the

system won’t make any actions.


permission in accessing the

system.


Staff

2. Only patient of the said clinic

are capable to have a medicine


Record.

Post Conditions: The user has successfully deleted

medicine into the system.


Zuzon

Table B: 8.0 Use Case: Manage User Account


Use Case Number 8.0

Use case Name Manage User Accounts

Actor: Administrator/Doctor

Summary: The administrator must manage the

user accounts by adding,

searching/viewing, updating, and

deleting.

Triggers: The Administrator needs to manage

User accounts because there are some

accounts that need to search, view, add,

update and delete.

Preconditions: The administrator has already logged in

into the system.

Basic Course of Events: 1. Administrator/Doctor: Log in

GDC-PRMS: Display GDC-PRMS UI

2. Administrator: Click Manage User

Account

GDC-PRMS: Display Manage User

Accounts Form

3. Administrator: Choose what action to

be done:

Add User Account

Search User Account

View User Account


Edit User Account

Delete User Account


chosen action.

Alternative Paths: The administrator can click cancel to

cancel managing user accounts.

Exception Paths: If the administrator did not click the

right button the system will display an

error message for the admin.

Related Business rules: 1. The Administrator must have valid

User Account.

2. The Administrator must be authorized

personnel.

Post Conditions: The administrator has already

successfully managed the user

accounts.

Author ANANAYO, Sepulveda, Valerio,

Zuzon

Table B: 8.0.1 Use Case: Add User Account


Use Case Number 8.0.1

Use case Name Add User Account


Summary: The administrator needs to add User

Account into the system.

Triggers: Some of the staffs were required to

have a user account to have access on

the system.


into the system and currently managing

the accounts.

Basic Course of Events: 1. Administrator: Log in

2. GDC-PRMS: Display GDC-PRMS

UI

3. Administrator/Doctor: Click

Manage User Account

4. GDC-PRMS: Display Manage User

Accounts Form

5. Administrator/Doctor: Click Add

User Account

6. GDC-PRMS: Display the Add User


Accounts Form

First name

Last Name

Middle Name

Username

Password

Retype Password

7. Administrator/Doctor: Fill in the

add User Account Form

8. Administrator/Doctor: Click Save

Button

9. GDC-PRMS: Notify the user that

the User Accounts was saved

Alternative Paths: The administrator can click cancel

button to cancel adding user account.

Exception Paths: If the Administrator did not enter data

on a required field, system will alert the

Staff that there has been error and it

will not save.

Post Conditions: The administrator has successfully

added User Accounts into the system.



User Account.

2. The Administrator must be

authorized personnel.


Zuzon

Table B: 8.0.2 Use Case: Search User Account



Use case Name Search User Account


Summary: The administrator will search the user

accounts.

Triggers: The Administrator needs to search the

user accounts to view.

Preconditions: The administrator has already logged


access in managing account.

Basic Course of Events: Administrator/Doctor: Log in


Administrator/Doctor: Click Manage

User Account

GDC-PRMS: Display Manage User

Accounts Form

Administrator/Doctor: Click on Search

Button and type Desired user name

and enter.

GDC-PRMS: Find user name on the


database.


cancel the Searching of user accounts.

Exception Paths: If the administrator did not click the

right button the system will display an

error message for the admin.


User Account.

2. The Administrator must be authorized

personnel.


successfully searched the user

accounts.


Zuzon

Table B: 8.0.3 Use Case: View User Account



Use case Name View User Account


Summary: The administrator will view the user

accounts.

Triggers: The Administrator needs to view the

user accounts to monitor and verify

accounts.



in managing account.


2. GDC-PRMS: Display GDC-PRMS

UI


Manage User Account


Accounts Form

5. Administrator/Doctor: Click on

Search Button and type desired user

name and enter.

6. GDC-PRMS: Find user name on

the database.

7. GDC-PRMS: Show the desired

output.


8. Administrator/Doctor: Click on the

patient Name to fully view the user

account.


cancel the viewing of user accounts.

Exception Paths: 1. If the administrator did not click

the right button the system will display

an error message for the admin.

2. If the admin input a wrong name,

the system won’t display the output.


User Account.

2. The Administrator must be



successfully viewed the user accounts.


Zuzon

Table B: 8.0.4 Use Case: Edit User Account



Use case Name Edit User Accounts

Actor: Administrator

Summary: The administrator will update the user

accounts in the system.

Triggers: The administrator need to update the user

accounts because some of the staff can’t

log in.


into the system and has the full control in

managing the user accounts.


GDC-PRMS: Display PRMS UI


Manage User Accounts


Accounts Form

4. Administrator/Doctor: Search &

select User Accounts

5. GDC-PRMS: Display User

Accounts

First name

Last Name

Middle Name

Username


Password

Retype Password

6. Administrator/Doctor: Edit User

Account.

7. Administrator/Doctor: Click save

Button.

8. GDC-PRMS: Notify User Account

was successfully Updated

Alternative Paths: The administrator can also click cancel to

cancel updating user account.

Exception Paths: If the Administrator did not properly

execute the necessary action, the system

won’t give expected output and won’t

save the edited information.

Post Conditions: The System Administrator successfully

updated some user accounts.

Related Business rules: 1. The administrator must have valid

User Account.

2. The administrator must be


Author ANANAYO, Sepulveda, Valerio, Zuzon

Table B: 8.0.5 Use Case: Delete User Account



Use case Name Delete User Account

Actor: Administrator

Summary: The administrator will delete the user

account of a certain staff.

Triggers: There are user accounts of staff that is

needed to be deleted because it is no

longer needed.


into the system and currently managing

the accounts.



2. Administrator/Doctor: Click Manage

User Account


Accounts Form

4. Administrator/Doctor: Click on Delete

User Account

5. GDC-PRMS: Display delete user

account form

6. Administrator/Doctor: Search & Select

User Account

7. GDC-PRMS: Display the User Account

8. Administrator/Doctor: Click Delete


9. GDC-PRMS: Notify that User if

Account was successfully deleted

Alternative Paths: The administrator can click on cancel to

cancel the deleting of user accounts.

Exception Paths: If the administrator is not sure to delete

the user account, he must click button

cancel.

Post Conditions: The Administrator successfully deleted

the user account.

Related Business rules: 1. The administrator must have valid

User Account.

2. The administrator must be


3. The administrator must have been

required by the head to manipulate the

user accounts.


Zuzon

Table B: 8.0.6 Use Case: View Audit Trail



Use Case Name: View Audit Trail

Actors: Administrator

Summary: The User will view the audit trail in

the system.

Triggers: The user needs to view the audit trail

in the system for monitoring and

verification.




Basic Course of Events: 1. Staff: Click on Manage User

Account.


User Account.

3. Staff: Click on View Audit trail.


Audit Trail.


to cancel the viewing of audit trail.

Exception Paths: Only the administrator/doctor is


authorized to view the audit trail.





Staff

Post Conditions: The staff has successfully viewed the

audit trail.


Zuzon

Appendix F


Appendix F: Use Case 1.0 Login


Appendix F Use Case: 2.0.1 Add Patient Information


Appendix F Use Case: 2.0.2 Search Patient Information


Appendix F Use Case: 2.0.3 View Patient Information

Appendix F Use Case: 2.0.4 Edit Patient Information


Appendix F Use Case: 2.0.5 Delete Patient Information


Appendix F Use Case: 3.0.1 Add Patient Diagnosis


Appendix F Use Case: 3.0.2 Search Patient Diagnosis


Appendix F Use Case: 3.0.3 View Patient Diagnosis


Appendix F Use Case: 3.0.4 Edit Patient Diagnosis


Appendix F Use Case: 3.0.5 Delete Patient Diagnosis


Appendix E Use Case: 4.0.1 Add Patient Schedule


Appendix E Use Case: 4.0.2 Search Patient Schedule


Appendix E Use Case: 4.0.3 View Patient Schedule


Appendix F Use Case: 4.0.4 Edit Patient Schedule


Appendix F Use Case: 4.0.5 Delete Patient Schedule


Appendix F Use Case: 5.0.1 Add Patient Bill


Appendix F Use Case: 5.0.2 Search Patient Bill


Appendix F Use Case: 5.0.3 View Patient Bill


Appendix F Use Case: 5.0.4 Edit Patient Bill


Appendix F Use Case: 6.0.1 Add Services


Appendix F Use Case: 6.0.2Search Services


Appendix F Use Case: 6.0.3 View Services


Appendix F Use Case: 6.0.4 Edit Services


Appendix F Use Case: 6.0.5 Delete Services


Appendix F Use Case: 7.0.1 Add Medicines


Appendix F Use Case: 6.0.2 SearchMedicines


Appendix F Use Case: 7.0.3View Medicines


Appendix F Use Case: 7.0.4 Edit Medicines


Appendix F Use Case: 7.0.5Delete Medicines


Appendix F Use Case: 8.0.1Add User Account


Appendix F Use Case: 8.0.2Search User Account


Appendix F Use Case: 8.0.3View User Account


Appendix F Use Case: 8.0.4Edit User Account


Appendix F Use Case: 8.0.5Delete User Account


Appendix F Use Case: 8.0.6View Audit Trail


Appendix F Use Case: 9.0.1 View Reports


Appendix F Use Case: 9.0.2 Print Reports


Appendix G

Appendix G Use Case: 1.0Login


Appendix G Use Case: 2.0 .Manage Patient Information


Appendix G Use Case: 2.0.1Add Patient Information


Appendix G Use Case: 2.0.2 Search Patient Information


Appendix G Use Case: 2.0.3View Patient Information


Appendix G Use Case: 2.0.4EditPatient Information


Appendix G Use Case: 2.0.5Delete Patient Information


Appendix G Use Case: 3.0Manage Patient Diagnosis


Appendix G Use Case: 3.0.1Add Patient Diagnosis


Appendix G Use Case: 3.0.2Search Patient Diagnosis


Appendix G Use Case: 3.0.3 View Patient Diagnosis


Appendix G Use Case: 3.0.4 Edit Patient Diagnosis


Appendix G Use Case: 3.0.5 Delete Patient Diagnosis


Appendix G Use Case: 4.0Manage Patient Schedule


Appendix G Use Case: 4.0.1 Add Patient Schedule


Appendix G Use Case: 4.0.2Search Patient Schedule


Appendix G Use Case: 4.0.3 View Patient Schedule


Appendix G Use Case: 4.0.4 Edit Patient Schedule


Appendix G Use Case: 4.0.5 View Patient Schedule


Appendix G Use Case: 5.0 Manage Patient Bill


Appendix G Use Case: 5.0.1 Add Patient Bill


Appendix G Use Case: 5.0.2 Search Patient Bill


Appendix G Use Case: 5.0.3 View Patient Bill


Appendix G Use Case: 5.0.4 Edit Patient Bill


Appendix G Use Case: 6.0 Manage Services


Appendix G Use Case: 6.0.1 Add Service


Appendix G Use Case: 6.0.2 Search Service


Appendix G Use Case: 6.0.3 View Service


Appendix G Use Case: 6.0.4 Edit Service


Appendix G Use Case: 6.0.5 Delete Service


Appendix G Use Case: 7.0 Manage Medicine


Appendix G Use Case: 7.0.1 Add Medicine


Appendix G Use Case: 7.0.2 Search Medicine


Appendix G Use Case: 7.0.3 View Medicine


Appendix G Use Case: 7.0.4 Edit Medicine


Appendix G Use Case: 7.0.5 Delete Medicine


Appendix G Use Case: 8.0 Manage User Account


Appendix G Use Case: 8.0.1 Add User Account


Appendix G Use Case: 8.0.2 Search User Account


Appendix G Use Case: 8.0.3 View User Account


Appendix G Use Case: 80.4 Edit User Account


Appendix G Use Case: 8.0.5 Delete User Account


Appendix G Use Case: 8.0.6 View Audit Trail


Appendix G Use Case: 9.0.1 View Reports


Appendix G Use Case: 9.0.2 Print Reports


Appendix H






Documents

Galutera Clinic