Initial requirements, survey questions and UML diagrams for a post treatment healthcare app that would enable easier and smoother interaction between doctors and patients

1. POST TREATMENT FOLLOW-UP CARE
APP
Post Treatment Follow-up Care App
APRIL 14, 2016
Swadeesh, Snehal , Sneha , Swati, Sumit, Soumita

2. 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

3. 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

4. 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.

5. 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

6.  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 Doctorsshould be able torecord commenton 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

7. 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.

8. 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.

9. 4 USE CASE DIAGRAMS

10. 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

11. 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?

12.  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.

13. 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

14. Activity Diagram: Post Treatment Follow-up
Post Treatment Follow-up App
Patients Doctor HelpDesk System
Phase
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
ProvideConfirmation of
FeedBack Stored in the
System
Updates System with
Questionaire for Particular
Access Code
System Feedback
Questonair Updated and
Made Availableto the
Patient
Analyze FeedBack Update
PatientSystem based on the
Feedback Provided
Send Updateto Patient
FeedBack From Doctor
Continue FeedBack?
Yes
No
Close Case
Wait for UpdateFrom
Doctor
Follow Doctors Treatment
Flags Patient Red ,
Orangeand Green
based on FeedBack

15. USE CASE:

16. SEQUENCE DIAGRAM

17. 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 generated
Wait 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..*