Feasibility Study (Sample)

					I. INTRODUCTION

Many physicians have been practicing their profession by having private clinics and
attending to patients in hospitals if necessary. Here in Koronadal, we can see many private
clinics, almost everywhere, but none of these clinics are using computer automated systems
in keeping records of patients. Many physicians are using high technology machines as aid
in their diagnosing and determining patient’s sicknesses but none have dared to use
computers in keeping patient’s records. Instead, they rely on their secretaries to keep and
maintain their individual patient’s records.

Dr. Sylvia Barrientos-Adalin is an obstetrician – gynecologist. Her clinic is located in Notre
Dame of Sienna Commercial Complex, Alunan Avenue, City of Koronadal. She is sharing a
space with her husband who is a dentist. She has been practicing her profession for years.
Attending to women’s illnesses and pregnancy, for years, she has been relying on her
secretary to keep files of her patients. Every time a patient calls or texts her, she could not
do anything except to refer first to the records of her patient that is kept in bulky filing
cabinets in her clinic.

This study aims to create a customized application program that can be used by Dr. Adalin
being the recipient. The system would be designed to store and retrieve patients’ records.
The system would also include the functionality of downloading patients’ records to Dr.
Adalin’s PDA.

The study methodology that will be used in this endeavor is Systems Development life Cycle
(SDLC). This will give the chance to the author/programmer to do a detailed and structured
study on the development of the system.

II. PROBLEM DEFINITION

Dr. Adalin has been experiencing the following problems:

   1. From the time cell phones are in everybody’s hands, it becomes hard to answer/
      entertain a patient or a relative of any patient, asking about medications and
      suggestions on what to do during some emergency. This is true if Dr. Adalin is not in
      her clinic where she can’t pull out from loaded cabinets and browse patient’s
      previous records to check for history before giving out any information.
   2. It is difficult to trace up history of an admitted patient in a hospital with her records
      still kept in the clinic.

III. BUSINESS SYSTEM OPTIONS

The following are the options considered in this study:

   Option 1: From manual to computer automated patient record keeping.

       With this option come the following advantages:

         a. Dr. Adalin’s clinic can be free of bulging filing cabinets. Instead, they will be
       replaced by at least two computers. One will be operated by the secretary and the
       other one will be for Dr. Adalin’s disposal.
       b. Dr. Adalin can bring along her patients’ records with her as electronic files saved
       into in her PDA.
       c. Improved service to patient especially in the clinic during busy time. This is the
       time when many patients come to see Dr. Adalin. Systematic updates on patients to
       come for follow up can be done and can be determined earlier.
       d. It would be easy to prioritize patients, who come first, whose next, and so on.




                                                                                             1
    Option 2: No conversion at all. Leave the current manual system as it is.

        With this option come the following advantages and disadvantages.
         Advantages:
        a. Everybody will just be comfortable with the familiarity of the existing system.
        b. No cost and ROI to think about.

        Disadvantages:
        a. The same problems will just continue to exist.
        b. No possibility of improving patient – physician communication if record keeping is
            still in a traditional way.

   These options will be considered using the following criteria:

   1.   Cost of software.                          -       10%
   2.   Availability and cost of hardware.         -       10%
   3.   Solution to the problem.                   -       70%
   4.   Trainings needed.                          -       10%
        Total                                              100 %

       The cost of the system itself (software) is P 25,000. Other software license like the
        RDBMS backbone considered can be bought by Dr. Adalin herself or an open source
        version provided by the author/programmer can be used.
       Hardware requirements include two computers. One will be used by the secretary
        connected through a peer-to-peer connection to another computer at Dr. Adalin’s
        treatment room.
       Training will be provided by the author/programmer to the users as part of the
        package when the project will be realized.


       The following table summarizes the rating of the two options:
Criteria                   Option 1 – Conversion from Option 2- No change in
                           manual     to     computer the        current   manual
                           automated patient’s record patients’ record keeping
                           keeping
Cost of software – 25 %               5%                             10%
Availability and cost of              5%                             10%
hardware
Solution to the problem               70%                             0%
Trainings needed                      5%                             10%
Total                                85%                             30%




IV. OPTION SELECTION

Option 1 was given the perfect rating as far as its capacity to address to problem is
concerned while option 2 can’t offer any solution to the problem and therefore, was given a
zero rating. No hardware, software, nor training is required if option 2 is chosen and
therefore, these three criteria were given a perfect rating.

Based on these results, the author/programmer is presenting option 1 to be pursued – to
fully convert the existing manual system to a computer automated patients’ record keeping.




                                                                                             2
V. DATA FLOW MODELING

Considering option 1, the following Data Flow Diagram summarizes the transaction in Dr.
Adalin’s clinic:

Context Diagram:

                     blank patient information sheet               Secretary

                     filled-up patient information sheet
      Patient



         medical instructions and list
         of medications,
         if any
                                         0

                                Patient’s Record                 Patients’ Information
                                Keeping System




                 Complaints (if any)
                                             Assessment / Diagnosis

                                             Plans / Treatment

                                                                       Physician


This flow is still similar to the current manual system except that records are to be kept in a
database through a customized application program specifically designed for patient’s record
keeping.




                                                                                             3
The following Entity – Relationship Diagram shows the details of the processing for the
proposed system:




                                            Patient’s
                                             Record                            Patient
     Secretary




                                             Doctor




VI. INPUT/OUTPUT STRUCTURE

The flow of the processing starts when the patient enters the clinic and is being entertained
by the secretary. If the patient is a new one and does not have any record yet in the clinic,
the secretary will give her an information sheet to be filled out. Refer to Figure 1 for the
sample form of this information sheet. After the patient has filled out the necessary
information, the secretary will have to encode them in the computer.

In case the patient has records in the clinic already, the secretary will just retrieve patient’s
records in the database through the system. Name of the patient can be searched using
either the last name or the first name or both. Technically, each patient will be assigned and
be identified by a patient ID which will be used at the background of the search, unknown to
the user – the secretary. The secretary will then get the patient’s weight and update the
patient’s record. The patient will be classified as an obstetric case (pregnant) or a
gynecology case (has reproductive system disorder / problem).

The system will assign and display numbers of patients based on the sequence of how each
will be served. When Dr. Adalin will be finished with a previous patient, the patient counter
will tell the secretary to tell the next patient that it is her turn. By the time the patient is
inside the treatment room, her record is already displayed on the screen of Dr. Adalin.

After the patient has been examined, Dr. Adalin will update the patient’s record. If the
patient is a gynecology case, she will be encoding the S (subjective complaint of the
patient), O (objective complaint by the doctor), A (Assessment or diagnosis of the doctor),
and P (Plans or treatment for the patient based on the diagnosis of the doctor). If the
patient is an obstetric case, the pre-natal record of the patient is updated. With this,
anytime she needs to refer to patient’s record for medical history purposes or for any other
purpose, queries can be entertained and will be answered by the system.

VII. TABLE AND DATA DEFINITIONS

The database will be named as Clinic. It will be composed of three tables: one master table
named mPatient, two transaction tables named tPatientVisitGyne and tPatientVisitOB,
and the table to store usernames and passwords of users of the system, mUserProfile.

mPatient will store permanent records of the patients. Its primary key is PatientID.

tPatientVisitGyne will store medical information gathered by Dr.Adalin every gynecology
patient visit. A record in this table is uniquely identified by the combination of the
PatientID and VisitDate. PatientID is a foreign key that links to mPatient table.


                                                                                               4
tPatientVisitOB will store pre-natal record every obstetric patient visit. A record in this
table is also uniquely identified by the combination of the PatientID and VisitDate.
PatientID is also a foreign key that links to mPatient table.

mUserProfile is a master table for passwords and usernames. Its primary key the
password.

It is also possible that a patient can visit the same doctor on the same date but the first
visit is always considered the formal one. Succeeding visits made on the same day are
considered follow-up and are recorded under the first formal visit.

RDBMS will be used in keeping and maintaining patient’s record on a SQL Server using
MySQL.

mPatient
       Field Name                    Description              Data Type
PatientID                   Patient identification no.      numeric
LName                       Patient’s last name             Varchar(50)
FName                       Patient’s first name            Varchar(50)
MidName                     Patient’s middle name           Varchar(50)
Bday                        Patient’s birth date            Date
Address                     Patient’s address               Varchar(255)
ContactNo                   Patient’s contact number        Decimal
Status                      Patient’s marital status        Varchar(30)
Sex                         Patient’s gender(F/M)           Char(1)
Occupation                  Patient’s occupation            Varchar(100)
PatientType                 A character that specifies      Char(1)
                            the type of the patient (O-
                            obstetric; G – gynecology)

tPatientVisitGyne
       Field Name                    Description              Data Type
PatientID                   Patient’s identification no.    numeric
VisitDate                   Patient’s date of every visit   Date
Subjective Complaints       Things patient’s complains      Mediumtext
                            about in her health.
Objective Complaints        The patient’s medical           Mediumtext
                            problem as seen by the
                            doctor.
Assessment / Diagnosis      Doctor’s diagnosis on the       Mediumtext
                            patient based on the
                            examination done.
Plans                       Include plans for patient’s     Mediumtext
                            treatment, medical
                            instructions and
                            medications.
ConsultationFee             Amount paid by the patient      Float (9,2)
                            as consultation fee




                                                                                         5
tPatientVisitOB
       Field Name                     Description             Data Type
PatientID                   Patient’s identification no.    Numeric
VisitDate                   Patient’s date of every visit   Date
LMP                         Patient’s last menstruation     Date
                            date
AOG                         Patient’s age of gestation      Numeric
                            (in weeks)
BP                          Patient’s blood pressure        Varchar (10)
                            during the visit
Weight                      Patient’s weight during the     Numeric
                            visit (in kg.)
FH                          Patient’s fundic height (in     Numeric
                            inches)
FHB                         Fetal heart beat (as counted    Numeric
                            per minute)
Remarks                     Doctor’s comments on the        MediumText
                            medical condition of the
                            pregnant patient
ConsultationFee             Amount paid by the patient      Float (9,2)
                            as consultation fee


mUserProfile
       Field Name                   Description               Data Type
Name                        User’s name                     Varchar(100)
Designation                 User’s designation              Varchar(50)
UserName                    User’s username                 Varchar(30)
Password                    User’s password                 Varchar(30)
AccessLevel                 User’s access level of          Varchar(10)
                            authority


VIII. USER ROLES

Dr. Adalin and her secretary are the identified users of the system. The secretary will be
the one to enter patient’s personal information on first visits. Diagnoses, impressions,
medical instructions and medications will be encoded by Dr. Adalin herself.

Dr. Adalin will have access to patient’s record whenever needed. This information can be
viewed on screen, printed on paper, or downloaded onto another storage media for
portability and mobility.




                                                                                        6

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:104279
posted:4/12/2010
language:English
pages:6
Description: A feasibility study sample of a system application.