Analysis and Design of a Simplified Patient Care System, DNS

Analysis and Design of a Simplified Patient Care System, DNS Info 620: Information Systems Analysis and Design Claire King, Christie McHargue, Adelaida Montanez, Sarah Neergaard Project Category: Analysis and Design 1

Table of Contents Chapter 1: System Analysis..4 Section 1: Problem Statement..4 Section 2: Requirements 4-5 2.1: Functional Requirements..5 2.2: Data Requirements.5 2.3 Business Rules and Logic 5 2.4 Non-functional.5 Section 3: Use Case Model 6 3.1: Actors and their Goals..6 3.2: Use Case Diagram.7 3.3: Use Case Overview 8-9 3.4: Use Case Description 10-40 3.5: Use Case Discussion..41 Section 4: Class Model.42 4.1: TCM Table.42-43 4.2: Class Diagram 44 4.3: Class Model Discussion..45 Chapter 2: System Design.46 Section 5: Sequence Diagram 46 5.1: System Sequence Diagrams 46-50 5.2: Sequence diagrams.51-54 5.3: Validation and discussion of sequence Diagram..55 Section 6: Design Class Diagram..56 6.1: Design Class Diagram.56 2

6.2: Validation and Discussion 57 Chapter 3: Physical Design.58 7.1: ERD 58 7.2: Relational Database Schema 59 Chapter4: Evaluation of Analysis and Design.60 8.1: Evaluation of Project...60 8.2: Evaluation of UML and Tool.60 References.61 Appendix 62 9.1 Lessons Learned..62-63 9.2 Individual Team Member Contribution 63 9.3 Unsolved Problems 63 3

CHAPTER 1: System Analysis (1) The Problem Statement A small clinic is interested in exploring the creation of a simplified patient care system (SPCS) to provide a sophisticated method of processing daily tasks. (a) Context and Importance of the system The thought process behind redesigning the traditional system is to update the scheduling system, convert paper files to electronic files, and provide a more efficient method of processing payments. Flaws in the traditional system are responsible for increase in costs, conflicting schedules, lack of full medical history, and poor time management. It is important to implement a computerized system which allows easy and accurate changes in scheduling, maintains past and present medical records, sorts data, manages billing and payment history, generates invoices, and updates insurance information regularly. (b) Overall goals of the system The overall goal of the system is to provide greater functionality by increasing workflow, organization and accuracy within the clinic; via management of appointment scheduling, patient history, and billing records. (c) Scope of project Our team will develop a database system which is suitable for a small office comprising of fewer than 10 medical staff. The system will run on both desktop computers for the office staff and tablets issued to doctors and nurses. (2) Requirements 2.1 Functionality of the system The system will provide an efficient scheduling service o System will have a pop up box for easy input of appointments o Conflicts in scheduling will be clear, and avoidable o System will be able to generate invoices off of scheduled appointments o Schedule will be printable, to provide daily list as needed for staff The system will handle all payments from patients and insurance companies o Invoices can be generated and sent to appropriate party for request of payment o The system will track payments, send reminders for late/unreceived payments o The system will have the ability to print receipts for patients who have paid The system will keep track of patient s medical history and basic information o A patient s record will include their medical history, provided by the patient at The system will keep track of treatments undergone both past and present from patients 4

o The system will keep track of patient referrals o The system will log patient insurance information, and prompt for updates when policy expires o The system will send and receive lab results to be shared with medical staff and patients o The system will be able to send a receive scripts from a pharmacy 2.2 Data requirements of the system The system will be comprised of a database with search capabilities The data will mainly be patient information, staff information, and daily schedules Tables included: o Patient (PatientID is PK) o Employee (EmployeeID is PK) o ICD9 Codes for Diseases/Infections of Patients o Payment Table, cost of appointment/prodecures o Insurance Table (Provider, Contact Info, Co-Pay) o User ID/Password storage 2.3 Business rules and logic Only employees allowed in system, username and password required Accounting of Clinic not in this system Ordering of supplies for office also a separate function of the business Office staff/nurses can clearly see all doctors schedules. Reports of schedule are printed daily and handed to Medical Staff for reference. 2.4 Other non-functional requirements such as security, usability, performance, etc. Security is of the utmost importance when handling medical data. System programmers will review HIPAA laws to protect patient confidentiality when writing security protocols. System will be password protected, only accessible by Office or Medical staff. Password must be changed every 30 days and come with three security questions. System will have advanced search capabilities System will track Physician and Nurses licenses and include prompts for renewals 2.5 Other important assumptions The system will be small enough to sit on a single server Hardware will include a large amount of RAM so as not to keep patients, or medical staff waiting, especially in situations where time is limited System will not include functionality for Office Accounting, use quickbooks as a separate entity. Only used for scheduling and patient information. 5

(3) Use Case Model 3.1 Actors and their Goals Office Staff- The office staff is the main user of the DNS system. They need to add appointments, keep track of schedules, bill for services, and process labs and prescriptions. Medical Staff- The medical staff (doctors and nurses at the clinic) need to be able to access the program to view and print their daily schedule of appointments. Referring Physician- The referring physician needs to be able to send a referral which can be received and inputted into the system. Lab- The lab needs to be able to receive lab orders, and send results. Pharmacy- The pharmacy needs to be able to receive orders for prescriptions and process and fill them for patients. 6

3.2 Use Case Diagram DNS System P1: Cancel Appointment <<include>> I1: InputApptDate Office Staff P3: InputPatientHistory <<extend>> <<extende>> P4: ProcessPayment P3Ext1: InputPatient History w/ Symptoms P3Ext2: InputPatient History w/symptioms & Treatment <<include>> <<include>> P2: Schedule Appointment I5: Lookup Diagnosis Code <<extend>> P2E1: Schedule Multiple Appointments <<include>> <<include>> <<include>> I2: InputApptTime I3: AssignDoctor I4: AssignPatient <<extend>> <<include>> I6: PrintReceipt P5: SendInvoice <<extend>> «subsystem» ICD9 Database P5E1: Send Invoice to Insurance P4E1: Process Insurance Payment P6: SendLateNotice <<extend>> P6E1: Send Late Notice to Insurance P7: InputStaff <<extend>> <<extend>> P7E1: InputDoctor P7E2: InputNurse Nurse P8: ViewSchedule <<include>> I7: PrintSchedule P9: OrderLabs <<include>> I8: AssignPatient Lab <<include>> Doctor P10: Write Prescription Pharmacy 7

3.3 Overview of the Use Cases Primary Use Cases (With Extend and Include scenarios) P1: CancelAppointment P2: ScheduleAppointment o Include: I1: InputApptDate o Include: I2: InputApptTime o Include: I3: AssignDoctor o Include: I4: AssignPatient o Extend: P2E1:ScheduleMultipleAppts P8: ViewSchedule o Include: I7: PrintSchedule This is the primary need for the DND system. These use cases allow office workers to schedule and track appointments. Once medical staff are assigned to an appointment, they can access and print their schedule. P3: InputPatientHistory o Extend: P3E1: InputPatientHistory w/symptoms o Extend: P3E2: InputPatientHistory w/symptoms and Treatment o Include: I5: LookupDiagnosisCode P4: ProcessPayment o Extend: P4E1: ProcessInsurancePayment o Include: I6: PrintReciept P5: SendInvoice o Extend: P5E1: SendInvoicetoInsurance P6: SendLateNotice o Extend: P6E1: SendLateNoticetoInsurance These use cases allow the system to create a patient record and track medical history, treatments and payment info. Fulfills system requirements to bill either a single insurance company, or the patient for services rendered. P7: InputStaff o Extend: P7E1: InputDoctor o Extend: P7E2: InputNurse P9: OrderLabs o Include: I8: AssignPatient P10:WritePrescriptions o Include: I8: AssignPatient Allows office staff or system administrators to add medical staff to system for scheduling. Allow the system to communicate with outside resources to process labs and prescriptions (anything not able to be done at the clinic). 8

Routine Use-Cases LaunchProgram Staff Login TerminateProgram ArchiveSchedule BackupSchedule BackupLabs BackupScripts BackupPatient Routine use cases for any system, not essential to be defined in diagram. 9

3.4 Case Descriptions for Primary Use Cases (Extended and Included) USE CASE DESCRIPTION- Sarah Neergaard USE CASE # P2 USE CASE Name ScheduleAppointment ACTOR Office Staff Goal (1 phrase) To schedule an appointment for a new, or continuing patient. Overview and scope The office staff receives a call or walk-in from a patient requesting an appointment. They schedule the appointment on the specified date and time that the patient wishes, and assign a doctor to the appointment. Level Primary Preconditions 1. Office staff member is logged into DNS. 2. The office is open on the selected day and time. 3. The chosen doctor is available for that specific appointment time. Postconditions in words (write in passive and past tense) 1. The appointment was created. 2. The patient was assigned to the appointment. 3. The correct doctor was assigned to the appointment. Trigger Patient contacts office and requests appointment. Included Use Cases I1: InputApptDate, I2: InputApptTime, I3: AssignDoctor, I4: AssignPatient Extending Use Cases P2E1: ScheduleMultipleAppointments MAIN SUCCESSFUL Actor Action System Action SCENARIO in 1. The office staff opens the 2. System prompts for date of numbered sequence appointment scheduling appointment. Reference included use cases in this section using INCLUDE ius_name assistant. 3. Office staff confers with patient, asks for preferred date. 4. System records date. INCLUDE I1: InputApptDate 5. The office staff confirms. 6. System prompts for time of appointment. 7. Office Staff views available 8. System records time. INCLUDE times, confers with patient, I2: InputApptTime assigns time. 9. Office staff confirms. 10. System prompts for doctor to be assigned. 10

11. Office worker confers with patient. Selects doctor. 12. System assigns doctor. INCLUDE I3: AssignDoctor 13.Office worker provides final confirmation. 14. System assigns patient and saves. INCLUDE I4: AssignPatient OTHER SUCCESSFUL SCENARIOS (Specify any successful variations of the normal execution path, including any extension points using EXTEND eus_name) Step 12. (a) Patient wants to make multiple appointments. Branching Action Return to home screen, make another appointment. EXTEND P2EI: ScheduleMultipleAppointments UNSUCCESSFUL SCENARIOS (erroneous situations) Conditions Actions *a Abort the transaction 3. (a) Date not available. Prompt patient to choose new date. 7. (a) Time not available. Prompt patient to choose new time. 11. (a) Doctor not available. Prompt patient to either choose other date/time, or new doctor. Priority in scheduling Frequency Business rules and data logic Other non-functional requirements Superordinates Developer Creation date and last modified date Primary Up to 100 times per day. Depending on call volume. 1. Patient must exist in the system. 2. The doctor must be currently employed at the clinic. 3. The office must be open on the date and time selected. 1. Computers must be working to schedule appointment, no paper schedules. 2. All staff must be HIPPA certified. None Sarah Neergaard Created on: August 14, 2013 Modified on: August 25, 2013 11

USE CASE DESCRIPTION- Sarah Neergaard USE CASE # P2E1 USE CASE Name ScheduleMultipleAppointments ACTOR Office Staff Goal (1 phrase) To schedule multiple appointments for a new, or continuing patient. Overview and scope The office staff receives a call or walk-in from a patient requesting multiple appointments. They schedule the appointments on the specified dates and times that the patient wishes, and assign a doctor to the appointments. Level Extended Preconditions 1. Office staff member is logged into DNS. 2. The office is open on the selected day and time. 3. The chosen doctor is available for that specific appointment time. Postconditions in 1. The appointment was created. words (write in passive 2. The patient was assigned to the appointment. and past tense) 3. The correct doctor was assigned to the appointment. Trigger Patient contacts office and requests multiple appointments. Included Use Cases I1: InputApptDate, I2: InputApptTime, I3: AssignDoctor, I4: AssignPatient Extending Use Cases MAIN SUCCESSFUL SCENARIO in numbered sequence Reference included use cases in this section using INCLUDE ius_name Actor Action 1. The office staff opens the appointment scheduling assistant. 3. Office staff confers with patient, asks for preferred date. System Action 2. System prompts for date of appointment. 4. System records date. INCLUDE I1: InputApptDate 5. The office staff confirms. 6. System prompts for time of appointment. 7. Office Staff views available 8. System records time. INCLUDE times, confers with patient, I2: InputApptTime assigns time. 9. Office staff confirms. 10. System prompts for doctor to be assigned. 12

11. Office worker confers with patient. Selects doctor. 12. System assigns doctor. INCLUDE I3: AssignDoctor 13. Office worker provides final confirmation. 7. System assigns patient and saves. INCLUDE I4: AssignPatient OTHER SUCCESSFUL SCENARIOS (Specify any successful variations of the normal execution path, including any extension points using EXTEND eus_name) UNSUCCESSFUL SCENARIOS (erroneous situations) Step Branching Action Conditions Actions *a Abort the transaction 3. (a) Date not available. Prompt patient to choose new date. 7. (a) Time not available. Prompt patient to choose new time. 11. (a) Doctor not available. Prompt patient to either choose other date/time, or new doctor. Priority in scheduling Extended Frequency Up to 40 times per day. Depending on call volume and if patients want to make multiple appointments. Business rules and 1. Patient must exist in the system. data logic 2. The doctor must be currently employed at the clinic. 3. The office must be open on the date and time selected. Other non-functional 1. Computers must be working to schedule appointment, no paper requirements schedules. 2. All staff must be HIPPA certified. Superordinates P2: ScheduleAppointment Developer Sarah Neergaard Creation date and last Created on: August 14, 2013 modified date Modified on: August 25, 2013 USE CASE DESCRIPTION- Sarah Neergaard 13

USE CASE # USE CASE Name ACTOR Goal (1 phrase) Overview and scope Level Preconditions Postconditions in words (write in passive and past tense) Trigger Included Use Cases Extending Use Cases MAIN SUCCESSFUL SCENARIO in numbered sequence Reference included use cases in this section using INCLUDE ius_name I1 InputApptDate Office Staff To record the date of an appointment. The office staff selects an appropriate date for an appointment. Included 1. The Office Staff is logged into the DNS system. 2. The office is open on the selected date. 1. The appointment was scheduled on a specific date. Patient calls the office to make an appointment. Actor Action 1. The office staff receives a request for a new appointment. 3. The office staff confers with the patient, selects date. System Action 2. The system prompts for date of appointment. 4. The system records date. OTHER SUCCESSFUL SCENARIOS (Specify any successful variations of the normal execution path, including any extension points using EXTEND eus_name) Step Branching Action UNSUCCESSFUL SCENARIOS (erroneous situations) Conditions Actions *a Abort the transaction 3 (a) Date is not available. System prompts to select new date. 14

Priority in scheduling Included. Frequency Up to 100 times per day. Happens every time an appointment is scheduled. Business rules and 1. Patient must exist in the system. data logic 2. The doctor must be currently employed at the clinic. 3. The office must be open on the date and time selected. Other non-functional 1. Computers must be working to schedule appointment, no paper requirements schedules. 2. All staff must be HIPPA certified. Superordinates P2: ScheduleAppointment Developer Sarah Neergaard Creation date and last Created on: August 14, 2013 modified date Modified on: August 25, 2013 USE CASE DESCRIPTION- Sarah Neergaard USE CASE # USE CASE Name ACTOR Goal (1 phrase) Overview and scope Level Preconditions Postconditions in words (write in passive and past tense) Trigger Included Use Cases Extending Use Cases MAIN SUCCESSFUL SCENARIO in numbered sequence Reference included use cases in this section using INCLUDE ius_name I2 InputApptTime Office Staff To record the time of an appointment. The office staff selects an appropriate time for an appointment. Included 1. The Office Staff is logged into the DNS system. 2. The office is open on the selected time. 1. The appointment was scheduled on a specific time. Patient calls the office to make an appointment. Actor Action 1. The office staff receives a request for a new appointment. 3. The office staff confers with the patient, selects time. System Action 2. The system prompts for time of appointment. 4. The system records time. OTHER Step Branching Action 15

SUCCESSFUL SCENARIOS (Specify any successful variations of the normal execution path, including any extension points using EXTEND eus_name) UNSUCCESSFUL SCENARIOS (erroneous situations) Conditions Actions *a Abort the transaction 3 (a) Time is not available. System prompts to select new time. Priority in scheduling Included. Frequency Up to 100 times per day. Happens every time an appointment is scheduled. Business rules and 1. Patient must exist in the system. data logic 2. The doctor must be currently employed at the clinic. 3. The office must be open on the date and time selected. Other non-functional 1. Computers must be working to schedule appointment, no paper requirements schedules. 2. All staff must be HIPPA certified. Superordinates P2: ScheduleAppointment Developer Sarah Neergaard Creation date and last Created on: August 14, 2013 modified date Modified on: August 25, 2013 USE CASE DESCRIPTION- Sarah Neergaard USE CASE # USE CASE Name ACTOR Goal (1 phrase) Overview and scope Level Preconditions Postconditions in words (write in passive and past tense) Trigger Included Use Cases I3 AssignDoctor Office Staff To assign a doctor to a specific appointment. The office staff selects an available doctor for the appointment. Included 1. The Office Staff is logged into the DNS system. 2. The office is open on the selected date. 3. The doctor is available. 1. The doctor was assigned to the appointment. Patient calls the office to make an appointment. 16

Extending Use Cases MAIN SUCCESSFUL SCENARIO in numbered sequence Reference included use cases in this section using INCLUDE ius_name Actor Action 1. The office staff receives a request for a new appointment. 3. The office staff confers with the patient, selects doctor. System Action 2. The system prompts to assign a doctor to the appointment. 4. The system records assignment. OTHER SUCCESSFUL SCENARIOS (Specify any successful variations of the normal execution path, including any extension points using EXTEND eus_name) Step Branching Action UNSUCCESSFUL SCENARIOS (erroneous situations) Conditions Actions *a Abort the transaction 3 (a) Doctor is not available. System prompts to select new date. Priority in scheduling Frequency Business rules and data logic Other non-functional requirements Superordinates Developer Creation date and last modified date Included. Up to 100 times per day. Happens every time an appointment is scheduled. 1. Patient must exist in the system. 2. The doctor must be currently employed at the clinic. 3. The office must be open on the date and time selected. 1. Computers must be working to schedule appointment, no paper schedules. 2. All staff must be HIPPA certified. P2: ScheduleAppointment Sarah Neergaard Created on: August 14, 2013 Modified on: August 25, 2013 17

USE CASE DESCRIPTION- Sarah Neergaard USE CASE # USE CASE Name ACTOR Goal (1 phrase) Overview and scope Level Preconditions Postconditions in words (write in passive and past tense) Trigger Included Use Cases Extending Use Cases MAIN SUCCESSFUL SCENARIO in numbered sequence Reference included use cases in this section using INCLUDE ius_name I4 AssignPatient Office Staff To assign a patient to an appointment. The office staff assigns the patient to their desired appointment time, date and doctor. Included 1. The Office Staff is logged into the DNS system. 2. The office is open on the selected date. 1. The appointment was scheduled on an open date and time with an available doctor. Patient calls the office to make an appointment. Actor Action 1. The office staff receives a request for a new appointment. 3. The office staff confers with the patient and confirms. System Action 2. The system assigns date, time and doctor. 4. The system records appointment. OTHER SUCCESSFUL SCENARIOS (Specify any successful variations of the normal execution path, including any extension points using EXTEND eus_name) Step Branching Action UNSUCCESSFUL SCENARIOS Conditions Actions *a Abort the transaction 18

(erroneous situations) 3 (a) Any variable is not available. System prompts to select new time/date/doctor. Priority in scheduling Frequency Business rules and data logic Other non-functional requirements Superordinates Developer Creation date and last modified date Included. Up to 100 times per day. Happens every time an appointment is scheduled. 1. Patient must exist in the system. 2. The doctor must be currently employed at the clinic. 3. The office must be open on the date and time selected. 1. Computers must be working to schedule appointment, no paper schedules. 2. All staff must be HIPPA certified. P2: ScheduleAppointment Sarah Neergaard Created on: August 14, 2013 Modified on: August 25, 2013 USE CASE DESCRIPTION- Claire King USE CASE # USE CASE Name ACTOR Goal (1 phrase) Overview and scope Level Preconditions Postconditions in words (write in passive and past tense) P3 InputPatientHistory Office Staff To record patient vital statistics and examination notes for a standard patient appointment. The office staff member fills out the electronic form (User Interface) for recording patient history that includes importing the appointment information containing the patient name, the date and time of the examination and attending doctor s name. Then referring to the doctor s chart, the staff member records the height, weight and blood pressure of the patient at the time of the appointment. Finally the staff member transcribes the examination notes into the electronic record. Primary 4. Office staff member is logged into the DNS System. 5. The patient appointment is finished. 6. The doctor has given an office staff member the complete patient chart record for the appointment. 4. The patient history object was created. 5. The patient name and ID was imported and stored. 6. The doctor name and ID was imported and stored. 7. The appointment date and time was imported and saved. 8. The patient s weight, height and blood pressure was recorded and 19

Trigger Included Use Cases Extending Use Cases MAIN SUCCESSFUL SCENARIO in numbered sequence Reference included use cases in this section using INCLUDE ius_name OTHER SUCCESSFUL SCENARIOS (Specify any successful variations of the normal execution path, including any extension points using EXTEND eus_name) UNSUCCESSFUL SCENARIOS (erroneous situations) Priority in scheduling stored. 9. The doctor s notes were transcribed and stored. Patient appointment is complete and the chart is delivered to a staff member. InputPatient History w/ Symptoms, InputPatient History w/ Symptoms & Treatments Actor Action System Action 8. The office staff member initiates a new patient history record. 10. The office staff member types in appointment keyword(s) and submits the form 12. The office staff member confirms the appointment date, time, patient name and doctor 15. The staff member enters the weight, height and blood pressure and examination notes and submits the electronic form Step 5. (a) Appointment search information not valid 8. (a) Height, weight, or blood pressure information invalid 9. The system displays a lookup/search form to import the appointment object (date, time, patient name and doctor name) 11. The system returns the appointment search results: patient name, date, time and doctor name 13. The system imports the appointment data 14. The system displays a form for vital statistics and examination notes 16. The system saves the vital statistics and physician s notes Branching Action Return to appointment lookup/search display and correct search terms Return to vital statistics screen and correct height, weight, or blood pressure information Conditions Actions *a Abort the transaction 6. (a) The patient history has already been entered into the system Primary Abort the transaction 20

Frequency Business rules and data logic Other non-functional requirements Superordinates Developer Creation date and last modified date 15 times per day. 1 (45 total patients seen * 33% (1 of 3 use cases)) 4. Patient chart must be associated with a patient appointment. 5. The chart appointment record must include vital statistics that include weight, height and blood pressure. 6. The chart appointment record must doctor s examination notes. 3. All staff must belong to a security group. 4. All staff must be HIPPA certified. 5. All staff must have access to a desktop or tablet computer. None Claire King Created on: August 14, 2013 Modified on: August 24, 2013 USE CASE DESCRIPTION- Claire King USE CASE # USE CASE Name ACTOR Goal (1 phrase) Overview and scope Level Preconditions Postconditions in words (write in passive and past tense) P3Ext1 InputPatient History w/ Symptoms Office Staff To record patient vital statistics, symptoms, diagnosis and examination notes for a patient appointment. The office staff member fills out the electronic form (User Interface) for recording patient history that includes importing the appointment information containing the patient name, the date and time of the examination and attending doctor s name. Then referring to the doctor s chart, the staff member records the height, weight and blood pressure of the patient, at the time of the appointment. The staff member transcribes the examination notes, the symptoms presented during examination and the diagnosis using the Diagnosis Code Database to find the ICD9 (International Statistical Classification of Diseases) codes. Extended 7. Office staff member is logged into the DNS System. 8. The patient appointment is finished. 9. The doctor has given an office staff member the complete patient chart record for the appointment. 10. The patient history object was created. 11. The patient name and ID was imported and stored. 12. The doctor name and ID was imported and stored. 13. The appointment date and time was imported and saved. 1 Frequency estimate based on a Study from the Annals of Family Medicine found here: http://www.ncbi.nlm.nih.gov/pmc/articles/pmc1466945/#!po=73.0769 where the average workday for a doctor is 8.6 hours and of that time 54.9% percent is spent face-to-face with the patient. The average patient visit is 18.7 minutes; therefore a doctor can reasonably expect to see 15 patients a day. Further if our clinic has 3 doctors then we can reasonably expect to see 45 patients a day. (Gottschalk & Flocke, 2005) 21

Trigger Included Use Cases Extending Use Cases MAIN SUCCESSFUL SCENARIO in numbered sequence Reference included use cases in this section using INCLUDE ius_name 14. The patient s weight, height and blood pressure was recorded and stored. 15. The doctor s examination notes were transcribed and stored. 16. The patient s symptoms were recorded and stored. 17. The diagnosis codes were found in the ICD9 Database, imported and stored. Patient appointment is complete and the chart is delivered to a staff member. Lookup Diagnosis Code Actor Action 17. The office staff member initiates a new patient history record. 19. The office staff member types in appointment keyword(s) and submits the form 21. The office staff member confirms the appointment date, time, patient name and doctor 24. The staff member enters the weight, height and blood pressure and examination notes and submits the electronic form 27. The staff member enters the symptoms and submits the form 30. The staff member enters the diagnosis keywords and submits the form System Action 18. The system displays a lookup/search form to import the appointment object (date, time, patient name and doctor name) 20. The system returns the appointment search results: patient name, date, time and doctor name 22. The system imports the appointment data 23. The system displays a form for vital statistics and examination notes 25. The system saves the vital statistics and physician s examination notes 26. The system displays a form for symptoms 28. The system saves the symptoms data 29. The system displays a form for diagnosis 31. INCLUDE Lookup Diagnosis Code OTHER Step Branching Action 22

SUCCESSFUL SCENARIOS (Specify any successful variations of the normal execution path, including any extension points using EXTEND eus_name) 6. (a) Appointment search information not valid 9. (a) Height, weight, or blood pressure information invalid 14. (a) Diagnosis code search returned zero results Return to appointment lookup/search display and correct search terms Return to vital statistics screen and correct height, weight, or blood pressure information Enter different keyword(s) for the diagnosis and search again UNSUCCESSFUL SCENARIOS (erroneous situations) Priority in scheduling Frequency Business rules and data logic Other non-functional requirements Superordinates Developer Creation date and last modified date Conditions Actions *a Abort the transaction 7. (a) The patient history has already been entered into the system Abort the transaction Primary 15 times per day. 2 (45 total patients seen * 33% (1 of 3 use cases)) 7. Patient chart must be associated with a patient appointment. 8. The chart appointment record must include vital statistics that include weight, height and blood pressure. 9. The chart appointment record must doctor s examination notes. 10. Patient diagnosis must have a corresponding IDC9 code. 6. All staff must belong to a security group. 7. All staff must be HIPPA certified. 8. All staff must have access to a desktop or tablet computer. InputPatientHistory Claire King Created on: August 14, 2013 Modified on: August 24, 2013 2 Frequency estimate based on a Study from the Annals of Family Medicine found here: http://www.ncbi.nlm.nih.gov/pmc/articles/pmc1466945/#!po=73.0769 where the average workday for a doctor is 8.6 hours and of that time 54.9% percent is spent face-to-face with the patient. The average patient visit is 18.7 minutes; therefore a doctor can reasonably expect to see 15 patients a day. Further if our clinic has 3 doctors then we can reasonably expect to see 45 patients a day. (Gottschalk & Flocke, 2005) 23

USE CASE DESCRIPTION- Claire King USE CASE # USE CASE Name ACTOR Goal (1 phrase) Overview and scope Level Preconditions Postconditions in words (write in passive and past tense) Trigger Included Use Cases Extending Use Cases MAIN SUCCESSFUL SCENARIO in numbered sequence Reference included use P3Ext2 InputPatient History w/ Symptoms & Treatment Office Staff To record patient vital statistics, symptoms, diagnosis, treatments and examination notes for a patient appointment. The office staff member fills out the electronic form (User Interface) for recording patient history that includes importing the appointment information containing the patient name, the date and time of the examination and attending doctor s name. Then referring to the doctor s chart, the staff member records the height, weight and blood pressure of the patient, at the time of the appointment. The staff member transcribes the examination notes, the symptoms presented during examination and the diagnosis using the Diagnosis Code Database to find the ICD9 (International Statistical Classification of Diseases) codes. Finally the staff records all treatments prescribed during the appointment including lab work and prescription medicines. Extended 10. Office staff member is logged into the DNS System. 11. The patient appointment is finished. 12. The doctor has given an office staff member the complete patient chart record for the appointment. 18. The patient history object was created. 19. The patient name and ID was imported and stored. 20. The doctor name and ID was imported and stored. 21. The appointment date and time was imported and saved. 22. The patient s weight, height and blood pressure was recorded and stored. 23. The doctor s examination notes were transcribed and stored. 24. The patient s symptoms were recorded and stored. 25. The diagnosis codes were found in the ICD9 Database, imported and stored. 26. The lab orders were imported and stored. 27. The prescriptions for medicine were imported and stored. Patient appointment is complete and the chart is delivered to a staff member. Lookup Diagnosis Code Actor Action 32. The office staff member initiates a new patient history record. System Action 33. The system displays a lookup/search form to import the appointment object (date, time, patient name and doctor name) 24

cases in this section using INCLUDE ius_name 34. The office staff member types in appointment keyword(s) and submits the form 36. The office staff member confirms the appointment date, time, patient name and doctor 39. The staff member enters the weight, height and blood pressure and examination notes and submits the electronic form 42. The staff member enters the symptoms and submits the form 45. The staff member enters the diagnosis keywords and submits the form 48. The staff member enters lab ID number(s) and submits the form 50. The office staff member confirms lab(s) ordered 53. The staff member enters prescription ID number(s) and submits the form 55. The office staff member confirms prescriptions written 35. The system returns the appointment search results: patient name, date, time and doctor name 37. The system imports the appointment data 38. The system displays a form for vital statistics and examination notes 40. The system saves the vital statistics and physician s examination notes 41. The system displays a form for symptoms 43. The system saves the symptoms data 44. The system displays a form for diagnosis 46. INCLUDE Lookup Diagnosis Code 47. The system displays lookup/search form to import labs ordered 49. The system returns the lab(s) order information 51. The system imports the lab(s) data 52. The system displays lookup/search form to import prescription(s) 54. The system returns the prescription(s) order information 56. The system imports the prescription(s) data 25

OTHER SUCCESSFUL SCENARIOS (Specify any successful variations of the normal execution path, including any extension points using EXTEND eus_name) UNSUCCESSFUL SCENARIOS (erroneous situations) Priority in scheduling Frequency Business rules and data logic Other non-functional requirements Superordinates Developer Creation date and last modified date Step 7. (a) Appointment search information not valid 10. (a) Height, weight, or blood pressure information invalid 15. (a) Diagnosis code search returned zero results 18. (a) Lab ID number search returned zero results 23. (a) Prescription ID number search returned zero results Conditions Branching Action Return to appointment lookup/search display and correct search terms Return to vital statistics screen and correct height, weight, or blood pressure information Enter different keyword(s) for the diagnosis and search again Enter correct lab ID number and search again Enter the correct prescription ID number and search again Actions *a Abort the transaction 8. (a) The patient history has Abort the transaction already been entered into the system Primary 15 times per day. 3 (45 total patients seen * 33% (1 of 3 use cases)) 11. Patient chart must be associated with a patient appointment. 12. The chart appointment record must include vital statistics that include weight, height and blood pressure. 13. The chart appointment record must doctor s examination notes. 14. Patient diagnosis must have a corresponding IDC9 code. 15. Patient treatments must have a corresponding lab or prescription number. 9. All staff must belong to a security group. 10. All staff must be HIPPA certified. 11. All staff must have access to a desktop or tablet computer. InputPatientHistory Claire King Created on: August 14, 2013 Modified on: August 24, 2013 3 Frequency estimate based on a Study from the Annals of Family Medicine found here: http://www.ncbi.nlm.nih.gov/pmc/articles/pmc1466945/#!po=73.0769 where the average workday for a doctor is 8.6 hours and of that time 54.9% percent is spent face-to-face with the patient. The average patient visit is 18.7 minutes; therefore a doctor can reasonably expect to see 15 patients a day. Further if our clinic has 3 doctors then we can reasonably expect to see 45 patients a day. (Gottschalk & Flocke, 2005) 26

USE CASE DESCRIPTION- Claire King USE CASE # USE CASE Name ACTOR Goal (1 phrase) Overview and scope Level Preconditions Postconditions in words (write in passive and past tense) Trigger Included Use Cases Extending Use Cases MAIN SUCCESSFUL SCENARIO in numbered sequence Reference included use cases in this section using INCLUDE ius_name I5 Lookup Diagnosis Code To look up diagnosis and return a code to the Include 13. Office staff member is logged into the DNS System. 14. The patient appointment is finished. 15. The doctor has given an office staff member the complete patient chart record for the appointment. 28. The patient history object was created. 29. The patient name and ID was imported and stored. 30. The doctor name and ID was imported and stored. 31. The appointment date and time was imported and saved. 32. The patient s weight, height and blood pressure was recorded and stored. 33. The doctor s examination notes were transcribed and stored. 34. The patient s symptoms were recorded and stored. 35. The diagnosis codes were found in the ICD9 Database, imported and stored. 36. The lab orders were imported and stored. 37. The prescriptions for medicine were imported and stored. Patient appointment is complete and the chart is delivered to a staff member. Actor Action 57. The office staff member initiates a new patient history record. 59. The office staff member types in appointment keyword(s) and submits the form 61. The office staff member confirms the appointment date, time, patient name and doctor System Action 58. The system displays a lookup/search form to import the appointment object (date, time, patient name and doctor name) 60. The system returns the appointment search results: patient name, date, time and doctor name 62. The system imports the appointment data 63. The system displays a form for vital statistics and examination notes 27

OTHER SUCCESSFUL SCENARIOS (Specify any successful variations of the normal execution path, including any extension points using EXTEND eus_name) 64. The staff member enters the weight, height and blood pressure and examination notes and submits the electronic form 67. The staff member enters the symptoms and submits the form 70. The staff member enters the diagnosis keywords and submits the form 73. The staff member enters lab ID number(s) and submits the form 75. The office staff member confirms lab(s) ordered 78. The staff member enters prescription ID number(s) and submits the form 80. The office staff member confirms prescriptions written Step 8. (a) Appointment search information not valid 11. (a) Height, weight, or blood pressure information invalid 16. (a) Diagnosis code search returned zero results 65. The system saves the vital statistics and physician s examination notes 66. The system displays a form for symptoms 68. The system saves the symptoms data 69. The system displays a form for diagnosis 71. INCLUDE Lookup Diagnosis Code 72. The system displays lookup/search form to import labs ordered 74. The system returns the lab(s) order information 76. The system imports the lab(s) data 77. The system displays lookup/search form to import prescription(s) 79. The system returns the prescription(s) order information 81. The system imports the prescription(s) data Branching Action Return to appointment lookup/search display and correct search terms Return to vital statistics screen and correct height, weight, or blood pressure information Enter different keyword(s) for the diagnosis and search again 28

UNSUCCESSFUL SCENARIOS (erroneous situations) Priority in scheduling Frequency Business rules and data logic Other non-functional requirements Superordinates Developer Creation date and last modified date 19. (a) Lab ID number search returned zero results 24. (a) Prescription ID number search returned zero results Conditions Enter correct lab ID number and search again Enter the correct prescription ID number and search again Actions *a Abort the transaction 9. (a) The patient history has Abort the transaction already been entered into the system Primary 15 times per day. 4 (45 total patients seen * 33% (1 of 3 use cases)) 16. Patient chart must be associated with a patient appointment. 17. The chart appointment record must include vital statistics that include weight, height and blood pressure. 18. The chart appointment record must doctor s examination notes. 19. Patient diagnosis must have a corresponding IDC9 code. 20. Patient treatments must have a corresponding lab or prescription number. 12. All staff must belong to a security group. 13. All staff must be HIPPA certified. 14. All staff must have access to a desktop or tablet computer. InputPatient History w/ Symptoms, InputPatient History w/ Symptoms & Treatments Claire King Created on: August 14, 2013 Modified on: August 24, 2013 4 Frequency estimate based on a Study from the Annals of Family Medicine found here: http://www.ncbi.nlm.nih.gov/pmc/articles/pmc1466945/#!po=73.0769 where the average workday for a doctor is 8.6 hours and of that time 54.9% percent is spent face-to-face with the patient. The average patient visit is 18.7 minutes; therefore a doctor can reasonably expect to see 15 patients a day. Further if our clinic has 3 doctors then we can reasonably expect to see 45 patients a day. (Gottschalk & Flocke, 2005) 29

USE CASE DESCRIPTION- Christie McHargue USE CASE # USE CASE Name ACTOR Goal (1 phrase) Overview and scope Level Preconditions Postconditions in words (write in passive and past tense) Trigger Included Use Cases Extending Use Cases MAIN SUCCESSFUL SCENARIO in numbered sequence Reference included use cases in this section using INCLUDE ius_name P7 ViewSchedule Doctor To view patients scheduled for a particular day. After viewing patients scheduled for the day the doctor receives printed schedule if he chooses and/or views it throughout the day on his tablet. Primary 1. Doctor is logged into the DNS System. 2. Doctor views schedule for the day. 3. The Doctor prints schedule. 1. Doctor accepts schedule. 2. Doctor changes schedule. 3. Doctor updates schedule. Doctor is scheduled to work. I7: PrintSchedule None Actor Action System Action 1. Doctor logs into DNS system with login code on his tablet. 3. Doctor views current days schedule. 5. Doctor chooses to have printed copy of schedule. 2. Login code verified. 4. Displays patients scheduled for the day. 6. Schedule printed. OTHER SUCCESSFUL SCENARIOS (Specify any successful variations of the normal execution path, including any extension points using EXTEND eus_name) Step Branching Action UNSUCCESSFUL Conditions Actions 30

SCENARIOS (erroneous situations) These could be doctor cancels Patient cancels Priority in scheduling Frequency Business rules and data logic Other non-functional requirements Superordinates Developer Creation date and last modified date Patient no-show Primary ~5 times a day (based on Claires description of normal work days) 21. A doctor must be scheduled for work. 22. A doctor must agree on schedule. 23. A doctor must report to work on scheduled days. 24. A doctor must see scheduled patients on or about time patient scheduled for appointment. 15. All staff must belong to a security group. 16. All staff must be HIPPA certified. 17. All staff must have access to a desktop or tablet computer. None Christie McHargue Created on: August 24, 2013 USE CASE DESCRIPTION- Christie McHargue USE CASE # USE CASE Name ACTOR Goal (1 phrase) Overview and scope Level Preconditions Postconditions in words (write in passive and past tense) Trigger Included Use Cases Extending Use Cases MAIN SUCCESSFUL SCENARIO in numbered sequence P8 OrderLabs Doctor To order lab work needed for patient diagnosis. After speaking with patient and physical examination the doctor feels it necessary to order further lab work for confirmation. Primary 4. Doctor is logged into the DNS System. 5. Doctor examines patient. 6. Doctor determines further testing is needed to confirm diagnosis. 4. Doctor assigns patient. 5. Doctor orders lab work. 6. Doctor sends request to lab electronically. Doctor needs to confirm suspected diagnosis. I8: AssignPatient None Actor Action System Action 1. Doctor logs into DNS system with login code on his tablet. 2. Login code verified. 31

Reference included use cases in this section using INCLUDE ius_name OTHER SUCCESSFUL SCENARIOS (Specify any successful variations of the normal execution path, including any extension points using EXTEND eus_name) 3. Doctor assigns patient. 4. Displays patient chart. 5. Doctor assigns lab work chart. 6. Displays lab work chosen, queries if correct? Y/N 7. Doctor confirms Y 8. Displays patient information and lab work desired. 9. Doctor confirms and orders. 10. Lab work order sent electronically to lab. Step Branching Action UNSUCCESSFUL SCENARIOS (erroneous situations) Priority in scheduling Frequency Business rules and data logic Other non-functional requirements Superordinates Developer Creation date and last modified date Conditions 1. Doctor incorrectly assigns lab work. 3. Doctor notes error, indicates N. Actions 2. Displays lab work chosen, queries if correct? Y/N 4. Displays lab work chart. 5. Doctor assigns labs 6. Displays lab work chosen, queries if correct? Y/N 7. Doctor confirms and 8. Lab work order sent orders. electronically to lab. Primary ~5 times a day (based on Claires description of normal work days) 25. A patient must be examined. 26. A doctor must need diagnosis confirmed. 27. A patient must be assigned 28. A doctor must order the lab work. 29. Lab order must be sent electronically to lab. 18. All staff must belong to a security group. 19. All staff must be HIPPA certified. 20. All staff must have access to a desktop or tablet computer. None Christie McHargue Created on: August 24, 2013 32

USE CASE DESCRIPTION- Christie McHargue USE CASE # USE CASE Name ACTOR Goal (1 phrase) Overview and scope Level Preconditions Postconditions in words (write in passive and past tense) Trigger Included Use Cases Extending Use Cases MAIN SUCCESSFUL SCENARIO in numbered sequence Reference included use cases in this section using INCLUDE ius_name OTHER SUCCESSFUL SCENARIOS (Specify any successful variations of the normal execution path, including any extension points using EXTEND eus_name) P9 WritePrescription Doctor To order medication(s) needed for patient diagnosis. After speaking with patient and physical examination the doctor feels it necessary to order medication. Primary 7. Doctor is logged into the DNS System. 8. Doctor examines patient. 9. Doctor determines medication is required. 7. Doctor assigns patient. 8. Doctor orders medication. 9. Doctor sends request to Pharmacy electronically. After examination doctor deems medication is necessary for patient well being. I8: AssignPatient None Actor Action System Action 1. Doctor logs into DNS 2. Login code verified. system with login code on his tablet. 3. Doctor assigns patient. 4. Displays patient chart. 5. Doctor assigns medication 6. Displays medicine(s) chosen, chart. queries if correct? Y/N 7. Doctor confirms Y 8. Displays patient information and medication desired. 9. Doctor confirms and 10. Prescription sent electronically to orders. Pharmacy. Step Branching Action UNSUCCESSFUL SCENARIOS (erroneous situations) Conditions 1. Doctor incorrectly assigns medication. Actions 2. Displays medication chosen, queries if correct? Y/N 33

3. Doctor notes error, indicates N. 4. Displays medicine chosen, queries Y/N? Priority in scheduling Frequency Business rules and data logic Other non-functional requirements Superordinates Developer Creation date and last modified date 5. Doctor notes error indicates 6. Displays medicine chosen, N. queries if correct? Y/N 7. Doctor confirms and 8. Prescription sent electronically to orders. Pharmacy. Primary ~5 times a day (based on Claires description of normal work days) 30. A patient must be examined. 31. A patient must be assigned 32. A doctor must order medication. 33. Prescription must be sent electronically to Pharmacy. 21. All staff must belong to a security group. 22. All staff must be HIPPA certified. 23. All staff must have access to a desktop or tablet computer. None Christie McHargue Created on: August 24, 2013 USE CASE DESCRIPTION- Christie McHargue USE CASE # USE CASE Name ACTOR Goal (1 phrase) Overview and scope Level Preconditions Postconditions in words (write in passive and past tense) Trigger Included Use Cases P3 ProcessPayment Office Staff To record patient payment for services. After inputting all action needed to record completed office visit office staff accepts form of payment and prints receipt. Primary 10. Office staff member is logged into the DNS System. 11. The patient appointment is finished. 12. The payable transactions are ready to be processed for payment. 10. A receipt will be generated with the following anticipated information If patient direct payment, then Patient ID Name of Patient Payment amount 11. Updated payment information is loaded and payment status is set to Paid on patient direct payment. 12. Receipt will print Payment history is recorded and stored in Patient appointment history PrintReceipt 34

Extending Use Cases MAIN SUCCESSFUL SCENARIO in numbered sequence Reference included use cases in this section using INCLUDE ius_name ProcessInsurancePayment Actor Action 1. Office Staff inputs patient direct payment information. System Action 2. ius_i6:print Receipt: Receipt generated that includes Patient ID, Name of Patient and Payment Amount 3. Updated payment information is loaded and payment status is set to Paid. 4. Receipt is printed OTHER SUCCESSFUL SCENARIOS (Specify any successful variations of the normal execution path, including any extension points using EXTEND eus_name) UNSUCCESSFUL SCENARIOS (erroneous situations) Step 1. Office Staff inputs patients Insurance Provider information. Branching Action 2. eus_p3e1: Process Insurance Payment: Invoice generated that includes: Provider ID, Name of Provider, Address information (street, city, state, zip) and ICD9 diagnosis codes, labs 3. Updated payment information is loaded and payment status is set to Payment-in-Process 4. Invoice is sent electronically to Insurance Provider via email. Conditions Actions *a Abort the transaction Priority in scheduling Primary Frequency 45 times per day. 5 5 Frequency estimate based on a Study from the Annals of Family Medicine found here: http://www.ncbi.nlm.nih.gov/pmc/articles/pmc1466945/#!po=73.0769 where the average workday for a doctor is 8.6 hours and of that time 54.9% percent is spent face-to-face with the patient. The average patient visit is 18.7 minutes; therefore a doctor can reasonably expect to see 15 patients a day. Further if our clinic has 3 doctors then we can reasonably expect to see 45 patients a day. (Gottschalk & Flocke, 2005) 35

Business rules and data logic Other non-functional requirements Superordinates Developer Creation date and last modified date 34. A payment must be ready to process. 35. A receipt must be generated for direct patient payment. 36. The direct patient payment must include patient id. 37. The direct patient payment must include payment amount. 24. All staff must belong to a security group. 25. All staff must be HIPPA certified. 26. All staff must have access to a desktop or tablet computer. None Christie McHargue Created on: August 24, 2013 USE CASE DESCRIPTION- Christie McHargue USE CASE # USE CASE Name ACTOR Goal (1 phrase) Overview and scope Level Preconditions Postconditions in words (write in passive and past tense) Trigger Included Use Cases Extending Use Cases MAIN SUCCESSFUL SCENARIO in numbered sequence Reference included use cases in this section P3E1 Process Insurance Payment Office Staff To generate invoice for Insurance Payment After inputting all action needed to record completed office visit office staff accepts form of payment and generates invoice for insurance payment. Extend 13. Office staff member is logged into the DNS System. 14. The patient appointment is finished. 15. The payable transactions are ready to be processed for payment. 13. A invoice will be generated with the following anticipated information Provider ID Name of Provider Address information (street, city, state, zip) Payment amount. 14. Updated payment information is loaded and payment status is set to Payment-in-Process. 15. Invoice is sent electronically to Insurance Provider Payment history is recorded and stored in Patient appointment history None None Actor Action System Action 1. Office Staff inputs patient insurance provider information. 2. Invoice is generated that includes: Provider ID, Name of Provider, Address information (street, city, state, zip) and ICD9 diagnosis codes, labs 36

using INCLUDE ius_name 3. Updated payment information is loaded and payment status is set to Payment-in-Process. 4. Invoice is sent electronically to Insurance Provider. OTHER SUCCESSFUL SCENARIOS (Specify any successful variations of the normal execution path, including any extension points using EXTEND eus_name) Step Branching Action UNSUCCESSFUL SCENARIOS (erroneous situations) Conditions Actions *a Abort the transaction Priority in scheduling Extended Frequency 45 times per day. 6 Business rules and 38. A payment must be ready to process. data logic 39. An invoice must be generated for Insurance Provider 40. An invoice must be sent electronically to Insurance Provider. Other non-functional requirements Superordinates Developer Creation date and last modified date 41. Payment information must be updated. 27. All staff must belong to a security group. 28. All staff must be HIPPA certified. 29. All staff must have access to a desktop or tablet computer. None Christie McHargue Created on: August 24, 2013 6 Frequency estimate based on a Study from the Annals of Family Medicine found here: http://www.ncbi.nlm.nih.gov/pmc/articles/pmc1466945/#!po=73.0769 where the average workday for a doctor is 8.6 hours and of that time 54.9% percent is spent face-to-face with the patient. The average patient visit is 18.7 minutes; therefore a doctor can reasonably expect to see 15 patients a day. Further if our clinic has 3 doctors then we can reasonably expect to see 45 patients a day. (Gottschalk & Flocke, 2005) 37

USE CASE DESCRIPTION- Adelaida Montanez USE CASE # USE CASE Name ACTOR Goal (1 phrase) Overview and scope Level Preconditions Postconditions in words (write in passive and past tense) Trigger Included Use Cases Extending Use Cases MAIN SUCCESSFUL SCENARIO in numbered sequence Reference included use cases in this section using INCLUDE ius_name OTHER SUCCESSFUL SCENARIOS P8 ViewSchedule Nurse To maintain the patient and doctor schedules and organize visits. The nurse will log into the DNS system. The nurse will verify the doctors and patient schedules as needed. The patient s visit is dependent on the availability of the doctor s schedule. Primary 1. Nurse must be logged into the system 2. Doctor or patient schedule is chosen (1) A last viewed/modified record was created (2) Update_ViewScheduleDate was created (3) Update_ViewScheduleDate was associated with View Schedule Doctor needs an update of their schedule. PrintSchedule None Actor Action System Action 1. Logs into DNS 2. Authenticates login 3. Enters Doctor file 4. Allows navigability 5 Clicks Doctor Schedule 6. Doctor Schedule opens 7. Clicks on the Month 8. Calendar opens 9. Views Schedule and logs off Step 1. Logs into DNS 10. Logs staff member off Branching Action UNSUCCESSFUL SCENARIOS (erroneous situations) Priority in scheduling Frequency 3a Enters patient file Clicks Doctor Schedule 6. Clicks on the Month 8. Views Schedule and logs off Conditions Actions *a DNS does not recognized Denies access to DNS, prompts staff username and or passcode member to re-enter the information correctly. Primary When a doctor needs to know the time of his next patient. 38

Business rules and data logic Other non-functional requirements Superordinates Developer Creation date and last modified date 1. Schedule must contain first and last name 2. Schedule must contain and time and date of each appointment 3. Schedule must contain the date and time each appointment was made. 4. Schedule must record the staff member, which made the appointment. Schedules cannot be accessed from foreign computers or laptops. None Adelaida Montanez August 21, 2013 USE CASE DESCRIPTION- Adelaida Montanez USE CASE # USE CASE Name ACTOR Goal (1 phrase) Overview and scope Level Preconditions Postconditions in words (write in passive and past tense) Trigger Included Use Cases Extending Use Cases MAIN SUCCESSFUL SCENARIO in numbered sequence Reference included use cases in this section using INCLUDE ius_name P8Inc7 PrintSchedule To print a complete schedule including month, date, and appointments for office use The nurse will log into the DNS system. The staff member will print the doctor and patient schedules as needed. Include 1. Must be signed into the DNS system 2. Must be in the doctor or patient schedule file (1) A last viewed/modified record was created (2) Update_ViewScheduleDate was created (3) Update_ViewScheduleDate was associated with View Schedule Doctor asks for a printed schedule None None Actor Action System Action 1. Logs into DNS 2. Authenticates login 3. Enters Doctor file 4. Allows navigability 5. Clicks Doctor Schedule 6. Doctor Schedule opens 7. Clicks on the Month 8. Calendar opens 9. Prints Schedule and logs off 10. Logs staff member off 39

OTHER SUCCESSFUL SCENARIOS Step Branching Action UNSUCCESSFUL SCENARIOS (erroneous situations) Priority in scheduling Frequency Business rules and data logic Other non-functional requirements Superordinates Developer Creation date and last modified date Conditions Actions *a DNS does not recognized Denies access to DNS, prompts staff username and or passcode member to re-enter the information correctly. Optional Whenever a doctor asks for a hard copy of the schedule None None ViewSchedule Adelaida Montanez August 21, 2013 40

1.5 Discussion of Use Cases The DNS use case diagram is comprised of yellow base, blue extend, and red include use cases. The primary actors are office staff, nurse, and doctor while secondary actors are the subsystem, lab, and pharmacy. An office staff has the ability to schedule one or multiple appointments and cancel appointments. During the scheduling process the office staff will include a date and time, as well as assign a doctor to a patient. The office staff is able to look up diagnosis codes in the ICD9 database and input patient history with symptoms only or with symptoms and treatment. An office staff will process self-pay or insurance payments and print a receipt for the patient. The office staff is responsible for sending invoices to insurance companies and late notices to both patients and insurance companies. Office staff input nurses and doctors in the system. The office staff, nurse, and or doctor with the option to print can view the schedule. The doctor will order labs, which will be sent to a lab for processing and write prescriptions that will be taken to a pharmacy for assigned patients. Earlier versions of the use case diagram consolidated all actors into the office staff actor, considered office staff both a primary and secondary actor, and had less include and extend use cases. The final version selected shows the important roles carried out by doctors, nurses, and office staff, which is why it was altered from the earlier version. More include and extend use cases were needed to give a more satisfying scope of DNS. 41

(4) The Class Model 4.1 TCM Table Nouns Class Elimination Rules Applied (Step N2) Meta-Language (CER6) Class Categories Applied (Step N3) Simplified Patient Care Clinic System (PCCS) clinic NO (Singleton) Physical Thing (CC3) patient NO Roles of People (CC1) appointment NO Event (Transaction) (CC5) medical history Adopted patient history, Redundant (CER1) symptom Attribute (CER7) labs NO Physical Thing (CC3) prescription NO Physical Thing (CC3) treatment Attribute (CER7) payment NO Transaction (CC5) doctor NO Roles of People (CC1) nurse NO Roles of People (CC1) staff NO Roles of People (CC1) comprehensive system Meta-Language (CER6) system Meta-Language (CER6) insurance payment NO Physical Thing (CC3) patient payment NO Physical Thing (CC3) diagnosis Attribute (CER7) IDC9 code Adopted diagnosis, Redundant (CER1) medical code Adopted diagnosis, Redundant (CER1) tasks Vague (CER3) computerized system Meta-Language (CER6) medical records Adopted medical history, Redundant (CER1) data Meta-Language (CER6) payment history Derived (CER9) invoice NO Physical Thing (CC3) office staff Adopted staff, Redundant (CER1) scheduling system Meta-Language (CER6) electronic files Meta-Language (CER6) functionality Vague (CER3) workflow Vague (CER3) organization Adopted clinic, Redundant (CER1) customers Adopted patient, Redundant (CER1) employees Adopted staff, Redundant (CER1) patient history NO Transaction (CC5) billing records Derived (CER9) database Meta-Language (CER6) Class 42

Nouns Class Elimination Rules Applied Class Categories Applied (Step N2) (Step N3) Class office Irrelevant (CER2) medical staff Adopted staff, Redundant (CER1) computers Irrelevant (CER2) tablets Irrelevant (CER2) schedule NO Physical Thing (CC3) reminder NO Physical Thing (CC3) receipt NO Physical Thing (CC3) 43

4.2 The Class Diagram 44

4.3 Selected Class Definitions All classes are intuitive. 4.4 Selected Association Definitions All associations are intuitive. 4.5 Discussion A staff member manages one to many schedules that contain one to many appointments with date and time. A patient comes to one or many appointments, which are attended by an assigned doctor that is following a set schedule. A doctor makes diagnosis, which are later recorded in a patient s medical history. Treatments are ordered by a doctor for a patient and then also recorded in the patient s medical history. Following the visit staff members print and send invoices to the patient. The payments can be paid by the patient or covered by an insurance provider. Doctors are affiliated with a clinic, which employs staff. Earlier versions of the class model lacked appropriate classes as defined in Larman s textbook, which lead to inappropriate associations. The final version was chosen after numerous attempts and suggestions made by a collaboration of team members. The diagram chosen more closely represents the goal of the DNS. 45

CHAPTER 2: System Design (5) Sequence Diagrams 5.1 System Sequence Diagrams for the chosen use cases Sequence Diagram for InputAppointment DNS System Office Worker 1. createnewappointment() 2. enterdate() 3. entertime() 4. assigndoctor() 5. assignpatient() 6. confirmappointment() 46

Sequence Diagram for InputMultipleAppointment DNS System Office Worker 1. createnewappointment() 2. enterdate() 3. entertime() 4. assigndoctor() 5. assignpatient() 6. confirmappointment() 7. createnewappointment() 8. enterdate() 9. entertime() 10. assigndoctor() Repeat as many times as requested. 11. assignpatient() 12. confirmappointment() 47

Adelaida Montanez- Sequence Diagram 48

Claire King- Sequence Diagram 49

Christie McHargue- Sequence Diagram 50

5.2 A set of sequence diagrams that expand the system sequence diagram System Sequence Diagram for ScheduleAppointment Sarah Neergaard Patient DNS System Keyboard DNS Scheduler Display Office Worker 1.1 Receive call for appointment 1.2 Request Appt for specified Date 2.1 Input Calendar week 2.2 View Schedule 2.4 Assign date to appointment. 2.3 Date confirmed as available. 2.4 Confirm date. Ask for time. 3.2 Request specific time 3.2 Check to see if time is available on visual display 3.3 Confirm time is available. Assign time to appointment. 4.1 Ask for preferred doctor 4.2 Request specific doctor 4.3 Search for requested doctor's schedule 4.4 View schedule, see doctor is free 4.5 Confirm doctor is available. Assign doctor to appointment. 5.1 Review appointment details 5.2 Confirm details 5.1 Finalize and save appointment. 5.2 View final appointment on schedule 5.3 Patient assigned to appointment. Saved and confirmation sent. The above diagram helps illustrate the process of scheduling an appointment. It shows the interaction between the Office Worker, the keyboard, and the DNS display. 51

Adelaida Montanez-System Sequence Diagram The above diagram helps reduce the complexity of an increasing domain. The input generated by the actor is depicted with a solid black arrow connected to the system. A dotted arrow connected to the actor depicts the output by the system. 52

Claire King- System Sequence Diagram The above diagram illustrates the process of creating a new patient record, and the follow through that would take place during an appointment. The doctor access an appointment, reviews patient, enters symptoms and diagnoses with ICD 9 codes. They can then order labs or write prescriptions and communicate with outside actors. 53

Christie McHargue- System Sequence Diagram The above diagram illustrates a payment going through the system. The staff logs in, enters payment method, submits payment, confirms and marks as paid. The system then prints a receipt. 54

5.3 Validation and Discussion of Sequence Diagrams The system sequence diagram (5.1) is expanded into a set of sequence diagrams in section 5.2. The solid black arrows indicate a command sent from an actor to an object or an object to another. The dotted arrows indicate a response to the command. This diagram depicts the sequence of events experienced by a nurse when viewing and printing a schedule. The loop frame helps indicate the repeated action of the Print object requesting the PrintLineItem object. 55

(6) Design Class Diagram of the Entire Project 6.1 Design Class Diagram 56

6.2 Validation and Discussion of Design Class Diagram The Design Class Diagram includes the class in the first section, attributes in the second section, and operations in the third section. Nurse and doctor are derived from the class staff while payment is derived from insurance. The relationship between appointment and history is an aggregation indicating history is a part of appointment but can exist independently. Appointment has a unidirectional relationship with labs and prescriptions, where the appointment knows about labs and prescriptions. Patient and appointment have a bidirectional relationship because both classes have knowledge of each other. Patient and history, payment, and invoice have a unidirectional relationship. Lastly, the clinic is a singleton restricting it to one obect. 57

CHAPTER 3: Physical Design (7) ERD ERD ClinicID userid Password SSNumber Name FirstName Clinic Works for Staff Location MiddleName Address LastName FirstName MiddleName LastName Appointment ID Date Time Schedule ID Patient ID Address Patient Appointment Scheduled Doctor Specialty Phone Number PaymentID PaymentType Payment OrderID Lab Type Labs Perscriptions Perscription ID Medicine Description Payment Amount Invoice Number Amount Due Invoice History Height Due Date Total Charges Paid Diagnosis Examination Notes Weight Blood Pressure Symptoms Specialty 58

7.1 Relational Database Schema 59