POST TREATMENT FOLLOW-UP CARE APP

Post Treatment Follow-up Care App

APRIL 14, 2016

Swadeesh, Snehal , Sneha , Swati, Sumit, Soumita

Version Description of Change Author Date

1. Document Created Sneha Salian 11/04/2016

2. Document Updated Swati Mehta 12/04/2016

3. Document Updated Sumit Lamba 13/04/2016

4. Document Updated Swadeesh 13/04/2016

5. Document Updated Soumita Sen 13/04/2016

6. Document Updated Snehal Datta 14/04/2016

CONTENTS

1 INTRODUCTION ..............................................................................................................3

1.1 Purpose ........................................................................................................................3

1.2 Scope ............................................................................................................................3

1.3 Assumptions and Constraints ...................................................................................3

2 FUNCTIONAL REQUIREMENTS ....................................................................................4

Context .........................................................................................................................4

2.3 User Requirements ......................................................................................................4

Functional Requirements ..........................................................................................5

3 NON FUNCTIONAL REQUIREMENTS...........................................................................6

Interface Requirements .............................................................................................6

Hardware/Software Requirements .........................................................................6

Operational Requirements ........................................................................................6

Software Quality Attributes. .......................................................................................7

Recoverability ..............................................................................................................7

General Performance ...................................................................................................7

Error Handling .............................................................................................................7

4 USE CASE DIAGRAMS .....................................................................................................8

1 INTRODUCTION

Guaranteeing appropriate follow-up for our patients is frustrating, time-consuming, and often impractical in the 24/7 world of emergency medicine. Yet, it still remains one of the most necessary and valuable actions we can take to ensure proper care and reduce liability. This is a post treatment follow up App which caters to the need of ensuring an in time follow ups to patients.

1.1 Purpose

This is a Requirement document capturing both the functional and non-functional requirements of Post Treatment Follow-up Care App.

1.2 Scope

The project intends to improve patient outcomes, reduce healthcare costs, and provide more information to physicians with the help of a mobile and web based application. The mobile/web application developed will have the following features:

I. Log patient symptoms II. Track weekly progress

III. Ask questions based on patient's diagnosis Flags the symptoms as per the care needed for example:

Red flag symptoms could send the patient in for follow up quicker or into urgent care or into the Emergency department

An orange flag might just need a nurse calling the patient and advising him

Time alarms for taking any prescription medications Send reminders to update information

1.3 Assumptions and Constraints

1.3.1 Assumptions

The patient has Accepted to use the Post Treatment follow up care App and has an Access code to access the System

The system has 24/7 Uptime.

There is no change in the legal changes and policy decisions.

There is a central Database for a preset of question which is already available to the system

1.3.2 Constraints

Two reminder emails must be sent before the Final follow up meeting date.

2 FUNCTIONAL REQUIREMENTS

Context

The following diagram captures the essence of the data flow Post Treatment Follow-up Care

App. There is a central Data base for the system which captures all the information of the patients who have registered for the App. The Doctors, Patients and the help desk send and receive information via

the Central data base.

Exhibit 1 – General Data Flow in the System

(The arrows represent data)

2.3 User Requirements

Patients i. Need to access the System (App) based on the code provided by the help desk

officials on the bill. ii. Fill in follow up information as and when prompted by the App.

iii. Schedule an Appointment with the doctor based on the follow up.

Doctors: i. Need to have Access to the information of all the patients under him who are using

the App. ii. Need to approve the set of question per patient based on the disease he or she is

diagnosed with and the treatment taken. iii. Need to have access of the Feedback of the patient given on the follow up

questions. iv. Recommend or suggest changes in the Treatment the patient is taking. v. Need to View high priority cases flagged Red by the App to take impromptu

decision to inform the help desk if the patient needs an in person checkup. vi. Send help desk with the updated list of patients who do not need follow up any

further.

System

Doctors

Patients

Helpdesk

Helpdesk Officials: i. Needs to access all the information of the System.

ii. Send the Doctors with all the Patients flagged as a Red on the follow-up Questionnaire.

iii. Need to update the cases as closed according to the list sent by the doctor.

Functional Requirements

2.2.1 Functional Requirements

Section/ Requirement ID

Requirement Definition

FR1.0. The Application shall store follow up information of all the patients based on the Access code as a part of the composite key in the central data base.

FR1.1 The System stores the history of the customer as recorded by the doctor using the Access code as the key.

FR1.1.1 The system shall generate a List of Red Flagged follow Up Patients Weekly.

FR1.1.2 The system shall have a stored set of questions classified according to various diseases. (Update rights to Doctors)

FR2.0. Patients must be able to access the system view their Access code

FR 2.1. Patients must be able to view the feedback question on their mobile applications as and when made available by the doctors.

FR 2.2. Patients must be able to save their feedback answers into the system.

FR 2.3 Patients must get alert mails regarding any updates on their Application

FR 2.4 Patients should be able to request an in person appointment with their doctor.

FR 2.5 The System must be able to classify the patient’s feedback as a Flag Red/Orange/Green.

Red : Severe

Orange : Mild

Green : No Feedback

FR 3.1 Doctor should be able to view all the patients under them

FR 3.2 Doctors should be able to view all the feedback recorded by their patients.

FR 3.3 Doctors should be able to sort their patients based on the flag generated by the system

FR 3.4 Doctors should be able to record comment on the feedback which should be available to the Patient

FR 4.0 Helpdesk officials should be able to generate a new access code for each patient who avails the Post Checkup App

FR 4.1 Helpdesk should be able to close the cases according to the list provided by the doctors.

FR 4.2 Helpdesk should resend a reminder email to the patients who are defaulting on the feed back

Section/ Requirement ID

Requirement Definition

FR 4.3 Helpdesk should maintain the database of all the patient records.

FR 4.4 Helpdesk should be able to view the classified questionnaire and suggest changes if and when required.

3 NON FUNCTIONAL REQUIREMENTS

Interface Requirements

There would be three user interfaces implemented by the System. 1. Patient Interface: The interface used by the users on their mobile phones. 2. Doctor’s Interface: The interface used by doctors to view their patients and add

details to the patient’s follow-up. And additional management for the questionnaire sent to the patient.

3. Helpdesk Interface: The interface used by the helpdesk official to maintain the data base of the patients.

Hardware/Software Requirements

Operating System o The software is being designed to run on Windows Server 2008. Windows

Server 2008 includes the latest version of Internet Information Services, version 6.0

Web Server o The software is being designed to run on Internet Information Server

version 6.0. Database

o The software will access the SQL Server 2000 Enterprise Edition database

Libraries o The software will be created using the Microsoft .NET version 1.1

framework.

Operational Requirements

1. The Users Patients will Log into the system via their Mobile Application, with the unique Access code provided to them.

2. The Patients can fill in follow up forms, which is a specific set of questions selected by the doctors for each access code (or Each patient).

3. Doctors will Log into their system via their Desktop Application.

4. The Doctors can view their patient list.

5. Which can be further maximized to view the feedback provided by the patient.

6. Doctors select the list of questions to be sent to their patient by selecting the questions from the central database.

7. Doctors can update the system with a case as closed.

8. Helpdesk can view modify and maintain the system.

Software Quality Attributes.

Availability: The system must be available for use when it is needed during the

critical months of updating the directory. The web site should have 99% uptime.

Reliability: Data, as entered, must be correctly stored in the database. In addition, the database should use transactions so that partial entries are not stored in the database. Because the user of the system may be inexperienced, each feature must work correctly 99% of the time. The logic required is not complex enough to allow for a lower expectation.

Usability: The system will be used by individuals of varying skill level and technical competence. The system shall be intuitive to use and have extensive online help documentation to walk users through the operations they are trying to perform.

Maintainability: The system will likely be developed by a different team at the same time next year. The code and design need to be documented well enough and designed such that a senior project team with the same amount of academic and co-op experience can ramp up on the project within 3 weeks.

Recoverability

A. In the event the application is unavailable to users (down) because of a system failure, System should recover in 24 Hours.

B. The database must be capable of being restored to its condition of no more than 1 hour before the corruption occurred.

C. If the processing site (hardware, data, and onsite backup) is destroyed, it should be restored in 2 business dats.

General Performance

A. Response time for queries and updates

B. Throughput

C. Expected rate of user activity (for example, number of transactions per hour, day, or month, or cyclical periods)

Error Handling

1. Errors are handled by centralized Error Logging Table.

2. When an Error occurs the Error ID and the details of the Error must be stored in the Error-Log Table.

4 USE CASE DIAGRAMS

POST TREATMENT FOLLOW-UP CARE APP

System Analysis and Design Deliverable -2

APRIL 14, 2016 UNIVERSITY AT BUFFALO

Soumita Sen, Sumit Lamba, Swati Mehta, Swadeesh, Snehal Dutta, Sneha

Questions to doctors:

How are you currently tracking patient recovery / post treatment progress?

How many patients come and meet you weekly for this purpose? How many of these actually require additional care?

Is there an application that helps you track this?

Would it benefit you if there was an application that helps you track patient recovery progress?

If an application is made to track patients post treatment follow up, would you suggest your customers to use it? If yes - why? If No - Why?

What would be the benefit of such an application?

What kind of additional features would you like an application like this to have? Questions to sponsors and senior management:

Where does the process start?

Who will use this feature?

Is it a mobile app or a web application app?

When will this application be used?

Does this feature meet the business need and solve the problem we’re trying to solve?

How will patients access application?

What will be the key features of the application?

Does this application bring changes to existing hospital management applications?

Out of all the features, which features do you think are the most critical ones?

What is the implementation plan for this application? What platform would you suggest for building this application?

Where will all the data pertaining to this application stored?

How many interfaces should the application have?

Do you have any suggestions regarding the performance of the application, considering both backend and frontend?

Would you like to incorporate a system to handle and record all the errors pertaining to application?

What all information would you like to see for each error occurrence?

Would you like these errors to be reported to the management?

Questions to Patients

Do you face situations where you have to revisit doctor to update progress of your illness?

Do you feel that sometimes revisit can be avoided?

Would you like to use a feedback and post follow up application?

Have you ever used such an application before?

What issues you think are present in current patient follow up system/method currently used by physicians?

Would you like to use a mobile app or a web app which can provide the status of your illness to physicians post initial visit?

How often would you like to be receive follow up messages from the application?

Would you also like to be followed up via telephone call from hospital management? If yes, how often?

Would you like to answer the questions related to your illness by typing details or related ready to select options?

What other features would you like to have in this post follow up application?

Do you think such an app will help you cut down your revisit to doctor in some situations? What are the other potential benefits you think this app can provide to patients and doctors?

Questions to hospital Management: How is the hospital currently following up with patients post their treatment?

Would it be useful to add feature related to post treatment follow up in your current Health Information System?

If an application is made to automate follow up with patients, would it help the hospital run more efficiently?

Would you like to have a standalone application or integrate it with existing systems?

What all features you expect in such a follow up application?

MOM:

Doctors currently do not use any application or specific procedure to follow up with patients. In most of the cases, patients are called post treatment which turns out to be inefficient way of follow up. Doctors will be happy to use this follow up care and believe that this will definitely aid to quality of patient care.

Hospital Management also sees introduction of this application as a positive change. However, they would like to integrate this application with the existing system. This can be taken into consideration in future.

Patients are willing to use this follow up application as it not only helps cure the problem in an

efficient way but also help to cut down the expenses incurred for frequent follow up checkup in ordinary situations as well. Also, they welcome any additional features application can incorporate in future, to streamline other processes.

Based on feedback from all the sponsors and stakeholders both mobile and web application will be developed for the follow up feature and it would initially be a standalone application.

POST TREATMENT FOLLOW-UP CARE APP

System Analysis and Design Deliverable -2

APRIL 14, 2016 UNIVERSITY AT BUFFALO

Soumita Sen, Sumit Lamba, Swati Mehta, Swadeesh, Snehal Dutta, Sneha

Activity Diagram: Post Treatment Follow-up

Post Treatment Follow-up App

Patients Doctor HelpDesk System

Ph

ase

Request AccessCode for Post Treatment

follow-up App

On Recieving the Request Sends request to System

Generates Random AccessCode

Recieves Code From the System

Recieves Code For their Patients

Recieves Code

Use code to Provide Feedback Questionaire

Use code to View Patient feedBack

FeedBack Stored in the System.

Show FeedBack Provided by the Patient

Provide Confirmation of FeedBack Stored in the

System

Updates System with Questionaire for Particular

Access Code

System Feedback Questonair Updated and

Made Available to the Patient

Analyze FeedBack Update PatientSystem based on the

Feedback Provided

Send Update to PatientFeedBack From Doctor

Continue FeedBack?

Yes

No

Close Case

Wait for Update From Doctor

Follow Doctors Treatment

Flags Patient Red , Orange and Green based on FeedBack

USE CASE:

SEQUENCE DIAGRAM

STATE DIAGRAM:

CLASS DIAGRAM:

Patient requests access code

Requesting Access code

HelpDesk sends request to system

Access Code generated

Patient receives access code

Provide Feedback Questionaire

Patient provides feedack

Confirmation generatedWait for doctor s update

Doctor's treatement

followed

Continue feedback

Yes

Questionaire updated

NO

Viewed patient feedback

Update sent to Patient from Doctor

flag patient red, orange and green

Patient

+PatientID: int

+PatientName: string+ContactNo: int+Address: string+Age: int+Sex: string

PayBills( )Feedback( )ReqforAppntmnt( )

Doctor

+DocID: int

ReviewQues( )

+DocName: string+ContactNo: int

UpdateQues( )ViewHist( )RecommendTrtmt( )DetermineCheckup ( )MarkCaseClosed( )InformHelpDesk( )

HelpDesk

+PersonID: int

GenerateBill( )

+StaffName: string+StaffGrade: string

GenerateCode( )ScheduleAppmnt( )

CloseCase( )SendReminder( )

Bill

+BillNo: string+PatientName: string+AppCode: string+BillAmnt: float

Appointment

+AppointmntID: int+PatientName: string+Date: string+time: string

Feedback

+FeedbackID: int+FdbackFlag: char

+FlagType: string

+FeedbackDesc: string+1..*

+1

+1 +1

+1..*

+1

+1

+1

+0..*

+1

+0..*

+1

+1..*

+1

+1..* +1..*