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.

• 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.

• 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

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:

• 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.

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

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 frequency2. 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

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.

4 Modeling Requirements

Use CaseFigure 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

High-Level Class DiagramFigure 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

UML Sequence DiagramFigure 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

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

State DiagramFigure 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

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.

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.

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.

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)