Software Requirements Specification (SRS) Project PMR-Droid

Software Requirements Specification (SRS)
Project PMR-Droid
Authors: Joe Heldt, Jong Jang, Michael Keesey, Tom Randall, and Kurt Seippel
Customer: Dr. Betty Cheng and Dr. Tom Foster, Droid user.
Instructor: Dr. Betty Cheng
Introduction
This Software Requirements Specification document provides an overview of the
functionality of a Personal Medical Record (PMR) designed for the Motorola Droid phone.
This document will cover the scope, organization, description, constraints, requirements, and
the prototype of the PMR.
1.1
Purpose
The purpose of this document is to describe the functionality and specifications of the
design of a PMR for the Droid. The expected audiences of this document are the developers
and users of the application.
1.2
Scope
The PMR will be designed to run on the Droid. The user will be able to store, access and
comment on their medical records from their Droid phone. This information will be stored
on a central database where health care providers will be able to upload the most recent
medical records for their patients. The application will then be able to download this data
from the server whenever it needs the up to date medical record.
1.3
Definitions, acronyms, and abbreviations
Android- The operating system, developed by Google, made to run on cellular

phones.
Droid- A smart phone that is currently distributed by Verizon Wireless that runs the
latest version of the Android operating system.
EMR (Electronic Medical Record) - An electronic copy of the patients medical
record. Your health care providers provide all information.
GUI (Graphical User Interface) - The part of the application that the user sees and
interacts with.
IP Address- A unique number given to every computer on a network to uniquely
identify it.
PC (Personal Computer) - A desktop or laptop running the Microsoft windows
operating system.
PMR (Personal Medical Record) - A copy of the patients EMR that is stored,
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have been
made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
1.4
accessed and possibly edited by the patient. Contains most, if not all, medical data
that is in your medical record.
SDK (Software Development Kit) set of tools that makes it possible to create
software for a particular piece of software or hardware, in our case the Android 2.0
operating system.
Thumbnail- A scaled down version of an image used to save space but still allow you
to preview the image.
XML (Extensible Markup Language) A widely used type of text data organization
and storage language that use < and > to label and distinguish sections of data or
instructions from each other.
Organization
The remaining portions of this document are decomposed into four major sections,
followed by references and a point of contact. The first section will provide an overall
description of the project and the next part will give more detailed requirements. Following
the requirements, there are models describing the application and the description/use of the
prototype.
2
Overall Description
This section provides a high level description of the entire application. It describes the
product perspective, functionality, and characteristics of an expected user, constraints,
assumptions and dependencies, and the approportioning of requirements.
2.1
Product Perspective
This application is specifically designed for the Droid. There needs to be a database with
all of the different patients EMRs for the application to access. The interface will be made
to have a similar look and feel that is consistent with other Droid applications. Most Droid
applications have a similar way to display and navigate through data. The display that will be
implemented by the PMR application will be consistent with other applications. This
familiar GUI will make the user feel more comfortable navigating and viewing the data on
our system.
Our PMR system is a part in a larger system. In figure 2.1 you will see that the health
care worker is in charge of inputted the medical data to make an EMR. Once the EMR is
made, it is stored on a secure database, refer to section 3, which our PMR can access. Once
our application downloads this data, it provides the patient with an organized and easy way to
navigate and view their medical record.
EMR
Health Care Provider
Database
PMR
Patient
Figure 2.1
Product Functions
2.2
2.3
Provides a high-level view of the key types of medical information that includes
medications, procedures, vaccinations, conditions, allergies, family history, test and lab
results, insurance providers, and emergency contacts.
Provides a means to easily navigate, using the Droids touch screen interface and
keyboard, to the details of any of the key types of medical information.
Provides access to different types of media for medical records including images, textbased documents, and scanned documents.
The user is able to backup a local copy of their PMR on their personal computer and edit
it. This backup can be later transferred back to the phone if needed.
User Characteristics
The user should be familiar with the basic functionality of the phone.
The user should be able to use the touch screen and the other navigation
buttons along with the keyboard to input the data. The user will also have to
know some basic medical terminology and information to understand the
application and the different categories.
2.4
Constraints
One major constraint on the application is the amount of data that can
be stored on the phone. The EMRs on the server can contain large sized files,
like images and scanned documents. These large files can quickly use up a lot
of the space available on the Droid, so our application doesnt save these files
stored locally. Instead, a thumbnail is saved on the Droid and the user can
choose to download the image if they feel it is important. This will save space by
limiting the amount of images actually stored on the phone.
One other constraint is that this application will not work on other
phones. This application will only work on the Android 2.0 operating system. The
Motorola Droid is currently the only phone in production that supports Android
2.0.
2.5
Assumptions and Dependencies

Android 2.0 has a number of features that are included that we can assume our
application can utilize. Some important features include a web browser, java support, video
and camera, and touch-screen support. Our application will use all of these features and
should work on any phone as long as it is running Android 2.0.
We can also assume that all input will only come in three forms, the touch screen,
keyboard, and the other buttons found on the Droid. Since each phone has its unique
buttons, we will only use these buttons to end the application and rely on the touch screen
and keyboard to perform the rest of the applications navigation.
2.6
Approportioning of Requirements
One of the things the customer would like implemented is a more robust application on
the computer. The computer side application will only have limited functionality to edit and
view the PMR. Having a more robust system could offer better navigation, ability to see if a
file on the Droid or server has changed, or many other features.
Another feature to be added will be an auto-sync feature. This will automatically
update the PMR on either the Droid or computer whenever the EMR on the server has
changed. It could do this automatically or could accept only certain changes.
As of now, to access the PMR on the Droid you need the correct username and password.
Some customers might want their PMR to be more secure so there could be functionality
added to improve the security. Some ways to improve security could be to add some
biometric access, like finger print or iris scanning which is possible using the Droid, but not
reliable as of yet.
Specific Requirements
This section provides further details on the specific requirements of our application.
Each requirement is given along with a description of the requirements.
1. Provide a high-level view of the key types of medical information: We will have a front
page where basic medical data will be displayed. This front page is designed to be used
in case of an emergency. If doctors would need to quickly obtain important medical data,
like blood type or allergies to certain medications, they could look at this main page
without having to log in. For security reasons, the user can hide whatever information
they dont want someone to see without logging in. They can go through and select
whatever information they think is important on the front page, and hide whatever
information they dont want anyone to see.
2. Provide a means to easily navigate to the details of any major categories: there is a tabbed
user interface where the major topics will be selectable. Once a category is selected, the
screen will be refreshed to a separate page where all the relevant information will be
displayed in an organized fashion.
3. Provide access to different types of media for medical records, including:
a. Text-based documents
b. Images (CT-scans, X-rays)
c. Scanned documents
d. Photographs
All of the above information will be stored on the server unless specifically
downloaded by the user. A persons medical record can contain dozens of pictures
and scanned documents so this could take up a lot of space very quickly. For this
reason, we allow users to download these different pieces of media if they think it
is important, but dont include it automatically to save space.
4. For each medical procedure, diagnosis, medication prescribed, there will be the following
information stored with the entry:
a. A healthcare workers complete contact information
b. Date of event
c. Rationale for treatment/medication/diagnosis
d. Follow-up activities
e. As appropriate, any short-term or long-term side effects
f. As appropriate, any relationship to family history (ancestors and/or descendants).
This information is standard for any information provided by in the medical
record, other than the basic information. There can be more information needed
depending on the kind or medical information being provided, so wherever
necessary there are more fields to input additional data. Below is a list of this
additional information:
1.
2.
3.
4.
Medication - name, dosage, frequency, date prescribed and date ended.

Medical procedure - procedure type and date of procedure.
Vaccination - name and frequency.
Medical condition name, diagnosis, symptoms, treatment, severity, onset
date, and cured date.
5. Allergy - what you are allergic to, what kind of medication are you taking,
if any, any other treatments you are receiving, and the severity of the
allergy.
6. Lab and test results - the type of result, what hospital it was administered
at, the results, and a link to the scanned document.
5. A means for a patient to record information (e.g., symptoms, context, photographs of
condition): Sometimes the user will want to comment on the different pieces of
information in the application. This is possible for any of the information stored on the
phone or computer. Once the user comment on something, it is flagged as Commented
on by User so the users doctor knows that this is not information provided by a doctor
but by the patient. This is important so the doctor knows that all the other data is still
reliable and he can trust that it can from a medical provider. These comments will be
synced with the data on the database so whenever the user downloads the latest version of
the data, the user will also get their comments.
6. Be able to backup information onto computer: At any point the user can connect the
Droid phone to a computer, or use the computer application to download the data from
the server directly. Once the medical record is on the computer, it provides a safe backup
in the event that something happens to your phone. The PMR on the computer can also
be synced with the medical record on the server if something is added or changed. If at
any point the PMR on the Droid becomes corrupt or lost, the user can download the file
on their computer and save it back to the phone.
7. Security: Some information is more private than the users personal medical history. With
this in mind, the system seeks to maintain a high level of security. The security measures
are separated into two domains: database/server security, and user authentication.
a. Database/Server
i. The data is separated into two groups, according to the sensitivity of the
data, see figure 3.1. The first group will contain most of the basic
information like name, address, phone number, etc. The second group will
contain the more secure data like test results, medical condition,
medications, etc.
These groups are
stored on separate
servers, with a firewall
in
between them, as well
as
a firewall protecting
the system as a whole.
This multi-layer
firewall approach
allows the most
sensitive data to be
protected by multiple
firewalls.
Figure 3.1
ii. Direct access to the databases will be restricted by IP to the developers

only. No one else will have direct access to the data.
iii. Commercial anti-virus software will be employed on all servers.
iv. Administrator and developer passwords must be changed every 14 days.
v. Developers will also use CryptoCard authentication tokens for one-use
randomly generated passwords.
b. User Authentication
i. Users, defined as either patients or health care providers, will need to use
username and password authentication to gain access to their data.
ii. User passwords will require one or more uppercase letters, one or more
lowercase letters, one or more numerical values, and one or more special
characters (@, $, %, etc.).
iii. If no activity within the application is registered for a period of ten
minutes, the user will be logged out automatically.
4
Modeling Requirements
To start use of the PMR, a doctor registers the patient and adds the patient's record to
his/her database of patient medical records and the PMR database-server. A medical record
consists of basic personal information (e.g. name, social security number, gender, blood
type), insurance information, family history, emergency contacts and zero or more medical
record entries. A medical record entry consists of text data (e.g. information on medications,
vaccinations, x-rays and test results) and any images associated to that entry (see figure 4.1).
All text-based data is stored both on the server and the Droid, while all non-text based data,
such as images and any large files are stored only in the server; links to them are stored on
the Droid device, and can be downloaded when in network for display or storage. Both
physicians and patients can upload images or scans to associate with any entry and each
image will be flagged as being uploaded by either the patient or the doctor. Only the health
care provider can add or edit entries, but the patient can comment on any entry (see figure
4.2), and when the patient syncs their info to the database, the comments will be added to the
server along side the entries for the doctor to view.
Sync is a function done by both the doctor and patient to update their records as well as
the databases records. When the health care provider syncs, they add the new and updated
entries to the server and can update any comments made by the patient. Along with adding
any comments made by them, when the patient syncs to the database they also receive the
updated information that the doctor added (see figures 4.3 and 4.4). After syncing, the user
can display the new info on their Droid, though syncing is not necessary when out of
network; the Droid will just display the latest version of the medical record since the last
sync. When displaying an entry, the patient can choose to download any images associated
in the entry from the server by tapping on the link. The image can be displayed, copied, emailed or saved onto disk. If nothing is done with it, the image will remain in the Droid's
memory until the patient logs off the PMR.
The patient can also backup the record by connecting the Droid to a laptop or desktop
computer (see figure 4.4). The record will copy to a folder (or make one) as an xml
encrypted document and will overwrite the previous copy. If any images are still in memory
when syncing, the patient will have the option of backing those up as well.
Figure 4.1: Class Diagram. This illustrates the relationship between the Patient, Health Care
Provider (both are Users), and the relationship between the different parts of a Medical Record.
System
Login
Logoff
newRecord
editInfo
uploadImage
commentInfo
sync
Health Care Provider
backupInfo
Patient
display
Extends
downloadImage
Figure 4.2: Use Case Diagram. The arrows point to what functions the
patient and the healthcare provider can do within the PMR system.
10
11
:Health Care
Provider
:Patient
:Medical Record
:Entry
:Basic Info
:Database
:Computer
login()
newRecord()
addBasicInfo()
addEntry()
uploadImage(string filepath)
sync()
editInfo()
editBasicInfo()
editEntry(E)
uploadImage(string filepath)
sync()
logoff()
Figure 4.3: Sequence Diagram for the Health Care Provider use cases. This shows the
sequence
events
and Std
interactions
between
the health (content
care provider
and of
other
members
ofbeen
the
Templateof
based
on IEEE
830-1998 for
SRS. Modifications
and ordering
information)
have
12
class
diagram
(figure
4.1).
Here,
the
heath
care
provider
logs
in,
creates
a
new
patients
medical record, edits a patients medical record, adds images to the database, syncs the info
back to the database and logs off.
13
:Health
Care
Worker
:Patient
:Medical Record
:Entry
:Basic Info
:Database
:Computer
login()
sync()
display()
returnXML()
display()
downloadImage(image i)
returnImage()
commentInfo()
commentBasicInfo()
commentEntry()
sync()
backupInfo()
logoff()
Figure 4.4: Sequence Diagram for the Patient use cases. This shows the sequence of events and
interactions between the patient and other members of the class diagram (figure 4.1). Here,
the patient logs in, syncs any new information onto the Droid, displays an entry, downloads an
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have been 14
image, comments on an entry, syncs the comment back to the database, backs up the record and
logs out.
15
The following diagrams (Figures 4.5 and 4.6) illustrate the behavior of our Patient and
Health Care Provider classes, respectively. The Patient object initially executes the login
function when starting the program, and enters the Patient Logged In state upon successful
authentication. In this state, the Patient automatically executes the sync function, which
updates the data on the Droid device to match that on the systems database server (and if
there is still unsaved Patient-edited data on the Droid device, uploads that data to the
database). The Patient also executes the display function from this state automatically,
which displays the data from the Patients medical record on the screen of the Droid device.
The Patient can also change his or her data from the Patient Logged In state in two
main ways. First, the Patient can upload an image file and attach it to an entry in the medical
record. This happens when the UploadImage function is executed by the user and the
Patient enters the Uploading Image state. When the image has finished uploading, the
Patient enters the Local Patient Info Changed state. Similarly, from the Patient Logged
In state, the Patient can make a comment on an entry in the medical record when the
commentInfo function is executed by the user and the Patient enters the Commenting on
Info state. When the Patient finishes the comment, he or she enters the Local Patient Info
Changed state, and the commented information is flagged as edited by the Patient. From the
Local Patient Info Changed state, the Patient can execute the sync function to upload the
data back to the database. The Patient can log out of the system from either the Patient
Logged In or the Local Patient Info Changed states in the latter, the changed data is
stored on the Droid device until the Patient logs in again.
Figure 4.5
16
Figure 4.6 shows the state diagram for the Health Care Provider class. Initially, the
Health Care Provider logs into the system using the login function and enters the HC
Provider Logged In state upon successful authentication. A Health Care Provider can add a
new Patient to the system from here by executing the addPatient function from the
interface. The Provider can also display a patients medical record from this state. When a
Provider begins editing the data in a Patients medical record, the EditInfo function is
executed and the Provider enters the Editing Info state. When the editing is complete, the
Provider executes the syncInfo function, and returns to the HC Provider Logged In state.
The Provider can also log out of the system from this state by executing the Logoff
function.
Figure 4.6
Prototype
The prototype of this Android application will encompass the basic functions of the
completed application. This will include most of the features on the Droid phone, as well as
the form used by a health care provider. The main functions on the Droid will include
downloading a data file from the server, viewing the file in separate categories, and editing
sections of the data file. The application will also include buttons to upload the data files to
both the server and a PC as a backup file. The server side will include a template located
online to input information that will generate an XML based file. This file will then be
downloaded by the application on the phone when it is started. The server will also contain
example pictures and/or medical documents that will be viewable on the phone.
17
5.1
How to Run Prototype
The primary way to view this application is to download the Android emulator to your home or
office computer. Windows, Mac, and Linux systems are all able to access this emulator. You will
find information that will help you download and install the emulator at
<http://developer.android.com/sdk/index.html>. You will need to download an SDK tool to run
the emulator. The Motorola Droid is running SDK 2.0, which is what the application has been
running on. There are more links under the SDK tab on the android development website that
will further assist you in downloading and installing the emulator. Source code for this
application will be located on the project website under the Prototype section
<http://www.cse.msu.edu/~cse435/Projects/F09/PMR-droid/web/Prototype/pmr.zip>.
A Microsoft Powerpoint presentation has been set up if this option is not feasible for you.
The link to this presentation is <http://www.cse.msu.edu/~cse435/Projects/F09/PMRdroid/web/proto-2.html>. This presentation provides screen captures of each of the viewable
screens on the application.
5.2
Sample Scenarios
If a doctor wants to add a patient to the PMR database, the doctor will
have to go to the form. Figure 5.2.1 shows the first blank screen that a doctor
would see.
Figure 5.2.1
To add information, the doctors will have to simply type in the
information. Figure 5.2.2 represents input for the basic information such as name
and address.
18
Figure 5.2.2
For basic info, all they need to do is type in the information. However,
entries such as medications or vaccinations, they need to click on Add (Entry
name) to add the info to the output file. Figure 5.2.3 shows where the button is.
Figure 5.2.3
After inputting all the data, doctors will then save the information to a
file the server by clicking on Submit All button. This button will save the
information as an XML file. Figure 5.2.4 shows where the Submit All button is.
19
Figure 5.2.4
Since the data was saved in the server, the client will have access to
this data. When the patient first open up the application, the patient will see a
screen that looks like Figure 5.2.5.
Figure 5.2.5
Since the user did not log in yet, everything but Basic Information and
Emergency Contacts will be disabled. To log in and see the patients information,
the patient will click the Login button. Figure 5.2.6 shows the login screen.
20
Figure 5.2.6
After logging in the patient will have complete access to the application.
Figure 5.2.7 shows the unlocked main screen.
Figure 5.2.7
Now the patient wants to see their basic information. All they need to
do is click on the basic information to go to basic information screen. Figure 5.2.8
shows the basic information screen.
21
Figure 5.2.8
In this case, the patients name is John Smith, not John Doe as shown in
Figure 5.2.9. This means that the patient needs to comment or edit the last
name. To do so, the patient will click on Edit button to go to the edit screen
shown in Figure 5.2.9.
Figure 5.2.9
After changing the name, the user has two options. The first option is
22
to click the button Return with Unchanged Data and have all changes reverted.
The second option is to click the Done Editing button to change the data as
shown in Figure 5.2.10
Figure 5.2.10
References
6
[1]
Download the Android SDK Android Developers 2009 Android

http://developer.android.com/sdk/index.html
[2]
CRC. Update on Meaningful Use CRC Healthcare. November 2009
[3]
PIH Model Online. EMR Benefits, Challenges and Uses
[4]
Ilie, Virginia, Courtney, James, and Slyke, Craig. Paper vs.
Electronic: Challenges Associated with Physicians Usage of Electronic

Medical Records. Hawaii International Conference on System Science.
2007
7
Point of Contact
For further information regarding this document and project, please contact Prof. Betty H.C.
Cheng at Michigan State University (chengb at cse.msu.edu). All materials in this document
have been sanitized for proprietary data. The students and the instructor gratefully acknowledge
the participation of our industrial collaborators.
23

Software Requirements Specification (SRS) Project PMR-Droid

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Requirements Specification (SRS) Project PMR-Droid

Uploaded by

Copyright:

Available Formats

Software Requirements Specification (SRS)

Definitions, acronyms, and abbreviations

Android- The operating system, developed by Google, made to run on cellular

Assumptions and Dependencies

Medication - name, dosage, frequency, date prescribed and date ended.

ii. Direct access to the databases will be restricted by IP to the developers

Download the Android SDK Android Developers 2009 Android

Electronic: Challenges Associated with Physicians Usage of Electronic

You might also like