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
1
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 patient‟s medical
record. Your health care providers provide all information.
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
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 patient‟s EMR that is stored,
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.
1.4
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 patient‟s EMR‟s 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.
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)
2
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
Database
PMR
Health Care Provider
Patient
Figure 2.1
2.2
Product Functions
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 Droid‟s 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.
2.3
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 EMR‟s 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 doesn‟t 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.
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)
3
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.
3
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 don‟t 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 don‟t want anyone to see.
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)
4
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 person‟s 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 don‟t 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 worker‟s 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
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)
5
phone or computer. Once the user comment on something, it is flagged as “Commented
on by User” so the user‟s 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 user‟s 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.
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)
6
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
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)
7
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 database‟s 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.
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)
8
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.
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)
9
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.
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)
10
: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()
F ig u re 4 .3 : S eq u en ce D ia g ra m fo r th e H ea lth C a re P ro vid er u se ca ses. T his sh o w s th e
seq u en ce o f even ts a n d intera ctio n s b etw een th e h ea lth ca re p ro vid er a n d o th er m em b ers o f th e
cla ss d ia g ra m (fig u re 4 .1 ). H ere, th e h eath ca re p ro vid er lo g s in, crea tes a n ew p atient ’s
m ed ica l reco rd , edits a p a tien t’s m ed ical reco rd , a d d s im a g es to th e d ata ba se, syn cs th e info
b a ck to th e d ata b a se a n d lo g s of f.
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)
11
: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
image, comments on an entry, syncs the comment back to the database, backs up the record and
logs out.
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)
12
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 system‟s 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 Patient‟s 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
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)
13
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 patient‟s medical record from this state. When a
Provider begins editing the data in a Patient‟s 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
5
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.
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)
14
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.
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)
15
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.
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)
16
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 patient‟s information, the patient will click
the “Login” button. Figure 5.2.6 shows the login screen.
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)
17
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.
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)
18
Figure 5.2.8
In this case, the patient‟s 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
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)
19
After changing the name, the user has two options. The first option is 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
6
References
[1]
[2]
“Download
the
Android
SDK”
Android
Developers
http://developer.android.com/sdk/index.html
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
2009
Android
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.
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)
20