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 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
Template based on IEEE Std 8301998 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)
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
WiFi 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 WebInterface over the Internet.
The iPhone is limited to connecting to the system with a cellular or WiFi 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 highspeed 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 webbased 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., Xrays) 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 drilldown 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
webbased 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.
iPhone.
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.
iPhone,
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 nonlocal 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 “nonlocal” 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:
<http://www.cse.msu.edu/~cse435/Projects/F09/PMRiphone/web/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 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 Specification (SRS)

You might also like