Software Requirements Specification (SRS) Project

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)

pg 1

Software Requirements Specification (SRS)

Project: Personal Drug Management

Authors: Matt Bowser, Steven Cornfield, Dennis Cornwell, John Richter, Neil Owen, Brian Smith, Maurice Wong, Adam Cook, Patrick Nelson, Rob Allie, Justin Hammack, Mark Sun

Customer: Dr. Raza Haque

Instructor: Dr. Betty Cheng

1 Introduction

This document will cover the Personal Drug Management software product line. The

software is intended to be used by patients to manage their personal drug therapy

regimens by providing a mobile solution which is easy to maintain and readily accessible.

This document describes the scope of the project and any terminology that must be

understood because it will be referenced throughout the document with respect to a

specific meaning. The document will then discuss the users of the system, the high level

behavior of the system, and any assumptions that are made about its working

environment. The document will examine the specific low level software requirements

for each functional piece of the system. A high level system domain model and associated

set of use cases will be provided. Prototype specifications and usage instructions will be

included to ensure success and clarity of intent within the prototype of the system. Finally

any references, including a point of contact for this project, will be listed for further

information.

1.1 Purpose

The purpose of this document is to present a description of the Personal Drug

Management Software. It will describe the software in terms of its intended use, its

functionality, the systems which it will operate on, and constraints under which it will

operate. The intended audience of this document is: Dr. Raza Haque, Dr. Betty Cheng,

and the developers of this system.

1.2 Scope



pg 2

The specifications in this document are in reference to version 1.0 of the Personal

Drug Management System for the Android and iPhone mobile platforms as well as the

iPad tablet Macintosh platform. This software lies within the electronic medical record

domain and the application of this software is such that a patient may utilize it for

entering and managing personal and private medical information. The software will

interface with both a local and web-based repository of current patient medication

information. This information will pertain to medication dosing information including,

but not limited to: amount to be taken, when to take it, who prescribed it, why it was

prescribed, and the duration for which it will be taken. This software’s intended scope of

access is limited to the patient and their legally entrusted clinicians and care-givers. The

application will not display medications that are not explicitly entered by the medical

professional or the patient themselves. It will however, note dangers exposed in

consuming drugs with potentially adverse interactions when taken concurrently. The

software will also provide patients with a means to keep track of how their body is

responding to a specific medication, enabling them to provide more detailed information

to their clinicians during follow-up exams.

1.3 Definitions, acronyms, and abbreviations

PDM – Personal Drug Manager. The PDM is an application on a mobile device which

helps users to keep track of their medications as well as remind them of their medication

schedule.

PMR – Personal Medical Record. The PMR is an application on a mobile device which

allows users to access their medical records whenever internet access is available.

DDI – Drug-Drug Interaction. This represents any possible side effects created when

taking two or more drugs concurrently. These interactions can be classified in categories

such as: common, moderate, or severe.

ARMOR – Assess, Review, Minimize, Optimize, Reassess. The ARMOR tool is used to

aid physicians by providing recommendations to lists of drugs which they prescribe to

their patients. This tool emphasizes quality of life as a key factor for making decisions.

SPL – Software Product Line. Software product lines refer to engineering techniques for

creating a portfolio of similar software systems from a shared set of software assets using

a common means of production.[5]

EMR – Electronic Medical Record. EMR is a computerized medical record created by the

health care organization.

EHS – Electronic Health System

LEXI Database – A comprehensive drug database.



pg 3

iOS – The operating system for Apple® mobile and tablet devices.

Android – The operating systems created by Google®.

Xcode – Suite of tools for developing software on Mac OS X.

SDK – Software Development Kit. SDK is typically a set of development tools that

allows for the creation of applications for certain software package, software framework,

or platforms.

1.4 Organization

This document will include the specific items listed previously in the introduction in

ascending order of detail with respect to the specification of the system and its intended

uses. Sections 2 and 3 will indicate the description and specific required behaviors of the

system along with any associated assumptions or dependencies. Section 4 will provide a

developer oriented view of the system’s requirements and provide some context for the

initial application design. Section 5 will define the usage and domain constraints of the

system prototype. Instructions on accessing and using the prototype will be provided.

SPL variations in interface, functionality, and high level implementation will be noted as

needed.

2 Overall Description

This section will give an overview of the software through descriptions of the

products operating environment, its functionality and assumptions made about the

anticipated users.

Section 2.1, Product Perspective, will describe the context of the product within the

large-scale Electronic Health System for which the software is being developed. This

perspective will include specific hardware and software constraints relevant to the

software. Section 2.2, Product Functions, will explain major functions which the

software will perform. This section will give explanations of the functionality in general

terms and is intended for any reader. Section 2.3, User Characteristics, will include any

assumptions being made about the intended users of the software, including anticipated

technical knowledge, accessibility needs and general expertise. The final sections will

describe general constraints on the software associated with the functionality, specific

assumptions being made about external software interactions, operating environment and

expected usage, and any dependencies on which the described functionality are reliant.

Any functionality requested in the client specifications that cannot be implemented will

be described in Section 2.6, Apportioning of Requirements.

2.1 Product Perspective

This product is intended to be a tool used to manage personal drug information on

portable devices. The information stored on these devices will synchronize with a central



pg 4

server. This product must be able to interface with the ARMOR data collection system,

for a patient’s information. This product must also work with the limited storage and

memory available on hand-held devices. This product must be able to interface with an

external source for drug information.

2.2 Product Functions

The software will provide the user with an organized list of all medications

included in their personal drug therapy regimen. The user will be able to sort this list by

time of day administered or by how it affects their body. The software will provide the

user with a list of possible interactions between their current medications. Users will be

able to view detailed information for each drug on their list, such as the name of the

prescribing clinician, dosage, and side effects. Users will have the ability to edit any of

these drug details. Each detail will indicate whether the information was added by the

user or by a certified health care provider. Users will be able to add a photograph of their

drug to the detailed information screen. The form option will open the mobile device’s

camera utility and enable the user to take a picture of the drug and store it within the

application. This option is not available on the iPad. Users will be able to add drugs to

their regimen in two ways. They may retrieve their prescription information from the

ARMOR database or they may add a drug to their regimen manually, entering specific

information about dosage at this time. Users may add notes regarding conditions they

believe to be related to their current drug therapy regimen. Users will have the option to

add photographs of any visible conditions to these notes.

2.3 User Characteristics

Users are expected to have a basic understanding of their mobile device’s controls

and interfaces. They should have the ability to navigate through the application via the

touchscreen. Users should be able to use the touchscreen or keyboard (if one is available)

to enter information into the application. Users should be able to use the standard camera

utility on their device if one is available. Users are expected to have a basic

understanding of the drug therapy regimen they and their clinicians have developed.

They must be able to comprehend basic medical terminology.

2.4 Constraints

There are several safety critical properties of this system. An active internet

connection must be present periodically for updates and synchronization of medication

dosages and prescriptions. Missing a change in dosage could lead to the patient taking an

incorrect amount of a drug which may lead to serious health issues. The user should be

able to access stored application data without an active internet connection. Without this

requirement, a user without a connection would be unable to view their medication

information. An authentication system must be present on the device in which this



pg 5

application is installed. Without a system for authenticating a user into the device, others

may gain unauthorized access to confidential medical information. Also, an unauthorized

user may modify any unofficial record within the system leading to potentially dangerous

dosages of drugs suggested to the patient. The connection during data backup must not be

broken until the full backup is complete. Disconnecting the external storage device while

data backup is in progress may lead to a corrupt or incomplete snapshot of the system

data. Should this data be used within the system again, drug information may be corrupt

or incomplete leading to serious complications within the patient’s treatments. For

devices with a camera, the device camera must provide a consistent scale and color tone

for all pictures intended for use in this system. Inconsistent colors and sizes may

complicate the use of this system as a means to document what a drug a patient takes

should look like. This may lead to the wrong drugs being taken in certain situations. To

address this, it may be required to ask users to take photographs on a blank sheet of white

paper to provide a consistent background.

2.5 Assumptions and Dependencies

It is assumed that there is some method of authentication to protect access to a

patient's private data within the application. It is also assumed that it is possible to make

some form of authentication required for this application to be installed on the device.

Only devices with a functional camera will be able to take photos of drugs and

conditions. Each device must have access to an active internet connection periodically for

updates and synchronization. For data backup purposes, the device must have some

method of physically linking to a laptop or other external storage device. It is assumed

that users have access to their device’s application marketplace (iTunes or Android

Market) and are able to download this application to their mobile device.

2.6 Apportioning of Requirements

Based on negotiations with customers, it has been determined that the ability to monitor

a relative’s or consented party’s medication information is out of scope for version 1.0 of

the Personal Drug Management System.



pg 6

3 Specific Requirements C = Common requirement across software product line

V = Variant requirement, specific to device implementation

High-level Description of Functionality

1. The PDM system will allow the patient to view all of the drugs that they are

taking.

2. The PDM system will allow the patient to enter information about drugs that they

are taking.

3. The PDM system will allow the patient to view possible drug interactions.

4. The PDM system will allow the patient to view side-effects of the drugs.

5. The PDM system will allow the patient to record information about their

conditions.

6. The PDM system will allow the patient to backup information onto a laptop or

external storage device.

7. The PDM system will require the patient to authenticate prior to allowing any

access to the information stored within the system.

8. The PDM system will allow the synchronization of data to an ARMOR database

containing patient information.

Functional Requirements

1. C The patient must be required to verify their identity via a personal log-in or PIN

in order to access the application.

C The patient must be able to view all of the drugs that they have entered into the

system.

2.1. C Sorted by time of day administered.

2.2. C Sorted by impacts on the body (as listed in 4.3).

C The patient must be able to enter information about drugs that they are taking.

This data should include:

3.1. Name of the specific drug

3.1.1. There should be some kind of auto completion method to assist the

user in entering the correct drug name so that the interactions can be loaded correctly.

3.2. Reason for taking the drug (condition)

3.3. Picture or description of the drug for identification

3.4. Dosage

3.4.1. Frequency

3.4.2. Amount

3.4.3. Duration

3.4.4. Associated signs of toxicity (overdose)

3.5. Associated physician’s name (optional)

3.5.1. Contact information (optional)

3.6. Follow up exam date (optional)



pg 7

C The patient must be able to view possible side effects of the drugs as provided

by the LEXI drugs database:

4.1. Interactions caused by combinations of drugs that they are taking.

4.2. Complications caused by the introduction of the drug into an existing

condition of the patient.

4.3. Impacts on their body (side-effects)

4.3.1. Appetite

4.3.2. Balance

4.3.3. Weight

4.3.4. Pain

4.3.5. Mood

4.3.6. Vision

4.3.7. Hearing

4.3.8. Bladder

4.3.9. Bowel

4.3.10. Skin

4.3.11. Activity Level

4.3.12. Swallowing

C The patient must be able to record information about their conditions

5.1. Symptoms

5.2. Context

5.3. Photographs

C Records synchronized to the ARMOR database can be certified by authorized

medical personnel, at which point those records would no longer be editable by the

patient.

6.1. The patient should be able to modify their entry until it is certified by their

clinician.

6.2. Certified information should be denoted by a change in color or emphasis

to signify that it is an official medical record wherever that information is shown

throughout the program.

C The patient must be able to backup information that is local to their device to a

laptop or other external device for use in the event of restoration.

Data Constraints

1. C The system is designed to keep track of medication information for one patient.

2. C The patient may enter as many drugs as they choose into the system.

3. C The patient may record as much information about their conditions as they feel

is necessary.

Design and Interface Constraints

1. V The PDM system must work on an Android device.

V The PDM system must work on an iOS device.

C The patient should only be able to view one drug or condition entry at a time.

C The patient should need to re-authenticate any time that the application is

closed or left inactive for more than ten minutes.



pg 8

4.1. V Due to multitasking capabilities of Android devices and iPhones

(version 4.0 and later), setting the application to run in the background should constitute

being “closed” and require re-authentication.

Quality Requirements

1. C The PDM system should use simple screen layouts designed for readability and

ease of access.



pg 9

4 Modeling Requirements

4.1 Use Case Diagram (Figure 4.1)

A Use Case Diagram is used to describe high level interactions between all actors

and the system. High level interactions are defined by the circles within the system

boundary. The system is denoted by the system boundary which contains all

interactions the system is capable of. The name of the system is defined as the title of

the system boundary. Actors are the end users of the system and any external entities

that the system uses to perform its routines. Each Actor must appear outside of the

System Boundary. Use Cases may also have extends or includes relationships. Extends

denotes a Use Case that is, at its core, the same Use Case that it is extending, but also

includes extra functionality. A Use Case may also include another Use Case in order to

use the included Use Cases functionality in its own.

The diagram below describes the Personal Drug Management - Software Product

Line Use Case representation of the core interactions needed in our system.

Descriptions of each use case are below.



pg 10

Figure 4.1 – Use Case Diagram for Personal Drug Management Application

Use Case: Authenticate << variation>>

Actors: Patient

Description: User authenticates with password stored locally on device and gains access to the

system

Type: Primary

Includes: N/A

Extends: N/A

Cross-Refs: Functional 1

Use cases: None

Use Case: Authenticate iOS << variant>>

Actors: Patient

Description: User authenticates with iOS specific authentication method

Type: Secondary

Includes: N/A

Extends: Authenticate



pg 11


Use cases: None

Use Case: Authenticate Android << variant>>

Actors: Patient

Description: User authenticates with phone unlocking method specific to Android OS

Type: Secondary

Includes: N/A

Extends: Authenticate


Use cases: None

Use Case: View Medication Schedule

Actors: Patient

Description: User views a chronological schedule of medication consumption times and doctor’s

appointments.

Type: Primary

Includes: N/A

Extends: N/A

Cross-Refs: Functional 2.1

Use cases: Requires Authenticate use case and Add Medication OR Synch Data use case

Use Case: Record Observations <<variation>>

Actors: Patient

Description: User enters general information about a symptom or condition into the application

Type: Primary

Includes: N/A

Extends: N/A


Use cases: Requires Authenticate use case

Use Case: Add Photo << variant>>

Actors: Patient

Description: User associates a camera shot with the observation being recorded about a

particular condition. NOTE: This use case would not be available for iPad devices.

Type: Secondary

Includes: N/A

Extends: Record Observations

Cross-Refs: Functional 5.3


Use Case: Add Note

Actors: Patient

Description: User associates a personal note with the observation being recorded about a

particular condition.

Type: Secondary

Includes: N/A

Extends: Record Observation

Cross-Refs: Functional 5.1, 5.2




pg 12

Use Case: Synchronize Data

Actors: Patient, ARMOR Database

Description:

User manually determines that data should be synchronized between their personal

device and the ARMOR database of their personal medical information. NOTE:

This use case requires an internet connection Type: Primary

Includes: N/A

Extends: N/A



Use Case: Add Medication

Actors: Patient, LEXI Database

Description:

User manually fills in information about a drug they have started taking. For ease

of access, medication information such as correct name spelling, and known side

effects are prefilled once drug has been determined

Type: Primary

Includes: N/A

Extends: N/A





pg 13

Use Case: Edit Medication

Actors: Patient

Description:

User edits information about an existing drug. Ability to modify, add, or delete mutable

information is available to user. No information that has been deemed legal medical record

may be modified or deleted.

Type: Primary

Includes: N/A

Extends: N/A



Use Case: Sort Medications <<variation>>

Actors: Patient

Description: User sorts drugs by their side effects or time of day taken. All drugs remain displayed, but

those matching the filter criteria are emphasized and moved to top of the drug list.

Type: Primary

Includes: N/A

Extends: N/A



Use Case: Small Screen Sort <<variant>>

Actors: Patient

Description: User sorts drugs by their side effects or time of day taken. Drugs will be organized to best fit

a mobile phone display.

Type: Secondary

Includes: N/A

Extends: Sort Medications



Use Case: Large Screen Sort <<variant>>

Actors: Patient

Description: User sorts drugs by their side effects or time of day taken. Drugs will be organized to best fit

a tablet display, utilizing the added screen surface area.

Type: Secondary

Includes: N/A

Extends: Sort Medications



Use Case: View Medication Details << variation>>

Actors: Patient

Description: User selects a drug to view in more detail. Details are listed all in one view for specific drug.

Type: Primary

Includes: N/A

Extends: N/A





pg 14

Use Case: View Small Screen << variant>>

Actors: Patient


Details are organized to best fit a mobile phone display

Type: Secondary

Includes: N/A

Extends: View Medication Details



Use Case: View Large Screen << variant>>

Actors: Patient


Details are organized to best fit a tablet platform, utilizing additional screen surface area

Type: Secondary

Includes: N/A

Extends: View Medication Details



Use Case: Backup Data

Actors: Patient, External Computer

Description: User backs up all information locally stored on local device to an external computer file

system. All data must be stored in a secure format.

Type: Primary

Includes: N/A

Extends: N/A





pg 15

4.2 Domain Model

The Domain Model (Fig. 4.2) depicts a system level depiction on the system. It

contains all of the classes and their interactions for the entire system. It is derived from

the Use Case diagram, but differs in its purpose. Each class is connected by delimited

links called associations, aggregates, compositions, or inheritance. Each link has

multiplicities to denote how many of these relations may exist between each class. These

multiplicities may also have end names to describe the relations. Each class contains

three items: name, attributes, and methods. These three items describe what the class will

be referenced as, the data members the class will contain and manage, and the functions

used to modify, access, and interact with other classes. The Diagram above describes the

Software Product Line implementation of the Personal Drug Management system. The

Data Dictionary describing each class follows.

Figure 4.2 – Domain model for Personal Drug Management System



pg 16

Element Name Description

Patient Patient contains all personal information about the

patient and maintains connections to all other

information.

Operations

AddDrug (Drug) Adds a drug to a patients record.

GetDrugInfo

(DrugName): DrugUsage

Gets a specific drugs details.

GetDrugs(): Drugs Gets a all drugs a patient has

Relationships Patient links to all the drugs taken by a patient (DrugUsage objects), the

authenticator, and any notes the patient may have made. The UI has a link to the

patient.

UML Extensions None


Authenticator This class ensures the user is authenticated before

allowing any interaction.

Operations

Login(): bool Attempts to log in the user.

Relationships This class connects to the patient and the UI. It also is inherited by two

authentication methods.

UML Extensions This is a variation point in the product line, with 2 different variations.


AndroidAuthenticator This class is the android specific authentication.

Relationships This class inherits from Authenticator.

UML Extensions This is a variant of the Authenticator.


iOSAuthenticator This is the iOS specific authentication method.

Relationships This class inherits from Authenticator.

UML Extensions This is a variant of the Authenticator.


Note The class stores information on symptoms and

context entered by a patient.

Operations

GetInfo(): string Gets the data associated with a the note.

Relationships This class is connected to the patient they apply to and potentially to any pictures

about the note.

UML Extensions This is a variation in the product line.


Picture This class stores pictures associated with a note.

Relationships This is connected to a note.

UML Extensions This is one variation in the product line.



pg 17


DrugUsage This stores information about a patient’s individual

usage of a particular drug, such as dosage and time

taken.

Operations

GetInfo(): string Gets all the data in a drug usage object.

Relationships This is connected to the conditions it treats and the drug it refers to.

UML Extensions None.


UI This class serves as a way for the user to

interact with the other parts of the system.

Operations

AddDrug() Adds a new drug based on entered

information

SortDrugs() Sorts and displays all drugs

SelectDrug() Moves to display of specific drug information

DisplayInfo(DrugName) Displays information for a specific drug

DisplayInteractions(DrugName) Displays interactions for a specific drug

ViewMainMenu() Displays the main menu screen

ViewCalendar() Displays the calendar.

Relationships This has a connection to Patient, Authenticator, LEXIDatabase, and

ARMORDatabase.



Calendar This class keeps track of times that drugs should be

taken.

Relationships This is connected to all drug usage classes and inherited by specific variations of

the class for different devices.

UML Extensions This is a point of variation in the product line.


AndroidCalendar This class is the specific implementation of the

calendar for the Android operating system.

Relationships This inherits from Calendar.

UML Extensions This is a variant in the product line.


IOSCalendar This class is the specific implementation of the

calendar for the iOS devices.

Relationships This inherits from Calendar.

UML Extensions This is a variant in the product line.


Drug This class stores all information about a drug’s

general characteristics such as color.

Operations

GetInfo() : string Returns all the information for a drug

Relationships This stores connections to any side effects.




pg 18


SideEffect This class stores all information about specific drug

interactions, such as severity, type, and rarity.

Operations

GetInfo() : string Returns all the interactions for a drug

Relationships This is connected to the drugs that these interactions are caused by.



Condition This class stores information about a condition a

drug is treating, such as area of body it affects.

Operations

GetInfo() : string Returns all the information for a condition

Relationships This is connected to any drugs that are treating this condition.



ARMORDatabase This class serves as a way for the system to

communicate with the ARMOR database.

Operations

Synchronize(Patient) Synchronizes patient data with server data.

Relationships This is connected to the UI.



LEXIDatabase This class serves as a way for the system to

communicate with the LEXI database.

Operations

GetDrugInfo(DrugName) Gets all information stored for particular drug




Backup This connects to a external computer to backup

Operations

BackupData() Backs up all patient data.





pg 19

4.3 Sequence Diagrams

A Patient uses the system to add a drug to their current list of drugs (Fig 4.3.1). When

filling out the new drugs info, Drug Usage will query the LEXI database for auto fill

information about the drug. When the user is finished filling out the drug, the system will

synchronize the data with the ARMOR database. The ARMOR database returns if the

sync was successful.

Figure 4.3.1 – Sequence Diagram for adding a new drug



pg 20

Figure 4.3.2 shows the way our system will be used to sort and access medication data.

The patient first sorts their collection of drugs by side effect to find relevant drugs. The

patient then selects a drug to view. The drug usage collects information about the

condition it is intended to treat and the specific details about the drug. Once the usage has

completed gathering its related data, the patient displays this information to the user.

Figure 4.3.2 – Sequence Diagram for sorting and viewing a list of drugs



pg 21

Figure 4.3.3 describes the scenario of synchronizing their applications drug information

with the information stored on the ARMOR database. After a successful login, the user

makes a request to synchronize their data with the ARMOR database, the database will

retrieve the local drug list from the patient, get up-to-date drug details from the LEXI

database and finally edit local patient drug information.

Figure 4.3.3 – Sequence Diagram for synchronizing drug information with ARMOR



pg 22

4.4 State Diagram

Figure 4.4.1 describes the PDM system in a state diagram. Various states are shown as

roundtangles and the event trigger that occurs to reach a state is named along the

incoming arrow.

Figure 4.4.1 – State Diagram for PDM system



pg 23

5 Prototype - Android

Web prototype

The main goal of our prototype was to mimic the interfaces available to the user

in the real application as closely as possible. The first screen is the log in page. Any

username or password will work. This demonstrates the experience of logging into our

application. In production, the user will require an ID and password that will authenticate

them. The second screen is the action selection page. The user may choose to go to the

calendar view, drugs view, notes view, or the backup view. In the calendar, the user can

view days, weeks, or a month. The user can add appointments and drag them around.

This view is very close to the intended functionality for the application. In the drugs view

the user may expand a drug to view its associated information. The user can organize

drugs by both the time of day they are taken and by the body system they produce side

effects for. At the bottom of the list of drugs the user can click add to see the add drug

view. Here the user will see some fields where a user can enter information about a drug.

This view will not actually save the drug but models what it would be like. The notes

view is very similar to the drugs view. The user may view previous notes as well as see

that the intention is to be able to sort them by date. The user can click on add at the

bottom of the list and fill out a mock note. The user can also simulate taking a picture to

be associated with the note. This note will not save. The backup view simulates the

process of backing up to a connected PC. The user can click the backup button and watch

the progress bar fill. The user may at any time use the Android menu bar located at the

bottom. Every Android phone has this standard set of buttons so we demonstrated how

they will interact with our application. The user can use the back button to return to a

previous screen. The user can hit the menu button to either logout (returns the user to the

log in screen) or the home button (which returns the user to the action selection page).

5.1 How to Run Prototype

The Android prototype is located at

http://www.cse.msu.edu/~cse435/Projects/F2010/PDM-Droid/web/prototype.html and

can be run using the mouse as though

The prototype has been tested and verified to run correctly from Google Chrome version

7.0.517.44 and Mozilla Firefox version 3.6.12.

5.2 Sample Scenarios

In the following sample scenario, the patient will add a note regarding a

problematic symptom. The user will first be required to authenticate their identity

through the log in screen (Fig. 5.2.1). After a successful login, the user will be taken to

the main menu (Fig. 5.2.2) where they will be able to access the Notes screen (Fig. 5.2.3).

http://www.cse.msu.edu/~cse435/Projects/F2010/PDM-Droid/web/prototype.html



pg 24

Figure 5.2.1 – Authentication/Log-in Screen

The user will log onto the system using their username and password, and then

click the “Login” button. This will access all current medications, notes, and calendar

information.



pg 25

Figure 5.2.2 – Main Menu.

The patient will click the “Note” button to add a new note. Upon

clicking/tapping, the Note button will become highlighted to signify that the user control

was activated.



pg 26

Figure 5.2.3 – Note Screen, showing previously stored notes sorted by date of entry.

The patient can view old notes taken, delete them, or add a new one. To add a

new note, the patient would click “Add…”. This will prompt the user to fill in a form to

record a new note (Fig. 5.2.4).



pg 27

Figure 5.2.4 – A blank template used when adding a new note.

The patient will either select a symptom provided or enter their own using the

“Other…” option. Figure 5.2.5 and 5.2.6 show examples of what a completed form

might look like.



pg 28

Figure 5.2.5 – Note template with information added by the user.

The patient can leave “Context” notes pertaining to the domain of the problem as

well as add side notes that are relevant to the symptom.



pg 29

Figure 5.2.6 – Note template with completed information, including a photo.

The patient may also attach or take a new photo, using the built in camera on the

device, to the note for a visual description. When finished, the patient will tap “Done” to

add the note to their patient database.

5.2.1 Common functionality scenarios Common functionality across all product lines would pertain to the core

functionality of the PDM system. This would include a login window with login and

password security before access to any patient data, the ability to view and add

medications to the current medications list, synchronization of all information

(medications, notes, schedules, etc.) to a medical database in order to track official

information and patient entered information. On supported devices, the ability to take a

photo using the built in camera for notes or drug information will be provided. Finally,

the ability to sort drugs based on the criteria specified in the requirements and the ability

to schedule a reminder via calendar or other system utility for medication doses will be

provided.

6 Prototype - iPhone



pg 30

The iOS prototype includes the following functionality; password protection,

users are able to view, add and edit different drugs. The following information about each

drug is available; a picture of the drug from the device camera, user notes about the drug,

a physical description of the drug, dosage information, the prescribing doctor, any notable

side effects, the time of the day to take the drug, any related special instructions, begin

date, and the date of follow up exam. The user will be able to view a timeline or calendar

that specifies when the next medication should be taken. The user will be able to view

any drug interactions between the medications that are being taken.


The IOS prototype requires a system running Mac OS X 10.6 with Xcode and the

iPhone SDK. To execute the application from Xcode, simply load the project and select

“Build and Run” from the top of the Xcode window. The iOS prototype can also be run

on an iPhone or iPod Touch device, but the software must be installed from the Mac OS

X system that has the prototype source code on it. In addition to this, the system with the

source code must also have an apple developer’s account. Once on the device, the user

can simply press the appropriate icon for the application to start it. The iOS prototype can

also be viewed as an online video at the PDM-iPhone website by visiting

http://www.cse.msu.edu/~cse435/Projects/F2010/PDM-iPhone/web/ or direct from

YouTube by visiting http://www.youtube.com/watch?v=RiuzaMnpakk.


1. The user opens application and types in their password to gain access.

2. The user then sees a list of drugs in the system. (Figure 6.2.1)

3. If the user selects one of the drugs, the application will go to a detailed view of the

drug. The user can then scroll through this view, add a note or edit the drug. (Figure

6.2.2)

4. If the user decides to edit a drug, they will be taken to a drug edit view. In this

view they can edit all the various details about the drug and can even take a picture of the

pills to display. (Figure 6.2.3)

5. At any point in time, the user can go to the timeline/calendar view and see a list of

drugs sorted by the time they are supposed to take them. (Figure 6.2.4)

6. If the user wishes to view drug interactions, they can select the interaction tab and

have a list of drugs sorted by what they are interacting with. (Figure 6.2.5)

http://www.cse.msu.edu/~cse435/Projects/F2010/PDM-iPhone/web/

http://www.youtube.com/watch?v=RiuzaMnpakk



pg 31

Figures 6.2.1(left) and 6.2.2(right) – IOS drug list view and IOS drug view

Figures 6.2.3(left) and 6.2.4(right) – IOS edit drug view and timeline view.



pg 32

Figure 6.2.5 – IOS interaction view.

7 Prototype – iPad

This functional prototype will show all standard interactions with our system. It

will allow adding, viewing and editing of medication data; it will have authentication

before allowing a user to access any information; it will allow users to examine side

effects and interactions of their drugs; it will connect to database to access drug

information; and it will have a way to backup user medication data. In the iPhone and

Android version the user will have the added ability to take and add photos to their

medication data. The major differences between each version will be the way the

information is displayed. On the iPhone and Android version there will be a display

system designed for a small screen. On the iPad version there will be a much bigger

display that will allow for a persistent navigation bar and a single screen interface.


The iPad prototype will be accessible through the web and downloadable via the iPad

browser interface. The web prototype is located at

http://www.cse.msu.edu/~cse435/Projects/F2010/PDM-iPAD/web/




pg 33


7.2.1 Sample Scenario – Check when to take next drug

1) Log in (Fig. 7.1).

2) View Medication Detail for schedule information (Fig. 7.2).

Figure 7.1 – Authentication/Log-In Screen

Figure 7.2 – Drug Details Screen showing Schedule information



pg 34

7.2.2 Sample Scenario – Add one Aspirin Daily to Medications

1. Log in (Fig. 7.1).

2. Tap “Add Medication” at the bottom of the screen (Fig 7.3).

Figure 7.3 – Drug Detail Screen showing “Add Medication” button.

3. Fill in “Aspirin” for name, 1 for dosage, 325mg, every 24 hours, today for start

date (Fig. 7.4).

Figure 7.4 – Add Medication Screen showing information being entered into fields.



pg 35

7.2.3 Sample Scenario – Filter Drugs by Side Effects

1. Log in (Fig. 7.1).

2. Tap “Filter”.

3. Tap “Sort By” and select “Side Effects” (Fig. 7.5).

Figure 7.5 – Drug View sorted by Side Effects

8 References

[1] D. Thakore and S. Biswas, “Routing with Persistent Link Modeling in

Intermittently Connected Wireless Networks,” Proceedings of IEEE Military

Communication, Atlantic City, October 2005.

[2] PDM Droid. “PDM-Droid Project Website”,

http://www.cse.msu.edu/~cse435/Projects/F2010/PDM-Droid/web/index.html

[3] PDM IPhone. “PDM-IPhone Project Website”,


[4] PDM IPad. “PDM-IPad Project Website”,


[5] Wikipedia “Software Product Line”,

http://en.wikipedia.org/wiki/Software_product_line

9 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

http://www.cse.msu.edu/~cse435/Projects/F2010/PDM-Droid/web/index.html





pg 36

this document have been sanitized for proprietary data. The students and the instructor

gratefully acknowledge the participation of our industrial collaborators.

Documents

Software Requirements Specification (SRS) Project