ACME MEDICAL MANAGEMENT SYSTEM (AMMS)

Transcription

1 Section ACME MEDICAL MANAGEMENT SYSTEM (AMMS) 1.1 Purpose The main purpose of the AMMS is to facilitate reception desk functions at the Acme Medical Clinic (keeping track of patient and doctor information, scheduling appointments, etc) while allowing clinic staff to quickly search and locate patient information in real time. 1.2 Document Conventions All system features and requirements are listed in the order of decreasing precedence. 1.3 Intended Audience and Reading Suggestions This document is directed towards the designers, test team, project managers, and the ACME staff members who will be utilizing the patient-doctor database on a regular basis. It is highly recommended that the glossary as seen in Appendix A be reviewed prior to reading any section of this SRS. The suggested reading sequence for the ACME staff members is listed below: START 1. Appendix A 2. All subsections of section 1 3. Section Section Section Section All subsections of section 4 8. All subsections of section 5 END All other sections are optional for the ACME staff reader. 1.4 Product Scope AMMS is intended to be used by the reception desk staff and doctors at Acme Medical Clinic to replace the current manual process to manage patient and doctor information. Currently, ACME is plagued by an inefficient and ineffective management system, which often leads to several problems which includes but not limited to the following: 1. Patients missing appointments 2. Scheduling conflicts 3. Examination room conflicts 1

2 4. Unforeseen waiting period between schedule appointment time, and the time the patient is seen by the doctor 5. Loss of patient files. 6. Difficulty in finding patient records. The AMMS will improve efficiency by assisting the reception desk staff in performing desk related functions. Similarly, this system will assist the doctors by providing them with a real-time view of their day to day appointments. There are other benefits that the AMMS will provide and these are: 1. Avoidance of schedule conflicts 2. Automated schedule reminders 3. Improvement of appointment scheduling, while allowing scheduling of the maximum appointments possible per day 4. Quick search interface for locating patient information such as insurance information, vitals, and scheduled appointments 5. Quick search interface for locating doctor information such as doctor name, doctor specialty, and scheduled appointments 6. Electronic data storage of patient and doctor record. 7. Easy to use graphical user interface 8. Addition, deletion and change functionality for maintaining doctor and patient records 9. Enforcement of a no wait policy 1.5 References Project 2 Description <Link to Instructor site> Microsoft Design Guidelines for Class Library Developers < 2

3 Section 2.1 Product Perspectives The AMMS serves as a replacement of the manual process employed by the reception desk staff in performing their day-to-day activities Product Functions The major functions provided by AMMS are: Data entry and modifications o Patient information o Doctor information o Visit information Doctor information retrieval Automated appointment reminders Appointment rescheduling Appointment scheduling Provision and maintenance of payment information o Methods of Payment Credit Card information Co-pay information Preferred Payment option Cash Retrieval of patient history o Initial visit o Scheduling History o Doctors Seen o Purpose of Visits 3

4 o Descriptive Diagnosis and prescription o Vitals o Payments Provision of electronic forms for patience and doctors. 2.3 User Classes and Characteristics User/Actors Reception Desk staff Doctor Characteristics Primary user of AMMS. This will include but not limited to reception desk staffs, secretaries, and administrative assistance Secondary Users. 2.4 Operating Environment AMMS will operate in a windows environment particularly on either a Windows XP or 2000 operating system. The Microsoft.NET framework 2.0 is a required component that must co-exist with the system. 2.5 Design and Implementation Constraints The following constraints were identified for the AMMS. a) The AMMS must work in a windows environment. b) The AMMS must interface with SQL server. c) The AMMS must be implemented in Microsoft.NET framework 2.0. d) The user (reception desk staff or doctor) must be notified when a search request is inappropriate or illegal. e) When a search is performed, the search results should be displayed and organized in tabs with the default tab being the general information tab. f) Each doctor is able to have more than one patient. g) Each doctor must have a unique ID number. h) Each patient must have a unique ID number. i) Each patient must have only one record. j) Any computer on which the AMMS will be running must have the following properties: I. 233 MHz minimum processor clock speed required (single or dual processor system); II. Intel Pentium/Celeron family, or AMD K6/Athlon/Duron family, or compatible processor available III. 128 MB of RAM or higher recommended IV. 10 megabytes of free disk space. 4

5 The design convention or programming standard to be used is the Microsoft Design Guidelines for Class Library Developers. 2.6 User Documentation User documentation will be provided in the form of a manual and interactive tutorial that will be accessible through the help section of the system 2.7 Assumptions Below are the assumed factors that affect the requirements stated in this SRS: 1. It is assumed that ACME has user-password management system which will be incorporated into AMMS. 2. It is assumed that ACME has SQL Server installed and running on a server. 3. It is assumed that any user (reception desk staff or doctor) possess some basic computer skills with the ability to type and use a Windows XP or 2000 PC. 4. It is assumed that ACME has an enforced NO WAIT policy 5. It is assumed that an ACME has an existing system which supports SMTP through a Microsoft exchange server. 5

6 Section 3.1 User Interfaces Logon Data Entry 6

7 7

8 8

9 9

10 3.1.3 Patient and Doctor Search Doctor: Patient: 10

11 11

12 12

13 3.2 Hardware Interfaces Any computer on which the AMMS will be running must have the following properties: MHz minimum processor clock speed required (single or dual processor system); 2. Intel Pentium/Celeron family, or AMD K6/Athlon/Duron family, or compatible processor available MB of RAM or higher recommended megabytes of free disk space. 5. A 7200 rpm hard drive. 3.3 Software Interfaces 1. The computer must have Windows XP/2000 installed. 2. Will use the.net framework 3. Will use SQL server 4. Will use existing password management system, for single signon to the system. 3.4 Communication Interfaces 1. functionality will be supported by the existing system used by ACME. 2. sent from the AMMS is customizable with patient name, and schedule appointment information. 13

14 Section 4.1 DATA ENTRY Description and Priority The data entry feature will be used to enter the patient information into the computer after the patient fills out the hard copy form on their initial visit. Similarly, this feature will be used to enter doctor information. This data will be saved into the database and will be available in the future for viewing and editing purposes. PRIORITY HIGH Stimulus/Response Sequences Use Case: Data entry Diagram: Brief Description The user/reception desk staff enters the patient/doctor information into the computer. Reception desk staff Initial Step-By-Step Description Before this use case can be initiated, the reception desk staff must have already accessed AMMS. 1. The reception desk staff chooses to add new patient or doctor information. 14

15 2. New patient or doctor is entered into the form a. For doctors, personal information is entered. b. For patients, general, emergency, and medical insurance information are entered. 3. The system assigns a unique ID to the patient or doctor. 4. Information entered is saved to the database Functional Requirements REQ-1: The system must not allow duplicate patient or doctor records to be saved into the database. REQ-2: The system should only allow information to be saved if it conforms to the format specified in the tables below. REQ-3: The system should generate unique patient and doctor IDs. PATIENT PERSONAL INFORMATION TABLE INPUT ERROR CONDITIONS Numeric Character Numeric/Character Format Today s Date X 6/3/2007 First Name X John Last Name X Doe Middle Initial X K Street X 123 Gary Lane City X Tampa State X Florida Zip Code X Home Phone X (813) Work Phone X (813) Cell Phone X (813) Address X johnd@gmail.com Sex: M or F X M Date of Birth X 4/23/1967 Age X 40 SSN X Employer X Ford Motors Occupation X Mechanic Patient ID# X 12345A 15

16 EMERGENCY INFORMATION TABLE INPUT ERROR CONDITIONS Numeric Character Numeric/Character Format First Name X Mary Last Name X Doe Middle Initial X K Relationship X Sister Phone X (813) MEDICAL INSURANCE INFORMATION TABLE INPUT ERROR CONDITIONS Numeric Character Numeric/Character Format First Name X John Last Name X Doe Middle Initial X K Relationship To Patient X Self Insured s X Ford Motors Employer Insurance X Coverall123 Company Insured s SS# X 12345AG or ID# Group Number X 34656G DOCTOR PERSONAL INFORMATION INPUT ERROR CONDITIONS Numeric Character Numeric/Character Format First Name X Mark Last Name X Johnson Middle Initial X L Cell Phone # X (813) Work Phone # X (813) Pager Phone # X (813) Specialty/Field X Surgeon Doctor ID X 34656G 16

17 4.2 Modify Patient and Doctor Information Description and Priority The reception desk staff should be allowed to update a patient and doctor information, and delete doctors. Priority: HIGH Stimulus Response Sequences Use Case: Modify patient and doctor information Diagram: Search Doctor/Patient Modify Data Initial Step-By-Step Description Before this use case can be initiated, the reception desk staff must have already accessed AMMS. 1. The reception desk staff enters search criteria. 2. The reception desk staff clicks record of interest from the search result returned. 3. The reception desk staff edits information as need be Functional Requirements REQ-1: The system must permit the user to search for patient and doctor. REQ-2: The system must permit patient or doctor information editing. 17

18 4.3 Schedule Appointments Description and Priority This feature is intended to give the reception desk staff the ability to schedule appointments based on a doctor s availability. Priority: HIGH Stimulus Response Sequences Use Case: Scheduling Diagram: Search Doctors calendar Reception desk staff Update Doctors calendar Save appointment Initial Step-By-Step Description Before this use case can be initiated, the reception desk staff must have already accessed AMMS. 1. The patient provides appointment specific information such as date and/or doctor of interest. 2. The reception desk staff searches for available appointment times based on these criteria. 3. The reception desk staff presents available options to the patient, and other required scheduling information such as purpose of visit,. 4. Upon confirmation of an appointment time and doctor with the patient, the reception desk staff records and saves the appointment which must be no less than 15 minutes apart from adjacent appointments. 5. The doctor s calendar is modified accordingly as appointments are saved. Note: if this is the patient first appointment with the clinic, and prospective patient and reception desk staff is not in direct contact (e.g. Over the hone) then upon saving the appointment the system automatically creates a new patient record based on the 18

19 information provided which must include First name, Family name, and at least one contact information, and a random patient Id is generated Functional Requirements REQ-1: The reception desk staff should be able to search the calendars of doctors by date, or earliest time of availability. If the doctor requested is not available at the time specified, the result presented to the reception desk staff must be the closest available time for that doctor, and names of other doctors which are available at the specified time. REQ-2: Search result must be sorted by earliest possible available time if no time is specified, or by closest available time as specified. REQ-3: The system should allow sorting by doctor. REQ-4: The system should not allow the reception desk staff to schedule appointments within 15 minutes of each other. REQ-5: The reception desk staff should be able to save appointments to the database. REQ-6: The system should automatically post appointment to the doctor s calendar. REQ-7: Allow for receptionist to create a new patient record, using just the prospective patient first name, last name, and at least one method of contact. 19

20 4.4 Reschedule Appointments Priority: High Stimulus Response Sequences Use Case: Reschedule appointments Diagram: Search Doctors calendar Reception desk staff Retrieve appointments Modify appointment Save appointment <<Include>> Update Doctors calendar Doctor Inform Receptionist Scenario: Patient initiates reschedule Initial Step-By-Step Description (patient rescheduling) Before this use case can be initiated, the reception desk staff must have already accessed AMMS. 1. The patient requests to reschedule appointment. 2. The reception desk staff retrieves patient s appointment information. 3. The reception desk staff modifies the appointment as requested. Modifying an appointment includes canceling, and making updates such as changing the appointment date, or doctor. 4. The reception desk staff saves changes. 5. The system automatically updates the calendar of the doctors involved to reflect changes to the appointment. 20

21 Scenario: Doctor initiates reschedule Initial Step-By-Step Description (Doctor rescheduling) Before this use case can be initiated, the reception desk staff must have already accessed AMMS. 1. The doctor selects which appointments are to be modified. Modification entails either canceling the appointment or changing the time for appointment. 2. The system notifies the reception desk staff that an appointment was modified. 3. If certain conditions are satisfied (see decision table below), the patient is informed about the changes. 4. If the appointment is cancelled within 24 hours of scheduled time, and the secondary doctor is available, then the patient is automatically assigned to the secondary doctor, and changes are reflected on affected doctors calendars. Appointment cancelled on Doctor Schedule by Doctor is within 24 hours Other Doctors are available to take over Appointment cancelled on Doctors Schedule Patients Secondary Doctor is available to take the appointment T T F F T T F F T F T F T F T F T T T T F F F F Automatically Reschedule with secondary X X doctor Inform patient of changes contacting X X X X X X through automated telephone calls. Post changes to Doctors Schedule X X Notify Reception desk staff of changes and X X X X X X X X possible Assignment of Doctor to patient Decision Table: Doctor Rescheduling X- The action should be executed. T- The Precondition is true. F- The Precondition is false Functional Requirements: REQ-1: A doctor or reception desk staff should be able to retrieve appointment information for scheduled appointments. 21

22 REQ-2: Doctors and reception desk staff should be able to edit appointments, and save the corresponding changes. REQ-3: Doctors should be able to edit their calendars to indicate the days and time when they are unavailable. 22

23 4.5 Appointment Reminder Priority: High Description and Priority This is a medium priority automated feature for sending reminders out to the patients about their upcoming appointment. The automated feature sends out either an or makes a call to the patient s designated phone number at designated periods prior to the patient s scheduled visit. Two reminders are sent to the patients within 96 hours of an appointment. Patients are notified via the reminder feature 72 hours and 24 hours prior to the scheduled appointment. The reminder runs without human intervention but its prerequisite is that AMMS must be running. Listed below are the necessary details included in each reminder sent out Name of patient Date and time of scheduled appointment Name of clinic Location of clinic Doctor to be seen by Rescheduling and appointment cancellation process information Stimulus/Response Sequences Use case: Appointment Reminder Diagram: AMMS Reception desk staff Brief Description The reception desk staff accesses AMMS and the appointment reminder is triggered and begins sending out reminders to patients Functional Requirements REQ-1: The system should include an automated appointment reminder functionality that sends out reminders and makes phone calls to patients notifying them about upcoming appointments. REQ-2: The system should automatically start sending out reminders either via or phone calls at system startup. REQ-3: The system should send out two reminders to the patients. 23

24 72 hours before scheduled appointment 24 hours before scheduled appointment REQ-4: The reminders sent out automatically by the system should include the following information: Name of patient Date and time of scheduled appointment Name of clinic Location of clinic Doctor to be seen by Rescheduling and appointment cancellation process information 24

25 4.6 Retrieve Information Description and Priority This feature enables the reception desk staff to perform a search against the database records Stimulus/Response Sequences Use Case: Retrieve Patient information Diagram: View General Information Reception desk staff Search for patient View Medical History View previous visits View Insurance Info. Use Case: Search for Doctor Diagram: Search for Doctor Initial Step-By-Step Description (Retrieve doctor information) Before this use case can be initiated, the reception desk staff must have already accessed AMMS. 1. The reception desk staff chooses to search by doctor name or employee ID 25

26 Initial Step-By-Step Description (Retrieve patient information) Before this use case can be initiated, the reception desk staff must have already accessed AMMS. 1. The reception desk staff chooses to search by patient name, address, phone number, social security number, patient id or drivers license. 2. The system displays the list of results found to the reception desk staff. 3. The reception desk staff selects the patient desired. 4. The system presents the patient information in various tabs to the reception desk staff. 5. The reception desk staff clicks on the desired tab Functional Requirements REQ-1: The system should provide the following general information for a patient to the reception desk staff. REQ-1-1: Name REQ-1-2: Date last visit REQ-1-3: Social security number REQ-1-3: Address REQ-1-4: Work, home and cell phone REQ-1-5: Occupancy REQ-1-6: Employee REQ-2: The system should provide the following insurance information for a patient to the reception desk staff. REQ-2-1: Name of account holder REQ-2-2: Phone number REQ-2-3: company name REQ-2-4: insurance number, REQ-3: The system should provide the following medical history information for a patient to the reception desk staff. REQ-3-1: Family history REQ-3-2: Allergies REQ-3-3: surgeries REQ-4: The system should provide the following appointment history information for a patient to the reception desk staff. REQ-4.1: Date and time of patient s visit REQ-4.2: Doctors seen REQ-4.3: Reason for visit REQ-4.4: Doctor Notes: descriptive diagnosis and associated prescription if any REQ-4.5: Vitals Height Weight, Body temperature Blood pressure 26

27 Pulse Respiration REQ-4.6: Payment details Amount paid Form of payment Credit card and card type (i.e. MasterCard, Visa, American Express etc) Check Cash REQ-5: The doctor search should return the following information: name, specialty/field, doctor ID, phone numbers, list of patient. REQ-6: The system should provide the following information to the reception desk staff: REQ-6-1: Last Name REQ-6-2: First Name REQ-6-3: Middle Initial REQ-6-4: Specialty REQ-6-5: Doctor ID REQ-6-6: Phone Number(s) REQ-6-7: List of Patients 27

28 Section 5.1 Performance Requirements Each performance requirement (PERF-REQ) is uniquely identified below: PERF- REQ 1 If updates are made to any displayed information on the system interface, the information must be refreshed within five seconds of adding, updating, or deleting the information in the database. PERF -REQ 2 For the patient search, the information will be sent to the database and back five seconds from when the query is executed. PERF -REQ 3 notifications will be issued within 5 seconds from a change in the database. 5.2 Safety Requirements Each safety requirement (SAFE-REQ) is uniquely identified below: SAFE- REQ 1 For the medical history, each new visit entry must not overwrite any existing database entry for any patient when entered into the system. 5.3 Security Requirements Each security requirement (SEC-REQ) is uniquely identified below: SEC- REQ 1 The system must require a valid username and password to utilize the interface. SEC- REQ 2 The system must encrypt customer sensitive information: social security number and credit card information. SEC- REQ 3 The system must not allow multiple concurrent sign in for a given patient or doctor id. 28

29 5.4 Software Quality Requirements Each quality requirement (QUA-REQ) is uniquely identified below: QUA- REQ 1 Up to 10 people must be able to use the system at any given time. QUA- REQ 2 The system must provide a 99.9% chance that the program will not crash QUA- REQ 3 The system must be easy to port from one computer to another provided all the required system components needed to function are available. 5.5 Business Rules Each business rule (BUS-RULE) is uniquely identified below: BUS- RULE 1 A doctor can only modify his/her calendar. BUS- RULE 2 A reception desk staff can add, update or delete a patient record. BUS- RULE 3 A reception desk can add, delete or update any patient appointment entry on a doctor s calendar. 29

30 Section Appendix A: Glossary Term Database Software Requirements Specification Stakeholder Reception Desk Staff Doctor AMMS SQL Server No wait policy MHz MB RAM SRS SMTP Definition Collection of all the information monitored by this system. A document that completely describes all of the functions of a proposed system and the constraints under which it must operate. For example, this document. Any person with an interest in the project who is not a developer. User of the system. This are principal system user This is the secondary system user Acme Medical Management System Data store for the system. System interfaces with this. This is a policy that ensures that appointment times as honored. Thus, if an appointment is scheduled for 8am, the patient must see the doctor at exactly 8am and no later. MegaHertz MegaByte Random access memory Software requirements specification Simple mail transfer protocol Appendix B: Analysis Models Appendix C: To Be Determined List 30