jocelyn lipata,cheryl lou tinaan, joel bautista,se msit-ou,projectsection final documentation (1)

83
PRESENTED BY: Jocelyn T. Lipata Software Engineering Page | 1

Upload: slcc0819

Post on 22-Nov-2015

7 views

Category:

Documents


0 download

TRANSCRIPT

PRESENTED BY:

Jocelyn T. LipataCheryl Lou R. TinaanJoel T. Bautista

November 13, 2011

TABLE OF CONTENTS1. Company Background31.1 The Health Services Department61.2 Roles and Responsibilities of the Physician61.3 ICT Structure of LPU81.4 Description of the Current System in HSD92. System Overview112.1 Methodology112.2 Conceptual Framework162.3 System Functionalities173. Business Process Flow of existing System193.1 Processes214. Functional Specification/Use Case Narratives235. Design Specification495.1 Class Diagram495.2 Database Design505.3 Tables & Structures515.4 Interface design536. Appendices556.1 Glossary of Terms556.2 Project Proposal56I. Project Description56II Objectives:57III Business Imperative:58IV Benefits:58V Feature Behavior:60VI Data Needs:60VII Development Requirements617. References62

1. Company BackgroundThe Lyceum of the Philippines University acknowledges the legacy of its founder, Dr. Jose P. Laurel, a lawyer, legislator, constitutionalist, jurist, writer, scholar, statesman, philosopher and above all, an educator. He was the President of the second Philippine Republic.Teaching was his great love, and concern for education, his abiding passion. A graduate of the University of the Philippines College of Law, the Escuela de Derecho, Yale University, and the University of Sto. Tomas, his credentials as an educator were unassailable. Dr. Laurel wrote extensively on education, and in spite of his many commitments, managed to teach in several schools in Manila.During the dark days of the nation's history, while carrying the burden of wartime leadership , he introduced educational policies that emphasized and upheld the national character. After World War II, as senator, he authored the law creating the National Education Board and with Senator Claro M. Recto sponsored the Rizal Law.The idea for a school came to him in the early 1920's while he was at Yale. It was only three decades later when, with close friends, he was able to fulfill his dream of founding an institution that would become a center of learning in the Philippines and in the Far East. On July 7, 1952, Lyceum opened its doors to its first students.Laurel's admiration for the great seats of learning and his appreciation for classical thought inspired him to name it Lyceum, after Lykeio, the grove in ancient Athens where Aristotle searched for truth and wisdom. The school's motto, Veritas et Fortitudo courage and unyielding resolution in the quest for truth reflects Dr. Laurel's belief in the value of learning and his enduring devotion to the pursuit of academic excellence.Even at its early stage, the Board of Trustees had already considered in their agenda an expansion program with the end in view of converting Lyceum into a university. Eventually, after 53 years, Lyceum was granted its University status in January, 2006.

Figure 1 Lyceum of the Philippines University Cavite Campus Phase 2 Building

Figure 2 Location Map of Lyceum of the Philippines University Cavite Campus1.1 The Health Services DepartmentThe Health Services Department of the Lyceum of the Philippines University has started its operation since the day the university opened its gates to the students way back in the year 2008. Its services were also offered on the successive follow up days. Health care services shall include among others the following:1. Consultations2. Determination and facilitation of appropriate diagnostic examinations.3. Interpretation of diagnostic results.4. Therapeutic or definitive care procedures not requiring hospitalization.5. Preventive Health Care and Health Education.6. Review of Wellness Programs as requested.7. Annual Medical Examinations.8. House calls or home visits as requested.9. Specialty referral if indicated.10. Others: As stipulated in the scope of work.1.2 Roles and Responsibilities of the Physician1.2.1 The Physician agrees to provide primary Health Care Services to companys client at Lyceum of the Philippines University Cavite Campus, Manggahan, Governors Drive, General Trias, Cavite for a minimum period of forty(40) hours a week, or at such time or place as may be designated by the company under terms mutually agreed upon both parties.1.2.2 The Physician shall be physically present on the scheduled time (i.e. days and hours) mutually determined by the company and the physician.1.2.3 The Physician shall support and recommend strategies in coordination with the company pertinent to the quality assurance, expansion, licensing and marketing, of the companys health care services.1.2.4 The Physician shall support, recommend, develop and/or implement refinements in the business processes of the companys health care services for its effective and efficient operations.1.2.5 The Physician shall address and/or recommend appropriate action pertaining to issues affecting the companys health services.1.2.6 The physician shall attend and/or participate in meetings, medical audits, quality assurance sessions and such other activities required by the company or its clients in order to ensure the proper implementation of the companys health care programs.1.2.7 The Physician shall assist and/or participate in the companys orientation modules, public relations programs and marketing efforts.1.2.8 The Physician shall maintain the highest degree of professionalism.1.2.9 The Physician shall make appropriate arrangements with an equally qualified and certified doctor as his/her reliever in case of the Physicians absences or leaves whose work hours shall be compensated under the Physicians compensation. The Physician shall be directly liable for professional services rendered by the reliever. This arrangement shall be agreed upon by the reliever and the Physician in writing, copy of which shall be forwarded to the company.1.2.10 The Physician shall perform such other functions as may be designated by the company.1.3 ITD Structure of LPUThe Information Technology Department (ITD) holds the principal responsibility for all IS/IT-related projects of the university. It is mainly in charge of systems, data, and network administration.The ITD acts as the research and development arm of the university organization. It performs collaborative study to provide solutions for various transaction processes. It focuses on several aspects of development such as generation, evaluation, and administration of automated systems being utilized. Aside from its administrative functions, the ITD also provides extensive IT services like help-desk support (end-user assistance, ID orientation etc.) and computer laboratory maintenance.Currently there are six Technical Support Staff, one Supervisor and Director of the Information Technology Department.1.4 Description of the Current System in HSD The Health Services Department renders consultation as its primary goal. The physician and other staff perform first its main concern by checking the condition of the patient; they check the medical records and the vital signs. The physician mainly serves with regards with the chief complaints, as they give prescription, advises, and health teachings. There are also times when assessments are also performed. Based from the patients condition, the patient will be advised either to stay or to rest for a while in the Health Services Department also cover up existing problems. The current system they are utilizing necessitates improvements for faster, more convenient and more efficient procedures. The said department is unofficially tied up with other health institutions but rather its partnered with the First Care Medical Clinic and Laboratory located at Brgy. Manggahan. During the enrollment, enrollees are referred to have initial health check-ups on the said clinic. Information are gathered from there and transferred to the university using thumb drives. From that phase onwards, more time is consumed. Going to the preceding academic year, they will face difficulties with regards to the student queuing.Hence, the present system of the Health Services Department is still passive mostly with manual operations; therefore, believe that it needs aid from the thinking machine for a better and innovated Health Services Department.As an organization, LPU Cavite and its respective departments had begun its operations at the same time. One of its departments, the Health Services Department is utilizing a manual existing system up to the present time. This system gave rise to certain predicaments which lessens the efficiency of the said department.At the present time, the H.S.D. faces different problems for the sole reason that the existing system utilized is done manually. This system involves paper works. All forms and records kept inside the department are all tangible. By the mere fact that the department is using tangible forms, data redundancy is believed to exist. This fact is one of the reason why the manual processes done necessitate more time.As the students population grows, the department finds the existing system harder to perform. The number of patients grows but the number of staff performing the same processes remains the same. The department as of today seeks solutions that will fill the loop holes in their existing system.In accordance to the students request for medicines, they are required to fill out a form called Dispensed Medicine Log Sheet. Their names, student numbers, courses, as well as the quantity of the medicines they have requested are written on the said form. Because they are using a manual system, dates are also manually written on the form. On the first week of every month, reports are manually done to keep track of the amount of medicines that are still at hand. On the other hand, the student medical records that are being kept in the H.S.D. are manually processed in partnership with First Care Medical Clinic and Laboratory. These medical records are manually browsed when necessary. During regular school days, inevitably there will come a time when students and school employees will visit the department for consultation. During these times, the nurse is required to record the transactions done. They use a certain form called Consultation Form wherein different fields are needed to be filled out such as vital signs/complaints, diagnosis and intervention.2. System Overview2.1 Methodology

Developing a system is difficult to do because there will be series of tests and revisions before it will become functional. Therefore, there are some useful tools in building in integrated system methods such as System Development Life Cycle models which include waterfall, fountain, spiral, build and fix, rapid prototyping, incremental, and synchronize and stabilize.

Paper prototyping is a widely used method in the user-centered design process, a process that helps developers to create software that meets the users expectations and needs. It is a throwaway prototyping and involves creating rough, even-hand sketched, drawings of an interface to use as prototypes, or models, of a design. While paper prototyping seems simple, this method of usability testing can provide a great deal of useful feedback which will result in the design of better products. In this model, the software is developed in a series of incremental releases with the early stages of being either paper models or prototypes. Later iterations become increasingly more complete versions of the product.

The development included creating rough drafts of how the proposed system would look like and what the pages would contain. Through paper prototyping, the developer had a more organized approach and modifications of the system could easily be implemented compared to working with the system directly where there is a great possibility that the internal workings of the system could encounter certain errors.

Figure 3 Prototyping (Systems Development Methodologies)

The developer developed a preliminary release or version of the system where the key requirements and functionalities were used as a basis. With continuous testing and evaluation of the initial release, the developer were able to come up with series of incremental releases, and these releases were developed through the integration of the results gathered from the tests, evaluations, and feedbacks. When the results are to be implemented, the developers use paper prototyping before directly applying the modifications directly to the system itself.

Activities and steps of the Prototyping:

Analysis The first step encompassed the tasks that go into determining the needs or conditions to meet for a new or altered product, taking account of the possibly conflicting requirements of the various stakeholders, such as beneficiaries or users. This step was critical to the success of the development project. The requirements must be actionable, measurable, testable, related to identified needs or opportunities, and defined to a level of detail sufficient for system design.

For the analysis, the proponents conducted an interview to gather the data needed and went to the institution to observe how the manual system works.

Design Design is a process of problem-solving and planning for a software solution. After the purpose and specifications of software are determined, software developers will design or employ designers to develop a plan for a solution. It includes low-level component and algorithm implementation issues as well as the architectural view. The developers considered different aspects in the design of the system. Each aspect must reflect the goals that the developer and H.S.D. were trying to achieve. Some of the aspects that the developer incorporated in their study are the following: compatibility, extensibility, fault-tolerance, maintainability, reliability, reusability, and usability. For the design of the system, the developer also used data flow diagram and entity relationship diagram along with normalization.

Implementation Implementation is the process of writing, testing, debugging/troubleshooting, and maintaining the source code of computer programs. This source code is written in a programming language. The purpose of programming is to create a program that exhibits a certain desired behavior. Coding requires expertise in many different subjects, including knowledge of the application domain, specialized algorithms and formal logic.

The developers used PHP for the coding and the interface and for the system to be available online. Upon being uploaded, errors were expected to emerge since the codes must also be compatible with the technology that the host website supports, further debugging was done until there are no errors found.

Testing Testing is an empirical investigation conducted to provide the company with information about the quality of the product or service under test, with respect to the context in which it is intended to operate. It also provides an objective, independent view of the software to allow the business to appreciate and understand the risks at implementation of the system. Test techniques include the process of executing a program or application with the intent of finding software bugs. It can also be the process of validating and verifying that the system meets the requirements that guided its design and development. Deployment Deployment is all of the activities that make a software system available for use. The general deployment process consists of several interrelated activities with possible transitions between them. These activities can occur at the producer site or at the consumer site or both. Deployment should be interpreted as a general process that has to be customized according to specific requirements or characteristics.

When the system became available over the web, the both the institution and the developer were able to evaluate how the system provided the needs of the institution and how the developer were able to include the specified requirements to the system that they have developed.

Maintenance Maintenance is the modification of a software product after delivery to correct faults, to improve performance or other attributes, or to adapt the product to a modified environment. When the system became ready and available for H.S.D., there continuous improvements and modifications would be done as needed to correct the errors that the system might encounter and might cause it to be inefficient to meet the needs of its users for the H.S.D..

2.2 Conceptual Framework

SRDMHRDFIRST CARE CLINICSTUDENTEMPLOYEELPU CARES SYSTEMRESOURCESACCOUNTING

The figure shows that the system will have the following as the source of the data that will be used in processing: the SRDM: for the student record, HRD: for the employees records, FIRST CARE CLINIC: for the result of the laboratory test, STUDENT: for consultation information, EMPLOYEE: for consultation information and ACCOUNTNG: for the medicine supplies.

2.3 System Functionalities

The Proposed Use-Case diagram is subdivided in to four (4) subsystems namely: Record Keeping, Medical Laboratory Outsourcing, Consultation and the Inventory subsystems. It will be a lot easier to analyze the whole system if it is broken down into smaller bits of operation. Several actors were identified and these are Student Record Management Department (SRMD) which can feed all the initial information to the system (e.g. students name, year, course, gender, etc.), the First Care Clinic who caters our medical laboratory needs for students and employees, the patient or client (e.g. students or employees), the doctor who is currently the head of the clinic, the nurse who is serving a vital role in the implementation of the system, the Accounting office who accepts initially the delivered medical supplies. The time is also considered as an action since the proposed system will automatically generation reports and even trigger and event based on time set by the user.

Record KeepingSubsystemMedical OutsourceSubsystemInventorySubsystemConsultationSubsystemExtractClients InfoGenerateReferral SlipUpdateClients recordGenerateMedical reportForwardClients InfoEncodeMedical ResultSubmitPurchase RequestDeliverMedical suppliesGenerateInventoryReportRequestMedical ConsultationCollectPre-assessmentDispenseMedicine/PrescriptionDiagnosisReceiveMedical resultSRMDAccountingTimeDoctorClientStudentEmployeeFirst CareClinicNurseiMEDSIntegrated Medical and Dental SystemHRDUpdateInventoryRecord

Figure 4 Use-Case Diagram3. Business Process Flow of existing System

Figure 3 Context Diagram of the Existing System

Figure 4 Leveled Data Flow Diagram of Existing System3.1 Processes

3.1.1 Verify Student/Employee Data and Provide Referral SlipThis is the process where the Health Services Department gathers and verifies the student data of the patient through their Enrolment Assessment Form (EAF) in order to refer him to an external medical agency for evaluation and/or observation. Usually, the H.S.D. gets the patients name, student number and course.3.1.2 Create Student/Employee Medical RecordA New Student/Employee medical record will be created in the H.S.D., the medical record will be added to the storage of H.S.D. and will be updated for future use.3.1.3 Update Student/Employee Medical RecordStudent/Employee Medical Records determines if a Student/Employee has his own medical records stored inside the cabinets of the H.S.D. If, so the medical record of the respective Student/Employee will be updated.3.1.4 Issuing of Medical CertificateMedical Certificate are one of the most important documents produced by the Health Services Department (H.S.D.). It serves as a confirmation if a certain student/employee, is cleared and free from all possible infirmities. A Student/Employee will only be given a medical certificate if his/her medical findings are verified to be normal. It is good to note that verification may come from external medical agency referred by the said department. At present, the H.S.D. will now just stamp the students E.A.F. rather than to give away clearance stubs.3.1.5 Medical ConsultationMedical Consultations are inherent to both students and employees from the day they were enrolled at or employed to Lyceum of the Philippines University Cavite Campus. This privilege includes medical and dental counseling, health teaching and referrals to those who seek consultations.3.1.6 Dispense MedicinesThe Health Services Department monitors the outgoing medicines whenever an employee or a student requests for a medicine. This process involves a record known as the Dispensed Medicine Log Sheet.3.1.7 Request MedicineOne of the most important tasks of the H.S.D. is to make it to a point that all consumed medicines be reinstated to their desired quantity through a process known to the department as the Medicine Requisition. Medicine Requisition is done every first Friday of the month.

4. Functional Specification/Use Case NarrativesiMEDSIntegrated Medical and Dental System

Author(s): Jocelyn T. LipataDate: October 30, 2011Cheryl Lou R. TinaanVersion:Joel T. BautistaUse-case Name:Extract Clients InformationUse-Case TypeSystem Analysis:

Use-case ID:LPU-iMEDS001

Priority:High

Source:None

Primary BusinessActor:SRMD (Student Record Management Department)HRD (Human Resource Department)

OtherParticipatingActors:Nurse

OtherInterestedStakeholders: Students Interested to be included in the list of extracted information Employees Interested to be included in the list of extracted information Management Interested in the number of freshmen students and new employees that will undergo medical check-up

Description:This Use-case describes the event of extracting freshmen and new employees information from the Lyceum Integrated System Service (LISS) with the permission of the Chief of the SRMD and the Director of HRD. The Nurse can then access it, however, this information cannot be altered.

Precondition:SRMD and HRD must first grant the access to the LISS for the nurse to view and extract information from the database by checking the share information checkbox in the LISS.

Trigger:This use-case is initiated when the SRMD and the HRD grant the extraction.

Typical Courseof Events:Actor ActionSystem Response

Step 1: At the end of the enrolment period, SRMD Chief grants the access of the Nurse by clicking the share button. Step 2: The HRD grants the access of the Nurse by clicking the share button.Step 4: The Nurse logs-in to his/her account in the iMeds website.Step 8: The Nurse extracts the information by clicking the generate button.Step 3: The system notifies the Nurse that the students and employees information are ready for extraction.Step 5: The system responds by accepting the username and password.Step 6: The system validates the username and password.Step 7: Once the user account is validated, the system generates a confirmation message.Step 9: The system transfers the extracted information to the Health Service Department database exclusive for medical and dental records of the students and employees.Step 10: The system displays a message saying extraction completed.

Alternate Courses:Alt-Step 3: In the absence of the Nurse, the Doctor logs-in his/her account.Alt-Step 4: In case the HRD has not yet granted the access, the Nurse can send a request thru the iMEDS website.

Conclusion:This use-case concludes when the Nurse clicks the generate button.

Business Rules: Students information is only available at the end of the enrolment period. Employee information can only be generated from the HRD Access can be done only if SRMD and HRD approve the sharing of data. Access can only be granted for the legitimate user(s). Nurse cannot alter the information. The system records the transaction

Implementation Constraints and Specification:GUI to be provided for the SRMD, HRD and Health Service Department.Database must be created and used exclusively to handle medical records of students and employees.

Assumptions:The Nurse will be notified by the system confirming that information from the SRMD and HRD are now available and ready for extraction.

Open Issues:1. Need to determine who will be given access among the existing personnel in the Health Care Department

Author(s): Jocelyn T. LipataDate: October 30, 2011Cheryl Lou R. TinaanVersion:Joel T. BautistaUse-case Name:Forward Clients InformationUse-Case TypeSystem Analysis:

Use-case ID:LPU-iMEDS002

Priority:High

Source:Extract Student Information - LPU-IMEDS001

Primary BusinessActor:Nurse

OtherParticipatingActors:First Care Clinic

OtherInterestedStakeholders: Students Interested to be included in the list to be forwarded to the First Care Clinic Employee Interested to be included in the list of the newly hired employees to undergo laboratory tests. Management Interested in the medical laboratory results both for students and employees

Description:This Use-case describes the event of submitting or forwarding the students information to First Care Clinic for Medical Laboratory Outsourcing since the university cannot accommodate such services as of the moment. This procedure can be facilitated by allowing First Care Clinic representative to view/print the student and employees basic information.

Precondition:The Nurse must enter the correct recipient in the input box and must click the send button.The First Care Clinic must know the URL of the iMEDS.

Trigger:This use-case is initiated when the Nurse enters the intended recipient in the sent to input box and clicks the send button.

Typical Courseof Events:Actor ActionSystem Response

Step 1: The Nurse enters the recipient in the recipient input box.Step 2: The Nurse clicks the send button.Step 4: The Nurse logs out his/her account.Step 3: The system responds by displaying a message saying the massage has been sent.Step 5: The system logs the date, time and the user account for documentation purposes.Step 6: The system logs-out.

Alternate Courses:Alt-Step 3: In case of technical problem in the network, the Nurse prints the extracted information.Alt-Step 4: The Nurse faxes it to the First Care ClinicAlt-Step 5: The Nurse verifies if message has been received by First Care Clinic thru a phone callAlt-Step 6: If the fax massage is not received, the Nurse must re-fax the message.

Conclusion:This use-case concludes when the Nurse logs-out from the system after clicking the send button.

Business Rules: The Nurse must enter the complete information of the recipient. The Nurse must click the send button. The Nurse must wait for the system confirmation that the message has been sent.

Implementation Constraints and Specification:GUI to be provided to the Health Service Department.

Assumptions:The Nurse will be notified by the system that the message has been sent.

Open Issues:1. Need to determine who from among the First Care Clinic staff is authorized to receive the message from LPU.

Author(s): Jocelyn T. LipataDate: October 30, 2011Cheryl Lou R. TinaanVersion:Joel T. Bautista Use-case Name:Encode Medical ResultUse-Case TypeSystem Analysis:

Use-case ID:LPU-iMEDS003

Priority:High

Source:Forward Clients Information - LPU-IMEDS002

Primary BusinessActor:First Care Clinic

OtherParticipatingActors:Nurse

OtherInterestedStakeholders: Clients (Student and Employees) Interested in the medical laboratory results. Management Interested in the medical results.

Description:This Use-case describes the event of encoding medical laboratory results of the students and employees thru the use of the iMEDS website once the lab procedures are done. A GUI is provided for First Care Clinic representative for them supply all the vital medical information of the client.

Precondition:The First Care Clinic representative must log-in to the iMEDS website and encode the results.

Trigger:This use-case is initiated when the First Care Clinic logs-in to the iMEDS website.

Typical Courseof Events:Actor ActionSystem Response

Step 1: The First Care Clinic representative logs-in to the iMEDS websiteStep 4: Once the validation is ok, First Care Clinic representative clicks the Encode medical result button.Step 5: First Care Clinic representative encodes the medical result.Step 7: First Care Clinic representative clicks the ok button once encoding is completed.Step 9: First Care Clinic representative logs-out.Step 2: The system responds by accepting the username and password.Step 3: The system validates the username and password.Step 6: The system records all transactions made in the database.Step 8: The system displays record saved.Step 10: The system records all the transactions and logs-out.Step 11: The system notifies the Nurse that medical result is now available.

Alternate Courses:Alt-Step 3: In case of technical problem in the network, the First Care Clinic representative prints the medical results.Alt-Step 4: The First Care Clinic representative faxes it to the LPU-Health Service DepartmentAlt-Step 5: The First Care Clinic representative verifies if message has been received by LPU-Health Service DepartmentAlt-Step 6: If the fax massage is not received, the First Care Clinic representative must re-fax the message.

Conclusion:This use-case concludes when the First Care Clinic representative encodes all the record successfully and log out from the system.

Business Rules: First Care Clinic logs-in to iMEDS web site. First Care Clinic encodes the medical laboratory results. First Care Clinic logs-out from the system. The system notifies the Nurse.

Implementation Constraints and Specification:Auto update in iMEDS database

Assumptions:The First Care Clinic representative will be notified by the system that all records saved.The Nurse on the other hand will receive a notification that medical result is now available.

Open Issues:1. Need to provide the First Care Clinic representative username and password2. Need to provide online notification to the Nurse of the status of the medical result even the Nurse is not logged in.

Author(s): Jocelyn T. LipataDate: October 30, 2011Cheryl Lou R. TinaanVersion:Joel T. Bautista Use-case Name:Receive Medical ResultUse-Case TypeSystem Analysis:

Use-case ID:LPU-iMEDS004

Priority:High

Source:Encode Medical Result - LPU-IMEDS003

Primary BusinessActor:Nurse

OtherParticipatingActors:Client

OtherInterestedStakeholders: Parents/Guardians Interested in the medical result to plan for appropriate action Management Interested in the medical result to plan for appropriate course of action

Description:This Use-case describes the event of receiving medical result. The Nurse informs the student or the employee regarding the result especially those with medical findings.

Precondition:The Nurse must log-in to the iMEDS website and print the result.The Nurse must call the attention of the concerned students or employees regarding the status of the medical condition.

Trigger:This use-case is initiated when the Nurse logs-in the system and views the medical result.

Typical Courseof Events:Actor ActionSystem Response

Step 1: The Nurse logs-in to the iMEDS websiteStep 4: Once the validation is ok, the Nurse clicks the view button to display the medical result.Step 5: The Nurse filters the information by categories (e.g. by course, by year, by gender, by medical condition, etc.)Step 8: The Nurse informs the students and employees by writing a memo addressed to the chairs of different Colleges.Step 9: The Nurse logs-outStep 2: The system responds by accepting the username and password.Step 3: The system validates the username and password.Step 7: The system generates result based on the filter request set by the Nurse.Step 8: The system displays record saved.Step 10: The system records all the transactions and logs-out.

Alternate Courses:Alt-Step 3: In case of power failure, the Nurse may just use the printed copy as basis in releasing the memo.

Conclusion:This use-case concludes when the Nurse receives the medical result, filters the result and prints the result.

Business Rules: The Nurse logs-in to iMEDS web site. Performs filtering process Generates the medical result as basis of the memo and report Maintaining the privacy and confidentiality of the medical results.

Implementation Constraints and Specification:Auto filtering and custom filtering feature of record for the Nurses GUI

Assumptions:The Nurse will be able to filter-out information base on the needs of the user.The Nurse on the other hand will receive a notification that medical result is now available.

Open Issues:1. There is a need for filtering features in generating results2. Privacy issue should be taken cared of.3. Strict confidentiality of the medical results should be observered.

Author(s): Jocelyn T. LipataDate: October 30, 2011Cheryl Lou R. TinaanVersion:Joel T. Bautista Use-case Name:Request Medical ConsultationUse-Case TypeSystem Analysis:

Use-case ID:LPU-iMEDS005

Priority:High

Source:Receive Medical Result - LPU-IMEDS004

Primary BusinessActor:Client

OtherParticipatingActors:Nurse

OtherInterestedStakeholders: Parents/Guardians Interested to sign in the medical request form Management Interested in statistical result of freshmen and new employees that will seek request for consultation.

Description:This Use-case describes the event of recording medical request for consultation based on the result of the medical examination.

Precondition:The Nurse must be able to inform the students/employee regarding their medical condition or findings.The clients must fill-out Request for Medical Consultation Form

Trigger:This use-case is initiated when a client approaches the clinic for a request for a medical consultation based on the memo given to each college.

Typical Courseof Events:Actor ActionSystem Response

Step 1: The Client fills-in the Request for Medical Consultation form.Step 2: The Nurse verifies the informationStep 3: The Nurse encodes the information in the system.Step 4: The system responds by accepting the information from the medical consultation request form.Step 5: The system updates the database.

Alternate Courses:Alt-Step 2: In the absence of the Nurse, the Doctor can entertain the client

Conclusion:This use-case concludes when the system updates its database after pre-assessment information has been encoded.

Business Rules: The Client fills-in the medical consultation request form The Nurse encodes the information to the system from the medical request form.

Implementation Constraints and Specification:Auto scheduling/queuing of clients for medical consultation.

Assumptions:The Nurse will be able to release medical consultation schedule/queue coming from the system

Open Issues:1. The system should know the availability of the Doctor for auto generation of schedule/queue.

Author(s): Jocelyn T. LipataDate: October 30, 2011Cheryl Lou R. TinaanVersion:Joel T. Bautista Use-case Name:Collect Pre-assessmentUse-Case TypeSystem Analysis:

Use-case ID:LPU-iMEDS006

Priority:High

Source:Request for Medical Consultation - LPU-IMEDS005

Primary BusinessActor:Nurse

OtherParticipatingActors:Client

OtherInterestedStakeholders: Parents/Guardians Interested to accompany their sons/daughters during pre-assessment

Description:This Use-case describes the event of getting information from the client/patient such as vital signs to be encoded in the system. This will be added to the database of the Health Service Department (HSD) of the university. Medical history can be acquired from this database.

Precondition:The Nurse must encode to the database all the vital signs gathered in the pre-assessment.

Trigger:This use-case is initiated when the Client submits medical consultation request form.

Typical Courseof Events:Actor ActionSystem Response

Step 1: The Nurse performs the necessary vital sign examination to the client.Step 2: The Nurse then encodes the result of vital sign examination to the system.Step 3: The system responds by accepting the information from the pre-assessment procedure.Step 4: The system updates the database.Step 5: The system responds information savedStep 6: The system generates the schedule of the actual consultation.

Alternate Courses:Alt-Step 2: The client submits medical history (if theres any) to the Nurse as reference of his present condition.

Conclusion:This use-case concludes the system generates the schedule/queue of the client for medical consultation

Business Rules: The Client fills-in the medical consultation request form The Nurse encodes the information to the system from the medical request form.

Implementation Constraints and Specification:Auto updating of the schedule.

Assumptions:The Nurse will be able to release medical consultation schedule/queue coming from the system

Open Issues:1. The system should know the availability of the Doctor for auto generation of schedule/queue.

Author(s): Jocelyn T. LipataDate: October 30, 2011Cheryl Lou R. TinaanVersion:Joel T. Bautista Use-case Name:DiagnosisUse-Case TypeSystem Analysis:

Use-case ID:LPU-iMEDS007

Priority:High

Source:Collect Pre-assessment - LPU-IMEDS006

Primary BusinessActor:Doctor

OtherParticipatingActors:ClientNurse

OtherInterestedStakeholders: Parents/Guardians Interested to know the explanation of the findings and the recommendation of the Doctor. Management - Interested to know the result of the Doctors diagnosis

Description:This Use-case describes the event of evaluation and interpretation of the medical findings in comparison with the pre-assessment record of the clients. Diagnosis is required to be included it the medical record of the clients in the database.

Precondition:The Doctor must be able to completely interpret the medical findings and provide accurate diagnosis. The Nurse encodes the diagnosis given by the Doctor.

Trigger:This use-case is initiated when the Nurse successfully updated the database coming from the pre-assessment.

Typical Courseof Events:Actor ActionSystem Response

Step 1: The Doctor reads the pre-assessment.Step 2: The Doctor evaluates the findings from the medical lab outsourcingStep 3: The system responds by accepting the information from the pre-assessment procedure.Step 4: The system updates the database.Step 5: The system responds information savedStep 6: The system generates the schedule of the actual consultation.

Alternate Courses:Alt-Step 2: The client submits medical history (if theres any) to the Nurse as reference of his present condition.

Conclusion:This use-case concludes the system generates the schedule/queue of the client for medical consultation

Business Rules: The Client fills-in the medical consultation request form The Nurse encodes the information to the system from the medical request form.

Implementation Constraints and Specification:Auto updating of the schedule.

Assumptions:The Nurse will be able to release medical consultation schedule/queue coming from the system

Open Issues:1. The system should know the availability of the Doctor for auto generation of schedule/queue.

Author(s): Jocelyn T. LipataDate: October 30, 2011Cheryl Lou R. TinaanVersion:Joel T. Bautista Use-case Name:Dispense of Medicine/PrescriptionUse-Case TypeSystem Analysis:

Use-case ID:LPU-iMEDS008

Priority:High

Source:Diagnosis - LPU-IMEDS007

Primary BusinessActor:Nurse

OtherParticipatingActors:Client

OtherInterestedStakeholders: Parents/Guardians Interested to know about the medicines prescribed by the doctor. Management - Interested to know quantity of the medicines being disposed

Description:This Use-case describes the event of evaluation and interpretation of the medical findings in comparison with the pre-assessment record of the clients. Diagnosis is required to be included it the medical record of the clients in the database.

Precondition:The Doctor must be able to completely interpret the medical findings and provide accurate diagnosis. The Nurse encodes the diagnosis given by the Doctor.

Trigger:This use-case is initiated when the Nurse successfully updated the database coming from the pre-assessment.

Typical Courseof Events:Actor ActionSystem Response

Step 1: The Nurse records the diagnosis of the Doctor, prescribed medicine or the prescription control number.Step 5: The Nurse releases the medicines/prescriptions.Step 6: The Nurse logs the medicine/prescription to the log-book.Step 7: The Client signs in the log-bookStep 2: The system responds by accepting the information supplied by the Nurse.Step 3: The system updates the database.Step 4: The system responds information saved

Alternate Courses:Alt-Step 2: The client submits medical history (if theres any) to the Nurse as reference of his present condition.

Conclusion:This use-case concludes the system generates the schedule/queue of the client for medical consultation

Business Rules: The Client fills-in the medical consultation request form The Nurse encodes the information to the system from the medical request form.

Implementation Constraints and Specification:Auto updating of the schedule.

Assumptions:The Nurse will be able to release medical consultation schedule/queue coming from the system

Open Issues:2. The system should know the availability of the Doctor for auto generation of schedule/queue.

Author(s): Jocelyn T. LipataDate: October 30, 2011Cheryl Lou R. TinaanVersion:Joel T. Bautista Use-case Name:Generate Referral SlipUse-Case TypeSystem Analysis:

Use-case ID:LPU-iMEDS008

Priority:High

Source:Dispense Medicine/Prescription - LPU-IMEDS007

Primary BusinessActor:Nurse

OtherParticipatingActors:Client

OtherInterestedStakeholders: Management - Interested to know the partner institution where the client/patient is referred.

Description:This Use-case describes the event of generating computerized referral slip based on the collated information from the initial medical findings, the pre-assessment result and the Doctors diagnosis.

Precondition:The Doctor must be able to complete all the information from the initial medical findings, the pre-assessment result up to the Doctors diagnosis. The system must be able to generate computerized referral slip to lessen human intervention.

Trigger:This use-case is initiated after the Nurse successfully encoded the Doctors diagnosis to the system.

Typical Courseof Events:Actor ActionSystem Response

Step 1: The Doctor reads the pre-assessment.Step 2: The Doctor evaluates the findings from the medical lab outsourcingStep 3: The system responds by accepting the information from the pre-assessment procedure.Step 4: The system updates the database.Step 5: The system responds information savedStep 6: The system generates the schedule of the actual consultation.

Alternate Courses:Alt-Step 2: The client submits medical history (if theres any) to the Nurse as reference of his present condition.

Conclusion:This use-case concludes the system generates the schedule/queue of the client for medical consultation

Business Rules: The Client fills-in the medical consultation request form The Nurse encodes the information to the system from the medical request form.

Implementation Constraints and Specification:Auto updating of the schedule.

Assumptions:The Nurse will be able to release medical consultation schedule/queue coming from the system

Open Issues:1. The system should know the availability of the Doctor for auto generation of schedule/queue.

Author(s): Jocelyn T. LipataDate: October 30, 2011Cheryl Lou R. TinaanVersion:Joel T. BautistaUse-case Name:Update Inventory RecordUse-Case TypeSystem Analysis:

Use-case ID:LPU-iMEDS009

Priority:High

Source:Generate Referral Slip - LPU-IMEDS008

Primary BusinessActor:Nurse

OtherParticipatingActors:Client

OtherInterestedStakeholders: Management Interested with the Updated Inventory report of HSD for the Administrative planning and Budget request.

Description:This Use-case describes the event of generating computerized referral slip based on the collated information from the initial medical findings, the pre-assessment result and the Doctors diagnosis.

Precondition:The Doctor must be able to complete all the information from the initial medical findings, the pre-assessment result up to the Doctors diagnosis. The system must be able to generate computerized referral slip to lessen human intervention.

Trigger:This use-case is initiated after the Nurse successfully encoded the Doctors diagnosis to the system.

Typical Courseof Events:Actor ActionSystem Response

Step 1: The Doctor reads the pre-assessment.Step 2: The Doctor evaluates the findings from the medical lab outsourcingStep 3: The system responds by accepting the information from the pre-assessment procedure.Step 4: The system updates the database.Step 5: The system responds information savedStep 6: The system generates the schedule of the actual consultation.

Alternate Courses:Alt-Step 2: The client submits medical history (if theres any) to the Nurse as reference of his present condition.

Conclusion:This use-case concludes the system generates the schedule/queue of the client for medical consultation

Business Rules: The Client fills-in the medical consultation request form The Nurse encodes the information to the system from the medical request form.

Implementation Constraints and Specification:Auto updating inventory record

Assumptions:The Nurse will be able to release medical consultation schedule/queue coming from the system

Open Issues:1. The system should know the availability of the Doctor for auto generation of schedule/queue.

Author(s): Jocelyn T. LipataDate: October 30, 2011Cheryl Lou R. TinaanVersion:Joel T. Bautista Use-case Name:Submit Purchase ReportUse-Case TypeSystem Analysis:

Use-case ID:LPU-iMEDS010

Priority:High

Source:Update Inventory - LPU-IMEDS009

Primary BusinessActor:Nurse

OtherParticipatingActors:Accounting

OtherInterestedStakeholders: Doctor Interested in the Purchase request to check if there is additional supplies or even equipment needed. Management - Interested in the amount of the supplies and equipment being requested with supporting documents. Clients Interested in the content of the request since they are the stakeholders of the institution.

Description:This Use-case describes the event of submitting Purchase Request to the Accounting office. The purchase request is based on the report produced by the system.

Precondition:The Nurse must submit Purchase Request to the Accounting Office.The Doctor must affix his/her signature being the head of the Health Care Department

Trigger:This use-case is initiated after the Nurse successfully updated the inventory record. The system will recommend the priority supplies/equipment for purchase.

Typical Courseof Events:Actor ActionSystem Response

Step 1: The Nurse verifies the inventory report if it is updatedStep 2: The Doctor evaluates the findings from the medical lab outsourcingStep 3: The system responds by accepting the information from the pre-assessment procedure.Step 4: The system updates the database.Step 5: The system responds information savedStep 6: The system generates the schedule of the actual consultation.

Alternate Courses:Alt-Step 2: The client submits medical history (if theres any) to the Nurse as reference of his present condition.

Conclusion:This use-case concludes the system generates the schedule/queue of the client for medical consultation

Business Rules: The Client fills-in the medical consultation request form The Nurse encodes the information to the system from the medical request form.

Implementation Constraints and Specification:Auto updating of the database and inventory record.Auto alert when purchase request is to be made.

Assumptions:The Nurse will be notified by the system regarding the needed supplies/equipment to be requested.

Open Issues:1. Need to know the supplies/equipment to be requested thru computer alert

Author(s): Jocelyn T. LipataDate: October 30, 2011Cheryl Lou R. TinaanVersion:Joel T. BautistaUse-case Name:Deliver Medical SuppliesUse-Case TypeSystem Analysis:

Use-case ID:LPU-iMEDS011

Priority:High

Source:Submit Purchase Report - LPU-IMEDS010

Primary BusinessActor:Nurse

OtherParticipatingActors:Accounting

OtherInterestedStakeholders: Doctor Interested in the delivery of the medical supplies/equipment Management - Interested in the amount of the supplies and equipment being delivered Clients Interested if the supplies are readily available.

Description:This Use-case describes the event of accepting the delivery of medical supplies.

Precondition:The Nurse must sign acceptance form from the Accounting Office.The Doctor must affix his/her signature being the head of the Health Care Department

Trigger:This use-case is initiated after the Nurse successfully updated the inventory record. The system will recommend the priority supplies/equipment for purchase.

Typical Courseof Events:Actor ActionSystem Response

Step 1: The Nurse verifies the inventory report if it is updatedStep 2: The Doctor evaluates the findings from the medical lab outsourcingStep 3: The system responds by accepting the information from the pre-assessment procedure.Step 4: The system updates the database.Step 5: The system responds information savedStep 6: The system generates the schedule of the actual consultation.

Alternate Courses:Alt-Step 2: The client submits medical history (if theres any) to the Nurse as reference of his present condition.

Conclusion:This use-case concludes the system generates the schedule/queue of the client for medical consultation

Business Rules: The Client fills-in the medical consultation request form The Nurse encodes the information to the system from the medical request form.

Implementation Constraints and Specification:Auto updating of the database and inventory record.Auto alert when purchase request is to be made.

Assumptions:The Nurse will be notified by the system regarding the needed supplies/equipment to be requested.

Open Issues:1. Need to know if the supplies/equipment delivered conforms with the requested specifications.

Author(s): Jocelyn T. LipataDate: October 30, 2011Cheryl Lou R. TinaanVersion:Joel T. BautistaUse-case Name:Generate Inventory ReportUse-Case TypeSystem Analysis:

Use-case ID:LPU-iMEDS012

Priority:High

Source:Deliver Medical Supplies - LPU-IMEDS011

Primary BusinessActor:Nurse

OtherParticipatingActors:Accounting

OtherInterestedStakeholders: Doctor Interested in the Purchase request to check if there is additional supplies or even equipment needed. Management - Interested in the amount of the supplies and equipment being requested with supporting documents. Clients Interested in the content of the request since they are the stakeholders of the institution.

Description:This Use-case describes the event of submitting Purchase Request to the Accounting office. The purchase request is based on the report produced by the system.

Precondition:The Nurse must submit Purchase Request to the Accounting Office.The Doctor must affix his/her signature being the head of the Health Care Department

Trigger:This use-case is initiated after the Nurse successfully updated the inventory record. The system will recommend the priority supplies/equipment for purchase.

Typical Courseof Events:Actor ActionSystem Response

Step 1: The Nurse verifies the inventory report if it is updatedStep 2: The Doctor evaluates the findings from the medical lab outsourcingStep 3: The system responds by accepting the information from the pre-assessment procedure.Step 4: The system updates the database.Step 5: The system responds information savedStep 6: The system generates the schedule of the actual consultation.

Alternate Courses:Alt-Step 2: The client submits medical history (if theres any) to the Nurse as reference of his present condition.

Conclusion:This use-case concludes the system generates the schedule/queue of the client for medical consultation

Business Rules: The Client fills-in the medical consultation request form The Nurse encodes the information to the system from the medical request form.

Implementation Constraints and Specification:Auto updating of the database and inventory record.Auto alert when purchase request is to be made.

Assumptions:The Nurse will be notified by the system regarding the needed supplies/equipment to be requested.

Open Issues:2. Need to know the supplies/equipment to be requested thru computer alert

5. Design Specification

5.1 Class DiagramFigure 5 Class DiagramClass diagram shows a set of classes, interfaces, and collaborations and their relationships also include active classes address the static process view of a system.. These diagrams are the most common diagram found in modeling object-oriented systems. Class diagrams address the static design view of a system for it shows a set of classes, interfaces, and collaborations and their relationships. Our class diagram is composed of 6 classes. Included here are the operations that will be implemented for every class.5.2 Database Design

Figure 6 Entity Relationship DiagramAn Entity-Relationship diagram is drawn at an early stage and developed as the requirements of the database and its processing become better understood. An entity-relationship diagram could serve as the basis for the design of the files in a conventional file-based system as well as for a schema diagram in a database system. The systems database composed of 6 tables to store the needed data for the operation of the system. The ERD shows also the relationship of each entity.5.3 Tables & Structures

5.3.1 Table Name: Student

Table Description: All Information of the student will be retrieve in the student table. The table will serves for verification of the student.

Field NameData TypeDescription

Stud_NoINT(10)The primary key of the table. It is a unique identifier of the employee.

Stud_NameVARCHAR(6)Name of the student.

CourseVARCHAR(6)Course of a particular student.

YearVARCHAR(4)Year level of the student.

SectionVARCHAR(6)Section where the student is assigned.

GenderVARCHAR(2)It serves the gender of the student if male or female.

Birth_DateDATETIME(20)The date of the birth of the student.

AgeNUMERIC(3)The age of the student.

5.3.2 Table Name: Employees

Table Description: All information of the employees will be retrieve in the employee table.

Field NameData TypeDescription

Emp_NoINTERGER(10)The primary key of the table. It is a unique identifier of the employee.

Emp_NameVARCHAR(50)Name of the employee.

CollegeVARCHAR(6)College where the employee is assigned.

DepartmentVARCHAR(4)Department were the employee is assigned.

Birth_dateVARCHAR(20)The date of the birth of the employee.

GenderV ARCHAR(2)It serves the gender of the student if male or female.

AgeVARCHAR(3)The age of the employee.

5.3.3 Table Name: Medical Record

Table Description: Records for lab medical results of the employee and student.

Field NameData TypeDescription

MedRec_NoINTEGER(10)Primary key for every transaction that are done in First Care.

Stud_NoINTEGER(10)Student number of a student. Also a foreign key.

Emp_NoINTEGER(10)Employee number of an employee. Also a foreign key.

Diag_Rec_NoCHAR(4)Serves as a foreign key that will describe the diagnosis for employee and student.

Blood TypeTEXT(20)Blood Type of the student and employee.

Blood ChemTEXT(20)Blood Chemistry for the student and employee.

UrinalysisTEXT(20)Laboratory Test findings for urinalysis.

Stool ExamTEXT(20)Laboratory Test findings for Stool exam.

AllergiesTEXT(20)Laboratory Test findings for Allergies.

Blood PressureTEXT(20)Blood Pressure of the student and employee.

5.3.4 Table Name: Medicine

Table Description: Storage for Medicine Information

Field NameData TypeDescription

Med_CodeINTEGER(10)Medicine code and serves as primary key.

Med_NameVARCHAR(30)Name of the medicine.

Med_CategoryVARCHAR(6)Category of the medicine.

BrandTEXT(20)Brand of the medicine.

Expiration_DateDATETIME(20)Expiration date of the medicine.

5.3.5 Table Name: Diagnosis

Table Description: Diagnosis table stores the diagnosis, prescribed medicine and recommendation of the physician.

Field NameData TypeDescription

Diag_Rec_NoINTEGER(10)Primary key of the table. Diagnosis Record Number.

Stud_NoINTEGER(10)Student Number of a student.

Emp_NoINTEGER(10)Employee Number of an employee.

Med_Rec_NoINTEGER(10)Medical Record Number.

Med_CodeINTEGER(10)Medical Code

Consult_DateDATETIME(6)Date of the consultation.

DiagnosisTEXT(30)Diagnosis of the physician.

PrescriptionTEXT(30)Prescription of the physician.

RecommendationTEXT(30)Recommendation of the physician.

5.3.6 Table Name: Inventory

Table Description: Storage for inventory of medicines.

Field NameData TypeDescription

Item_IDINTEGER(10)Item ID of the inventory and primary key for the table.

Med_CodeVARCHAR(10)Medicine code and it is a foreign key.

Starting_InventoryINTEGER(6)No. of stocks on hand.

Delivery_dateDATE(20)Date of the delivery of stocks

Med_IssuanceVARCHAR(20)Medical Issuance.

Date_IssuedDATE(2)Date when the stocks was issued.

5.4 Interface designFigure 7 Graphical User Interface (Log In)Figure 8 Graphical User Interface (Home Page)Figure 9 Graphical User Interface (Registration)

6. Appendices6.1 Glossary of Terms6.1.1 Blood Type Classification of blood based on the presence or absence of inherited antigenic substances on the surface of the red blood cells (RBCs).6.1.2 Bug A colloquial term used for any error in a piece of software.6.1.3 Computerization To furnish with a computer or computer system; to enter, process, or store (information) in a computer or system of computers.6.1.4 Diagnosis The determination of the nature if a disease or condition or the distinguishing of one disease or condition from another. Assessment may be made through physical examination, laboratory test, or the like and may be assisted by computerized programs designed to enhance the decision-making process.6.1.5 Electronic Medical Records (EMR) Are patient medical records that are stored in a computer instead of paper.6.1.6 Fecalysis It is also known as stool analysis. It refers to a series of laboratory test done on fecal samples to analyze the condition of a persons digestive tract in general.6.1.7 Hematology Branch of internal medicine, physiology, pathology, clinical laboratory work, and pediatrics that is concerned with the study of blood, the blood-forming organs, and blood diseases.6.1.8 Radiology Is the field of medicine that uses x rays and other means to create images of structures and processes inside the body.6.1.9 Urinalysis Examination of urine by clerical, physical, or microscopic means. Routine urinalysis usually includes performing chemical screening tests, determining specific gravity, observing any unusual color or odor, screening for bacteraemia, and examing the sediment microscopically.6.1.10 Vital Signs Are measures of various physiological statistics, often taken by health professionals, in order to assess the most basic body functions. Vital signs are an essential part of a case presentation. The act of taking vital signs normally entails recording body temperature, pulse rate (or heart rate), Blood pressure, and respiratory rate, but may also include other measurements. Vital signs often vary by age.6.1.11 X-Ray Penetrating electromagnetic radiation emitted when the inner orbital electrons of an atom are excited and release energy in the same energy range as gamma rays (0.010-10 Mev), but of non-nuclear origin of shorter wavelength than ultraviolet; soft X-Rays or Grenz rays are less penetrating and longer in wavelength than hard X-Rays.6.2 Project Proposal

Project Name: Integrated Medical and Dental SystemI. Project DescriptionThe Health Services Department renders consultation as its primary goal. The physician and other staff perform first its main concern by checking the condition of the patient; they check the medical records and the vital signs. The physician mainly serves with regards with the chief complaints, as they give prescription, advises, and health teachings. There are also times when assessments are also performed. Based from the patients condition, the patient will be advised either to stay or to rest for a while in the Health Services Department also cover up existing problems. The current system they are utilizing necessitates improvements for faster, more convenient and more efficient procedures. The said department is unofficially tied up with other health institutions but rather its partnered with the First Care Medical Clinic and Laboratory located at Brgy. Manggahan. During the enrollment, enrollees are referred to have initial health check-ups on the said clinic. Information are gathered from there and transferred to the university using thumb drives. From that phase onwards, more time is consumed. Going to the preceding academic year, they will face difficulties with regards to the student queuing.Hence, the present system of the Health Services Department is still passive mostly with manual operations; therefore, believe that it needs aid from the thinking machine for a better and innovated Health Services Department.II. Objectives1. To be able to reduce manpower cost.2. To improve customer service at Health Services Department.3. To improve management information when it comes to medical record tracking and medical record keeping of the students and employees of LPU.4. To propose a computerized system that will provide the Health Services Department the following:a. A computerized medicine dispensing record as well as its reports;b. A faster and more convenient way of indexing the students information;c. A shortened student queuing during the issuance of clearances;d. A strict monitoring of the students who are not complying with their medical requirements.III. Business ImperativeThis proposal seeks to create an Integrated Medical and Dental System (i-Med) Lyceum of the Philippines University Cavite Campus. The system features the computerization of the medical records of the students/employees as well as its updates. Its user accounts limit the number of people who can access the system. It also determines whether the given student is cleared or not depending on his medical record. This information is relevant to the staff because it determines whether the student is fit for enrolment or not. The system also performs inventory of the medicines available at the H.S.D. Though not intended for accounting purposes, the inventory keeps an accurate track of how many of the medicines are were dispensed to the students and how many were left. Converters and calculators are also added as auxiliary features of the system in order to help the staff perform their duties together with the system.IV. BenefitsLyceum of the Philippines Cavite Campus has just started operating since the year of 2008 as well as its facilities and departments and this includes the Health Services Department, that lead us students to develop a system that will contribute for the welfare of the department.The installation of this proposed system does not only concentrate with the benefits of the personnel in Health Services Department. This system is designed to eradicate array of problems of Health Services Department with efficiency, convenience, less manpower used and less time consumed.The developer aims to provide benefits to the following:The UniversityFirst and foremost, since most departments of the Lyceum of the Philippines University Cavite Campus are already functioning with the aid of a computerized system, the Health Services Department will now be adapting to the new specialized Information System as well. As a whole, the University will now become a more modern and a more computer based institution that will help the department in executing their respective processes without putting the employees jobs at risk but rather make their work easier and more convenient.The StudentsThe students will not anymore experience the long and exhausting queuing just to check whether they have already passed the requirements or not during the enrollment period. By implementing this system, the number of students during the enrollment period will be lessened and those who are already cleared of their requirements can now skip the long queue and proceed to the advising phase.

The Health Service DepartmentThe Health Service Department will now operate with the aid of the new system. As for the staff, they will no longer experience a hard time in doing their jobs such as organizing the students files, producing reports and inventories of the medicines, and issuance of medical and dental clearances because all of these will be possible in just a click of a mouse.V. Feature BehaviorThe Proposed System is specifically designed to meet the requirements of the Health Services Department.The HSD process of record keeping has been made faster, efficient and more reliable than that of the manual process. The developers have provided a database that will store the students information including their medical and dental records. Only the doctors and nurses are given the authority to have an access to these information pursuant to the rule that all information should be treated with strict confidentiality.In terms of organizing the dispensed medical log sheet, the system will automatically produce the total number of consumed medicines within a month. This report will help the department to keep track of the number of medicines that are still at hand.The proposed system will utilize a database to store the students medical and dental records. The system will only store students/employee medical and dental records. Access of the medical and dental records depends on whoever is logged in the system for confidentiality and security purposes.

VI. Data NeedsName of Document:Monthly Inventory ReportPrepared By: School NurseNumber of copies:2Frequency of Distribution:Monthly BasisRecipient:Accounting

Name of Document:E.A.F.Prepared By: SRMDNumber of copies:one copy per studentFrequency of Distribution:During enrollment prior to advisingRecipient:Student

Name of Document:Summary Consultation ReportPrepared By: H.S.D.Number of copies:One copyFrequency of Distribution:Per SemesterRecipient:Health Services DepartmentVII. Development RequirementsTo successfully perform the development of the project, the following requirements are needed:Knowledge Requirements Knowledgeable on record tracking and Medical processes (the manual process) Knowledgeable on database design & application Knowledgeable on web design & applicationSoftware Requirements Web tools with database development tools PHP Javascript & CSS Desgin tool (Photoshop CS5) Apache Server MySQL Internet Browser Windows Operating SystemHardware Requirements Laptop / Desktop Computer with specifications capable of handling web development. Minimum requirements is as follows: USB Mouse Keyboard Server Pentium 4 Monitor

7. References[1] Donald Yeates and Tony Wakefield, Systems Analysis and Design, (Prentice Hall)[2] Sikha Bagui and Richard Earp, Database Design Using Entity-Relationship Diagrams, (Auerbach Publications)[3] Kendall and Kendall, System Analysis and Desing, (McGrawHill Publishing)Software EngineeringPage | 1