1. Software Requirements Specification (SRS)
ARMOR Polypharmacy Software Tool
Authors: Dinesh Banda, Ryan Oswald, Phillip Studans, Kareem Janoudi
Customer: Dr. Raza Haque
Instructor: Professor Betty Cheng
1 Introduction
Polypharmacy is a common condition in elderly patients where the administration of
numerous medications leads to medical complications. In many cases, medications may be
redundant, unnecessary, or even conflicting. In an attempt to help improve geriatric
healthcare, Dr. Raza Haque (MD) has developed a system (ARMOR) to assist clinicians with
the resolution of polypharmacy cases. As a result, a software application was proposed to
assist with the ARMOR process.
This document presents a complete overview the customer specifications for the initial
version of the ARMOR Polypharmacy Software Tool (ARMOR PST) as well as proposed
upgrades. Additionally, this document outlines the ARMOR PST prototype design and specific
use cases.
1.1 Purpose
The purpose of the ARMOR PST is to aid geriatric physicians in their care of polypharmacy
patients. Specifically, the ARMOR PST will guide a physician through the steps of assessing
their current prescriptions, reviewing prescriptions, minimizing dosages, optimizing drugs and
dosages, and finally reassessing all of the above. The intended audience are physicians who
deal with geriatric patients, and may not be familiar with the processes established to avoid
polypharmacy.
In the initial version, the expectation is that geriatric physicians will use the PST to assess
polypharmacy at initial and subsequent visits. Potential upgrades to the PST will lead to a
more robust product, capable of providing more specific recommendations to physicians. In
addition, a number of other individuals are expected to use future versions of the ARMOR
PST, including:
• Medical Directors: To effectively manage polypharmacy in an interdisciplinary approach
and address important quality indicators (QIs) and accomplish gradual dose reduction
(GDR) successfully for their facilities.

2. • Physician Assistants/Nurse Practitioners/Nurses: As a supplemental tool in assessing
falls, behaviors, and unexplained functional decline.
• Residents/Fellows/Medical Students: As a guide to manage medications and
understand the changed physiology. To help them understand the impact of aging on
drug-body interactions.
• Pharmacists: As an aid to understand the clinician’s position on certain prescriptions
and rationale. It may also aid in improving communication between pharmacists and
other members of the nursing home clinical team in appropriate documentation and in
implementation of regulatory standards, with an optimal care plan tailored for each
resident of the facility.
1.2 Scope
The ARMOR Polypharmacy Software Tool will be used by physicians who hope to improve a
geriatric patient's overall healthcare by reducing complications due to polypharmacy. The
ARMOR PST benefits include:
• Aiding in the identification of potential polypharmacy in the elderly.
• Optimizing current prescriptions in geriatric patients.
• Allowing a physician who is inexperienced or unfamiliar with the care of geriatric
patients to more properly identify and deal with polypharmacy related medical
complications.
The principal objective of the ARMOR PST is to provide a software tool that can be easily
distributed to the medical community to help in identification and resolution of polypharmacy
in geriatric patients.
The ARMOR PST's application domain is geriatric healthcare facilities, who prescribe drugs to
the elderly and assess their current healthcare.
1.3 Definitions, acronyms, and abbreviations
• ARMOR Process: The document specification which describes the steps
recommended (Assess, Review, Minimize, Optimize, and Reassess) to geriatric
physicians in the proper treatment of their patients.
• ADR: dverse Drug Reactions, which are complications that can arise from giving
medicines at the normal dose.
• DDI: Drug-Drug Interactions.
• DBI: Drug-Body interactions.
• PST: Polypharmacy Software Tool, the tool that we are developing to assist in the
diagnosis and care of polypharmacy related issues.
• QI: Quality Indicators, observations that indicate a patients general well-being, such as
the ability to walk 250 feet.
• GDR: Gradual Dose Reduction, the process of slowly giving a patient less drugs over a
period of time in an attempt to discontinue negative systems caused by the drug.

3. • Polypharmacy: Refers to the use of multiple medications by a patient. The term is
used when too many forms of medication are used by a patient, more drugs are
prescribed than clinically warranted, or even when all prescribed medications are
clinically indicated, but there are too many to take (“pill burden”). This has a potential to
cause higher adverse drug reactions and drug-drug interactions .
• Geriatric Medicine: Field of medicine pertaining to elderly patients.
1.4 Organization
This software requirements specification is organized into the following sections:
• Introduction: introduces the specification for the ARMOR PST to it's intended readers.
• Overall Description: describes and outlines the product perspective and its functions,
along with characteristics and constraints
• Specific Requirements: outlines the specific requirements of the ARMOR PST system
• Modeling Requirements: describes various models of the ARMOR PST system
• Prototype: details the current prototype of the ARMOR PST
• References: defines and identifies the references used in the making of this document
and the ARMOR PST system
• Point of Contact: identifies the resource to contact if there are any questions regarding
this document or the ARMOR PST system
2 Overall Description
The following information will be covered in this section
• product context and usage
• physical and software limitations
• product features
• required user skill-set.
This product will be used by a geriatric physician when a patient visits for a general check-up.
The program will be accessed via the internet, so the only equipment needed to access the
system is a computer and an internet connection. The program is written in PHP and AJAX,
which will work in any browser like Internet Explorer, Mozilla Firefox, Safari, etc. without
installing any additional plug-ins. The product guides the physician through the 5 step
ARMOR process. It attempts to consolidate this process into a functional and interactive tool.
Since the program will be used by non-technical personnel, it is designed with a very simple
graphical user interface, making it easy for users to effectively utilize the capabilities of the
system.
2.1 Product Perspective
The product will be used by physicians and medical practitioners to add a more systematic
element to the check-up process of geriatric patients. Currently, lack of proper indications,
inappropriate dosage, and sub-clinical toxicities of medications are common observations in

4. the field of geriatric medicine. “Prescribing cascade” is another known problem, where a
medication results in an adverse drug event (ADE) that is mistaken as a separate diagnosis
and treated with more medications, which puts the patient at risk for additional ADEs. These
medications are prescribed by multiple providers at different times for different reasons. One
common cause of ADEs is that oftentimes prescriptions are not re-evaluated for
appropriateness after discharge from the hospital. Some current strategies, like “START”
(Screening Tool to Alert doctors to the Right Treatment) and “STOPP” (Screening Tool of
Older Person’s potentially inappropriate Prescriptions), do not solve all of the problems. The
ARMOR PST emphasizes quality of life as a key factor for making decisions on changing or
discontinuing medications. Use of a certain medication is weighed against its impact on
primary biological functions, such as bladder, bowel, and appetite. Functional status is held
up as the essential final outcome measure for any medication change using ARMOR.
The product will be a standalone software. It is not a part of a bigger system. Though the
current version requires the user to manually enter all the patient data, there is scope for
future versions to be connected to an EMR system, so all the patient history and patient
vitals will be automatically loaded based on a unique ID number. This will not be
implemented in the current prototype. The only adaptations that can be done in the prototype
is the vital patient data that has to entered for each patient.
Every system has a few limitations, and the ARMOR PST is no exception. The prototype will
be built on the web. Without internet, the product will be inaccessible. This system interface
obviously has an up-side and a down-side. It can be accessed by anyone, anywhere,
without having to install the program locally on their system. Contrarily, if there is an issue
with internet service, the program will be unable to analyze all of the data entered. As
internet is the only source for the program, the only way to access it is via a web browser.
Currently, the popular browsers, including Internet Explorer, Mozilla Firefox, Safari, Google
Chrome, are supported. Any browser that is post-2005 should not have any compatibility
issues. There are no hardware constraints. ARMOR PST is very resource friendly, and
works very efficiently, even on a dial-up internet connection. The program was designed
without any graphics, maintaining a simple and intuitive interface. The user interface is
simple - fewer information/text will be put on each page, so the physician can concentrate on
the current task. All the data that has to be entered will be divided into categories and placed
in different tabs. The user has an option of reviewing the data before submitting it for
assessment. The various operations performed by the program are Assess, Review and
Optimize. The other two operations, Minimize and Review, are done by the physician, not by
the software.
2.2 Product Functions
The ARMOR tool will assist the physician in performing the first two steps of the ARMOR
process. They are1:
Step 1: A = ASSESS the individual for total number of medications and for certain groups of
medications that have potential for adverse outcome. If the number of medications is greater
than or equal to 9, an alert will be given to the user. Also, alerts will be given for medications
that are categorized into one of the following groups:

5. • Beta blockers
• Antidepressants
• Antipsychotics
• Other psychotropics
• Pain medications
• Other medications listed in the Beers Criteria
• Vitamins and supplements
Step 2: R = REVIEW for possible:
• Drug-drug interactions (If using two or more medications concurrently has known,
malignant consequences)
• Drug-body interactions (pharmacodynamics).
Step 4: O = OPTIMIZE by addressing
• Adjust renally cleared medications to creatinine clearance.
Functional status, restoration of patient health, and maintenance are the primary goals of
ARMOR PST (see figure 2.1).
Figure 2.1: A brief overview of the ARMOR PST process
2.3 User Characteristics
The user is expected to have basic to no knowledge about computers. The program will be
self-explanatory and will guide the user through the entire process. The user will have to know
how to type on the keyboard. All users are expected to be medical professionals, since three
of the five steps (Minimize, Optimize and Reassess) require medical knowledge. Also, the
other two steps (Assess and Review) will be using some medical terminology. Knowledge of
those terms is vital for properly entering data into the program.

6. 2.4 Constraints
Every step of the software is a safety critical feature. Firstly, the software analyzes if the
patient is consuming more than 9 drugs, and if so, alerts the user. Secondly, the software
looks for drugs that fall in one of the critical categories. If a drug is found to be in one of the
critical categories, an alert will be sent to the user. Then, it checks for the drug-drug and
drug-body interactions from the lexicon database. If it notices an unwanted reaction between
drugs or between the drug and body, it alerts the user.
The user has to enter patient data so the software can calculate the creatinine formula.
Without the formula, the program will be unable to make an accurate suggestion about the
dosage. There are default values for this formula which can be used if the user does not have
vital information available.
2.5 Assumptions and Dependencies
ARMOR PST assumes the end user has access to a modern web browser and an internet
connection. It is also assumed that the user will be a medical professional with knowledge of
dosage minimization, optimization, and assessment. This software is designed for use as part
of a geriatric clinical assessment. User interactions will be limited to inputting the requested
data and modifying the recommendations produced by ARMOR PST.
2.6 Apportioning of Requirements
Features that have been determined to be beyond the scope of the current system include:
• Auto-complete for medication names to reduce spelling errors.
• Giving specific suggestions on how to resolve medication conflicts
• Portable platforms (blackberry, iPhone, etc.)
• Interfacing with an EMR database
• Restricted log-in
There are plenty of extensibility options for this system. Some of the options involve the
implementation of additional interfaces, and others are to add new functionality. Having a
mobile platform would allow doctors to quickly enter patient data from a hand held device.
Inputting information from an existing EMR database would help to eliminate doubly

7. entering data. In order for this tool to assist with all stages of the ARMOR process, it would
also need to provide additional features for the Minimize and Reassess stages. For
example, the ARMOR PST program could be extended to give doctors suggestions for how
to resolve conflicts rather than simply providing alerts. These upgrades would require
extensive efforts from someone with both computer skills and a background in geriatric
medicine as well as a carefully designed decision engine. Such a system may push the
limits of current AI technology.
3 Specific Requirements
1. The product must provide a system for inputting patient information, including:
1.1. Patient Vitals
1.1.1. Patient Height (in meters or inches)
1.1.2. Patient Weight (in pounds or kilograms)
1.1.3. Patient Gender
1.1.4. Patient Age (years)
1.2. Patient Labwork
1.2.1. Serum creatinine (mg/dL)
1.2.2. System must provide an option for automatically entering the normal
values for the lab work section if the actual lab work is unavailable.
1.3 Patient Medications
1.3.1 Medication name
1.3.2 Current dosage
1.3.3 Current frequency
2. The product must raise a series of alerts in the form of a popup throughout the
stages of the ARMOR system. In each The alert types and messages are described
below.
2.1 Assessment Stage: Number of medications
2.1.1 If the patient has more than 9 medications, an alert must be generated to
warn the user.
2.2 Assessment Stage: Medications from target groups
2.1.2 Target groups include1
2.1.2.1 Beta Blockers
2.1.2.2 Antidepressants
2.1.2.3 Antipsychotics
2.1.2.4 Other Psychotropics
2.1.2.5 Pain Medications
2.1.2.6 Other Medications listed in the Beers Criteria
2.1.2.7 Vitamins and Supplements
2.1.3 For each medication in a target group, an alert must be generated to
inform the user of which medication has triggered the alert, and which category the

8. medication falls into.
2.3 Review Stage: Drug-Drug Interactions
2.3.1 An alert should be generated for each pair of medications which have a
potential interaction. This alert should contain the names of both medications. In
addition, the alert may optionally provide additional information about the interaction
(severity, type, etc.).
2.4 Optimize: Drug Dosing
2.4.1 The system should suggest dosages based on the creatinine clearance. To
do this, the system will estimate the creatinine clearance using the Cockcroft-Gault
equation and adjust the medication dosage accordingly for renally cleared medications.

9. 4 Modeling Requirements
Use Case
Figure 4.1 details the use case of the system. A medical practitioner launches system, and
inputs patient data (vitals, lab information, medications). ARMOR PST analyzes the data and
determines which alerts are appropriate to be issued, taking into account the following:
Number of medications, medications that fall into specific categories, any potential drug-body
interactions, and any potential drug-drug interactions.
Figure 4.1: Use case for the ARMOR PST system

10. High-Level Class Diagram
Figure 4.2 depicts the classes involved in the ARMOR PST and how they will interact with
each other. The data stored on the server side will be lab information, prescription
information, and general patient information. Once the desired information is collected, the
client will call the server and tell it to analyze the given information. The patient data will be
transmitted then processed by the server. The server processing will send the data through
multiple filters in order to generate alerts for the user. Alerts will be compounded then sent
back to the client for medical analysis.
Figure 4.2: ARMOR PST Class Diagram

11. UML Sequence Diagram
Figure 4.3 depicts one sequence of events that might occur within the system. The client will
load the website, then start to input patient data. This would intuitively be done in succession,
as is shown. Information would be input, the the information will be sent to the server for
analysis. The server will create and process the data using the filter classes. The sequence
of actions is fairly straightforward.
Figure 4.3: The most common sequence of events for the ARMOR PST

12. Figure 4.4 shows a variation of the previous sequence diagram. In this case, the lab
information is not input. In some cases, patient lab information will be unavailable. When this
happens, the user will skip from inputting general patient information directly to prescription
information. The client will then pass generalized lab information to the server in order to
make an assessment.
Figure 4.4: Sequence of events when no lab information is available

13. State Diagram
Figure 4.5 shows the state diagram for the ARMOR PST. Once a geriatric physician loads the
ARMOR PST, the program begins in its initial state. All the entry fields (vitals, labworks, and
medications) load with no data. The physician enters the vitals in the very first tab (Vitals).
The user then has an option of entering the labwork into the program or just skipping directly
to the medication tab. This option is useful because the program needs the lab-work data to
do its analysis. If the data is not entered, then the default data is used. Then in the medication
tab, the physician enters all the current medication consumed by the patient. The physician
can always go back and change the data previously entered. After checking for the accuracy
of the data, the physician will click on Begin Assessment for the analysis to begin. After the
analysis, the program displays to the physician all the alerts that is has encountered. On the
final screen, all this data is summarized for ease of the viewer. Then the program exits.
Figure 4.5: State diagram for the ARMOR PST

14. 5 Prototype
The prototype will operate with a full feature set for a limited list of drugs. The
prototype will provide the proper alerts and dosage requirements for the ten most
common drugs which fall into target groups, ten most common drug-drug interactions,
as well as dosage recommendations for the ten most common renally cleared
medications, as provided by Dr. Raza Haque.
5.1 How to Run Prototype
The prototype will be available via the web address
http://www.cse.msu.edu/~cse435/Projects/F09/Polypharmacy1/web and will be
accessible from any standard JavaScript enabled web browser. Functionality will be
verified in Firefox 3.
5.2 Sample Scenarios
Figure 5.1: When the user logs in, they are greeted with a message then instructed to
input patient data.
Figure 5.2: Here is the screen where patient data is input along with some sample
values for a patient. There are two options: continue to labwork or skip labwork (go
directly to medications.

15. Figure 5.3: The Labwork tab has a field to input Plasma Creatinine and a button to
move on to the next tab.
Figure 5.4: The Medications tab allows the user to input medications that are given on
various frequencies.

16. Figure 5.5: The Assess tab displays the initial results for the analysis. It outputs a
message for too many medications as well as general warning messages for the drugs
themselves.
Figure 5.6: The Review tab displays the appropriate drug-drug and drug- body
reactions.
Figure 5.7: The Optimize tab displays the computed creatinine clearance for the
patient.

17. 6 References
[1] Haque, Raza. ARMOR: A Tool to Evaluate Polypharmacy in Elderly Persons.
Annals of Long-Term Care. 2009:17:26-30.
[2] ARMOR PST Team Website.
http://www.cse.msu.edu/~cse435/Projects/F09/Polypharmacy1/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.
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)