Software Requirements Specification Final

Software Requirements Specification (SRS)
Project PMR-Droid
Authors: Joe Heldt, Jong Jang, Michael Keesey, Tom Randall, and Kurt Seippel
Customer: Dr. Betty Cheng and Dr. Tom Foster, Droid user.
Instructor: Dr. Betty Cheng
Introduction
This Software Requirements Specification document provides an overview of the functionality of a Personal Medical Record (PMR) designed for the Motorola Droid phone. This document will cover the scope, organization, description, constraints, requirements, and the prototype of the PMR.
Purpose
The purpose of this document is to describe the functionality and specifications of the design of a PMR for the Droid. The expected audiences of this document are the developers and users of the application.
Scope
The PMR will be designed to run on the Droid. The user will be able to store, access and comment on their medical records from their Droid phone. This information will be stored on a central database where health care providers will be able to upload the most recent medical records for their patients. The application will then be able to download this data from the server whenever it needs the up to date medical record.
Definitions, acronyms, and abbreviations
Android- The operating system, developed by Google, made to run on cellular phones.
Droid- A smart phone that is currently distributed by Verizon Wireless that runs the latest version of the Android operating system.
EMR (Electronic Medical Record) - An electronic copy of the patient’s medical record. Your health care providers provide all information.
GUI (Graphical User Interface) - The part of the application that the user sees and interacts with.
IP Address- A unique number given to every computer on a network to uniquely identify it.
PC (Personal Computer) - A desktop or laptop running the Microsoft windows operating system.
PMR (Personal Medical Record) - A copy of the patient’s EMR that is stored, accessed and possibly edited by the patient. Contains most, if not all, medical data that is in your medical record.
SDK (Software Development Kit) – set of tools that makes it possible to create software for a particular piece of software or hardware, in our case the Android 2.0 operating system.
Thumbnail- A scaled down version of an image used to save space but still allow you to preview the image.
XML (Extensible Markup Language) – A widely used type of text data organization and storage language that use ‘<’ and ‘>’ to label and distinguish sections of data or instructions from each other.
Organization
The remaining portions of this document are decomposed into four major sections, followed by references and a point of contact. The first section will provide an overall description of the project and the next part will give more detailed requirements. Following the requirements, there are models describing the application and the description/use of the prototype.
Overall Description
This section provides a high level description of the entire application. It describes the product perspective, functionality, and characteristics of an expected user, constraints, assumptions and dependencies, and the approportioning of requirements.
Product Perspective
This application is specifically designed for the Droid. There needs to be a database with all of the different patient’s EMR’s for the application to access. The interface will be made to have a similar look and feel that is consistent with other Droid applications. Most Droid applications have a similar way to display and navigate through data. The display that will be implemented by the PMR application will be consistent with other applications. This familiar GUI will make the user feel more comfortable navigating and viewing the data on our system.
Our PMR system is a part in a larger system. In figure 2.1 you will see that the health care worker is in charge of inputted the medical data to make an EMR. Once the EMR is made, it is stored on a secure database, refer to section 3, which our PMR can access. Once our application downloads this data, it provides the patient with an organized and easy way to navigate and view their medical record.
DatabasePMREMRHealth Care Provider
Patient
Figure 2.1

Product Functions
Provides a high-level view of the key types of medical information that includes medications, procedures, vaccinations, conditions, allergies, family history, test and lab results, insurance providers, and emergency contacts.
Provides a means to easily navigate, using the Droid’s touch screen interface and keyboard, to the details of any of the key types of medical information.
Provides access to different types of media for medical records including images, text-based documents, and scanned documents.
The user is able to backup a local copy of their PMR on their personal computer and edit it. This backup can be later transferred back to the phone if needed.
User Characteristics
The user should be familiar with the basic functionality of the phone. The user should be able to use the touch screen and the other navigation buttons along with the keyboard to input the data. The user will also have to know some basic medical terminology and information to understand the application and the different categories.
Constraints
One major constraint on the application is the amount of data that can be stored on the phone. The EMR’s on the server can contain large sized files, like images and scanned documents. These large files can quickly use up a lot of the space available on the Droid, so our application doesn’t save these files stored locally. Instead, a thumbnail is saved on the Droid and the user can choose to download the image if they feel it is important. This will save space by limiting the amount of images actually stored on the phone.
One other constraint is that this application will not work on other phones. This application will only work on the Android 2.0 operating system. The Motorola Droid is currently the only phone in production that supports Android 2.0.
Assumptions and Dependencies
Android 2.0 has a number of features that are included that we can assume our application can utilize. Some important features include a web browser, java support, video and camera, and touch-screen support. Our application will use all of these features and should work on any phone as long as it is running Android 2.0.
We can also assume that all input will only come in three forms, the touch screen, keyboard, and the other buttons found on the Droid. Since each phone has its’ unique buttons, we will only use these buttons to end the application and rely on the touch screen and keyboard to perform the rest of the applications navigation.
Approportioning of Requirements
One of the things the customer would like implemented is a more robust application on the computer. The computer side application will only have limited functionality to edit and view the PMR. Having a more robust system could offer better navigation, ability to see if a file on the Droid or server has changed, or many other features.
Another feature to be added will be an auto-sync feature. This will automatically update the PMR on either the Droid or computer whenever the EMR on the server has changed. It could do this automatically or could accept only certain changes.
As of now, to access the PMR on the Droid you need the correct username and password. Some customers might want their PMR to be more secure so there could be functionality added to improve the security. Some ways to improve security could be to add some biometric access, like finger print or iris scanning which is possible using the Droid, but not reliable as of yet.
Specific Requirements
This section provides further details on the specific requirements of our application.
Each requirement is given along with a description of the requirements.
Provide a high-level view of the key types of medical information: We will have a “front page” where basic medical data will be displayed. This front page is designed to be used in case of an emergency. If doctors would need to quickly obtain important medical data, like blood type or allergies to certain medications, they could look at this main page without having to log in. For security reasons, the user can hide whatever information they don’t want someone to see without logging in. They can go through and select whatever information they think is important on the front page, and hide whatever information they don’t want anyone to see.
Provide a means to easily navigate to the details of any major categories: there is a tabbed user interface where the major topics will be selectable. Once a category is selected, the screen will be refreshed to a separate page where all the relevant information will be displayed in an organized fashion.
Provide access to different types of media for medical records, including:
Text-based documents
Images (CT-scans, X-rays)
Scanned documents
Photographs
All of the above information will be stored on the server unless specifically downloaded by the user. A person’s medical record can contain dozens of pictures and scanned documents so this could take up a lot of space very quickly. For this reason, we allow users to download these different pieces of media if they think it is important, but don’t include it automatically to save space.
For each medical procedure, diagnosis, medication prescribed, there will be the following information stored with the entry:
A healthcare worker’s complete contact information
Date of event
Rationale for treatment/medication/diagnosis
Follow-up activities
As appropriate, any short-term or long-term side effects
As appropriate, any relationship to family history (ancestors and/or descendants).
This information is standard for any information provided by in the medical record, other than the basic information. There can be more information needed depending on the kind or medical information being provided, so wherever necessary there are more fields to input additional data. Below is a list of this additional information:
Medication - name, dosage, frequency, date prescribed and date ended.
Medical procedure - procedure type and date of procedure.
Vaccination - name and frequency.
Medical condition – name, diagnosis, symptoms, treatment, severity, onset date, and cured date.
Allergy - what you are allergic to, what kind of medication are you taking, if any, any other treatments you are receiving, and the severity of the allergy.
Lab and test results - the type of result, what hospital it was administered at, the results, and a link to the scanned document.
A means for a patient to record information (e.g., symptoms, context, photographs of condition): Sometimes the user will want to comment on the different pieces of information in the application. This is possible for any of the information stored on the phone or computer. Once the user comment on something, it is flagged as “Commented on by User” so the user’s doctor knows that this is not information provided by a doctor but by the patient. This is important so the doctor knows that all the other data is still reliable and he can trust that it can from a medical provider. These comments will be synced with the data on the database so whenever the user downloads the latest version of the data, the user will also get their comments.
Be able to backup information onto computer: At any point the user can connect the Droid phone to a computer, or use the computer application to download the data from the server directly. Once the medical record is on the computer, it provides a safe backup in the event that something happens to your phone. The PMR on the computer can also be synced with the medical record on the server if something is added or changed. If at any point the PMR on the Droid becomes corrupt or lost, the user can download the file on their computer and save it back to the phone.
Security: Some information is more private than the user’s personal medical history. With this in mind, the system seeks to maintain a high level of security. The security measures are separated into two domains: database/server security, and user authentication.
Database/Server
The data is separated into two groups, according to the sensitivity of the data, see figure 3.1. The first group will contain most of the basic information like name, address, phone number, etc. The second group will contain the more secure data like test results, medical condition, medications, etc. These groups are stored on separate servers, with a firewall in between them, as well as a firewall protecting the system as a whole. This multi-layer firewall approach allows the most sensitive data to be protected by multiple firewalls.
Figure 3.1
Direct access to the databases will be restricted by IP to the developers only. No one else will have direct access to the data.
Commercial anti-virus software will be employed on all servers.
Administrator and developer passwords must be changed every 14 days.
Developers will also use CryptoCard authentication tokens for one-use randomly generated passwords.
User Authentication
Users, defined as either patients or health care providers, will need to use username and password authentication to gain access to their data.
User passwords will require one or more uppercase letters, one or more lowercase letters, one or more numerical values, and one or more special characters (‘@’, ‘$’, ‘%’, etc.).
If no activity within the application is registered for a period of ten minutes, the user will be logged out automatically.
Modeling Requirements
To start use of the PMR, a doctor registers the patient and adds the patient's record to his/her database of patient medical records and the PMR database-server. A medical record consists of basic personal information (e.g. name, social security number, gender, blood type), insurance information, family history, emergency contacts and zero or more medical record entries. A medical record entry consists of text data (e.g. information on medications, vaccinations, x-rays and test results) and any images associated to that entry (see figure 4.1). All text-based data is stored both on the server and the Droid, while all non-text based data, such as images and any large files are stored only in the server; links to them are stored on the Droid device, and can be downloaded when in network for display or storage. Both physicians and patients can upload images or scans to associate with any entry and each image will be flagged as being uploaded by either the patient or the doctor. Only the health care provider can add or edit entries, but the patient can comment on any entry (see figure 4.2), and when the patient syncs their info to the database, the comments will be added to the server along side the entries for the doctor to view.
Sync is a function done by both the doctor and patient to update their records as well as the database’s records. When the health care provider syncs, they add the new and updated entries to the server and can update any comments made by the patient. Along with adding any comments made by them, when the patient syncs to the database they also receive the updated information that the doctor added (see figures 4.3 and 4.4). After syncing, the user can display the new info on their Droid, though syncing is not necessary when out of network; the Droid will just display the latest version of the medical record since the last sync. When displaying an entry, the patient can choose to download any images associated in the entry from the server by tapping on the link. The image can be displayed, copied, e-mailed or saved onto disk. If nothing is done with it, the image will remain in the Droid's memory until the patient logs off the PMR.
The patient can also backup the record by connecting the Droid to a laptop or desktop computer (see figure 4.4). The record will copy to a folder (or make one) as an xml encrypted document and will overwrite the previous copy. If any images are still in memory when syncing, the patient will have the option of backing those up as well.
Figure 4.1: Class Diagram. This illustrates the relationship between the Patient, Health Care Provider (both are Users), and the relationship between the different parts of a Medical Record.
System
Health Care ProvidernewRecordLoginPatientsyncbackupInfodownloadImagedisplayExtendseditInfouploadImageLogoffcommentInfoFigure 4.2: Use Case Diagram. The arrows point to what functions the patient and the healthcare provider can do within the PMR system.
sync()uploadImage(string filepath)sync()editBasicInfo()logoff()uploadImage(string filepath)login()editEntry(E)addBasicInfo()editInfo():Database:Computer:Basic Info:Entry:Medical Record:Patient:Health Care ProvidernewRecord()addEntry()
sync()Figure 4.4: Sequence Diagram for the Patient use cases. This shows the sequence of events and interactions between the patient and other members of the class diagram (figure 4.1). Here, the patient logs in, syncs any new information onto the Droid, displays an entry, downloads an image, comments on an entry, syncs the comment back to the database, backs up the record and logs out.returnXML()returnImage()display()sync()backupInfo()commentEntry()commentBasicInfo()commentInfo()downloadImage(image i)display()logoff()login():Database:Computer:Basic Info:Entry:Medical Record:Patient:Health Care Worker
The following diagrams (Figures 4.5 and 4.6) illustrate the behavior of our “Patient” and “Health Care Provider” classes, respectively. The Patient object initially executes the “login” function when starting the program, and enters the “Patient Logged In” state upon successful authentication. In this state, the Patient automatically executes the “sync” function, which updates the data on the Droid device to match that on the system’s database server (and if there is still unsaved Patient-edited data on the Droid device, uploads that data to the database). The Patient also executes the “display” function from this state automatically, which displays the data from the Patient’s medical record on the screen of the Droid device.
The Patient can also change his or her data from the “Patient Logged In” state in two main ways. First, the Patient can upload an image file and attach it to an entry in the medical record. This happens when the “UploadImage” function is executed by the user and the Patient enters the “Uploading Image” state. When the image has finished uploading, the Patient enters the “Local Patient Info Changed” state. Similarly, from the “Patient Logged In” state, the Patient can make a comment on an entry in the medical record when the “commentInfo” function is executed by the user and the Patient enters the “Commenting on Info” state. When the Patient finishes the comment, he or she enters the “Local Patient Info Changed” state, and the commented information is flagged as edited by the Patient. From the “Local Patient Info Changed” state, the Patient can execute the “sync” function to upload the data back to the database. The Patient can log out of the system from either the “Patient Logged In” or the “Local Patient Info Changed” states – in the latter, the changed data is stored on the Droid device until the Patient logs in again.
Figure 4.5
Figure 4.6 shows the state diagram for the Health Care Provider class. Initially, the Health Care Provider logs into the system using the “login” function and enters the “HC Provider Logged In” state upon successful authentication. A Health Care Provider can add a new Patient to the system from here by executing the “addPatient” function from the interface. The Provider can also display a patient’s medical record from this state. When a Provider begins editing the data in a Patient’s medical record, the “EditInfo” function is executed and the Provider enters the “Editing Info” state. When the editing is complete, the Provider executes the “syncInfo” function, and returns to the “HC Provider Logged In” state. The Provider can also log out of the system from this state by executing the “Logoff” function.
Figure 4.6
Prototype
The prototype of this Android application will encompass the basic functions of the completed application. This will include most of the features on the Droid phone, as well as the form used by a health care provider. The main functions on the Droid will include downloading a data file from the server, viewing the file in separate categories, and editing sections of the data file. The application will also include buttons to upload the data files to both the server and a PC as a backup file. The server side will include a template located online to input information that will generate an XML based file. This file will then be downloaded by the application on the phone when it is started. The server will also contain example pictures and/or medical documents that will be viewable on the phone.
How to Run Prototype
The primary way to view this application is to download the Android emulator to your home or office computer. Windows, Mac, and Linux systems are all able to access this emulator. You will find information that will help you download and install the emulator at . You will need to download an SDK tool to run the emulator. The Motorola Droid is running SDK 2.0, which is what the application has been running on. There are more links under the SDK tab on the android development website that will further assist you in downloading and installing the emulator. Source code for this application will be located on the project website under the Prototype section .
A Microsoft Powerpoint presentation has been set up if this option is not feasible for you. The link to this presentation is . This presentation provides screen captures of each of the viewable screens on the application.
Sample Scenarios
If a doctor wants to add a patient to the PMR database, the doctor will have to go to the form. Figure 5.2.1 shows the first blank screen that a doctor would see.
Figure 5.2.1
To add information, the doctors will have to simply type in the information. Figure 5.2.2 represents input for the basic information such as name and address.
Figure 5.2.2
For basic info, all they need to do is type in the information. However, entries such as medications or vaccinations, they need to click on “Add (Entry name)” to add the info to the output file. Figure 5.2.3 shows where the button is.
Figure 5.2.3
After inputting all the data, doctors will then save the information to a file the server by clicking on “Submit All” button. This button will save the information as an XML file. Figure 5.2.4 shows where the “Submit All” button is.
Figure 5.2.4
Since the data was saved in the server, the client will have access to this data. When the patient first open up the application, the patient will see a screen that looks like Figure 5.2.5.
Figure 5.2.5
Since the user did not log in yet, everything but Basic Information and Emergency Contacts will be disabled. To log in and see the patient’s information, the patient will click the “Login” button. Figure 5.2.6 shows the login screen.
Figure 5.2.6
After logging in the patient will have complete access to the application. Figure 5.2.7 shows the unlocked main screen.
Figure 5.2.7
Now the patient wants to see their basic information. All they need to do is click on the basic information to go to basic information screen. Figure 5.2.8 shows the basic information screen.
Figure 5.2.8
In this case, the patient’s name is John Smith, not John Doe as shown in Figure 5.2.9. This means that the patient needs to comment or edit the last name. To do so, the patient will click on Edit button to go to the edit screen shown in Figure 5.2.9.
Figure 5.2.9
After changing the name, the user has two options. The first option is to click the button “Return with Unchanged Data” and have all changes reverted. The second option is to click the “Done Editing” button to change the data as shown in Figure 5.2.10
Figure 5.2.10
References
“Download the Android SDK” Android Developers 2009 Android http://developer.android.com/sdk/index.html
CRC. “Update on Meaningful Use” CRC Healthcare. November 2009
PIH Model Online. “EMR Benefits, Challenges and Uses”
Ilie, Virginia, Courtney, James, and Slyke, Craig. “Paper vs. Electronic: Challenges Associated with Physicians’ Usage of Electronic Medical Records”. Hawaii International Conference on System Science. 2007
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.

http://www.cse.msu.edu	13
http://www.health.medicbd.com	2
http://alef.fiit.stuba.sk	1

Software Requirements Specification Final

by jangjong

Accessibility

Categories

Upload Details

Usage Rights

3 Embeds 16

Statistics