Specialty Group

Document System Requirements Specification (SRS)

Content

1. Introduction

1.1. Purpose

1.2. Major Stakeholders

1.3 Overview of the system

1.4 Use Case Diagram

2. Functional requirements (FRs)

2.1. Primary functional requirements

2.2. Stakeholders

2.3. Use Cases

2.4. Detailed Use Cases

1.0 User registration

1.0.1 Register CU users

1.1.1 Validate CU users

1.2.1 CU Offer services

2.0 Control Patients

2.1.1 Register CU previous patient data

2.1.2 Registration CU patient's personal information

 CU 2.1.3 Registration Patient History

2.1.4 Medical consultation CU 1st time

2.1.5 History consultations CU

CU patient appointment Schedule 2.2

2.2.1 Control CU patient appointments

2.3.1 Checking CU subsequent patients

CU 2.3.2 Inserting images pictures

CU 2.3.3Emitir recipes

2.3.4 Request biopsies CU

2.3.5 Control biopsies CU

3.0 Control box

3.1.1 Control box CU

3.1.2 CU Court Case

3. Nonfunctional requirements (NFRs)

3.1. Performance

3.2. Scalability

3.3. Availability

3.4. Reliability and Safety

3.5. Usability

4. Glossary
1. Introduction
1.1. Purpose

The development of this document shows the functional and nonfunctional requirements
of project information system to monitor the daily operations of a medical clinic
dermatology CEEPI, ie, this document shows a detailed view of the major players or users
of the system, design use case diagram to show how the system will work, and finally the
detailed documentation of the cases to contain a general description of the use case, a
detailed description of each use case containing: use case name, purpose, preconditions,
description of the main flow of the use case and an exception section of each use case.

The development of this proposal will seek to give response to the needs of the clinical
information required from web development and can be accessed by stakeholders from
internet consulting information and from intranet to record daily operations clinic. That is,
schedule a consultation from a patient to record data in the medical record, and
proposing controls for inventory management, generating online inquiries and statistical
control of clinic patients.

The restrictions of this project are related to the lack of software and licensing to be used
in architecture for system development.Besides team has no servers.

The development of this project is related to the process of patient management, patient
care, cash control, inventory control and generation of statistics derived from the
information generated by patient care.

1.2 Major Stakeholders

Receptionist: Responsible for performing the main functions of patient care at the window,
record primary data of patients and schedule consultations, for charges for services
dermatological consultations and medical procedures and their respective cut daily cash
finally register and control the solitudes processes, sending and receiving biopsies of
patients of the clinic.

Nurse: Responsible for recording personal data of patients when they are first admitted to
query and ask the store assistant clinical resources and materials to be used in doctors'
offices.

Doctor on duty: Performs receiving patient clinical data, such as, medical history,
consultation 1st time, new query in which are recorded the symptoms, diagnoses and
photographs of injuries and laboratory results, which are recorded in the patient's clinical
history and finally issuing prescriptions.

Warehouse Assistant: Responsible for performing receiving medical supplies for patient
care and office areas of the clinic, meet the request and record the outputs of the store and
perform control vendor payments in the blog.

Clinic Manager: Responsible for managing and monitoring clinical processes and issue query
and statistical reports of the operations for decision making.

CEO of the clinic: Performs the role of doctors in turn and run the clinic

Project Managers: Will be responsible for conducting the survey process, proposal,
validation, approval and documentation requirements, and to determine the quality,
robustness, scalability and security of the information system.In addition to planning for the
determination of human and material resources, development time and product cost
estimation.

Graphic designers of interfaces: Will be responsible for designing system interfaces which
must be integrated from the user identification process, main menu navigation system
interfaces data check, popups, preconditions, exceptions, design consultations screen
design printed output reports, web service design: as mail, web maps, facebook, respecting
the style guide development standard used in addition to the colors, logos and images
institutions of the organization.

Designers databases and system architecture: Once validated and documented

requirements and interfaces will be responsible for designing the database entity-
relationship, relational, stored procedures, validation and data dictionary definition.

The definition of the architecture must be organized in layers, robust, secure, reliable,
scalable and fast deserrados oriented programming for web environments, for the
development of this proposal will use open source technology oriented Web processes.

Flash Programmers: Will be responsible for coding each iteration grouped in modules of the
system.This coding is done in pairs, the customer is always available, if possible face to face.
The idea is that a part of the development team and is present in all stages of the XP
methodology, participates in the description of user stories to help administrators and
developers requirements, participates in choosing the plan system releases, testing or
delivery of small releases, and functionality tests. The idea is to use the customer's time for
these tasks rather than to create a very detailed specification of requirements.
 Tester: Will be responsible for frequent acceptance testing, publishing the results
thereof.These tests are generated from user stories chosen for iteration, in which the client
verifies the correct operation of what is being tested. When you pass the acceptance test, it
is considered that the corresponding user story is complete.

1.3 Description of the problem

The patient monitoring system and inventory is a system that allows different users to
register and schedule appointments, record diagnoses and consult medical records of
patients.Besides being able to control the different inventories available to the clinical and
generate statistics located by the type and location of pathologies.They want the patient
monitoring system is accessible through the Internet (World Wide Web).

The system presented in a menu screen composed of modules Patients << >>, << >>
Schedule appointment, medical consultation << >>, << >> Inventories and Statistics >> <<
module, to access and use the system and inventory control patients. Is given by the
insertion of a previously specified username and password previously assigned by the
system administrator and should be validated.

Once registered the user and validated after registration and user password, you can select
the following activities:
• Register and heredity overview of patients who request consultations for the 1st
time.
• Schedule appointments and control of patient visits and subsequent 1st time.
• Register and get medical diagnostics medical records of patients
• Registration and Control of biopsies
• Control of cash payments and card patients

The consultation of the patient's previous data will be done through a filter which will locate
the previous data from patients who have been registered, if the patient is not found, it will
be added, indicating whether the patient is to query for CEEPI or CEEPI Plus.
If the patient is 1st time was recorded additional personal information and medical history,
once registered patients 1st time and subsequent will be served by the rascal and registered
medical diagnosis.

The consultation of medical records will be made by physicians, the consular post may be
filtered by the patient's name and date of consultation.

The consultation on the agenda will be selecting the clinic or CEEPI CEEPI Plus, the doctor
and the date available, consultations were recorded in periods of 20 minutes, providing the
opportunity to insert patient checkups or without an appointment.If the agenda was
complemented saturated, revisions and appointments without prior request is inserted
between scheduled visits.

To control selects the clinical consultation or CEEPI CEEPI Plus will filter the doctor and the
appointment date and the name of the patient showing the scheduled appointment time,
also the system will be able to record the arrival time and exit the patient.The time to query
input by the user will be logged.

If subsequent patients the physician selects the patient's name, record the data of
symptoms and diagnosis.Storing your data for history logging, in addition to storing
photographs of injuries of patients. The doctor may issue prescriptions printed after
consulting the patient.

To control box will filter the patient's name and added the concepts of charge for
consultation or procedure requested, this control allows you to record the payment in
different types of print and issue the receipt of the query. The system will allow daily cash
cuts, in addition to recording expenditures and other cash income.

To carry out the control of these biopsies will be requested by the physician and recorded
by the clerk in the system, the system will filter the patient's name and other data
requested, delivery control, the system will select the date and show the report delivery
process biopsies.
1.4 Use case diagram of the system

Specific use cases 1st increase patient monitoring system

2. Functional requirements (FRs)

2.1. Primary functional requirements
FRs ID FRs Category.
RF1 The system should allow receptionists record and track medical A
 appointments and procedures for patients and control specialist studies
requested.
The system should allow recording of personal information and medical
history, diagnosis and treatment of the patient, and must have a
RF2 A
repository to store photographs of injuries and specialized studies of
patients requested by physicians.
The system should allow recording payments consultations and other
RF3 A
medical services and control daily operations cash.
The system will display onscreen consultations and generates printed
reports of registered patients (1. Names and addresses, telephone
number, 2. List of names and emails), daily schedule of appointments,
consultations control (Assistance Percentage citations by query type),
RF4 M
records or medical records, issuing prescriptions, issuing payment
receipts or note cut cash daily (number of transactions per day and
month and income) and emission control biopsies (number of biopsies
per month).
The system should have an electronic repository storage as evidence:
RF5 photographs, specialized studies, medical records and diagnoses of B
patients, reliable and user-friendly.

2.2. Stakeholders
Action taker: Administrator
Use Cases Validate User, User registration, provide services, information consulting,
produce reports
Type Primary
Description It kind of actor is the person with the ability to add users and assign roles to
users authorized to use the system.

Action taker: Receptionist

Use Cases Validate User Data Register 1st time patient, appointment calendar, control
box, control biopsies, agenda control, look up information, produce reports.
Type Primary
Description It kind of actor is the person with the ability to record data before the patient
who come to your 1st consultation, appointment book you request by
patients, control charges to patients, prompt control biopsies, control the
agenda of patients when they come to clinic in the system.
Action taker: Nurse
Use Cases Validate User Registration 1st time patients
Type Primary
Description It kind of actor is the person with the ability to record clinical data of patients
who come to medical consultation for the first time in the system.
Action taker: - Doctor
Use Cases Validate User Registration subsequent patients, medical, diagnostic logging,
control of medical records and consult information
Type Primary
Description It kind of actor is the person with the ability to record patient information and
query information subsequent clinic patients in the system

Action taker: Users BD

Use Cases Validate User and User Register
Type Secondary
Description It kind of actor will have the functionality to store information about users of
the system and accesses control.

Action taker: Patient BD

Use Cases Offering services, consulting information, produce reports, record data 1st
time patient, appointment calendar, control biopsies, agenda control, patient
registration 1st time, register patients subsequent medical consultation,
diagnostic logging, control histories .
Type Secondary
Description It kind of actor will have the functionality to store and safeguard information
regarding the operations and control patients.

Action taker: Cash BD

Use Cases Control cash and cash cut
Type Secondary
Description It kind of actor will have the functionality to store and safeguard information
relating to daily cash transactions.

Use Cases 2.3

Use
Use Case Name Priority Description
Case ID

1.0 User registration

1.0.1 CU Register users B This use case allows registering new users to
give them access to the system, you assign a
user, password and confirm password
1.1.1 CU Validate users B This use case to validate the data of registered
users as: user name and password, enable the
 correct validation Clinic staff provide access to
the system.
1.2.1 CU Offer services B This use case allows users to select from the
main screen of the system options
2.0 Control Patients
2.1.1 CU Previous patient B This use case allows recording patient data
record data when it goes or request a consultation at the
clinic for the first time. The receptionist will
check first whether the patient is registered,
from the subflow search patient.
2.1.2 CU Record patient's B Once registered the previous patient data. This
personal information use case allows recording general or personal
data of the patient, this data will be requested
and registered nurses.
2.1.3 CU Registration Patient B This use case allows the registration of clinical
History and laboratory data. These data will be
requested by the physician consult
2.1.4 CU Clinical information of B In addition to registration of clinical data of the
patients 1st time patient, the doctor asked the patient
information that is attended by 1st time at the
clinic.
2.1.5 CU History consultations M This use case to store the queries of patients by
date of consultation itself to be consulted to
determine the patient's progress
CU 02.02 Schedule patient A This use case will schedule appointments
appointment requested by patients and schedule
appointments on the same day or at the time
that the patient's request, and schedule allow
spaces between appointments for patients
seeking a medical or little time consuming
procedure care
2.2.1 CU Control of patient A Once scheduled appointment, this use case will
appointments control appointments for the day, this use case
will record the time of arrival of the patient
during the day, and counted daily appointments
by type of access required.
2.3.1 CU Consultation M This use case will record information from a
subsequent patients doctor, to store diagnostic information from
patients or subsequent 1st time
2.3.2 CU Inserting images M After consulting the patient the doctor will
pictures attach photographs of injuries and results of
studies requested, which shall be available to
meet the patient's progress.
2.3.3 CU Issuing recipes M This use case will generate the patient's
prescription, which include drugs and the
categories to which the drug belongs.
 2.3.4 CU Application of biopsies B This use case allows the application register
receptionist biopsy studies ordered by
clinicians.
2.3.5 CU Control biopsies A This use case allows to control biopsies, related
to the delivery dates when they are sent to the
laboratory and the dates when they are
delivered to patients
3.0 Control box
3.1.1 CU Control box M This use case will record the daily operations of
collecting queries also allow other operations
recorded revenue, cash outflows, issue the note
or bill for medical services provided.
3.1.2 CU Court Case A This use case allows the control box cut daily,
detailing income in cash payments, payments
with credit or debit cards and the relationship
of daily expenses.

2.4. Detailed Use Cases

1.0 Register users
To support the description of use cases showing the various screens designed, starting with the
initial screen.Since the use of the system requirement is that all users will be registered by the
administrator, the main screen should give the option to validate an existing user registration and
as shown in Figure 1

Figure 1.0 Display of user authentication P-1

CU 1.1.1 Validate User

The Validate User use case is linked to the main screen (P-1) and is called after cases User Register,
Calendar appointment and look up information, as shown in the diagram of the system.

Use Case Validate user

Stakeholders Users, patients Database
Type Inclusion
Purpose Validate the user is already registered for the use of patient monitoring
system and inventories
Abstract This use case is initiated by the user. Validates the user by user name
and password with its own user registration in order to use the system.
Preconditions Are required to have previously run for creating User Register: User
Registration
Main flow 1. It presents the user with the main screen (P-1). The user can
select from the following options: "OK" and "Cancel".
2.If the selected activity is "OK", it validates the user record using
the user name and password entered by the user in the main screen
(P-1).
3. If the user is not logged in the administrator create users execute
subflow create system user registry (S-1).
4. Once validated the user continues to use case Provide Services.
5. If the selected activity is "Cancel" will exit the system.
Subflows None
Exceptions E-1 there was no validation: User / password not validated correctly.
Administrator is requested to register the user. After three attempts
they leave the system.

CU 1.2.1 Provide Services

If we refer to the use case diagram of the system generally see that there are 4 basic use cases
that the user can instantiate, User Registration, patient monitoring, inventory control and retrieve
information.The use case or menu offer is included in these four basic use cases to delegate
appropriately to them according to user-selected options. Also included is the use case Validate
User after user validation.

Use Case Providing medical services

Stakeholders Users (Usuarios)
Type Inclusion
Purpose Offering various services to a user and registered for using the system
and inventory control patients.
Abstract This use case is initiated by the user. Elections have to use the various
system options and inventory control patients.
Preconditions Are required to have the correct user validation.
Main flow 1. The user is presented Display Services (P-2). The user can select
from the following: "Patient", "Appointment Log", "medical ulta
 Cons", "Inventory", "Statistics" and "exit.
2.If the selected activity is "Check Information", continue with the
use case view information, subflow Consult (S-1).
3. If the selected activity is "Patient", continue with the use case
Make Patients, subflow Add Patient (S-2).
4. If the selected activity is "Registration Appointments," continues
with the use case Register of appointments, schedule appointments
subflow (S-3).
5. If the selected activity is "Medical consultation", continue with
the use case medical consultation, subflow New Query (S-4).
6. If the selected activity is "Inventory Control" is followed by the
use case of inventory control, Check underflow and outputs (S-5).
7. If the selected activity is "Exit" will exit the system.
Subflows None
Exceptions None

For this reason the following system screen allowing the user must select appropriate options, as
shown in Figure 2.

Figure 2 Display menu of medical services P-2

1.0.1 User Registration CU

The case User Register is linked to the user's initial registration and changing registration
information.They must also be included and the inclusion and extension points for Validate User
use cases and provide medical services, respectively.It then describes the initial sections of the use
case, with the remaining sections, subflows and exceptions below.

Use Case Register users

Stakeholders Manager, Database patients
Type Basic
Purpose Allowing the administrator to different users record patient monitoring
system for later use.
Abstract This use case is initiated by the Administrator. Provides functionality to
create, modify and delete the user record with the patient monitoring
system.
Preconditions All subflows, except for Creating User Registration (S-1), run initially
require the use case Validate User.
Main flow Run the Validate User use case. Depending on the options selected by
the user, it will continue with the various substreams this use case.

Figure 3 Display User Registration (P-3)

Subflows S-1 Registration Create Username

It presents the user with the Create User Registration (P-3).This screen
contains registration information that must be completed by the
administrator, including full name, username, password, role, position
and workspace, email and additional input password again to ensure
their correction and then press button "Save".
The username and password will be used by the system to validate the
 user.
The user can select from the following: "Find Record" "Add Record",
"Delete Record" and "Save Log". If the selected activity is "Cancel" will
exit the system.

S-3 Managing User Registration

It presents the user with the Create User Registration (P-3) with the
user registration information.
The user can select comes the following: "Delete", "Update", "Save"
and "Exit".
If the user presses "Update" running the substream Update User
Registration (S-4).
If the user selects "Delete" running the substream Delete User
Registration (S-5).
If the selected activity is "Exit" will exit the system (if you have not
pressed "Update", the new information will be lost).

S-4 Registration User Update

Update the user record with the changed information (E-1, E-3, E-4).
Continue the subflow Managing User Registration (S-3).
S-5 Clear Register Username
It removes the user record and continue with the subflow Creating User
Registration (S-1).
Exceptions E-1 incomplete: Missing information fill in the user record. It once again
requests the administrator to complete the registration.
E-2 Registration already exists: If a record already exists under that
user, it will prompt the administrator to change or end the use case.
E-3 Incorrect Password: The password is invalid. Administrator is asked
to correct the record.
E-4 bad password: The password chosen is simple or not properly
validated. It prompts the administrator to correct the record.

2.0 Control Patients

2.1.1 Register CU previous patient data

The use case Record data 1st time the patient is linked to the original registration of patients and
changing registration information.They must also be included and the inclusion and extension
points for Validate User use cases, provide medical services, and search patients respectively.

Use Case Record data 1st time patient

Stakeholders Receptionist CEEPI Database
Type Basic
Purpose Register data 1st time patient or those who come asking questions or
come to the clinic or cosmetic dermatology specialist first
Abstract This use case is initiated by the receptionist. Filters the patient by name
 and in the case of this will not be registered prior registration of
patients.
Preconditions Are required to have previously run the Validate User use case.
Main flow 1. When the patient requests an appointment the receptionist
peguntara if the patient is the 1st time I go to ask for a consultation.
2.Previous data will be requested to register as full name, phone
numbers and email. P-4 If the medical consultation is required for
the patient or CEEPI CEEPI Plus.
3. The patient discharge date shall be registered by the system and
the clerk may make a change of date, selected the calendar icon or
image.

Subflows S-1 Enter the required data on the screen P-4, once registered you can
select the << save button >> to store the data.
S-2 If the users want to add a new patient will select the sign << + >>,
once registered data, click on the button << >> store to store.
S-3 If the user wants to delete a patient must select the button << x >>
system.
S-4 If the user wants to update some of the recorded data of the
patient, you must select or locate patients by mediantes buttons << >>
or << back forward >>, make the change and then press the save button
<< >>.
S-5 If the user wants to perform a quick location location of the patient
or use the search subflow screen patients P-4.If the selected activity is
Out >> << button will exit the system.
Exceptions E-1 at the time of making a record of the patient's previous data of the
system will send a message that was Agredo or modified file.

Figure 4 Registration Screen previous patient data (P-4).

Subflows 1. The receptionist select the search icon in category patients. As

shown in the screen P -5.
 2.Write the first letters of the name or names of the patient and the
system will have the ability to show the names and related
surnames given filter.
3. If the patient is not able to locate. The receptionist will select the
button to add patients to the new patient registration.

Search screen Figure 5 patients (P-5).

2.1.2 Registration CU patient's personal information

The use case of personal information is linked to the patient record and clinical overview of the
patient.It must contain the inclusion and extension points for Validate User use cases, provide
medical services and data recording 1st time patient.

Use Case 1st time log data of patients

Stakeholders Nurse, Doctor, CEEPI Database
Type Basic
Purpose This process consists of recording personal data of patients, to carry
this out this registration is necessary that the previous data of patients
are registered in advance.
Abstract This use case is initiated by the nurse. The nurse should select the
patient's name and registered previously in the case of not being
registered, select its insertion through the module add 1st time
patients.
Preconditions Are required to have previously run the Validate User use case and 1st
time registry of patients.
Main flow 1. Once you have registered the previous data of the patient, the
nurse will register the personal data of the patient.
2.After selecting the name of the patient requested additional data
such as date of birth, age, sex, and discharge date.
3. Once the data recorded at point number 2.Be selected tab >> <<
 Personal Information to register additional personal information
such as occupation, address, contact details and ingr Photo esar
patient, as shown Figure P-6.

Subflows S-1 Enter the required data on the screen P-6, once registered you can
select the <<save button>> to store the data.
S-2 If the users want to add a new patient will select the sign << + >>,
once registered data, click on the button << >> store to store.
S-3 If the user wants to delete a patient must select the button << x >>
system.
S-4 If the user wants to update some of the recorded data of the
patient, you must select or locate patients by mediantes buttons << >>
or << back forward >>, make the change and then press the save button
<< >>.
S-5 The data logging query << tab >> 1st time will be recorded by the
doctor who will attend to the patient.
S-6 Registration Data tab >> << history is recorded by the doctor who
will attend to the patient.
S-7 << tab >> contain information medical history of patient
consultations and will be consulted by the doctor. If the selected
activity is Out >> << button will exit the system.
Exceptions E-1 If at the time of making a selection of a patient name is not
registered and this can be recorded using the Add button.
 Figure 6 Registration personal information of patients (P-6).

2.1.3 Registration CU patient history

The use case history record is linked to the initial registration of the patient and the use case of
personal information that is to select the patient's full name and then select the tab or << Patient
History >>, This type of information will be requested by the doctor on duty to the patient

Use Case Record history of patient

Stakeholders - Doctor
Type Extend
Purpose Allow the doctor on duty record information related to the medical
history of the patient and not pathological, such information is
requested by the doctor only once and may be updated as required.
Abstract This use case is initiated by the doctor on duty. Provides the
functionality to create, modify or update the information related to the
patient's medical history
Preconditions Registration is required prior to patient data such as full name, phone,
address
Main flow 1.Once registered the previous data of the patient, the doctor on
duty will register the data related to the patient's medical record.

2. After selecting the patient's full name or select the tab <<
patient's clinical history >>, additional information is requested as
body weight, skin phototype, allergies, drug consumption, among
others. As shown in Figure 7, P-7 screen.

Subflows Once the data recorded at point number 2. Will select the << Personal
Information >> tab to store the recorded information
Exceptions E-1 If at the time of making a selection of a patient name is not
registered and this can be recorded using the Add button.

Figure 7 registry patients clinical information (P-7).

2.1.4 Information CU patients clinic 1st time

The use case of clinical information for 1st time patients is linked to the initial registration of the
patient and the use case of personal information that is to select the patient's full name and then
select the tab << Medical consultation or 1st time >>, this information will be requested by the
doctor on duty to the patient

Use Case Record medical consultation 1st time

Stakeholders Doctor
Type Extend
Purpose Allow the doctor on duty recording information related to its
topography, morphology, signs, symptoms, duration, previous
diagnoses, and treatment indications, such information is requested by
the doctor only once and may be updated as required.
Abstract This use case is initiated by the doctor on duty. Provides the
functionality to create, modify or update the information related to the
patient's medical history
Preconditions Registration is required prior to patient data such as full name, phone,
address
Main flow 1.Once registered the previous data of the patient, the doctor on
duty will register information about previous diagnoses and
definitive patient.

2. After selecting the name of the patient, select the tab <<
Medical consultation >> 1st time, additional information is
requested as: topography, morphology, signs, symptoms, duration,
among others. As shown in Figure 8, P-8 display.

Subflows Once the data recorded at point number 2. Will select the << Personal
Information >> tab to store the recorded information.
Exceptions E-1 If at the time of making a selection of a patient name is not
registered and this can be recorded using the Add button.
 Figure 8 Information Patient clinic 1st time (P-8).

2.1.5 History consultations CU

The use case consultations historical record is linked to the subsequent medical consultations of
patients is to select the patient's full name and then select the tab << query historical >>, this use
case will allow the doctor turn consult the clinical record date, ie, will reveal the degree of
progress or patient outcomes.

Use Case History consultations

Stakeholders Doctor
Type Extend
Purpose It allows the doctor on duty to consult patients query historical
information, this information is recorded by the doctor on duty in
charge of patient care and diagnosis.
Abstract This use case is seen by the doctor on duty. Provides query functionality
clinical records of patients for dates, show the evolution of the patient
by displaying photographs and images of the lesions.
Preconditions Registration is required of patients attending for 1st time consultation
or subsequent consultation
Main flow 1.After registration of the patient, the doctor on duty shall perform
the insertion of photographic images of patients.

2. Once you have selected is the full name of the patient,

 select the tab <<historical Consultation>>, the physician may consult
regarding the evolution of the patient's illness by date. As shown in
Figure 9, 9 screen.
Subflows None
Exceptions E-1 If at the time of making a selection of a patient name is not
registered and this can be recorded using the Add button.

Figure 9 History consultations (P-9).

CU patient appointment Schedule 2.2

The use case schedule appointments for patients is linked to the registration of patients and
physicians, is to select the appointment date that patient requests, likewise, will select the name
of the doctor and time attend to the patients, this process also will schedule appointments on the
same day that the doctor is seeing patients

Use Case Schedule patient appointment

Stakeholders Receptionist
Type Basic
Purpose This registration process is patient appointments schedule
appointments that patients request, the system will record the date
and doctor appointments for care, the system will add or canceling
appointments
Abstract This use case is initiated by the receptionist, you must select the same
date, doctor's name and time of consultation that the client requests
Preconditions Registration is required of the patient and physician data are
registered.If not the case the system must allow add to list of patients
and doctors of the clinic
Main flow 1.After selecting the clinic name, date of reference and the name
 of the doctor on duty, the clerk shall set the time of care, the
patient's name, type of query, as shown in Figure 10, display 10.

2. Once the patient appointment schedule is added to the image of

the icon will change from one state to another to indicate that the
patient may revoke the appointment

3. The system insert new records, even if the agenda is completely

saturated, the clerk scans the agenda in areas where the doctor
used in patients less query time.

4. The system should allow add patients, doctors who are not on
the list and print the agenda patients attend a doctor.

5. The system should remove the agenda patients by date or name

of the doctor.

6. Once the registration or updating of the patient, the user must

save the changes.
Subflows S-1 This subflow to register the list of doctors for both clinics, this
thread will allow the registries of personal medical data, as well as
updating changes or cancellation of data and records from the list of
doctors. As shown in Figure 11, P-11 display.

S-2 This subflow allow the inclusion of emerging citations in this record
dating involves inserting patient who requests them without prior
notice, ie may be momentary, this thread requires selection of the clinic
where you will be attended, the date and the name of the doctor who
will attend. As shown in Figure 12, P-12 display.

Exceptions E-1 If at the time of making a selection from the name of a patient or
physician is not registered, they may be searched using the icons below
to add patients or physicians.
 Figure 10 Query History (P-10).

Figure 11 Medical Record, Screen P-11

 Figure 12 Medical Record, Screen P-12

2.2.1 Control CU patient appointments

The use case patient appointments control is linked to the process of scheduling appointments, is
to select or open the calendar on the day shift and care for patients, the system must select
combine the results of the meeting agenda control appointments, ie in this case the clerk shall
record use patients confirm the appointment or stop before your appointment time.

Use Case Control appointments

Stakeholders Receptionist
Type Includ
Purpose This process is to record the attendance of scheduled patient
appointments, the receptionist recorded in this process the
confirmation of the appointment of the patient when to go window.
Abstract This use case is initiated by the receptionist, who will select the clinic
where the patient is treated, the doctor is in consultation and date, so it
should do a search for patients who are on the agenda at the date and
time allocated and the query type requested.
Preconditions Patients should be pre-registered in the appointment book, must be
recorded dates and name of the doctor who will attend the
consultations
Main flow 1.After selecting the clinic name, date of reference and the name
of the doctor and the receptionist shift attention.

2. Once validated the name and date of the agenda, the

receptionist leaked patients scheduled and after locating the
system will display the date, time and type of query, also, indicate
whether the patient attends the meeting for the 1st time or is a
subsequent patient.As shown in Figure 1 3, P-13 display.
 3. After confirming the patient's appointment, the receptionist
added to list patient care consultation

4. Totalized system by query type total visits per day, date and
physician.

5. The system displays the name of the cashier on duty, it is printed

in the report to be

Subflows S-1 The system updates the total consultations increasingly confirming
the attendance of a consultation, the receptionist may obtain a printed
list of daily care of patients.
Exceptions E-1 should be validating the doctor's name and date of the consultation
on the agenda.

E-2 should validate the name, date and time of the patient who
scheduled the consultation.

Figure 13 Registration of doctors, Screen P-13

2.3.1 Checking CU subsequent patients

The use case subsequent patient consultation is linked to the registration of general information.It
must contain the points of inclusion and extension use cases of injury photographs and images
presented by patients and issuance and printing of patient prescriptions.

Use Case Consultation subsequent patients

Stakeholders Medical, CEEPI Databases
Type Basic
Purpose This process is to record the patient's symptoms, to carry this out this
registration is necessary that the previous data of patients are
registered in advance.
Abstract This use case is initiated by her doctor on duty, who is treating the
patient, the physician should select the patient's name previously
registered
Preconditions Registration is required prior to patient data such as full name, phone,
address
Main flow 1. Once selected the previous data of the patient who requested
the consultation, the doctor will register patient information
2.After selecting the patient's name will be selected tab <<
subsequent patient visits >>

3. Once the data recorded at point number 2. The results recorded

diagnoses of patients as well as treatment and indications
provided.
4. The following selection of definitive diagnosis, the system will
add more than one diagnosis to select the sign << + >> or sign << -
>> to remove

Subflows S-1 Enter the required data on the screen P-14, once registered you can
select the << save button >> to store the data.
S-2 If the users want to add a new patient visit will select the sign << +
>>, once registered data, click on the button << store >> to store.
S-3 If the user wants to delete a query the patient must select the
button << x >> system.
S-4 If the user wants to update some of the data recorded in the patient
consultation, you should select or locate patients by mediantes buttons
<< back >> or << forward >>, make the change and then press the <<
Save >>.
S-5 The data logging tab << photographs and images >> are taken and
inserted into the database by the doctor who will attend to the patient.
S-6 Registration Data, tab << Recipes >> be registered and issued by the
doctor who will attend to the patient.
If the selected activity is with << Out >> will exit the system.
Exceptions E-1 If at the time of making a selection of a patient name is not
registered and this can be recorded using the Add button.
 Figure 14 Registration of patient visits, display P-14

CU 2.3.2 Inserting images pictures

The use case insert photographs of patients is linked to the registration of medical consultations of
patients and subsequent 1st time, that is to select the patient's full name and then select the tab
or pictures << >>, this use case in turn allow the doctor to attach the images of lesions presenting
patients also register entries related injuries.

Use Case Insertion of photographs

Stakeholders Doctor
Type Extend
Purpose It allows the physician on duty attach photo images of lesions
presenting patients, in addition to related entries evolving lesions.
Abstract This use case is used by the doctor on duty. Provides functionality to
insert photographic images, the system will prompt the user to select
the path to store images,
Preconditions Registration is required of patients attending for 1st time consultation
or subsequent consultation
Main flow 1.Once registered and selected the patient, the doctor on duty
shall carry inserts record photographic images from his injuries on
the screen P-15.

2. After selecting the name of the patient, select the tab or tab <<
pictures >>, the doctor inserting images and select the path where
the information is stored.

Subflows S-1 The system user may perform shooting injuries to patients directly
from the computer.

S-2 The user of the system can store more than a photographic image,
you can also annotate related injuries, the images will be related to the
date of patient visit.

Exceptions E-1 If at the time of making a selection of a patient name is not

registered and this can be recorded using the Add button.

Figure 15 Inserting photographic images, display P-15

2.3.3 Emission CU recipes

The use case print recipe is linked to the registration of medical consultations or subsequent 1st
time patients is to select the patient's full name and then select the option or tab Recipes << >>,
this use case will allow the shift register medical category and select the type of drug that would
be supplied to the patient

Use Case Issuance of recipes

Stakeholders Doctor
Type Extend
Purpose It allows the physician on duty registration and printing of prescriptions
of patients, the doctor may add or remove different list drugs and doses
and general notes that the patient should be followed.
Abstract This use case is used by the doctor on duty. Provides functionality to
insert a list icamentos total med that the patient should be taken
during the patient's treatment
Preconditions Registration is required to attend the patient consultation for 1st time
or subsequent consultation
Main flow 1.Once registered and selected the patient, the doctor on duty
shall draw your prescription, P-16 display.

2. After selecting the name of the patient, select the tab << Recipe
>>, the doctor will add the total number of drugs for the treatment
of the patient.

3. The name of the patient, physician and date will be displayed

when you select the tab << Recipe >>, ie after the medical
consultation of patients

4. The user of the system can perform printing the recipe and
store your data

Subflows S-1 registration system user categories and drug names on screen P-17.

S-2 The user of the system can store more than a photographic image,
you can also annotate related injuries, the images will be related to the
date of patient visit.
Exceptions E-1 If at the time of making a selection of a patient name is not
registered and this can be recorded using the Add button.
E-2 The name of the doctors, drug categories and must be pre-
registered.
 Figure 16 Inserting photographic images, display P-16

Figure 17 Display registration categories and drugs, P-17 display

2.3.4 Request biopsies CU

The use case is linked biopsies request the registration of patients and physicians, is to select the
name of the patient to whom a request for studies performed in this use case is asked the name of
the doctor who requested the study and the date of the application and delivery of results to the
patient.

Use Case Application of biopsies

Stakeholders Receptionist, medical
Type Basic
Purpose This application process is to record the order of biopsy studies, the
system records in sequence number order.
Abstract This use case is initiated by the receptionist at the request of the doctor
on duty, the clerk must select the name of the patient and ordering
physician previously registered.
Preconditions Registration is required of the patient and physician data are registered.
If not the case the system must allow add to list of patients and doctors
of the clinic
Main flow 1.Once selected patient data and medical receptionist will register
the information corresponding to the request of the study.

2. The system will automatically display the date of the request for
study, the sequence number of the request and the age at time of
patient select your name.

3. In this use case is asked about the number of foil, type of biopsy,
date of delivery by the laboratory, the date on which it is received
by pathology, the date of delivery of results to the patient, and the
recording of costs incurred by studies.
Subflows S-1 Enter the required data on the screen P-18, once registered you can
select the << save button >> to store the data.
S-2 If the users want to add a new patient visit will select the sign << +
>>, once registered data, click on the button << store >> to store.
S-3 If the user wants to delete a query the patient must select the
button << x >> system.
S-4 If the user wants to update some of the data recorded in the patient
consultation, you should select or locate patients by buttons << back >>
or << forward >>, make the change and then press the << Save >>.
S-5 The data logging tab << photographs and images >> are taken and
inserted into the database by the doctor who will attend to the patient.
S-6 Registration Data tab << Recipes >> be registered and issued by the
doctor who will attend to the patient.
If the selected activity is << Out >> button will exit the system.
Exceptions E-1 If at the time of making a selection from the name of a patient or
physician is not registered, they may be searched using the icons below
to add patients or physicians.
 Figure 18 Screen biopsies request record, display P-18

2.3.5 Control biopsies CU

The use case biopsies control is linked to the registration of applications for studies of patients, is
to display a status report of biopsies requested and delivered, in this use case is asked the name of
the clinic, the date of consultation, and the date of the application and delivery of results to the
patient.

Use Case Control biopsies

Stakeholders Receptionist, medical
Type Extend
Purpose This use case is to generate a control sending and receiving and
delivering research results to patients, such a query is generated by
certain date.
Abstract This use case is initiated by the receptionist, you must select the same
date on which you wish to inquire
Preconditions The dates of consultation must be lower than the current date
Main flow 1.The receptionist must select the type of clinic to which the
patient belongs, and the date of consultation. Screen 19
2. The receptionist will select the return date of the pathology
results.
 3. The list displays the selected date of receipt of the studies or
results, here the receptionist will validate the date of delivery to
the patient, also, contain a text box where any observation
recorded delivery or condition of the patient results.
Subflows S-1 The clerk may print the report containing the list of studies or
results delivered or that are pending to be delivered to the patient
Exceptions E-1 In the case of printed reports, the printing system must be in line

Figure 19 Screen biopsies request record, display P-19

3.1.1 Control box CU

The use case control box is linked to patient registration, billing control consists of patients for
medical services rendered, the clerk will select the patient's name and then added the concepts of
recovery, the system will assign a number or sequential collection sheet.

Use Case Control box

Stakeholders Receptionist
Type Basic
Purpose This process is to record charges to patients, the receptionist record
charges made to customers for the medical services offered, the patient
can pay for services in different denominations.
Abstract This use case is initiated by the receptionist who must select patient
name and add the concepts of recovery. The teller or receptionist on
duty will be responsible for opening and closing the box. System will
support the registration of different denominations and payment
according to the total amount indicated, the system will indicate the
amount to be refunded.
Preconditions All patients and billing concepts must be pre-registered.
Main flow 1.The system displays the next number of the receipt of payment
 and date system. P-20 screen.

2. After selecting the name of the patient, the concept was

selected collection and display the price and amount after
deductions and VAT and then pressed the add button, you can add
as many concepts needed for recovery.

3. The system will calculate the total of the payable by the patient,
after deductions and taxes. It subtotal is represented by total
games.

4. The system will record the total payable in different

denominations

5. The operating system can store and cash register output when
the control patient appointments.

Subflows S-1 This underflow allows printing of receipts generated n by charging

patients.Screen P-21
S-2 This subflow will register another type of income other than the
concepts of consultation, record the date, time, amount, cash income
concept and observations.Screen P-22
S-3 This subflow will record expenses requested by the clinic staff, will
record the date, time, amount, and observations of discharge
concept.Screen P-23
Exceptions E-1 Not all collection items include discounts and value added tax
E-2 For receipt printing, the printing system must be found online
Figure 20 Screen biopsies request record, display P-20

Figure 21 Screen format medical bill, P-21 display

 Figure 21 Display record other cash income, P-21 display

Figure 22 Screen recording other cash outflows, Screen P-22

3.1.2 CU Court Case

The use case cut box is linked to the control box, is to show the cut in cash from daily cash
operations. The cash flow i niciarán with cash income plus total transactions for items of daily
income, minus total transactions for items of expenditure.

Use Case Court Case

Stakeholders Receptionist, Administrator
Type Include
Purpose This process is to record transactions in and out of box.The receptionist
will be responsible for making the cut and cash manager cash validate
the cut. The administrator is authorized to conduct cash counts to cu
ndo deemed necessary.
Abstract This use case is initiated by the receptionist who will select the cutoff
date, this process will show the total cash income and credit, show a
breakdown of revenues and egress, also present a cut of total cash
payments and payments with credit or debit cards.
Preconditions The cutoff date is less than or equal to the current system date.
Total cash showing the system should match the total cash and cash
there
Main flow 1.The system displays the current date or the receptionist can
select a date below to query the system.Screen 23.
2. In the case of total card, the clerk must show total bauchers
totaling the total income of the concept of card payments.
Subflows S-1 The receptionist can get an impression of the daily court report cash
Exceptions E-1 The system shall display an error message when you try to set a
court date than at present.
E-2 The printing system must be online to print report daily cash cut.

Figure 23 Screen Daily Cash cut, screen P-23

CU 4.0 Produce reports

This use case allows the generation of reports printed as:

Report registered patients

 Report Figure 24 patients on or off, display P-24

Report daily schedule of appointments

Figure 25 Report daily agenda, Screen P-25

Query Control (Assistance Percentage citations by query type),

 3 .Nonfunctional requirements (NFRs)

NFR Description Requirement

NFR-101 The system will respond to requests for information query system users
and Internet users previously validated.

NFR-102 The system will respond to local network users to the clinic for the
management and control of daily operations.

NFR-103 The system will have an automated backup process.

NFR-104 Permission is implemented, users levels and high level of security in that
part of the consultation process on the Internet

3.1 Performance

NFR Code Description

NFR-101 It will be necessary to have a reliable Internet connection, namely via
Ethernet between the client and the server machine.

NFR-102 The application will be used by a user with an instant response

operations.

NFR-103 It will use the internal network (Intranet) for the IP through the server
can access the application.
NFR-104 Is expected to have 10 concurrent internal users in the application
 3.2 Scalability

NFR Code Description

NFR-101 In the first phase of the system will develop patient care modules and
control box
NFR-102 In the second phase of the modules will be developed inventory
control and statistics

3.3 Availability

NFR Code Description

NFR-101 It is not necessary that the system is constantly active, with one time
you activate will update the database to the current date of the client
computer.
NFR-102 The workload is important in the morning shift from 8:30 to 20:00 for
internal staff and therefore the system must be without fault in that
time period.
NFR-103 The system is always available to you from anywhere in the general
direction or clinic manager need to see this information is reliable and
up to date.

3.3 Reliability and Safety

NFR Code Description

NFR-101 The information supplied will be stored in the central database that
already incorporates security features.

NFR-102 The application will have security modules to access authorized

applications depending on the role assigned to each user.
NFR-103 The embedded database has access control and monitored by the DBA
(IT Manager) who will be the Database Administrator.
NFR-104 Access to Intranet will be validated by the computer

NFR-105 Backups are performed every 3 days at a time that does not affect any
process.
 1.5 Usability

NFR Code Description

NFR-101 They incorporate menus, icons and tables for easy carrying information
management.

NFR-102 The application will have interactive displays and dynamic in order to
facilitate the use of the application to users

NFR-103 It can generate queries on the screen and printed reports of clinic
operations.
.

4. - Glossary
Stakeholder Is any person or group having an interest in the project. The set of
stakeholders including users and administrators on the client side and the full
project team developer side
Business Owner This person is the owner of the business and ultimately responsible for the
behavior of the system
FRs Functional requirements. Defines the behavior of the system from the user's
perspective
NFRs Nonfunctional requirements. Define the qualitative characteristics of the
system