Software Requirements Specification (SRS) Imedlife: Personal Medical Record Application For The Iphone

Software Requirements Specification (SRS)
iMedLife
Personal Medical Record Application for the iPhone
Authors: Thomas Davison, Austin Gregory, Thomas Parker, Edward Waller
Customer: Dr. John Smith II
Instructor: Dr. Betty Cheng
1 Introduction
This document goes over the requirements that must be fulfilled before
iMedLife can be delivered to the customer. In section 1 it discusses the scope
of the application, any definitions or acronyms used, along with the
organization of the SRS document.
1.1 Purpose
The purpose of this document is to present a detailed description of a
Personal Medical Record application for the iPhone. It explains the purpose
and features of the application itself, the web interface through which a user
can access a personal account, the server that hosts the user accounts, and
the constraints that must be satisfied for security purposes. This document is
intended for both the customer and the project development team.
1.2 Scope
This Personal Medical Record application for the iPhone, called
iMedLife, is used to capture personal medical history. This application will be
designed to provide a simple and reliable way to store and convey one’s
medical history. Upon the event of an emergency, medical information would
have to be acquired from the patient’s current doctor or family for any
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)
informed, safe procedure. iMedLife would alleviate the need to track down
this medical history because it would be readily available. Doctors would be
able to add information to the patient’s iMedLife account at anytime,
including at an appointment, with the patient’s consent.
More specifically, iMedLife will contain extensive documentation of the
iPhone owner’s medical records, which can be authored by the owner or the
owner’s healthcare provider(s). This includes diagnoses, treatments,
medications, allergies, and medical procedures. iMedLife would allow for
uniform communication of information between the patient and their
respective doctor(s). The software would label and organize information
authored by health care providers separately from information authored by
the patient to maintain authenticity.
1.3 Definitions, acronyms, and abbreviations

· Define all terns, acronyms, and abbreviations need to understand the SRS. If
this section is extensive, then move to an appendix. It is also possible to
provide a link to other resources for extensive terminology explanation.
Term Definition
SRS Software Requirements Specification
Iteration One execution of a sequence of operations or
instructions
Actors Entities that provide input data or receive the
output result
Wi-Fi Wireless networking technology that uses radio
waves to provide high speed internet as well as a
local area network
Operating system Interface between hardware and applications and
is responsible for managing, sharing and
coordination of resources
Secure account A web based account in which some form of
encryption is in place
User An instance of the User class for someone accessing
their own medical records with the web application
iPhone User An instance of the User class for someone accessing
their own medical records in the iMedLife System
with an iPhone
Healthcare Provider An instance of the User class, specifically a
healthcare professional (e.g., doctor)
MedRecord An instance of one person’s medical record
Local Refers to a MedRecord that is stored on the user’s

iPhone
1.4 Organization
The remaining sections of the SRS document contains detailed
information regarding the requirements of iMedLife. In section 2 the
document covers the product perspective, product functions, user
expectations, constraints, any assumptions or dependencies, and anything
that is beyond the scope of the application. In section 3 it lists any specific
requirements that must be met before the application can be delivered. In
section 4 the document gives graphical models which specify the bridge
between the application domain and the machine domain. In section 5 the
details of the prototype are given, including how to use the prototype and
sample scenarios that it addresses. Section 6 contains any sources for
documents that are referenced in this SRS document. Section 7 gives the
reader a point of contact for any inquiries about the application.
2 Overall Description
The purpose of this section is to present a detailed description of the
product’s perspective giving information about the context and interface
constraints. The product functions section outlines major functionality
iMedLife will perform. The user characteristics section explains the
expectations iMedLife has about the user. The constraints section contains
detailed descriptions of constraints and safety critical properties pertaining to
iMedLife. The assumptions and dependencies section summarizes any
assumptions or dependencies the application has about the hardware,
software, environment and user interactions associated with it. The
approportioning of requirements section goes over the functionality
customers want, but have been determined out of scope for the current
iteration of the application.
2.1 Product Perspective

The iMedLife application for the iPhone is part of a larger system
consisting of a Medical Record repository with three actors: iPhone User,
User, and Healthcare Provider. The iPhone User interacts with the Medical
Record Repository through the iMedLife application on the iPhone over the
Internet. The User and Healthcare Provider both interact with the Medical
Record Repository through a Web-Interface over the Internet.
The iPhone is limited to connecting to the system with a cellular or Wi-
Fi connection. The user is limited to interacting with the application by using
a 320 by 480 pixel multi-touch screen, on screen keyboard, microphone,
accelerometer sensor, proximity sensor, 3.15 Mega Pixel Camera, or voice
commands. The software needs to be compatible with the current iPhone
operating system (Current version 3.1). The hardware constraints are an
ARM Cortex A8 600 MHz processor and a PowerVR SGX graphics processing
unit. The application cannot exceed an active memory usage greater than
256MB, or exceed a disk usage larger than 16GB. No Flash or Java
operations can be handled on the iPhone.
2.2 Product Functions
There are several major functions that iMedLife will perform. The most
important is the ability to quickly display emergency information on
command. This information can be viewed at any time, provided the
application is running, by simply pressing the “Emergency Information”
button at the bottom of the interface. After the user has started the
application and entered the correct password, the software connects to the
company’s repository. Once a connection has been established, all other major
functions of the software can be performed. iMedLife automatically checks
the repository for any changes, and updates all local information accordingly.
Local information can be easily viewed by simply navigating through the
interface and selecting the desired medical record, which will have all local
information logically organized. Also, the software has the ability to download
specific parts of a medical record that are not already stored locally. These
records initially show up as a list of record labels only, meaning the actual
record is not stored on the device. All items in the list are selectable, and
selecting any item will download that record from the database and
temporarily store it locally. After the download is complete, the user will be
able to view the record. If a new record is chosen from the list, iMedLife
downloads this new record and replaces the one that is stored in active
memory. In addition to viewing and downloading information, the software
also has the ability to upload information. More specifically, the user can
upload pictures stored on the iPhone itself to the repository. Apart from using
the iPhone application, users can log on to the iMedLife website via any web
browser and perform all of the same tasks that they could using the actual
iPhone with two differences. The two differences are that users logged onto
the website have the ability to create an account, upload full medical records
to the database as opposed to just pictures, and these records are entered
through forms on the website and therefore do not have to previously exist.
2.3 User Characteristics

The user is expected to be familiar with either the iPhone or iPod touch
as well as perform basic navigational, input and picture taking operations on
the device.
The Web Users are expected to be Internet literate, understand how to
navigate around a web page and perform conceptual tasks such as logging
into a secure account, uploading pictures, and inputting data into specified
fields.
2.4 Constraints
iMedLife requires a connection for full functionality of the application.
If a connection is lost during an active session the outcome may result in
viewing only the data the application has currently downloaded on the
physical device. Full functionality of the application will resume upon
reconnection.
2.5 Assumptions and Dependencies

iMedLife assumes that there will be a database of medical records
hosted by a server. The server assumes it will be installed with a high-speed
Internet connection to communicate with iMedLife users. The software being
developed assumes that the users have either an iPhone or iPod touch with
access to the Internet from either a cellular or Wi-Fi connection to establish a
connection between the application and the medical record repository. The
web version of iMedLife assumes that the user has a computer with an
Internet connection and a web browser to access the online version of
iMedLife.
The iPhone application will run on the user’s iPhone or iPod touch.
Full functionality of iMedLife will depend on the availability of an Internet
connection. The web version of iMedLife will run on the user’s computer. The
use of this web-based application will completely depend on an Internet
connection.
2.6 Approportioning of Requirements

There is some functionality that currently lies outside of the scope of
the current project, but could possibly be included in later releases. Two such
options are the storage of large data items (e.g., X-rays) and the ability to
extract text information from images.
3 Specific Requirements
I. Information Recording
A. Information recorded must include an optional field for context.
B. Information should be tagged according to who is entering the data.
II. iPhone Application Requirements
A. It must be able to download the most recent medical record.
B. It must store the most recent copy of information in its application
data folder.
C. It must only update the parts that have changed when connecting to
the server.
D. It must be able to change and update information on the server.
E. Emergency medical information must be available without a password.
1.This information must only include basic information, current
medications, and any critical conditions
F. The application must log the user out when it is exited.
G. Large files should not be downloaded on the iPhone when updating,
instead, thumbnails should be used with full images being downloaded
on demand.
H. It should give a drill-down view of all data in the medical record after
logging in.
I. For data with dates, the data should be displayed in chronological
order.
J. The user must be able to set an option to hide information based on
who has tagged it.
K. The user must be able to add photos from his/her photo library to his/
her medical record.
III. Website Requirements
A. It must allow a user to login.
B. It must allow a user to logout.
C. All information must be viewable on the website.
D. All information must be updatable on the website.
E. It must allow a user to download a backup of their medical
information.
IV. Server Requirements
A. Logout must be automatic after 1 hour of inactivity.
B. Full data backups must be created daily.
C. A correct combination of username and password is required for a user
to login.
D. A user must be logged on to be able to view or edit any medical
information.
E. Medical Records cannot be edited, only replaced by a new revision with
the healthcare provider privileges.
V. User Accounts
A. Each account must securely store all of its data.
B. Each account must have a separate identifying account number.
C. Data must always be related to an account, and a user cannot view
data he/she does not own.
D. Basic Information That Must be Stored
1.Username
2.Password
3.Address
4.Phone Number
5.First Name
6.Last Name
7.Middle Name
8.Date of Birth
9.Sex
10.Hair Color
11.Eye Color
12.Ethnicity
13.Height
14.Weight
15.Blood Type
16.Allergies
E. Complex Data That Must be Stored
1.Health Care Providers
2.Medical History
a) Medical Conditions
b) Medications
c) Procedures
3.Tests
a) Labs
b) Tests
4.Referral Network
4 Modeling Requirements
Figure 1 – iMedLife System
The iMedLife system is accessed by three actors: the User, the

Healthcare Provider, and the iPhone User. The User and Healthcare Provider
both access the system by using a web-based application in a web browser.
The iPhone User accesses the content in an application on the iPhone.
User Creates Account With Web App
Use Case: Create An Account With Web App.
Diagram:
Description:
The User accesses the iMedLife System through a web application and
registers for an account.
Cross Ref.:
User Update Use Case

Use Case: Update Medical Records With Web App.
Diagram:
Description:
The User accesses the iMedLife System through a web application and
updates or changes certain attributes of a medical record.
Cross Ref.:
User View Use Case

Use Case: View Medical Records With Web App.
Diagram:
Description:
The User accesses the iMedLife System through a web application and views
the data of a certain medical record.
Cross Ref.:
Healthcare Provider Update Use Case

Use Case: Update Medical Records With Web App
Diagram:
Description:
The Healthcare Provider accesses the iMedLife System through a web
application and updates or changes certain attributes of a medical record.
Cross Ref.:
Healthcare Provider View Use Case

Use Case: View Medical Records With Web App
Diagram:
Description:
The Healthcare Provider accesses the iMedLife System through a web
application and views the data of a certain medical record.
Cross Ref.:
iPhone User Update Use Case

Use Case: Update Medical Records With iPhone
Diagram:
Description:
The iPhone User accesses the iMedLife System through an application on the
iPhone. The iPhone User will select which information will be sent to the
server to update his or her medical record.
Cross Ref.:
iPhone User Download Use Case

Use Case: Download Medical Records To iPhone
Diagram:
Description:
The iPhone User accesses the iMedLife System through an application on the
iPhone. The iPhone application will automatically query the server for
changes to the iPhone User’s medical record and download the new data.
Cross Ref.:
iPhone User View Use Case

Use Case: View Medical Records with iPhone
Diagram:
Description:
The iPhone User will run the iMedLife application on the iPhone, where his
or her medical record data may be viewed.
Cross Ref.:
Class Diagram That Depicts the Key Elements of the System
The architectural style for the database is the Repository style. The
MedRecord hierarchy represents a way to organize and display data gathered
from the repository. Data can be uploaded to the repository by Web Users,
iPhone Users, and Healthcare Providers, and will be tagged differently for
each type of uploader.
Representative Scenarios and Sequence Diagrams
User Creates An iMedLife Account

Use Case: Create an initial Account with the Web App.
Trigger: The User creates an iMedLife account through an application in a
web browser.
Description: The User creates a username and password. The User may then
log in to his iMedLife account.
User Updates Medical Record
Use Case: Update Medical Records with the Web App.
Trigger: The User accesses the iMedLife System through an application in a
web browser.
Description: The User logs into the system with a registered username and
inputs the appropriate password. If the User is a Patient, the User will
be shown only his or her MedRecord. The User may add to the
MedRecord any information about recent health changes. When
submitted, the data is sent to the server and applied to the MedRecord.
User Views Medical Record

Use Case: View Medical Records with the Web App.
Trigger: The User accesses the iMedLife System through an application in a
web browser.
Description: The User logs into the system with a registered username and
inputs the appropriate password. If the User is a Patient, the User will
be shown only his or her MedRecord. The User may view any of the
data which is presented on the MedRecord.
Healthcare Provider Updates Medical Record
Use Case: Update Medical Records with the Web App.
Trigger: The Healthcare Provider accesses the iMedLife System through an
application in a web browser.
Description: The Healthcare Provider logs into the system with a registered
username and inputs the appropriate password. The Healthcare
Provider is shown a list of MedRecords. After a MedRecord is chosen,
the Healthcare Provider may add or change data contained in the
MedRecord.
Healthcare Provider Views Medical Record

Use Case: View Medical Records with the Web App.
Trigger: The Healthcare Provider accesses the iMedLife System through an
application in a web browser.
Description: The Healthcare Provider logs into the system with a registered
username and inputs the appropriate password. The Healthcare
Provider is shown a list of MedRecords. After a MedRecord is chosen,
the Healthcare Provider may view the data contained in the
MedRecord.
iPhone User Updates Medical Record
Use Case: Update Medical Records with the iPhone.
Trigger: The iPhone User accesses the iMedLife System through an
application on the iPhone.
Description: The iPhone User logs into the system with a registered
username and inputs the appropriate password. The iPhone User is
shown his or her MedRecord, and may add to the MedRecord any
information about recent health changes. When submitted, the data is
sent to the server and applied to the MedRecord.
iPhone User Downloads Medical Record

Use Case: Download Medical Records to the iPhone.
application on the iPhone.
username and inputs the appropriate password. The first time the
application is opened, the iPhone User’s MedRecord will be retrieved
from the server. Each time the application is opened after this, it will
automatically query the server for changes to the iPhone User’s
MedRecord, and download the new data.
iPhone User Views Medical Record

Use Case: View Medical Records with the iPhone.
application on the iPhone,
username and inputs the appropriate password. The iPhone User may
then view the data stored in his or her MedRecord.
State Diagrams for All Key Classes
Patient (Figure 4.3a):
Once a patient enters the website, they are prompted to log in. If the
patient enters incorrect information, that patient cannot proceed. If the input
is valid, the patient is free to browse his/her personal medical records. The
patient also has an option to create a new personal account. If he/she wishes
to do so, the system prompts the patient for information, creates the account,
and logs him/her in. The patient can choose to upload new personal data, or
view an existing record. If the patient decides to input new data, he/she is
taken to a page that allows him/her to do so. The patient is returned to the
browsing page if he/she wishes to do so or inputs invalid data. If the patient
inputs correct data, the database is updating accordingly and the patient is
then returned to the browsing page. If the patient decides to view an existing
record, the system will check to make sure the selected record exists. If so, the
record is displayed. If the record does not exist, the patient is returned to the
browsing page. The patient can log off at any time while in the browsing
state.
Figure 4.3a: Patient
Healthcare Provider (Figure 4.3b):
Once a healthcare provider enters the website, they are prompted to

log in. If the healthcare provider enters incorrect information, that healthcare
provider cannot proceed. If the input is valid, the healthcare provider is free
to select one of his/her patients. Once a patient is successfully chosen, the
healthcare provider is free to browse that patient’s records. The healthcare
provider also has an option to create a new personal account. If he/she wishes
to do so, the system prompts him/her for information, creates the account,
and logs him/her in. The healthcare provider can choose to upload new
personal data, or view an existing record. If the healthcare provider decides to
input new data, he/she is taken to a page that allows him/her to do so. The
healthcare provider is returned to the browsing page if he/she wishes to do so
or inputs invalid data. If the healthcare provider inputs correct data, the
database is updating accordingly and the healthcare provider is then
returned to the browsing page. If the healthcare provider decides to view an
existing record, the system will check to make sure the selected record exists.
If so, the record is displayed. If the record does not exist, the healthcare
provider is returned to the browsing page. The healthcare provider can log off
at any time while in the browsing state.
Figure 4.3b: Healthcare Provider
iPhone (Figure 4.3c):
When the user opens the application, they are prompted for a
password. If the password is invalid, the user cannot proceed. If the password
is correct, then the iPhone enters an update state, where it automatically
checks for any changes to local records and updates them accordingly. After
this process is complete, the user is free to browse the medical records. At any
time while browsing or at the password entry screen, the user can view the
emergency medical record for the owner of the iPhone. When the user is done
viewing this record, they will be put back at the login screen if the user is not
already logged in. If, however, the user is logged in, he/she will be placed back
into the browsing state. While browsing, the user may select a local record to
be displayed. If the user wants to view a non-local record (selected from a
list), the iPhone will search the database for the record, and if the record
exists, it is downloaded and displayed. The user can also upload local data to
the database. If the user decides to do so, he/she selects the information that
he/she wants to upload, and the iPhone updates the database accordingly. At
any time while browsing, the user can log out of the application and be
returned to the password screen.
Figure 4.3c: iPhone
5 Prototype
The prototype is designed to demonstrate the key functionalities of the
system. The user will be seeing example data, and will not be able to actually
access any server. This is because the prototype is for demonstration purposes
only, and is not meant to be fully functional. However, the user will be able to
log in to the prototype, navigate the interface, select and view locally stored
medical records, select and view “non-local” records from a list, and view
emergency information. In addition, the user will be able to view a second
prototype, which is a small website that will demonstrate the key web aspects
of the system as well. These aspects include all of the above, with the
additional ability to upload new information.
5.1 How to Run Prototype

The prototype is web based, and is accessible through any web browser
on a computer with an internet connection. The only constraint is that the
computer being used must have the newest Microsoft Silverlight plugin
installed and working to view the prototype. As long as the plugin is working,
there are no other constraints. The URL for the prototype is:
< h t t p : / / w w w. c s e . m s u . e d u / ~ c s e 4 3 5 / P r o j e c t s / F 0 9 / P M R - i p h o n e / we b /
iphonePrototype>
5.2 Sample Scenarios

John Doe wishes to use iMedLife to manage his personal medical
records on his iPhone, but he does not have an account. So, John goes to the
iMedLife website at the login screen chooses to create a new account. The
system prompts John to create a password and to enter his basic information,
which includes his name, birth date, gender, ethnicity, weight, height, blood
type, and a list of his known allergies. When John finishes entering his basic
information, he is taken to a payment screen where he has to choose a
method of payment. Now, the system assigns John a patient ID, which he will
use in conjunction with his password to access his account. John is
automatically logged in and is able to create new records for himself or view
any existing records he may have.
Now that John has successfully created his iMedLife account, he now
wants his doctor, George Duckworth, to be able to view, update, and create
medical records on his account. George, however, does not have an iMedLife
account. So, John recommends that George create himself an account. George
agrees, and proceeds to do so. Since George is a doctor, the account he creates
is slightly different from John’s. When George chooses to create an account,
he chooses to create a “Healthcare Provider Account.” George goes through
the same process as John while setting up the account; however he must
enter some additional information to verify that he is indeed a legal doctor.
The system now assigns him a healthcare provider ID, which he will use in
conjunction with his password to log in. Since George currently has no
patients registered to him, he is only able to view and create his own medical
records. John goes to George’s office to sign a contract, which is downloadable
from the main web site. The contract simply confirms the fact that George is
John’s doctor and John wishes to grant George access to John’s personal
medical records. The form is signed by both parties and sent to iMedLife.
Now, when George logs on to his account, before he is taken to the record
browsing screen, he must choose which records he wants to access; John’s or
his own.
Since both accounts have now been successfully created, and John is
successfully registered as a patient of George, John now wishes to obtain the
iMedLife iPhone application. John downloads the application onto his iPhone
and installs it. During the installation process, the application prompts John
for his patient ID and password. This is used to link the application to John’s
account. Now that the application has been installed, John will never have to
enter his patient ID into the application because it is already linked to his
account; he only needs to enter his password. John is now able to view his
medical records on his iPhone. John logs into the application, and the system
performs an update routine, which is done every time John logs in. This
routine simply checks to see if any changes have been made to John’s records.
This includes new records being created or old records being changed or
deleted. Now that the update routine is complete, John begins to browse his
records, and notices that he has new records on his account. Since all records
are labeled depending on the user who created or changed them, John can see
that George has entered several new records on John’s account. These records
are labeled as “new” until John views them for the first time. One of these
records is an old test result from a CAT scan. John decides to view this
particular document, so John selects it from the list of test and lab result
records. Since test and lab results are not stored locally, the application
downloads the record from iMedLife and then displays it on the screen. John
also notices that at any time, even before he logs in, there is an “Emergency
Information” button that he can press. John logs out of the application, and
while at the login screen, presses the button. The application accesses John’s
basic information and displays it on the screen. John is now happy that he
has chosen to use iMedLife, and feels safer knowing that in the case of an
emergency medical personnel are able to view his basic information, and his
doctor is able to easily view his medical history.
6 References
[1] "iMedLife". <http://www.cse.msu.edu/~cse435/Projects/F09/PMR-
iphone/web/>.
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.

Software Requirements Specification (SRS) Imedlife: Personal Medical Record Application For The Iphone

Uploaded by

Document Information

Original Description:

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) Imedlife: Personal Medical Record Application For The Iphone

Uploaded by

Copyright:

Available Formats

Software Requirements Speciﬁcation (SRS)

Authors: Thomas Davison, Austin Gregory, Thomas Parker, Edward Waller

Customer: Dr. John Smith II

Instructor: Dr. Betty Cheng

1.3 Deﬁnitions, acronyms, and abbreviations

Local Refers to a MedRecord that is stored on the user’s

2.1 Product Perspective

2.3 User Characteristics

2.5 Assumptions and Dependencies

2.6 Approportioning of Requirements

Figure 1 – iMedLife System

The iMedLife system is accessed by three actors: the User, the

User Update Use Case

User View Use Case

Healthcare Provider Update Use Case

Healthcare Provider View Use Case

iPhone User Update Use Case

iPhone User Download Use Case

iPhone User View Use Case

Class Diagram That Depicts the Key Elements of the System

User Creates An iMedLife Account

User Views Medical Record

Healthcare Provider Views Medical Record

iPhone User Downloads Medical Record

iPhone User Views Medical Record

State Diagrams for All Key Classes

Healthcare Provider (Figure 4.3b):

Once a healthcare provider enters the website, they are prompted to

iPhone (Figure 4.3c):

5.1 How to Run Prototype

5.2 Sample Scenarios

You might also like